Assumeutxo

La instantánea enumera cada moneda gastable a una altura de bloque concreta, y su hash está compilado en el software en lugar de descargarse con él. Bitcoin Core 28.0 añadió parámetros de la mainnet para la altura 840.000, la primera altura para la que se puede cargar una instantánea en la red real. Su billetera se puede usar mucho antes de que se haya comprobado todo el historial, mientras el nodo verifica discretamente, por detrás, los bloques omitidos.

Cómo funciona

Assumeutxo divide un nodo en dos estados de la cadena (chainstate) y los ejecuta a la vez.

Se entrega un archivo de instantánea a la llamada RPC loadtxoutset. Bitcoin Core crea un segundo estado de la cadena en el que cargarlo y mantiene activo el original mientras se lee y se comprueba el contenido. Una vez cargado y validado, el estado de la cadena de la instantánea pasa a ser el activo, aparece un directorio llamado chainstate_snapshot en el directorio de datos y el nodo empieza a sincronizar desde el bloque base de la instantánea hacia la punta de la red. Dentro de ese directorio hay un pequeño archivo llamado base_blockhash, que registra en qué bloque se tomó la instantánea, de modo que la configuración sobrevive a un reinicio.

Toda la cuestión de la confianza se reduce al hash. La propia documentación de Core afirma que no existe una fuente canónica de instantáneas y que cualquier instantánea que usted descargue se comprueba contra un valor escrito en el código fuente. Por tanto, usted no está confiando en quien alojó el archivo. Está confiando en la misma versión que ya eligió ejecutar, y un archivo cuyo hash no coincide con el valor compilado se rechaza antes de llegar siquiera a ser su estado de la cadena.

Mientras tanto, el estado de la cadena original sigue avanzando trabajosamente desde el bloque génesis con todas las reglas aplicadas. Cuando alcanza el bloque base de la instantánea, calcula el hash de su propio conjunto de UTXO y compara el resultado con el parámetro compilado. La caché se asigna a la cadena que más la necesite: la cadena de la instantánea tiene prioridad mientras corre hacia la punta, y después la cadena en segundo plano recibe la mayor parte. La llamada RPC getchainstates muestra los dos estados de la cadena.

La limpieza ocurre en el siguiente reinicio y no de inmediato. Core cambia el nombre de chainstate_snapshot a chainstate, elimina los datos en segundo plano y, desde ese momento, el nodo es indistinguible de uno construido de la forma tradicional. El archivo base_blockhash permanece como registro de dónde empezó.

Por qué importa cuando compra bitcoin

Assumeutxo ataca el único inconveniente que impide a la mayoría de los compradores validar sus propias monedas.

De las 41 billeteras reseñadas en este sitio, Bitcoin Core es la única que descarga y comprueba por sí misma la cadena completa, y por eso nuestra reseña le da un 4,7 y aun así señala como su primer inconveniente que la primera sincronización descarga y verifica toda la cadena, lo que cuesta horas y mucho espacio en disco. Esa frase es la razón por la que la mayoría de la gente nunca lo intenta. Una instantánea no hace desaparecer el costo, lo traslada: las horas siguen ahí, solo que transcurren cuando su billetera ya funciona y no antes.

El momento en que esto compensa es el retiro. Usted compra en uno de los 63 exchanges registrados en este sitio, envía las monedas a claves que controla y luego quiere saber que llegaron. Sin un nodo propio, las dos partes a las que puede preguntar son el exchange que acaba de enviarlas y un explorador de bloques público que ahora conoce su dirección. Con uno, la respuesta sale de una aritmética que realizó su propia máquina.

También cambia lo que cuesta poner en marcha una configuración seria. Nuestra reseña de Sparrow, también con un 4,7, describe la conexión directa a Bitcoin Core como backend, y esa combinación solía implicar esperar a que terminara una sincronización completa antes de que Sparrow tuviera algo con lo que hablar. Una instantánea comprime el día de configuración en una tarde aprovechable, y la verificación que usted aplazó termina por sí sola mientras duerme.

Ejemplo práctico: generar una instantánea con dumptxoutset

Generar una instantánea de assumeutxo es un procedimiento deliberado en un nodo en el que usted ya confía, no un archivo que se va a buscar.

La genera la llamada RPC dumptxoutset, ya sea en la punta actual con el tipo "latest" o a una altura reciente con el tipo "rollback". Durante la mayor parte del tiempo que se ejecuta, el nodo permanece en un estado temporal que no refleja la realidad, en el que marca como inválidos bloques que sabe que son correctos, y, a causa de ese estado, la actividad de red se desactiva y se desconecta a todos los pares. La documentación de Core recomienda -rpcclienttimeout=0 porque el volcado tarda bastante sea cual sea el hardware y el tipo que se haya elegido, y desaconseja usar el nodo para cualquier otra cosa mientras tanto.

Dos detalles sorprenden a la gente. Una instantánea solo se puede usar si su altura ya tiene un hash incluido en los parámetros de la cadena, así que elegir cualquier otra altura supone editar ese código y recompilar, y el tipo "rollback" sirve también para comprobar un hash escrito en el código, regenerando la instantánea y comparando. Y Bitcoin Core 28.0 cambió la serialización: los volcados en el formato antiguo ya no se admiten y hay que recrearlos en un nodo con la 28.0 o posterior antes de que loadtxoutset los acepte.

Bitcoin Core 29.0 añadió una herramienta relacionada, contrib/utxo-tools/utxo_to_sqlite.py, que convierte una instantánea con serialización compacta en una base de datos SQLite3. Eso no tiene nada que ver con sincronizar un nodo y todo que ver con lo que es en realidad una instantánea: una imagen completa y autónoma de quién posee qué a una altura concreta, que resulta ser algo útil de consultar.

Assumeutxo frente a descarga inicial de bloques

Assumeutxo no reemplaza la descarga inicial de bloques, cambia el orden en que se hace el trabajo.

Un nodo que cargó una instantánea sigue realizando una descarga inicial de bloques completa desde el bloque génesis en su estado de la cadena en segundo plano, que es el encargado de la validación completa del tramo de cadena que la instantánea le permitió dar por supuesto. No se omite nada de forma permanente. Lo que consigue la instantánea es que la billetera deje de ser inútil durante la espera, porque el estado de la cadena activo ya conoce el estado actual de cada dirección que a usted le interesa. La región entre el bloque génesis y la altura de la instantánea se registra como presuntamente válida en lugar de contarse discretamente como verificada, y por eso Core mantiene dos estados de la cadena en vez de un indicador en uno solo. Un nodo que cargó una instantánea y nunca terminó la sincronización en segundo plano está en un estado real y con nombre, no en uno oculto.

Assumeutxo frente a un nodo podado

Assumeutxo y la poda reducen ambos lo que un nodo tiene que gestionar, y reducen cosas opuestas.

La poda tiene que ver con el disco después de la validación: un nodo podado comprueba cada bloque y luego elimina los archivos en bruto que ya no necesita. Assumeutxo tiene que ver con el tiempo antes de la validación: aplaza comprobaciones que aun así llevará a cabo. Los dos se combinan, y Core flexibiliza una de sus propias reglas para permitirlo. El piso habitual de -prune es 550 MiB, y un nodo que carga una instantánea ignora ese mínimo y usa en su lugar al menos 1100 MiB. El espacio no es la única partida: mientras se ejecuta la sincronización en segundo plano hay temporalmente dos directorios de estado de la cadena, cada uno de varios gigabytes y que probablemente acabará siendo más grande que la instantánea que usted descargó.

En los índices es donde más divergen los dos. Un índice no gana nada con una instantánea, porque los índices siempre empiezan a construirse desde el bloque génesis y solo pueden aplicar los bloques en orden, así que un índice alcanza la punta solo cuando la validación en segundo plano ha llevado al nodo más allá del bloque de la instantánea. La poda lo agrava: un índice, si es que admite la poda, solo permite al nodo eliminar bloques que ya ha indexado, así que una instantánea antigua deja en el disco un cúmulo de bloques descargados, sin indexar e imposibles de eliminar hasta que la indexación se pone al día.