Initial Block Download, o IBD, es la sincronización inicial de un nodo de Bitcoin. En el procedimiento habitual, obtiene bloques antiguos, los comprueba según las reglas de su software y construye un registro actual de los fondos aún no gastados.
Pones en marcha un Full Node en casa: un programa que comprueba de forma independiente los bloques y las transacciones de Bitcoin. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Los demás participantes ya cuentan con una larga historia; tu nodo nuevo todavía no la tiene. Primero obtiene las cabeceras, registros breves que enlazan los bloques. También contienen Proof of Work, evidencia de trabajo computacional. Los mineros buscan esa prueba repitiendo cálculos; los demás pueden comprobar rápidamente el resultado. Las cabeceras se parecen al índice de un libro: ayudan a orientarse, pero tenerlo no significa haber leído y comprobado todas las páginas. [1] [7]
Si los vecinos ofrecen distintas ramas de la historia, el nodo no cuenta votos. Las cabeceras permiten comparar el trabajo computacional acumulado y elegir una candidata para seguir verificándola. Más bloques no implican necesariamente más trabajo. Y ni siquiera mucho trabajo exime a las transacciones inválidas de cumplir las reglas: el contenido de la rama elegida todavía debe comprobarse. [1] [2] [6]
El nodo puede obtener bloques de varios vecinos a la vez, sin depender de la velocidad de un único remitente. Pero para incorporarlos a su historia validada necesita conocer el estado anterior. Las entradas de un pago hacen referencia a importes anteriores que pretende gastar. El nodo debe comprobar que existen y que no se han gastado ya. Por eso, un bloque posterior ya descargado puede esperar a que se procese otro anterior. Descargar los datos no equivale a terminar la sincronización. [1] [2]
El nodo compara el contenido del bloque con la huella de las transacciones incluida en su cabecera y calculada mediante un Merkle Tree. También revisa, por ejemplo, la secuencia de gastos y que la recompensa del minero no supere lo permitido. Aplica las reglas vigentes en ese punto de la historia. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Las comprobaciones antiguas de firmas y condiciones de gasto tienen una configuración especial, assumevalid, explicada más abajo. Las cabeceras o un archivo de un vecino aparentemente fiable no sustituyen este conjunto de controles. [2] [3]
Al procesar cada bloque, el nodo elimina las salidas gastadas y añade las nuevas. Una salida es una cantidad concreta con condiciones para utilizarla después. Si todavía no se ha gastado, se llama UTXO. El conjunto de estas salidas permite verificar el siguiente pago sin recorrer otra vez toda la historia. No es una lista de cuentas bancarias ni una copia de todas las transacciones antiguas. [2] [3]
Bajo ciertas condiciones, Bitcoin Core puede omitir comprobaciones antiguas de scripts: firmas y otras condiciones de gasto. La opción assumevalid identifica un bloque conocido cuya historia se ha verificado externamente; también importan sus antecesores, el trabajo suficiente y la profundidad. Las demás comprobaciones necesarias se mantienen, pero se da por válido parte del resultado. Una suposición incorrecta, por tanto, no está exenta de riesgo. assumevalid=0 desactiva esta optimización a cambio de más trabajo para tu ordenador. [2]
Un Pruned Node elimina los archivos de bloques antiguos después de procesarlos, conservando los UTXO actuales y otros datos necesarios. Durante el IBD habitual sigue obteniendo y procesando la historia; simplemente no la almacena entera de forma permanente. Ahorra espacio en disco, no automáticamente datos en la descarga inicial. Una tarea posterior que necesite bloques eliminados puede obligar a obtenerlos de nuevo. [2] [7]
Bitcoin Core v29.0 tiene en cuenta, entre otros factores, la antigüedad del último bloque aceptado, un mínimo de trabajo acumulado y el estado de carga. Cuando este indicador operativo pasa a false (que indica que la sincronización inicial ha terminado), no vuelve a true (que indica que sigue en curso) durante esa misma ejecución. Orienta el comportamiento del programa; no demuestra que no exista un bloque más reciente en alguna parte. Perder la conexión después tampoco lo convierte en un indicador fiable de actualización. [2] [5]
Una conexión rápida ayuda, pero el ordenador también debe calcular y escribir en disco. Influyen el procesador, la memoria, el almacenamiento y la disponibilidad de los vecinos. En la salida técnica de getblockchaininfo, verificationprogress estima el avance de la validación: no promete cuántos minutos quedan ni indica simplemente la proporción de bytes descargados. Tras cerrar correctamente el programa, al volver a arrancarlo se puede continuar desde el progreso guardado sin empezar todo de cero. [5] [7]
AssumeUTXO permite utilizar una instantánea compatible de UTXO: un estado guardado en un bloque determinado. El software compara su contenido con una huella esperada y puede alcanzar antes el presente desde ese estado mientras procesa la historia en segundo plano. Después también compara el estado obtenido mediante esa validación histórica. No se trata de cualquier base de datos entregada por un desconocido ni de evitar para siempre verificar el pasado. Poder usar el nodo antes y haber terminado de validar toda la historia son hitos distintos. [4] [8]
Para obtener la imagen más completa, lee esta entrada junto con Pruned Node, AssumeUTXO, Block Propagation, Compact Blocks, Bitcoin, Bitcoin Core. También enlazan con esta entrada Block Propagation, Compact Blocks, Pruned Node, AssumeUTXO.