¿Qué es Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) es, en pocas palabras, la capacidad de una red informática para seguir funcionando correctamente cuando una parte de los participantes falla, comete errores o difunde deliberadamente información incorrecta.

Esto es especialmente importante para las blockchains. Una blockchain no tiene un administrador central que determine qué transacciones y bloques son válidos. En su lugar, ordenadores distribuidos, también llamados nodos o validadores, deben alcanzar conjuntamente un acuerdo sobre una única versión de la blockchain.

Un validador puede presentar fallos de distintas formas: un fallo ordinario o un fallo bizantino. En un fallo ordinario, para la red es evidente que el validador no está funcionando correctamente. Por ejemplo, el validador se cae, pierde la conexión a internet o no envía un mensaje a tiempo. En ese caso, no aporta información útil. La blockchain, por lo general, puede gestionar esto con relativa facilidad. Los demás validadores no esperan indefinidamente, sino que continúan tras un cierto tiempo sin el validador caído. Mientras haya suficientes validadores activos, la red sigue procesando nuevos bloques.

En un fallo bizantino, un validador no solo se comporta de forma defectuosa, sino impredecible. Puede seguir enviando mensajes, pero proporcionar información incorrecta o contradictoria. Por ejemplo, puede decirle a un validador que el bloque A es válido y a otro validador que el bloque B es válido.

La diferencia, por tanto, es:

• En un fallo ordinario falta la información de un validador.
• En un fallo bizantino sí hay información, pero no está claro si es correcta.

Por ello, un fallo bizantino es más difícil de resolver. La red no solo debe poder continuar sin un validador caído, sino también evitar que mensajes incorrectos o contradictorios conduzcan a una decisión equivocada.

Byzantine Fault Tolerance describe cómo una red puede tomar una decisión conjunta a pesar de este tipo de problemas. Para ello, el protocolo utiliza, entre otros elementos, comprobaciones, firmas digitales, diferentes rondas de votación y un umbral de votación elevado.

Muchos protocolos BFT exigen que más de dos tercios del peso total de voto respalde la misma propuesta antes de que un bloque sea definitivo. De este modo, un grupo pequeño de validadores defectuosos o maliciosos no puede decidir por sí solo qué versión de la blockchain es válida.

BFT no es un mecanismo de consenso independiente. Es una propiedad de una red o de un protocolo de consenso. Protocolos como PBFT, Tendermint y HotStuff usan cada uno sus propias reglas para tolerar fallos bizantinos.

Puntos clave

• Byzantine Fault Tolerance ayuda a una blockchain a gestionar validadores defectuosos o no fiables.
• Un fallo bizantino puede originarse por una avería técnica, un error de software o un ataque deliberado.
• Los validadores verifican propuestas y votan sobre nuevos bloques.
• Muchos protocolos BFT exigen el respaldo de más de dos tercios del peso total de voto.
• BFT ayuda a evitar que distintas versiones de la blockchain queden definitivas al mismo tiempo.
• PBFT, Tendermint y HotStuff son ejemplos de protocolos BFT.

¿Qué resuelve Byzantine Fault Tolerance?

Byzantine Fault Tolerance evita que un pequeño grupo de validadores defectuosos o maliciosos pueda decidir por sí solo qué versión de la blockchain es válida. Ayuda a la red a mantener un único historial de transacciones compartido, incluso cuando algunos participantes fallan, no responden o difunden información incorrecta.

Por ejemplo, un validador no fiable puede enviar distintos bloques a distintos participantes, votar por dos bloques en conflicto o intentar que se apruebe un bloque no válido. Un validador también puede negarse a cooperar y, con ello, ralentizar la consecución del consenso.

Sin reglas adecuadas, distintos grupos de validadores podrían seguir cada uno una versión diferente de la blockchain. Entonces la red ya no podría determinar con certeza qué transacciones y bloques son válidos.

BFT lo evita al confirmar un bloque solo cuando suficientes validadores han verificado y respaldado la misma propuesta. De este modo, un grupo limitado de participantes no fiables no puede engañar a la red por sí solo.

Además, los participantes no necesitan confiar personalmente entre sí. Confían en las reglas fijas del protocolo de consenso, como las firmas digitales, las rondas de votación y un umbral de votación elevado.

Así, BFT hace posible mantener una única versión compartida y coherente de la blockchain sin un administrador central.

¿Cómo funciona Byzantine Fault Tolerance?

Para comprender bien Byzantine Fault Tolerance, primero es importante conocer la diferencia con un mecanismo de consenso.

Un mecanismo de consenso es el conjunto de reglas mediante el cual los participantes de una blockchain alcanzan un acuerdo sobre nuevos bloques y sobre el historial válido de la red. Por ejemplo, determina quién puede proponer un bloque, cómo votan los validadores al respecto y cuándo un bloque se confirma o se vuelve definitivo.

Byzantine Fault Tolerance es la propiedad que garantiza que este proceso siga funcionando incluso cuando algunos validadores fallan, cometen errores o envían información incorrecta.

Por tanto, BFT generalmente no es un sistema separado junto al mecanismo de consenso. Consiste en las reglas dentro del proceso de consenso que impiden que validadores no fiables puedan engañar a la blockchain. Piense, por ejemplo, en un umbral de votación elevado, firmas digitales, varias rondas de votación y la sustitución de un validador que no proponga un bloque válido.

El funcionamiento exacto difiere según la blockchain, pero en muchos protocolos BFT el proceso transcurre aproximadamente del mismo modo.

Un validador se designa temporalmente para proponer un nuevo bloque. A este validador se le suele llamar proposer o leader. En el bloque se incluyen nuevas transacciones y una referencia al bloque anterior. El proposer firma digitalmente la propuesta, para que los demás validadores puedan verificar de quién procede.

Luego, los demás validadores comprueban si el bloque es válido. Por ejemplo, revisan si las transacciones cumplen las reglas, si los usuarios tienen saldo suficiente y si los mismos tokens no se gastan dos veces. También verifican si el bloque encaja con la versión correcta de la blockchain.

Cuando un validador considera que el bloque es válido, emite un voto digital. Gracias a esa firma, la red puede ver quién ha votado, para qué bloque era el voto y si un validador también votó por un bloque en conflicto.

Aquí es donde entra en juego Byzantine Fault Tolerance. La red no confía en la decisión de un solo validador. En muchos protocolos BFT, más de dos tercios del peso total de voto deben respaldar el mismo bloque antes de que pueda volverse definitivo.

Este umbral de votación elevado garantiza que un pequeño grupo de validadores defectuosos o maliciosos no pueda decidir por sí solo qué bloque es válido. Cuando algunos validadores envían información incorrecta o no responden, los demás validadores aún pueden llegar juntos a una decisión única.

Ejemplo: Ethereum utiliza Proof of Stake y reglas similares a BFT para hacer definitivos los bloques. Los validadores bloquean ETH y luego votan sobre puntos de control en la blockchain. Al menos dos tercios del total de ETH en staking deben respaldar el mismo punto de control antes de que sea definitivo. Cuando una pequeña parte de los validadores falla o vota de forma incorrecta, Ethereum aún puede alcanzar finalidad. Si aproximadamente un tercio del peso total de voto no participa correctamente, la finalidad puede detenerse temporalmente. Para ello, Ethereum cuenta con un inactivity leak: los validadores que no participan durante un periodo prolongado pierden gradualmente una parte de su stake. De este modo, los validadores activos pueden llegar a representar de nuevo suficiente peso de voto para alcanzar finalidad.

En redes Proof-of-Stake, por eso, normalmente no se trata solo del número de validadores, sino sobre todo de su peso de voto. Ese peso de voto depende de la cantidad de tokens que hayan puesto en staking.

Algunos protocolos de consenso utilizan varias rondas de votación. Un ejemplo conocido es Tendermint, hoy desarrollado además como CometBFT y utilizado por muchas blockchains dentro del ecosistema de Cosmos, incluida Cosmos Hub. En este caso, los validadores primero votan sobre el bloque propuesto y luego, en una ronda siguiente, confirman que suficientes validadores respaldan la misma propuesta. Así, la red no solo verifica que el bloque sea válido, sino también que exista un amplio acuerdo sobre él.

También puede ocurrir que no se consiga apoyo suficiente. Por ejemplo, el proposer puede estar sin conexión, proponer un bloque no válido o difundir propuestas contradictorias. Entonces, tras un cierto tiempo de espera, el mecanismo de consenso inicia una nueva ronda con un proposer distinto.

Eso también forma parte de la tolerancia a fallos. Un único validador defectuoso o malicioso no puede bloquear la red indefinidamente.

Por tanto, el mecanismo de consenso determina cómo la blockchain toma decisiones de forma conjunta. Byzantine Fault Tolerance garantiza que esa toma de decisiones siga siendo fiable cuando no todos los participantes actúan correctamente.

Resumen breve: ¿cómo funciona Byzantine Fault Tolerance?

1. El mecanismo de consenso determina qué validador puede proponer un bloque y cómo votan los demás validadores sobre él.
2. Los demás validadores verifican si el bloque propuesto es válido.
3. BFT garantiza que la red no confíe en un solo validador, sino que solo tome una decisión cuando una gran mayoría respalde el mismo bloque.
4. Las firmas digitales hacen visible quién votó por qué y si un validador ha emitido votos contradictorios.
5. En muchos protocolos BFT se necesita más de dos tercios del peso total de voto para hacer definitivo un bloque.
6. Cuando un proposer falla, miente o no obtiene una mayoría válida, el protocolo inicia una nueva ronda de votación con otro proposer.
7. Por tanto, el papel de BFT es mantener la fiabilidad del consenso cuando algunos validadores fallan, cometen errores o difunden deliberadamente información incorrecta.

¿Qué intentan proteger safety y liveness?

Byzantine Fault Tolerance debe garantizar que una blockchain siga siendo fiable cuando algunos validadores fallan, cometen errores o difunden información incorrecta. En ese contexto, la red debe evitar dos problemas.

En primer lugar, los validadores no deben llegar a dos versiones definitivas distintas de la blockchain. En segundo lugar, la red, mientras sea posible, debe seguir procesando nuevos bloques y transacciones.

Estos dos objetivos se denominan, dentro de BFT, safety y liveness.

Safety: no dos versiones diferentes

Safety significa que la red no acepta dos bloques en conflicto como definitivos.

Suponga que dos grupos de validadores reciben cada uno un bloque diferente. Sin reglas claras, ambos grupos podrían pensar que su propia versión es válida. Entonces la blockchain podría tener dos historiales de transacciones distintos.

Los protocolos BFT intentan evitar esto con un umbral de votación elevado, varias rondas de votación y votos firmados digitalmente. También pueden existir reglas que impidan que los validadores voten sin más por otro bloque después de haber respaldado previamente una propuesta.

Por tanto, safety garantiza que los participantes honestos sigan la misma versión definitiva de la blockchain, incluso cuando algunos validadores difunden información contradictoria.

Liveness: la red sigue avanzando

Liveness significa que la red puede seguir tomando nuevas decisiones.

Eso implica que se producen nuevos bloques, se procesan transacciones y que un proposer defectuoso o malicioso puede ser reemplazado cuando bloquea el proceso.

Para ello, los protocolos BFT utilizan, por ejemplo, tiempos de espera y nuevas rondas de votación. Cuando un proposer no propone un bloque válido o no responde, con el tiempo le toca el turno a otro validador.

Safety y liveness a veces pueden entrar en conflicto. Cuando demasiados validadores están sin conexión o difunden información distinta, es posible que la red no pueda reunir suficientes votos fiables.

Entonces el protocolo puede optar por no hacer definitivos temporalmente los bloques. La blockchain no avanza durante ese tiempo, pero evita que se aprueben dos versiones diferentes.

Por ello, ante una incertidumbre grave, los protocolos BFT suelen dar prioridad a safety. La red prefiere detenerse temporalmente antes que hacer definitiva una versión posiblemente incorrecta o en conflicto de la blockchain.

¿Cuál es la diferencia entre Byzantine Fault Tolerance y el Byzantine Generals Problem?

El Byzantine Generals Problem y Byzantine Fault Tolerance están relacionados, pero no significan lo mismo.

El Byzantine Generals Problem es un experimento mental que muestra por qué es difícil alcanzar un acuerdo en una red sin un decisor central. En el relato, distintos generales deben decidir juntos si atacan o se retiran. Solo se comunican mediante mensajes, mientras que algunos generales pueden mentir o difundir información contradictoria.

En una blockchain ocurre, en esencia, el mismo problema. Los validadores deben decidir juntos qué transacciones y bloques son válidos, sin estar seguros de que cada participante sea honesto y fiable.

Byzantine Fault Tolerance describe, a continuación, cómo una red gestiona ese problema. Permite que los validadores lleguen a una decisión conjunta, incluso cuando una parte de los participantes falla, comete errores o envía información incorrecta.

Por tanto, el Byzantine Generals Problem describe el problema. Byzantine Fault Tolerance es la capacidad de una red para resolver ese problema. Las reglas concretas con las que sucede, como rondas de votación, firmas digitales y un umbral de votación elevado, conforman en conjunto el protocolo BFT.

¿Cómo aplican las blockchains Byzantine Fault Tolerance?

Las blockchains pueden aplicar Byzantine Fault Tolerance de diferentes maneras. No todas las redes usan el mismo protocolo, pero el objetivo siempre es similar: los validadores deben elegir conjuntamente una única versión válida de la blockchain, incluso cuando una parte de ellos falla o difunde información incorrecta.

Las diferencias se encuentran sobre todo en la forma en que se elige un validador para proponer un bloque, cuántas rondas de votación se necesitan y cuándo un bloque se vuelve definitivo. También varía según el protocolo qué ocurre cuando los validadores no responden o emiten votos contradictorios.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance, normalmente abreviado como PBFT, es uno de los protocolos BFT más conocidos. Fue desarrollado por Miguel Castro y Barbara Liskov para hacer que Byzantine Fault Tolerance fuera utilizable en sistemas informáticos reales.

PBFT funciona con un líder temporal que envía una propuesta a los demás participantes. Estos verifican la propuesta y luego comparten entre sí si la consideran válida. A continuación, confirman que suficientes participantes respaldan la misma propuesta.

Gracias a estas diferentes rondas de comunicación, la red puede verificar si realmente existe un acuerdo amplio. PBFT funciona especialmente bien con un grupo relativamente pequeño de participantes conocidos. Cuando el grupo crece, deben intercambiarse cada vez más mensajes. Por ello, el protocolo se vuelve menos eficiente para blockchains con muchísimos validadores.

Tendermint BFT

Tendermint BFT es utilizado por muchas blockchains dentro del ecosistema Cosmos. En Tendermint, primero un validador propone un bloque. Después siguen dos rondas de votación en las que los validadores indican si respaldan el bloque.

Un bloque solo se vuelve definitivo cuando más de dos tercios del peso de voto están de acuerdo. Tendermint además utiliza un mecanismo de locking. Cuando un validador ve que un bloque tiene apoyo suficiente, queda, por así decirlo, bloqueado en ese bloque.

Después, el validador no puede votar sin más por un bloque en conflicto. Esto ayuda a evitar que se aprueben dos bloques contradictorios en distintas rondas.

HotStuff

HotStuff es un protocolo BFT más moderno que intenta aplicar la misma idea básica de una manera más eficiente. También aquí un líder temporal propone bloques y suficientes validadores deben respaldarlos.

HotStuff puede resumir el apoyo de los validadores en un quorum certificate. Se trata de una prueba criptográfica de que suficientes validadores han respaldado la misma propuesta. Los validadores aún deben enviar sus votos, pero el quorum certificate permite transmitir de forma compacta la prueba de ese apoyo amplio. Además, HotStuff está diseñado para que la comunicación y el cambio de líder sean más eficientes.

De este modo, no es necesario procesar siempre todos los votos individuales por separado. El protocolo también está diseñado para cambiar de líder más rápidamente cuando el líder actual no funciona adecuadamente.

Varios protocolos modernos de blockchain se inspiran total o parcialmente en HotStuff.

Ethereum

Ethereum no utiliza una forma clásica de PBFT, Tendermint o HotStuff. La red utiliza Proof of Stake, en el que los validadores votan con el ETH que han puesto en staking. Aun así, se observan claramente principios BFT en la forma en que Ethereum alcanza finalidad.

Los validadores votan sobre puntos de control en la blockchain. Un punto de control solo se vuelve definitivo cuando al menos dos tercios del total de ETH en staking lo respaldan.

Cuando más de un tercio del peso de voto no coopera, la finalidad puede detenerse temporalmente. Entonces la red opta por esperar a contar con suficientes votos fiables, en lugar de hacer definitivas dos versiones distintas.

Los validadores que, de manera demostrable, votan por versiones contradictorias pueden ser sancionados. Esto se denomina slashing. La sanción económica refuerza aquí las reglas BFT: los validadores pueden difundir información incorrecta, pero ese comportamiento es visible y puede tener consecuencias.

Bitcoin

Bitcoin aborda el mismo problema básico de otra forma. La red también debe alcanzar consenso mientras los participantes no confían plenamente entre sí, pero no utiliza un protocolo BFT clásico basado en votos.

Bitcoin utiliza Proof of Work. Los miners usan potencia de cómputo para producir nuevos bloques, tras lo cual los nodos verifican si esos bloques son válidos. Los miners continúan construyendo sobre la cadena válida en la que se ha invertido la mayor cantidad de trabajo computacional acumulado.

En este caso, un bloque no es definitivo de inmediato. La probabilidad de que se revierta disminuye a medida que se construyen más bloques encima. Esto se denomina finalidad probabilística.

Por tanto, Bitcoin intenta resolver el mismo problema general que los protocolos BFT: ¿cómo mantiene una red un historial fiable cuando no todos los participantes son de confianza? La diferencia es que Bitcoin utiliza potencia computacional y costes económicos, mientras que los protocolos BFT clásicos trabajan principalmente con rondas de votación explícitas y un umbral de votación elevado.

¿Qué ocurre cuando los validadores no cooperan?

Lo que sucede cuando los validadores fallan o actúan de forma incorrecta depende de cuánto peso de voto representen en conjunto.

Cuando solo un pequeño grupo de validadores no coopera, los demás validadores normalmente pueden reunir suficiente apoyo para confirmar nuevos bloques. La red sigue funcionando con normalidad, aunque no todos los validadores estén activos o sean fiables.

La situación cambia cuando más de un tercio del peso total de voto no participa. En muchos protocolos BFT, la red ya no puede reunir el apoyo requerido de más de dos tercios. Como consecuencia, los nuevos bloques pueden no poder hacerse definitivos temporalmente. Por tanto, este grupo puede bloquear el avance, pero por lo general no puede aprobar por sí solo una versión en conflicto de la blockchain.

Cuando un grupo controla y coordina más de dos tercios del peso de voto, puede formar por sí solo apoyo suficiente para confirmar bloques. Ese grupo puede determinar qué bloques válidos alcanzan finalidad y puede censurar transacciones al no incluirlas. Para hacer definitivas dos versiones en conflicto, los validadores sí deben ir demostrablemente en contra de las reglas de consenso, lo que en muchas redes Proof-of-Stake puede conducir al slashing.

Por ello, no solo es importante el número de validadores, sino sobre todo la distribución del peso de voto. Una blockchain puede tener miles de validadores y aun así estar relativamente concentrada cuando un pequeño número de partes gestiona una gran parte de los tokens en staking.

¿Cómo se castiga a los validadores maliciosos?

Las blockchains Proof-of-Stake pueden sancionar a los validadores cuando, de forma demostrable, infringen las reglas de consenso. Esto se denomina slashing.

Por ejemplo, un validador puede ser sancionado cuando vota por dos bloques en conflicto o intenta respaldar dos versiones distintas de la blockchain. Dado que cada voto se firma digitalmente, la red puede verificar qué validador cometió la infracción.

La sanción varía según la blockchain. Un validador puede perder recompensas de staking, perder una parte de sus tokens en staking o ser retirado temporalmente del conjunto de validadores. En infracciones graves, la exclusión puede durar más tiempo o ser permanente.

El slashing no hace imposible hacer trampas, pero sí aumenta las consecuencias financieras. Un validador que incumple las reglas de consenso se arriesga así a perder una parte de su propio valor aportado.

¿Cuáles son las ventajas de Byzantine Fault Tolerance?

Byzantine Fault Tolerance tiene varias ventajas:

1. La red puede seguir funcionando ante fallos: No todos los validadores necesitan estar siempre en línea o libres de errores. Mientras suficientes validadores sigan funcionando correctamente, la red puede seguir procesando nuevos bloques.
2. La blockchain mantiene un único historial compartido: BFT ayuda a evitar que distintos grupos de validadores hagan definitivos bloques en conflicto. Por ello, los participantes honestos siguen la misma versión de la blockchain.
3. Los bloques pueden volverse definitivos rápidamente: Muchos protocolos BFT hacen definitivo un bloque tan pronto como suficientes validadores lo respaldan. Así, los usuarios a menudo no tienen que esperar muchos bloques adicionales.
4. El comportamiento de los validadores es verificable: Los votos se firman digitalmente. De este modo, la red puede ver qué validador votó por qué bloque y si alguien emitió votos contradictorios.
5. No se necesita un decisor central: Los validadores pueden determinar juntos qué bloques son válidos, sin que una única parte central tome todas las decisiones.

¿Cuáles son las desventajas de Byzantine Fault Tolerance?

Byzantine Fault Tolerance también tiene varias desventajas:

1. La red puede detenerse temporalmente: Cuando participan muy pocos validadores, no se puede formar el quorum requerido. En ese caso, la red puede seguir proponiendo bloques, pero no hacerlos definitivos. Por ello, las transacciones permanecen inciertas durante más tiempo y los usuarios deben esperar a que participen de nuevo suficientes validadores.
2. Los validadores deben intercambiar mucha información: Durante el proceso de consenso, los validadores deben compartir entre sí propuestas, votos y confirmaciones. A medida que crece el número de validadores, también aumenta la cantidad de comunicación. Esto puede ralentizar la red y exigir más ancho de banda y potencia de cómputo.
3. Los protocolos BFT son técnicamente complejos: Estos protocolos funcionan con varias rondas de votación, tiempos de espera, líderes temporales y reglas que determinan cuándo un validador puede cambiar su voto. Un error en estas reglas o en el software puede hacer que los validadores se bloqueen, procesen información distinta o no alcancen consenso temporalmente.
4. El peso de voto puede concentrarse: Una blockchain puede tener muchos validadores, mientras que algunos grandes proveedores de staking u organizaciones gestionan conjuntamente una gran parte del peso de voto. Cuando estas partes controlan más de un tercio del peso de voto, podrían bloquear la finalidad. Con más de dos tercios, pueden ejercer mucha influencia sobre qué bloques se confirman.
5. BFT solo protege la capa de consenso: BFT ayuda a los validadores a llegar a un acuerdo sobre la blockchain válida, pero no protege todas las partes de la red. Por ejemplo, una transacción puede confirmarse correctamente mientras el smart contract utilizado contiene un error. BFT tampoco evita carteras hackeadas, bridges vulnerables, información de precios incorrecta de oracles, problemas en crypto-exchanges o pérdidas por caídas de precio.

Reflexión final

Byzantine Fault Tolerance garantiza que una blockchain pueda seguir funcionando de forma fiable cuando algunos validadores fallan, cometen errores o difunden deliberadamente información incorrecta. En ese contexto, la red no confía en un solo participante, sino que utiliza, entre otros elementos, firmas digitales, rondas de votación y un umbral de votación elevado para llegar a una decisión conjunta.

BFT no es un mecanismo de consenso independiente, sino una propiedad del proceso de consenso. Ayuda a evitar que distintas versiones de la blockchain se vuelvan definitivas al mismo tiempo y garantiza que la red, mientras participen suficientes validadores, pueda seguir procesando nuevos bloques.

Las blockchains aplican estos principios de diferentes maneras. Tendermint utiliza varias rondas de votación y reglas de locking, Ethereum utiliza reglas similares a BFT para la finalidad y Bitcoin resuelve un problema comparable con Proof of Work y finalidad probabilística.

Byzantine Fault Tolerance no hace que una blockchain esté completamente protegida frente a todos los fallos y ataques. Sin embargo, constituye una base importante para redes en las que los participantes no tienen que confiar plenamente entre sí, pero aun así pueden mantener conjuntamente un único historial de transacciones válido.