Capstone: conectar un consenso BFT propio (estilo HotStuff) a un nodo Substrate

Un equipo tiene una cadena Substrate con Aura y GRANDPA. El negocio pide finalidad en un tiempo acotado y predecible, y el equipo ya conoce HotStuff: votos sobre propuestas, certificados de quórum y una regla de commit clara. La pregunta del arquitecto es directa: ¿podemos quitar GRANDPA y poner nuestro protocolo? ¿Y si además queremos que el líder de cada vista produzca el bloque, en lugar de Aura?

Este capítulo cierra la ruta respondiendo esa pregunta como una guía de ingeniería. No hay un tutorial oficial: como vimos en la anatomía del consenso, la guía del SDK sobre cambiar el consenso está vacía. Todo lo que sigue se apoya en el código del Polkadot SDK y en los capítulos de investigación de HotStuff, y separa con cuidado lo que el código garantiza de lo que es una decisión de diseño.

Preguntas guía

• ¿Gadget de finalidad junto a Aura o BABE, o un protocolo único que produce y finaliza?
• ¿Qué es el QC en términos de Substrate y quién lo verifica?
• ¿Dónde vive el pacemaker y cómo viajan los votos por la red del nodo?
• ¿Qué se pierde al retirar GRANDPA (warp sync, light clients, BEEFY) y cómo se recupera?
• ¿Cómo se prueba safety antes de la red real?

Conexiones dentro de la serie

• Antes: Anatomía del consenso dio el mapa del nodo. GRANDPA, Sincronización y light clients y BEEFY son lo que tu protocolo hereda o reemplaza.
• Investigación de HotStuff: QC, highQC y la regla de tres cadenas, view-change y pacemaker, Fast-HotStuff y AggQC de dos cadenas, safety, liveness y responsiveness, Substrate y HotStuff: sincronizar cuando finalizas rápido y verificación formal con TLA+.

La decisión de arquitectura: gadget o protocolo único

Hay precedente de que se puede. La documentación del SDK cita una cadena que construyó "both custom FRAME pallets and custom node-side components": aleph-node, de Cardinal Cryptography. [1] No describimos aquí su diseño; el dato importante es que el SDK reconoce este camino como legítimo.

La primera decisión es de arquitectura. Puedes mantener la producción de bloques existente (Aura o BABE) y reemplazar solo la finalidad, o diseñar un protocolo que haga ambas cosas.

El argumento a favor del gadget viene del propio artículo de GRANDPA: separar producción y finalidad permite "decouple safety and liveness in order to speed up recovery from failures." [2] La cadena sigue creciendo aunque la finalidad se detenga, y la finalidad se pone al día cuando vuelve la red.

El argumento a favor del protocolo único viene de HotStuff: un líder correcto puede llevar al consenso "at the pace of actual (vs. maximum) network delay", con comunicación lineal en el número de réplicas. [3] Si el líder de la vista propone el bloque y el mismo protocolo lo certifica, no hay dos relojes que coordinar. El coste es que, sin quórum, tampoco se producen bloques.

El QC como justificación

En HotStuff, un QC (quorum certificate) reúne votos firmados de n − f réplicas sobre una propuesta. El artículo de GRANDPA usa el mismo umbral: con f menor que n/3 votantes bizantinos, "We need n − f of voters to agree on finality." [2] El capítulo QC, highQC y la regla de tres cadenas explica cuándo un QC basta para comprometer un bloque.

En Substrate, la prueba de finalidad de un bloque tiene un tipo concreto: Justification = (ConsensusEngineId, EncodedJustification). [4] La traducción es directa: eliges un identificador de motor de cuatro bytes que no choque con los existentes (GRANDPA usa FRNK, Sassafras SASS) y codificas como bytes lo que haga falta para verificar el commit.

¿Qué hace falta? Depende de tu regla. Si comprometes con una regla de tres cadenas, el QC del bloque comprometido no basta: la prueba debe mostrar la cadena de QC consecutivos que dispara el commit. Esto es análisis propio a partir de la regla de HotStuff, no algo que el SDK imponga, y conviene fijarlo por escrito antes de programar. Una justificación mínima suele incluir el hash y la altura del bloque, la vista, el identificador del conjunto de validadores y las firmas o su agregado.

Hay una advertencia en el propio tipo. La justificación viaja fuera del bloque porque, si hay varias pruebas válidas, incluirlas cambiaría el hash del bloque. [4] En el protocolo único, el QC del padre sí puede ir en la propuesta, como el campo de justificación de HotStuff, porque el líder lo fija al proponer. La prueba de finalidad del propio bloque debe seguir viajando aparte. Esta separación es análisis propio y queda a validar en cada diseño.

Para elegir el esquema de firma, el capítulo de Fast-HotStuff y AggQC compara certificados agregados y de dos cadenas. Recuerda además a quién va dirigida la prueba: si un puente debe verificarla fuera de la cadena, el coste de verificación que vimos en BEEFY pasa a ser un requisito de diseño.

Figura 1

Conceptos de HotStuff y su pieza en un nodo Substrate

Fuentes:

[3][4][5]

Cómo leer esta figura

Dos columnas unidas por flechas. A la izquierda, conceptos de HotStuff en azul: pacemaker y vistas, voto firmado, QC con n menos f votos, regla de commit y conjunto de réplicas. A la derecha, en verde, la pieza correspondiente del nodo Substrate: tarea del voter con temporizadores propios, protocolo de notificación propio por gossip, justificación como engine id más QC codificado, finalize_block y notificación de finalidad, y runtime con autoridades por sesión expuestas por runtime API. Debajo, bajo el título un nodo nuevo sincroniza, una fila de cajas: bloque más QC llegan por sync, JustificationImport verifica el QC, una caja ocre pregunta si los firmantes pertenecen al conjunto vigente; si la respuesta es sí, una flecha verde lleva a bloque finalizado; si es no, una flecha roja lleva a se rechaza la justificación.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Las piezas que escribes: voter, red e importación

Con la decisión tomada, el trabajo se reparte en las piezas del mapa del capítulo anterior. El patrón de referencia es GRANDPA, cuyo crate documenta el uso: crear primero un envoltorio de block import con su LinkHalf y después arrancar el voter con ese enlace y una implementación de red. [6] Tu motor puede seguir la misma forma.

El envoltorio de BlockImport. Implementa BlockImport sobre el del cliente. En cada bloque lee las señales de cambio de validadores y, si un bloque llega con justificación de tu motor en justifications, la verifica y lo marca como final. [5] Si el bloque cambia el conjunto y no trae prueba, devuelve needs_justification en ImportedAux para que sync la pida.

El JustificationImport. Implementa también JustificationImport en el mismo objeto, como hace GRANDPA, y pásalo a la import queue como justification_import. Su método on_start devuelve las justificaciones que conviene pedir a la red al arrancar. La import queue usará el Link para pedir justificaciones a sync cuando falten. [7]

El voter y el pacemaker. Es una tarea esencial que recibe notificaciones de importación, decide en qué vista está, envía y recoge votos y, cuando se cumple la regla de commit, llama a finalize_block con la justificación. Finalizar un bloque finaliza implícitamente sus antecesores y dispara notificaciones de finalidad. [8] El pacemaker, con sus temporizadores y certificados de timeout, vive aquí; el capítulo View-change y pacemaker describe qué debe hacer.

La red de votos. El solochain template muestra el patrón: el servicio registra un protocolo de notificaciones propio de GRANDPA en la configuración de red (add_notification_protocol) y entrega el servicio de notificaciones al voter. [9] Tu motor necesita su propio nombre de protocolo y su propio formato de mensajes.

La autoría, si eliges protocolo único. Reemplazas el slot worker de Aura por un worker de vistas que, siendo líder, pide un bloque al Proposer y lo sella; y el verificador de Aura por uno que compruebe el sello del líder y el QC del padre. Si mantienes Aura, puedes además frenar la autoría cuando la finalidad se atrasa: el crate de slots ofrece una estrategia "that back offs if the finalized head is lagging too much behind the tip". [10]

Dos avisos de estabilidad. sp-consensus advierte que gran parte del crate es inestable y que "Implementors of traits should not rely on the interfaces to remain the same." [11] Y el crate de GRANDPA se declara inestable. Fija la versión del SDK y presupuesta el trabajo de cada actualización.

Rotación de validadores desde el runtime

El conjunto de réplicas no debe decidirlo el nodo. En Substrate lo decide el runtime, y el motor lo lee por dos vías: la runtime API del motor, que expone las autoridades actuales, y los digests Consensus que el runtime emite cuando programa un cambio. Es la regla del capítulo anterior: nodo y runtime deben coincidir en el motor.

GRANDPA resuelve el traspaso con una idea que puedes copiar: se acuerda una altura máxima que el conjunto actual puede finalizar, y "once a block with that height is finalized the next set will pick up finalization from there." [6] En un protocolo estilo HotStuff, eso significa que el bloque que aplica el cambio debe ser comprometido por el conjunto saliente antes de que el entrante empiece a votar, y que cada QC lleva el identificador del conjunto que lo firmó.

Un error típico es verificar un QC contra el conjunto de validadores actual del nodo verificador en lugar del conjunto vigente en la altura del bloque. Al sincronizar desde lejos, esa diferencia rechaza pruebas válidas o, peor, acepta pruebas de un conjunto que ya no debería contar.

Lo que se pierde al retirar GRANDPA

Retirar GRANDPA tiene efectos fuera del voter, y los tres capítulos anteriores de la ruta explican cuáles.

Warp sync. La especificación describe warp sync como la descarga de las cabeceras donde cambió el conjunto de autoridades "and by verifying the GRANDPA justifications". [12] Sin GRANDPA, tu motor debe implementar el WarpSyncProvider del SDK, el "Warp sync backend" que genera y verifica pruebas. [13] Y debe conservar las justificaciones de cada cambio de conjunto, como hace el filtro de poda de GRANDPA, porque son los eslabones de esa prueba. [6]

Light clients. Un light client existente sabe verificar las pruebas de los motores que implementa. Si tu prueba de finalidad es nueva, no podrá verificarla sin cambios; qué motores soporta cada cliente ligero concreto queda a validar. El capítulo Substrate y HotStuff: sincronizar cuando finalizas rápido trata este efecto desde la experiencia de una integración, con la salvedad de que se apoya en una nota de ingeniería secundaria.

BEEFY. El README de BEEFY es explícito: el protocolo se apoya en supuestos de GRANDPA "and is required to be built on top of it to work correctly." [14] Si retiras GRANDPA, pierdes BEEFY y, con él, los puentes que dependen de BEEFY. Un QC con firmas agregadas podría servir directamente a un puente, pero ese verificador habría que escribirlo.

Probar safety antes de la red real

Un protocolo BFT no se valida con una red que funciona bien. Se valida con una red que falla de las formas que el modelo permite, y comprobando que nunca se finalizan dos bloques en conflicto. El capítulo Safety, liveness y responsiveness da las propiedades; aquí van como lista de pruebas.

Antes de escribir el código, conviene modelar la integración. El capítulo de verificación formal con TLA+ muestra cómo expresar la regla de commit y comprobar exhaustivamente estados pequeños. Lo que más se beneficia de un modelo no es el protocolo publicado, sino tu traducción: el traspaso de conjuntos, el arranque con justificaciones viejas y la interacción entre el pacemaker y sync.

Qué cambia respecto de Ethereum

En Ethereum, la arquitectura de gadget es la de la red: Gasper combina una regla de fork choice para la cabeza con Casper FFG como finalidad por épocas. Cuando la finalidad se detiene, la red no se para: aplica el mecanismo de inactivity leak para recuperar la supermayoría. Es el mismo argumento de separar safety y liveness que GRANDPA formula.

La diferencia está en quién puede cambiarlo. En Ethereum, el consenso es una especificación común a todos los clientes. En Substrate, el consenso de tu cadena es código de tu nodo y de tu runtime. Eso te permite poner HotStuff donde Ethereum tiene Casper FFG, pero también te deja sin la red de seguridad de varias implementaciones independientes de la misma especificación. Las pruebas de la sección anterior sustituyen, en parte, esa red.

Laboratorio propuesto

Estado: propuesta. Este laboratorio todavía no está publicado en lab.trautslab.dev; describe lo que se construirá, en local, sin red pública ni fondos reales. Es un protocolo de juguete con fines didácticos, no una implementación para producción.

Objetivo. Recorrer de punta a punta la integración de una finalidad estilo HotStuff en el solochain template, y comprobar safety con fallos inyectados.

Pasos propuestos.

1. Mantener Aura para producir bloques y retirar GRANDPA del servicio del nodo: quitar su envoltorio de importación, su voter y su protocolo de red.
2. Implementar un voter mínimo que firme votos sobre la red del nodo, con un protocolo de notificaciones propio, y arme un QC por altura.
3. Finalizar el bloque cuando se cumpla la regla de commit elegida y guardar el QC como justificación con un engine id propio.
4. Inyectar fallos: un líder caído, mensajes retrasados y un votante que equivoca. Registrar en cada caso el último bloque final de cada nodo.
5. Arrancar un nodo nuevo y verificar que importa las justificaciones al sincronizar y llega al mismo bloque final.

Evidencia esperada. En todos los nodos, la misma secuencia de bloques finales, sin dos bloques finales distintos a la misma altura en ningún caso de fallo. Con el líder caído, una pausa de la finalidad seguida de un cambio de vista y su reanudación. Con el votante que equivoca, dos votos firmados para la misma vista guardados como evidencia. El nodo nuevo alcanza el mismo bloque final que los demás. Qué regla de commit usar (dos o tres cadenas) y cómo medir los tiempos queda a validar al construir el laboratorio.