AssumeUTXO

Pedro inicia su primer Full Node, un programa que comprueba las reglas de Bitcoin por sí mismo. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Un arranque normal exige recorrer primero un largo historial. AssumeUTXO permite partir de un conjunto UTXO preparado: las salidas de transacciones aún no gastadas, cada una con una cantidad y las condiciones para gastarla. La instantánea recoge el estado después de un bloque concreto. No es el archivo de todos los pagos ni demuestra que el ordenador de Pedro ya haya verificado todo el pasado. [1] [3]

El nombre de un archivo no basta para declarar correcta una instantánea. Al cargarla mediante loadtxoutset, Bitcoin Core v29.0 comprueba el formato, el bloque base (el bloque al que corresponde la instantánea) y los parámetros admitidos. También calcula el hash del contenido UTXO, una huella criptográfica, y lo compara con el valor esperado antes de activar el estado cargado. Un contenido modificado no supera la comprobación solo porque su archivo tenga un nombre que inspire confianza. [2] [3] [6]

Tras aceptar la instantánea, el nodo continúa desde ese estado, verifica los bloques posteriores y puede alcanzar el extremo actual de la cadena. No los acepta sin comprobarlos: sigue verificando, por ejemplo, las condiciones de gasto y la creación permitida de nuevos bitcoins. La ventaja es que este recorrido hasta la actividad presente no tiene que esperar a que termine el historial anterior. Eso no significa que el historial antiguo ya se haya verificado localmente. [1] [6]

Al mismo tiempo se construye un segundo estado a partir de los bloques históricos, desde el comienzo hasta la base de la instantánea. Es un cálculo independiente a partir del historial, no otra copia del inventario descargado. Durante un tiempo el programa mantiene dos estados con avances distintos. El comando técnico getchainstates permite verlos; que el estado activo alcance los últimos bloques no confirma por sí solo que haya terminado el trabajo en segundo plano. [1] [8]

El hash esperado y el bloque base admitido forman parte de una versión concreta del programa. Hasta que el nodo de Pedro recorra el historial por sí mismo, depende de que ese dato incorporado sea correcto. Comparar hashes permite comprobar si los contenidos coinciden, pero no demuestra por sí solo que procedan de un historial válido. Si el estado esperado fuera erróneo, el uso anticipado del nodo se apoyaría en esa suposición incorrecta. Por eso no hay que confundir la verificación histórica posterior con la comprobación del archivo al cargarlo. [2] [6]

El archivo puede proceder de otro operador, pero eso no le da autoridad para decidir qué estado se acepta. Lo decisivo es que coincida con el valor admitido por el programa, no la promesa del proveedor. Tampoco se admite cualquier instantánea de cualquier bloque: depende de la versión y de la red. La comprobación del hash no garantiza que el proveedor entregue el archivo ni evita que descargarlo y procesarlo consuma tiempo, conexión y disco. [2] [4] [7]

Cuando el trabajo en segundo plano llega al mismo bloque base, el nodo calcula el hash del conjunto UTXO que ha construido y lo compara con el hash esperado de la instantánea. No compara el estado de hoy con una fotografía antigua: ambos representan el mismo punto del historial. Si no coinciden, la implementación aquí descrita detiene el nodo y deja de usar el estado derivado de la instantánea. No oculta la discrepancia ni la presenta como una verificación satisfactoria. [1] [6]

AssumeUTXO cambia principalmente el tiempo necesario para disponer de un nodo utilizable. La descarga y la verificación históricas continúan, y temporalmente se mantienen dos bases de datos de estado. Eso requiere procesador y actividad de disco. Un Pruned Node ahorra espacio al borrar archivos de bloques antiguos ya procesados; no omite la comprobación de las reglas. Un Pruned Node también puede usar una instantánea, pero el ahorro de almacenamiento tiene sus propias limitaciones. Algunos índices auxiliares deben recorrer el historial desde el principio, así que el nodo puede estar disponible antes sin que todas las aplicaciones conectadas estén listas. [5] [7]

El conjunto UTXO contiene información sobre salidas no gastadas, no las claves privadas que autorizan el gasto. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. El conjunto UTXO no es una copia de seguridad de la cartera ni restaura una Seed Phrase perdida, las palabras de recuperación de una cartera que utiliza este método. Los pagos antiguos tampoco tienen por qué aparecer de inmediato: encontrarlos puede exigir bloques anteriores a la instantánea. Respaldar claves, buscar el historial de una cartera y verificar el estado de la red son tareas distintas. [1] [7]

Los nombres parecidos pueden confundir. AssumeUTXO parte de un estado cargado y reconstruye el historial anterior en segundo plano. En cambio, assumevalid puede omitir bajo ciertas condiciones parte de las comprobaciones históricas de scripts, es decir, de las condiciones de gasto, incluidas las firmas. Es una optimización independiente que también puede afectar a esa verificación histórica; terminar AssumeUTXO no demuestra que estuviera desactivada. Al leer instrucciones, distingue desde dónde arranca el nodo, qué comprueba y cuándo termina cada comprobación. [5] [6]