Glosario / Nodos y software
Sincronización headers-first
- ¿Qué es la sincronización headers-first?
- La sincronización headers-first (primero los encabezados) es la estrategia de arranque en la que un nodo descarga y verifica toda la cadena de encabezados de 80 bytes antes de solicitar el cuerpo de ningún bloque, y luego descarga esos cuerpos en paralelo.
Dividir la descarga en dos es lo que hace viable una primera sincronización. Bitcoin Core funciona así desde la versión 0.10.0, publicada en febrero de 2015, que convirtió la descarga de bloques, hasta entonces una única cola ordenada, en una tarea repartida entre todos los pares conectados. Si usted ejecuta su propio nodo para verificar su propio saldo, esta es la razón de que la sincronización inicial termine en horas y no en días.
Cómo funciona
La sincronización headers-first empieza pidiendo a los pares encabezados, no bloques.
El nodo envía un mensaje getheaders que lleva un localizador de bloques, una lista compacta de hash que describe dónde cree estar en ese momento. Un par responde con un mensaje headers que contiene hasta 2.000 encabezados de 80 bytes cada uno, así que una respuesta cubre aproximadamente dos semanas de cadena. Para cada encabezado, el nodo comprueba que apunta a un bloque padre que ya tiene y que su hash cumple la dificultad que declara su campo nBits, y luego vuelve a preguntar desde la nueva punta hasta que ningún par tiene nada más reciente que ofrecer.
Solo cuando ese esqueleto está en su sitio empieza la descarga de los cuerpos. Como el nodo ya conoce el hash de cada bloque que quiere, puede solicitar tramos distintos a varios pares al mismo tiempo en lugar de hacer cola detrás de una sola conexión. Bitcoin Core limita cuántas solicitudes de bloques deja pendientes con un mismo par, dieciséis en el código actual, y desconecta a un par que hace que la ventana se estanque. Los bloques que llegan antes que sus bloques padre simplemente se retienen, lo que puso fin a la vieja costumbre de guardar temporalmente en el disco datos sin verificar.
Dos salvaguardas viajan con los encabezados. El software no adoptará una cadena hasta que los encabezados que tiene sumen más prueba de trabajo acumulada que una cifra mínima compilada en la versión, de modo que un par no puede atraer a un nodo recién instalado hacia una rama alternativa barata hecha de bloques fáciles. Por otra parte, la opción assumevalid nombra un hash de bloque reciente que viene con cada versión: las firmas de los bloques enterrados bajo él no se vuelven a verificar, lo que ahorra horas de cálculos de curva elíptica mientras se sigue haciendo cumplir cada regla que depende del estado actual de la cadena.
Dónde aparece
La sincronización headers-first se manifiesta como dos contadores que no coinciden mientras un nodo se pone al día.
Ejecute la llamada RPC getblockchaininfo durante una primera sincronización y el campo headers irá muy por delante del campo blocks, a menudo por cientos de miles. El cliente gráfico dice lo mismo en lenguaje llano: solo puede estimar una hora de finalización una vez que han llegado los encabezados, porque hasta entonces no sabe cuánto camino le queda por recorrer. Ver cómo convergen esos dos números es la barra de progreso honesta.
El software ligero se detiene deliberadamente tras la primera mitad. Una billetera SPV, un cliente de filtros compactos o un nodo Lightning que funciona sin su propio backend de cadena guarda solo encabezados y superpone sobre ellos pruebas de Merkle o filtros. Esa es toda la razón por la que una billetera de teléfono puede comprobar su propio historial con datos móviles: los encabezados son pequeños y de tamaño fijo, y los cuerpos de los bloques no son ni lo uno ni lo otro.
Sincronización headers-first frente a sincronización blocks-first
La sincronización headers-first aprende la forma de la cadena antes de descargar su contenido, mientras que la sincronización blocks-first (primero los bloques) intentaba hacer ambas cosas a la vez. El método antiguo enviaba un mensaje getblocks, recibía un mensaje inv con no más de 500 hash de bloque y los descargaba de uno en uno del par que respondiera, así que una sola conexión lenta frenaba todo lo que venía detrás. Lo que llegaba desordenado no tenía otro sitio donde quedarse que una reserva de espera en memoria que un atacante podía llenar de basura. Bitcoin Core no sincroniza así desde la 0.10.0, aunque sigue entendiendo esos mensajes para que el software más antiguo pueda comunicarse con él.