Resiliencia no óptima en ChonkyBFT: Por qué N >= 5f + 1 simplifica Rollups

En Consenso BFT desde cero y en Quórums en acción trabajamos con el número $n = 3f + 1$: es el comité más pequeño capaz de tolerar $f$ fallas bizantinas bajo sincronía parcial. Casi todos los protocolos de esta serie lo tratan como un objetivo a alcanzar.

ChonkyBFT, el protocolo de consenso de ZKsync, se aparta deliberadamente de ese objetivo y exige $n \ge 5f + 1$. [1] Este artículo explica qué compra esa decisión, qué paga y por qué no es un error de diseño sino un intercambio explícito.

La cota óptima y lo que cuesta alcanzarla

Dwork, Lynch y Stockmeyer probaron que, con fallas bizantinas y sincronía parcial, el consenso es posible si y solo si $n \ge 3f + 1$. [2] Por eso a $3f + 1$ se le llama resiliencia óptima: ningún protocolo de ese modelo tolera más fallas con el mismo número de réplicas.

Alcanzar la cota tiene un costo en la estructura del protocolo. Con $n = 3f + 1$, dos quórums de $2f + 1$ comparten apenas $f + 1$ réplicas, y en el peor caso una sola de ellas es correcta. Ese testigo único basta para impedir dos certificados en conflicto dentro de una vista, pero no basta para que un nuevo líder reconstruya con certeza qué se decidió antes.

HotStuff resuelve ese problema con varias fases y locks. Una réplica guarda un lockedQC y el commit ocurre cuando se forma una cadena de tres QCs sobre bloques consecutivos; el predicado safeNode impide votar contra un lock sin evidencia de una vista más alta. [3] Las fases extra son el precio de la intersección mínima, y están explicadas en QC, highQC y three-chain.

Qué propone ChonkyBFT

El paper describe ChonkyBFT como un protocolo BFT para sincronía parcial, híbrido, inspirado en FAB Paxos, Fast-HotStuff y HotStuff-2. [1] Sus rasgos declarados son cuatro: está basado en comité, tiene una sola ronda de votación, ofrece finalidad en un slot y usa comunicación cuadrática, con tolerancia a fallas $n \ge 5f + 1$. [1]

Los autores justifican la combinación por el contexto de uso: dentro del rollup de ZKsync sus objetivos prioritarios son la simplicidad, la baja latencia de transacciones y una menor complejidad del sistema. [1] También indican que el protocolo fue implementado, analizado y probado con técnicas como fuzz testing y model checking. [1]

Hay dos renuncias explícitas en esa lista. La primera es la resiliencia: $5f + 1$ en lugar de $3f + 1$. La segunda es la comunicación lineal que HotStuff consigue con un líder que agrega votos. [3] ChonkyBFT acepta comunicación cuadrática a cambio de su regla de commit corta. [1]

La aritmética de $5f + 1$

Veamos por qué un comité más grande ayuda. Con $n = 5f + 1$ y quórums de $n - f = 4f + 1$, la inclusión-exclusión da:

$|Q_1 \cap Q_2| \ge (4f + 1) + (4f + 1) - (5f + 1) = 3f + 1$

Como a lo sumo $f$ réplicas son bizantinas, al menos $2f + 1$ réplicas de esa intersección son correctas. Con $n = 3f + 1$ el mismo cálculo deja $f + 1$ réplicas en común y, en el peor caso, una sola correcta. La diferencia no es de grado: pasar de un testigo correcto a una mayoría de testigos correctos cambia lo que un nuevo líder puede deducir.

El quórum sigue siendo alcanzable: $4f + 1 = n - f$ es exactamente el número de réplicas que responden cuando $f$ callan para siempre. Por eso subir $n$ no sacrifica liveness después de GST; sacrifica eficiencia de despliegue.

Por qué una sola ronda puede bastar

La siguiente es una lectura didáctica del margen que da $5f + 1$, no una transcripción de las reglas del paper; los detalles exactos de mensajes y certificados están en la especificación de ChonkyBFT. [1]

Supongamos que un bloque $B$ se confirmó en la vista $v$ con $4f + 1$ votos. Al cambiar de vista, el nuevo líder recoge el último voto reportado por $4f + 1$ réplicas. Ese conjunto se cruza con el quórum de $B$ en al menos $3f + 1$ réplicas, así que al menos $2f + 1$ reportes correctos mencionan $B$. Un bloque en conflicto de la misma vista solo puede aparecer en reportes de las $f$ réplicas bizantinas y de las a lo sumo $f$ correctas que quedaron fuera del quórum de $B$: como mucho $2f$ reportes.

Así, $B$ es identificable sin ambigüedad a partir de los reportes, y el líder puede verse obligado a volver a proponerlo. Con $n = 3f + 1$ ese conteo no separa los dos casos, y por eso los protocolos óptimos necesitan una ronda adicional de votos que deje locks antes de confirmar. [3] El comité más grande reemplaza una fase de votación.

El precio exacto del intercambio

El costo se mide en fallas toleradas por réplica desplegada. Con $n$ réplicas, la cota óptima tolera $\lfloor (n-1)/3 \rfloor$ bizantinas; con $n \ge 5f + 1$, solo $\lfloor (n-1)/5 \rfloor$. [2] [1] Con $16$ réplicas, por ejemplo, la primera regla tolera $5$ y la segunda $3$. Dicho al revés: para tolerar $f = 2$ hacen falta $7$ réplicas con la cota óptima y $11$ con la de ChonkyBFT.

Ese precio pesa distinto según el contexto. En una red abierta donde cada réplica representa stake independiente, perder tolerancia significa que menos participantes coludidos bastan para romper safety. En un comité acotado que opera un rollup, los autores priorizan latencia y simplicidad, y la elección del umbral se vuelve un parámetro de diseño más. [1]

También conviene no confundir simplicidad con ausencia de cambio de vista. Una regla de commit corta sigue necesitando timeouts, rotación de líder y una manera de transportar evidencia entre vistas; lo que cambia es cuánta evidencia hace falta y cuántas fases la producen. Ese mecanismo general está en el cambio de vista y el pacemaker.

Siguiente lectura

Para comparar esta regla de commit con la de HotStuff paso a paso, revisa QC, highQC y three-chain. Para el panorama de protocolos de frontera donde aparece ChonkyBFT junto a HotStuff-2 y los DAG-BFT, continúa con HotStuff-2, DAG-BFT y Twins.