Gobernanza On-Chain y Votos BFT: Actualizar parámetros por consenso

Cambiar una regla de un protocolo distribuido tiene dos problemas que suelen confundirse. Uno es social: quién tiene derecho a proponer y aprobar el cambio. El otro es técnico: cómo lograr que todas las réplicas apliquen el cambio en el mismo punto de la historia, sin que unas sigan con la regla vieja mientras otras ya usan la nueva.

Este artículo trata sobre todo el segundo. La idea central es que la gobernanza on-chain no necesita un protocolo de acuerdo propio: reutiliza el que ya existe. Si la propuesta, los votos y la ejecución son transacciones, el consenso BFT los ordena igual que a un pago, y la replicación de máquina de estados hace el resto. [1] [2]

Gobernanza como replicación de máquina de estados

PBFT se presenta como un algoritmo de replicación de máquina de estados: cada réplica mantiene una copia del servicio, y el protocolo garantiza que las réplicas correctas ejecuten las mismas operaciones en el mismo orden. [2] El paper exige que el servicio sea determinista, de modo que el mismo estado inicial y la misma secuencia de operaciones produzcan el mismo resultado en todas las réplicas correctas. [2]

HotStuff se formula en el mismo marco: las réplicas acuerdan una secuencia creciente de comandos, y un bloque confirmado mediante la cadena de QCs ya no puede ser revertido por una réplica correcta. [1] Para la gobernanza, eso significa algo muy concreto. Si la transacción que ejecuta un cambio de parámetro está en un bloque confirmado, todas las réplicas correctas la ejecutarán en la misma posición del log y, a partir de ahí, aplicarán el nuevo valor.

Fíjate en lo que no hace falta. No hace falta que las réplicas coordinen un reloj, ni que acuerden por separado "a qué hora entra el cambio". La posición del log es el reloj. Un diseño que active cambios por hora de pared reintroduce justamente el problema que el consenso resolvió: dos réplicas podrían procesar el mismo bloque con reglas distintas.

El ciclo de vida de una propuesta

Los sistemas reales varían mucho en los detalles, y esta sección describe un ciclo genérico como contexto general, no el diseño de ninguna cadena concreta.

1. Propuesta. Un participante envía una transacción que describe el cambio. La máquina de estados la valida y le asigna un identificador.
2. Votación. Los participantes con derecho a voto envían transacciones de voto durante un periodo medido en bloques. El conteo es una función determinista del estado.
3. Aprobación. Al cerrar el periodo, la máquina de estados evalúa la regla de aprobación. El resultado es el mismo en todas las réplicas correctas porque todas ejecutaron los mismos votos en el mismo orden.
4. Espera opcional. Muchos diseños separan aprobación y ejecución para dar margen a los operadores.
5. Ejecución. Una transacción, o una regla de la máquina de estados, aplica el nuevo valor en un bloque determinado.

El siguiente fragmento es ilustrativo y no corresponde al formato de ningún sistema real; sirve para ver que una propuesta no es más que datos dentro de una transacción.

{
  "proposal_id": 402,
  "target_parameter": "consensus.base_timeout",
  "new_value": "1000ms",
  "voting_period_blocks": 50000
}

Dos umbrales que no hay que confundir

El error más común al hablar de "votos BFT" es mezclar dos umbrales. El quórum de $2f + 1$ réplicas sobre $n = 3f + 1$ es un mecanismo del protocolo de consenso: decide qué bloque se confirma y garantiza, por intersección, que no se confirmen dos bloques en conflicto. [2] [1]

La regla de aprobación de una propuesta de gobernanza es otra cosa: un predicado que la aplicación evalúa sobre los votos registrados. Puede exigir mayoría simple, dos tercios del stake, un mínimo de participación o cualquier otra combinación. Ese umbral lo define la aplicación, no la teoría BFT, y no hereda automáticamente la propiedad de intersección. Un 66,7 % de votos a favor en una propuesta no tiene relación necesaria con el $2f + 1$ que certifica los bloques.

Lo que sí hereda la gobernanza del consenso es la integridad del conteo. Como los votos son transacciones ordenadas y ejecutadas de forma determinista, todas las réplicas correctas calculan el mismo resultado, y ningún voto confirmado puede desaparecer de la historia. [1] La gobernanza es tan segura como el log que la contiene, ni más ni menos: si más de $f$ réplicas fueran bizantinas, el consenso dejaría de garantizar safety y con él cualquier resultado de votación.

Cambiar el código, no solo los parámetros: el caso Polkadot

Ajustar un parámetro numérico es el caso fácil. Más ambicioso es cambiar la lógica misma de la máquina de estados. La especificación del protocolo Polkadot separa el host, que implementa red, consenso y almacenamiento, del runtime, la lógica de transición de estado compilada a Wasm. [3] El código del runtime se guarda en el propio estado bajo la clave :code, y el host ejecuta el runtime que encuentra en el estado. [3]

La consecuencia es elegante: reemplazar la lógica del runtime es una escritura en el estado, ordenada y confirmada por el consenso como cualquier otra. Las réplicas no necesitan instalar un binario nuevo en una fecha coordinada para ese tipo de cambio, porque todas leen el código nuevo en la misma posición de la historia. El mecanismo de decisión que autoriza esa escritura queda fuera de la especificación del host y depende de la lógica del runtime.

La misma especificación aplica la idea al conjunto de validadores: los cambios de authority set de GRANDPA se anuncian en la cadena y se aplican en puntos derivados de ella. [3] Cambiar quién vota es la forma más delicada de gobernanza, porque modifica los quórums que protegen el log, y merece un tratamiento propio como reconfiguración por épocas.

Lo que la gobernanza on-chain no resuelve

Es tentador decir que la gobernanza on-chain elimina los hard forks. Es más preciso decir que elimina la descoordinación técnica para los cambios que el sistema sabe ejecutar por sí mismo. Si un cambio exige modificar el software que no vive en el estado, como el host en el caso de Polkadot, los operadores siguen teniendo que actualizar. [3] Y si una parte de la comunidad rechaza el resultado de una votación, puede ejecutar software distinto; eso es un problema social que ningún quórum resuelve.

Hay además una trampa de diseño específica de los protocolos BFT. Algunos parámetros afectan al propio consenso: timeouts, tamaño de bloque, conjunto de validadores. Cambiar un timeout del pacemaker de forma determinista es seguro para safety, porque safety no depende de los timeouts, pero un valor mal elegido puede afectar liveness. [1] Cambiar el conjunto de validadores, en cambio, toca la premisa de la intersección de quórums y requiere el cuidado de una reconfiguración.

Siguiente lectura

Para repasar por qué un bloque confirmado no se revierte, vuelve a QC, highQC y three-chain. Si te interesa por qué ajustar timeouts afecta liveness pero no safety, continúa con por qué no usar timeouts fijos.