Reorganización dinámica de validadores: Cambio de nodos entre Epochs sin paradas

Los papers de consenso BFT suelen fijar el conjunto de réplicas al inicio y no volver a tocarlo. HotStuff, por ejemplo, define un QC como $n - f$ votos sobre un conjunto de $n$ réplicas conocido de antemano, y su argumento de safety se apoya en que dos quórums de ese mismo conjunto se cruzan. [1] En un sistema en producción ese supuesto dura poco: entran validadores, salen otros, se rotan claves.

La pregunta de diseño es concreta. ¿Cómo pasar del conjunto $V_E$ al conjunto $V_{E+1}$ sin detener la cadena y sin abrir una ventana en la que dos historias distintas puedan quedar certificadas? Este artículo arma la respuesta desde la intersección de quórums y la contrasta con un caso especificado con precisión: los cambios de authority set de Polkadot. [3]

Por qué un conjunto fijo es la premisa oculta de safety

La prueba de intersección dice que dos quórums de $2f + 1$ réplicas, tomados del mismo conjunto de $3f + 1$, comparten al menos $f + 1$ réplicas y, por lo tanto, al menos una correcta. [2] Esa réplica correcta es el testigo que impide certificar dos bloques en conflicto.

Ahora mezclemos conjuntos. Si un certificado se forma con dos tercios de $V_E$ y otro con dos tercios de $V_{E+1}$, nada garantiza que se crucen en una réplica correcta: pueden ser grupos casi disjuntos. Peor aún, los validadores que salieron de $V_E$ ya no tienen incentivos ni obligaciones, y sus claves pueden terminar en manos de un atacante. Si una mayoría de claves viejas pudiera seguir firmando después de la salida, podría certificar una historia alternativa.

De ahí salen tres requisitos que cualquier esquema de reconfiguración tiene que cumplir, y que conviene leer como análisis propio de este artículo, no como cita textual de una fuente:

1. El cambio lo decide el conjunto vigente. El nuevo conjunto se fija mediante un comando confirmado por las reglas de quórum de $V_E$, de modo que hereda la safety del log de la época $E$.
2. La frontera es una posición del log. Todas las réplicas correctas deben aplicar el cambio en el mismo bloque. Si la frontera dependiera del reloj local, dos réplicas podrían contar el mismo voto contra conjuntos distintos.
3. Los verificadores siguen la cadena de cambios. Quien valida la historia desde afuera necesita saber qué conjunto firmaba en cada tramo, y eso solo puede derivarlo de los cambios ya comprometidos.

El cambio como comando comprometido

En replicación de máquina de estados, las réplicas correctas ejecutan los mismos comandos en el mismo orden. [2] [1] Eso convierte la reconfiguración en un problema mucho más manejable: si el nuevo conjunto es el resultado de ejecutar un comando, todas las réplicas correctas calcularán el mismo $V_{E+1}$ en la misma posición del log, sin un protocolo de acuerdo adicional.

En notación de la serie, el cierre de la época $E$ puede pensarse como un bloque $B_{\text{fin}}$ que contiene la descripción de $V_{E+1}$ y que queda confirmado por certificados de $V_E$, por ejemplo $QC(B_{\text{fin}}, v)$ firmado por $2f + 1$ miembros de $V_E$. Esta notación es ilustrativa: cada sistema elige su propio formato de anuncio y su propia regla de confirmación. Lo esencial es que el anuncio esté en el log y que su confirmación use los quórums del conjunto saliente.

Hay un matiz que suele olvidarse. En HotStuff encadenado, un bloque se confirma solo cuando lo extiende una cadena de QCs de vistas consecutivas. [1] Si el conjunto saliente deja de participar justo después de proponer $B_{\text{fin}}$, ese bloque podría quedar certificado pero no confirmado. Un diseño correcto necesita que $V_E$ siga votando lo suficiente como para que la frontera quede efectivamente confirmada, o un mecanismo explícito para cerrar la época. Este punto es un razonamiento derivado de la regla de commit, no una descripción de un sistema concreto.

Cómo lo especifica Polkadot: authority sets y épocas

La especificación del protocolo Polkadot es útil porque describe estos mecanismos con precisión normativa. Su gadget de finalidad, GRANDPA, vota con un authority set identificado por un número de conjunto, y los cambios de ese conjunto se anuncian mediante mensajes de consenso incluidos en las cabeceras de los bloques. [3] La especificación distingue cambios programados, que se aplican a lo largo de la cadena finalizada después de un retardo, de cambios forzados, pensados como salida cuando la finalidad se ha detenido. [3]

La producción de bloques, a cargo de BABE, se organiza en épocas, y la especificación hace que la cadena anuncie los datos de la siguiente época, incluido su conjunto de autoridades, antes de que esa época comience. [3] Es exactamente el requisito de frontera determinista: cada nodo sabe, leyendo la cadena, quién puede producir bloques en la próxima época.

El cambio forzado merece una lectura cuidadosa. Es una válvula para recuperar liveness cuando el conjunto vigente no puede finalizar, y por lo tanto no se apoya en la confirmación del conjunto saliente. Es la misma tensión que aparece en el análisis de quórums: recuperar progreso cuando el conjunto actual no puede reunir dos tercios exige relajar alguna de las premisas del argumento de intersección.

Verificar la historia a través de varios cambios

Un validador que se une en la época $E + 20$ no vio ninguna de las transiciones anteriores. ¿Cómo sabe qué firmas aceptar? La especificación de Polkadot responde con pruebas acumuladas de cambios de authority set: el nodo parte de un ancla de confianza, típicamente el conjunto inicial, y verifica una secuencia de justificaciones de finalidad, cada una firmada por el conjunto vigente, para los bloques que cambian el conjunto. [3] Ese es el fundamento del warp sync.

Las notas de integración de xufeisofly sobre Substrate y HotStuff muestran por qué esto importa al cambiar de motor de consenso: si la finalidad pasa a ser HotStuff-like, las pruebas que recorre un nodo al sincronizar deben expresarse en QCs o evidencia equivalente, no en justificaciones de GRANDPA. [4] En otras palabras, la reconfiguración no termina en el protocolo de consenso; se extiende a cualquier componente que verifique certificados históricos.

La lección práctica es que cada transición debe dejar evidencia autocontenida: qué conjunto entra, en qué bloque y con qué firmas del conjunto saliente. Un detalle relevante, como análisis general: si las claves de validadores retirados se filtran, un atacante podría fabricar una historia alternativa firmada por un conjunto antiguo. Por eso los clientes que sincronizan necesitan un ancla razonablemente reciente o reglas adicionales sobre qué historias aceptar.

Siguiente lectura

Para profundizar en cómo un nodo nuevo recorre pruebas de finalidad al sincronizar, continúa con sincronización y finalidad en Substrate con HotStuff. Si quieres revisar la regla de commit que debe cerrar la frontera de época, vuelve a QC, highQC y three-chain.