Ponerse al día: full, fast y warp sync; light clients

Una billetera móvil muestra el saldo de una cuenta en una cadena construida con Substrate (Polkadot SDK). Para obtenerlo, consulta un endpoint JSON-RPC público. Un día, el operador de ese endpoint se queda atrás por un problema de disco y la billetera muestra un saldo de hace dos horas. Nadie mintió, pero la aplicación no tenía forma de saberlo: aceptaba lo que el servidor respondía.

El mismo día, un equipo de infraestructura levanta un validador nuevo para una cadena que lleva un año en producción. Re-ejecutar cada bloque desde el génesis tardaría días. Las dos situaciones plantean la misma pregunta: ¿cómo llega un participante nuevo al estado actual sin confiar ciegamente en quien le entrega los datos? Este capítulo responde con las tres familias de sincronización de Substrate y con los light clients, que se apoyan en las justificaciones de GRANDPA y en las pruebas del trie de estado.

Tres maneras de ponerse al día

La especificación de Polkadot, que describe el protocolo que implementan los nodos de Substrate, reconoce que no todos necesitan lo mismo: un validador necesita el estado completo; un light client solo quiere verificar afirmaciones puntuales, como un saldo. Por eso "different types of synchronization protocols are available, respectively Full, Fast, and Warp sync suited for different needs." [1]

Full sync es el modo por defecto. Escucha los anuncios de bloques nuevos y responde pidiendo "the blocks from the announcing peers or just the block headers in case of light clients". [1] Un nodo completo que sincroniza así descarga cada bloque y lo re-ejecuta. Es el modo más lento y el que menos confía en terceros: si un peer manda un bloque inválido, la re-ejecución lo delata.

Fast sync baja primero el historial de cabeceras "and validating the authority set changes" hasta llegar a una cabecera reciente; después descarga el estado de ese bloque y, al terminar, "the node will automatically switch to a full sync". [1] Se ahorra re-ejecutar la historia, pero todavía recorre todas las cabeceras.

Warp sync va más lejos: "only downloads the block headers where authority set changes occurred, so-called fragments", y las acepta "by verifying the GRANDPA justifications". [1] Según la especificación, "This protocol allows nodes to arrive at the desired state much faster than fast sync." [1] La siguiente sección explica por qué ese salto es seguro.

La especificación también aclara que los modos se combinan: full sync "usually downloads the entire chain", pero si una implementación solo quiere el último estado finalizado puede combinarlo con fast o warp sync. [1]

Warp sync: saltar de un conjunto de autoridades al siguiente

Recordemos dos piezas del capítulo anterior. Una justificación GRANDPA es un conjunto de precommits firmados por una supermayoría del conjunto de votantes. Y los cambios de conjunto se anuncian en cabeceras y se aplican al finalizar el bloque de traspaso. Con esas dos piezas, la cadena de confianza de warp sync se arma sola.

El nodo empieza conociendo el conjunto de votantes del génesis, porque está en el chain spec. Pide el primer fragmento: la cabecera donde ese conjunto entregó el mando, con su justificación. Verifica las firmas contra el conjunto que ya conoce. Si son válidas, esa cabecera está finalizada, y en ella está escrito cuál es el conjunto siguiente. Repite el paso con el nuevo conjunto hasta llegar al último bloque finalizado.

Figura 1

Full sync, warp sync y una consulta verificada

Fuentes:

[1][2]

Cómo leer esta figura

Arriba, una fila de diez bloques encadenados bajo el título full sync: descarga y re-ejecuta cada bloque. En medio, bajo el título warp sync, solo cuatro cabeceras: G, el génesis, H1, H2 y Hf, unidas por flechas verdes etiquetadas como justificación del conjunto V0, V1 y V2. Bajo Hf se indica último finalizado, raíz de estado r. Abajo, una secuencia de tres recuadros: el light client pregunta un saldo a un nodo completo, recibe la respuesta más una prueba de Merkle pi, y acepta si pi lleva a r; una línea punteada une la raíz r con ese último recuadro.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La cantidad de trabajo ya no depende de cuántos bloques tiene la cadena, sino de cuántas veces cambió el conjunto de autoridades. En una red con una rotación por época, eso son órdenes de magnitud menos que la cantidad de bloques. Lo que no se verifica es la ejecución: el nodo acepta el estado al que llegó la mayoría que firmó, no lo recalcula. Por eso la especificación advierte que "Warp sync is primarily designed for Light Clients" y que, usado por nodos completos, "the sync process may lack information to cater to complete functionality set of full nodes." [2]

En la práctica, un nodo completo que arranca con warp sync suele seguir después con una descarga del estado y del historial en segundo plano; el detalle exacto de ese proceso en la versión actual del nodo queda a validar.

Lo que la red tiene que conservar

Warp sync solo funciona si alguien puede servir las justificaciones de cada traspaso. Un nodo que poda bloques antiguos para ahorrar disco podría borrarlas. El crate de GRANDPA trae un filtro de poda pensado para eso, con un comentario explícito: "GRANDPA justifications at authority set change boundaries are needed to construct warp sync proofs." [3]

El solochain template lo usa: registra GrandpaPruningFilter en la configuración de la base de datos y crea un proveedor de warp sync a partir del conjunto de autoridades compartido de GRANDPA, sc_consensus_grandpa::warp_proof::NetworkProvider. [4] Si construyes un servicio de nodo propio y olvidas ese filtro, tus nodos sincronizarán bien pero no podrán ayudar a otros a hacer warp sync.

Esto tiene una consecuencia para quien cambie el motor de finalidad. Toda la cadena de confianza de warp sync está hecha de justificaciones GRANDPA. El capítulo de investigación sobre HotStuff y la sincronización en Substrate analiza qué hay que reemplazar cuando la finalidad deja de ser GRANDPA: sin un equivalente verificable, el catch-up rápido pierde su ancla.

Light clients: verificar en vez de confiar

Un light client no guarda el estado ni re-ejecuta bloques. Sincroniza cabeceras y verifica pruebas. La documentación de Polkadot lo presenta como "a trust-minimized alternative to JSON-RPC by verifying data through cryptographic proofs rather than blindly trusting remote nodes." [5] La implementación de referencia es smoldot, que la misma documentación describe como "the cornerstone of light client implementation for Polkadot SDK-based chains." [5]

La especificación fija dos requisitos de seguridad. Uno para arrancar: "The probability that an adversarial full node convinces a light client of a forged blockchain state is negligible." Otro para consultar: la probabilidad de que un adversario lo convenza de aceptar un estado de cuenta falsificado también debe ser despreciable. [2]

El primero se cumple con warp sync. El segundo, con la raíz de estado. Como explica la especificación, el light client no descarga el estado; envía la consulta a un nodo completo "and only the response of the full node is validated using the hash of the state root." [2] El nodo responde con el valor y con una prueba de Merkle: los nodos del trie que llevan desde la clave consultada hasta la raíz. Si la prueba reconstruye la raíz que figura en una cabecera finalizada, la respuesta es auténtica. El capítulo sobre el estado y el trie explica cómo se arma esa prueba.

Volvamos a la billetera del escenario. Con un light client, el servidor atrasado no podría haber hecho pasar un saldo viejo por actual: la billetera conocería la última cabecera finalizada por su propia cuenta, y una prueba contra una raíz anterior no la convencería. El servidor podría negarse a responder, pero no engañar.

Los límites: largo alcance y punto de partida

Warp sync confía en una premisa: que las firmas de un conjunto de autoridades pasado siguen significando algo. La especificación señala el riesgo con nombre propio: "Warp syncing is particularly vulnerable to what is called long-range attacks." [2] Dos tercios de un conjunto antiguo, que ya no tiene nada en juego, podrían firmar una historia alternativa, y un cliente que sincroniza desde muy atrás no tendría cómo distinguirla.

La defensa es económica y temporal. Según la especificación, los light clients basan su confianza "in provided snapshots and the ability to slash grandpa votes for equivocation for the period they are syncing via warp sync." [2] Por eso el punto de partida no debe estar demasiado atrás; la especificación da como ejemplo para Polkadot un máximo de 28 días, alineado con el período de slashing. Si ese número sigue vigente queda a validar. El capítulo sobre vectores de ataque BFT desarrolla el ataque de largo alcance.

Qué cambia respecto de Ethereum

En la ruta de Ethereum, la mayoría de las aplicaciones leen la cadena por JSON-RPC, y el capítulo sobre acceso por JSON-RPC insiste en fijar el bloque de cada lectura y en preferir finalized cuando hay dinero en juego. El supuesto de fondo es que el nodo consultado dice la verdad. El capítulo sobre diversidad de clientes muestra por qué importa qué nodo se consulta y quién lo opera.

Substrate no elimina ese supuesto para quien siga usando RPC, pero lo vuelve opcional: el light client está en la caja de herramientas estándar y verifica finalidad y estado por su cuenta. La pieza que lo hace posible es la misma que en Ethereum permite hablar de bloques finalized: una finalidad con firmas verificables. En Substrate, esas firmas son las justificaciones GRANDPA, y warp sync las encadena.

Lo que cambia para quien diseña una integración es la pregunta. En lugar de "en qué RPC confío", la pregunta es "qué tengo que verificar y desde qué punto de partida". El siguiente capítulo, parachains con Cumulus, muestra una cadena que ni siquiera se finaliza sola: su finalidad viene de otra.

Laboratorio propuesto

Estado: propuesta. Este laboratorio todavía no está publicado en lab.trautslab.dev; se ejecutará en local, sin red pública ni fondos reales.

Objetivo. Observar qué descarga un nodo con warp sync y verificar un saldo con un light client en vez de con un RPC.

Pasos propuestos.

1. Reutilizar la red local del laboratorio de GRANDPA y rotar el conjunto de autoridades al menos una vez.
2. Arrancar un nodo nuevo con warp sync y registrar en los logs qué cabeceras y justificaciones descarga.
3. Conectar un light client (smoldot) a la red local y verificar un saldo con prueba de estado.

Evidencia esperada. El nodo en warp sync pide tantos fragmentos como cambios de conjunto hubo, no tantos bloques como tiene la cadena. El light client obtiene el saldo junto con una prueba que reconstruye la raíz de una cabecera finalizada. Los nombres de las opciones de línea de comandos y los mensajes de log dependen de la versión del nodo y quedan a validar al construir el laboratorio.