Protocolos BFT: PBFT y Tendermint

El problema de los generales bizantinos, formulado por Lamport, Shostak y Pease en 1982, plantea la siguiente pregunta: ¿puede un sistema distribuido alcanzar el consenso cuando algunos participantes envían mensajes contradictorios? El problema recibe su nombre de los generales bizantinos, que deben coordinar un ataque, pero pueden incluir traidores que envían órdenes contradictorias. Un sistema tiene tolerancia a fallos bizantinos (BFT) si alcanza un consenso correcto a pesar de admitir hasta f nodos maliciosos entre un total de 3f+1. BFT es el estándar de oro para el consenso de cadenas de bloques que requiere seguridad frente a condiciones adversarias.

PBFT (Castro y Liskov, 1999) fue el primer protocolo BFT práctico y demostró que BFT podía funcionar de forma eficiente en sistemas reales. PBFT opera en vistas (términos), cada una con un primario (líder) designado. El funcionamiento normal consta de tres fases: pre-prepare (el primario difunde la solicitud del cliente y el número de secuencia), prepare (las réplicas difunden su acuerdo con la secuencia) y commit (las réplicas difunden la confirmación de commit). Una solicitud se ejecuta cuando una réplica recopila 2f+1 mensajes commit coincidentes. PBFT proporciona seguridad y vivacidad siempre que menos de 1/3 de las réplicas sean bizantinas.

La principal limitación de PBFT es su complejidad de mensajes O(n^2) por solicitud: cada una de las n réplicas envía mensajes a todas las demás durante las fases prepare y commit. Para n=100 réplicas, cada solicitud genera aproximadamente 10.000 mensajes. Esto hace que PBFT resulte poco práctico para grandes conjuntos de validadores. La comunidad de investigación de BFT dedicó dos décadas a mejorar este aspecto: BFT-SMART redujo las constantes, HotStuff logró una complejidad lineal de mensajes mediante un modelo de retransmisión por parte del líder y Tendermint adaptó las ideas de PBFT para su uso en cadenas de bloques públicas.

Cuando se sospecha que el primario de PBFT es defectuoso (timeout), las réplicas activan un cambio de vista. Cada réplica difunde un mensaje view-change que contiene su estado (los valores preparados de la vista anterior). El nuevo primario recopila 2f+1 mensajes view-change, construye un mensaje new-view que demuestra que la transición de estado es coherente con los valores confirmados anteriormente y lo difunde. Los cambios de vista son costosos —generan O(n^3) mensajes— y constituían un cuello de botella práctico. Optimizaciones como el certificado de cambio de vista de PBFT y el diseño canalizado de HotStuff abordan este problema.

Tendermint (2014, Kwon; en producción en Cosmos desde 2019) adapta PBFT a entornos públicos de cadenas de bloques. Tendermint tiene tres fases por bloque: propose (el líder difunde el bloque propuesto), prevote (los validadores votan sobre la propuesta) y precommit (los validadores votan para confirmar después de observar 2/3 de los votos prevote). Un bloque se confirma cuando un validador recopila 2/3 de los votos precommit, lo que constituye un certificado de quórum. Los validadores se turnan como proponentes en orden round-robin ponderado por participación. Si una ronda termina por timeout sin confirmación, los validadores avanzan a la siguiente ronda con un voto nil.

Tendermint proporciona una seguridad sólida: un bloque confirmado es final y no puede revertirse siempre que menos de 1/3 de la participación sea bizantina. Esta es una finalización síncrona: no hay bifurcaciones después de la confirmación. La vivacidad requiere una red parcialmente síncrona: el protocolo avanza cuando los retrasos de los mensajes están acotados, pero no necesita sincronía de forma continua. La compensación entre vivacidad y seguridad es fundamental: Tendermint sacrifica la vivacidad (puede detenerse si la red se particiona) para garantizar la seguridad, a diferencia de cadenas como Bitcoin, que sacrifican la seguridad (permiten bifurcaciones temporales) en favor de la vivacidad.

Un mecanismo fundamental de Tendermint es el bloqueo de votos. Cuando un validador envía un precommit para un bloque en la ronda r, queda bloqueado en ese bloque. En rondas posteriores, un validador bloqueado solo puede emitir un prevote por el bloque en el que está bloqueado (o un voto nil si recibe pruebas de que el bloque no se confirmó). Esto impide confirmaciones contradictorias entre rondas. Un validador solo puede desbloquearse si recibe una polka (2/3 de los votos prevote) para un bloque diferente en una ronda posterior, lo que demuestra que el bloque original no se confirmó.

Cosmos Inter-Blockchain Communication (IBC) se basa en la finalización instantánea de Tendermint para las transferencias entre cadenas. Un cliente ligero de Tendermint sigue el conjunto de validadores y el último commit (una cabecera de bloque más 2/3 de firmas precommit). Para verificar un paquete de la cadena A, el módulo IBC de la cadena B verifica el certificado de quórum: que 2/3 de los validadores de la cadena A firmaron la cabecera de bloque correspondiente. Por tanto, la seguridad de IBC depende de la garantía BFT de Tendermint: una transferencia entre cadenas es final en cuanto se confirma el bloque de origen.

HotStuff (Yin et al., 2018; base de LibraBFT/DiemBFT de Facebook, y actualmente de Aptos y Sui) logra una complejidad de mensajes O(n) por ronda de consenso mediante una topología en estrella: todos los validadores envían sus votos al líder, el líder los agrega en una firma de umbral (QC, certificado de quórum) y difunde la QC. HotStuff utiliza un diseño de encadenamiento de tres fases en el que las demostraciones de seguridad abarcan tres QC consecutivas, lo que permite la ejecución canalizada. La complejidad lineal hace que HotStuff sea práctico para entre 100 y 300 validadores, como se implementa en Aptos y Sui.

Las cadenas de bloques empresariales (Hyperledger Fabric, Besu, Quorum) utilizan consenso BFT para redes permisionadas en las que se conoce la identidad de los validadores. El servicio de ordenación de Hyperledger Fabric basado en Raft proporciona tolerancia a fallos por caída (no bizantinos) para consorcios de confianza. El hito de BFT planificado para Fabric tiene como objetivo SmartBFT, una implementación basada en una biblioteca. R3 Corda utiliza un clúster de notarios con BFT-SMART para prevenir el doble gasto. La elección entre CFT y BFT refleja las suposiciones de confianza: BFT es necesario cuando los validadores pueden ser adversarios; CFT es suficiente cuando solo pueden ser poco fiables.

Comprender BFT requiere entender qué ataques resiste y cuáles no. BFT gestiona los validadores que incurren en equivocación (envían mensajes contradictorios a distintos pares) y los validadores que fallan o quedan en silencio. No gestiona los ataques Sybil: un atacante que controla 1/3 de los validadores mediante la creación de identidades falsas puede quebrantar la seguridad. Por eso las cadenas BFT públicas utilizan ponderación por participación en PoS: adquirir 1/3 de la participación cuesta dinero real y proporciona resistencia frente a Sybil. BFT también presupone la entrega eventual de los mensajes (sincronía parcial): una partición de red que dure más que el tiempo de espera de vivacidad puede detener la cadena.

¿Cuál es la fracción máxima de validadores que puede ser bizantina en un protocolo BFT estándar sin perder la seguridad?

Los protocolos BFT garantizan el consenso a pesar de admitir hasta 1/3 de validadores maliciosos. PBFT (1999) demostró que BFT era práctico, pero tiene una complejidad de mensajes O(n^2). Tendermint adapta PBFT a las cadenas de bloques con finalización instantánea y bloqueo de votos. HotStuff logra una complejidad O(n) mediante QC de firmas de umbral y se utiliza en Aptos y Sui. Cosmos IBC utiliza la finalización instantánea de Tendermint para transferencias entre cadenas verificadas. Las cadenas de bloques empresariales utilizan BFT-SMART o Raft según se esperen fallos bizantinos o simplemente fallos por caída.