Sincronización blocks-first

Ya nadie sincroniza así, y la razón es aritmética. Una descarga estrictamente secuencial no puede aprovechar más velocidad de subida que la de un solo par, y ya en 2015 la cadena era demasiado grande para que eso terminara en un tiempo razonable. La técnica sobrevive como alternativa en el protocolo y como fuente de confusión en la documentación antigua.

Cómo funciona

Estado: la sincronización blocks-first fue reemplazada por la sincronización headers-first (primero los encabezados) en Bitcoin Core 0.10.0, publicada el 16 de febrero de 2015. Los mensajes que usaba siguen formando parte del protocolo entre pares y siguen recibiendo respuesta, pero ningún cliente actual depende de ellos para ponerse al día.

El intercambio era un bucle entre dos máquinas. Su nodo enviaba un mensaje getblocks con los hash de los bloques que ya tenía. El par respondía con un inventario que enumeraba hasta 500 hash de los bloques que seguían. Su nodo solicitaba esos bloques con el mensaje getdata, los recibía, validaba cada uno por completo y luego enviaba otro mensaje getblocks para preguntar qué venía después. Repita esto varios miles de veces.

De ese diseño salieron tres problemas. No había paralelismo, porque no tenía sentido solicitar a un segundo par bloques de cuya existencia aún no se tenía noticia, así que toda la sincronización avanzaba a la velocidad del par con el que se estuviera hablando en ese momento. No había forma de saber cuánto faltaba, ya que la cadena se iba revelando 500 hash cada vez, y por eso los clientes antiguos no podían mostrar una barra de progreso significativa. Y un par lento u hostil podía simplemente entregar los bloques con cuentagotas, sin que su nodo tuviera una forma barata de saber que había una cadena mejor disponible en otra parte.

La sincronización headers-first resolvió los tres problemas separando la evidencia barata de la cara. Al descargar y verificar primero la cadena de encabezados, que en diciembre de 2014 ocupaba 27 megabytes para todo el historial, se conocen tanto la forma de la mejor cadena como su longitud antes de descargar una sola transacción. Después, los cuerpos de los bloques pueden solicitarse a muchos pares a la vez. El efecto secundario fue que los bloques empezaron a llegar desordenados y a escribirse en el disco desordenados, y por eso el directorio de datos que crea la versión 0.10.0 no puede leerlo ningún software anterior.

Dónde aparece

Usted se encontrará con la sincronización blocks-first en la documentación más que en el software.

El material de referencia escrito antes de 2015, incluida buena parte del material para desarrolladores que aún circula, describe el bucle secuencial como si así funcionara bitcoin. No es así, y las páginas que describen una sincronización inicial como una descarga secuencial desde un solo par simplemente están desactualizadas. Bitcoin Core sigue atendiendo las solicitudes getblocks en beneficio de clientes muy antiguos o poco comunes, así que los mensajes aparecen en capturas de paquetes y en especificaciones del protocolo.

Para quien ejecuta un nodo hoy no hay nada que configurar ni nada que elegir. Su cliente descarga primero los encabezados porque así lo hace toda implementación mantenida.

Sincronización blocks-first frente a sincronización headers-first

La sincronización blocks-first y la sincronización headers-first se diferencian en lo que solicitan primero, y todo lo demás se desprende de ello. La sincronización blocks-first solicitaba bloques completos en secuencia y aprendía la forma de la cadena sobre la marcha, así que descubría la mejor cadena y la descargaba en la misma pasada lenta. La sincronización headers-first divide el trabajo: establece qué cadena acumula más prueba de trabajo usando 80 bytes por bloque y después reúne los cuerpos de los bloques en paralelo de quien quiera enviarlos. La validación aplicada a cada bloque es idéntica en ambas. Lo que cambió fue el orden de los pasos, y eso por sí solo redujo una sincronización inicial de semanas a horas.