Tolerancia a fallas bizantinas (BFT): ¿En qué consiste?

Los ecosistemas y redes blockchain deben gran parte de su popularidad a un mayor grado de fiabilidad en comparación con los sistemas tradicionales. Esta fiabilidad hace de los ecosistemas basados en la tecnología blockchain una alternativa más transparente, eficiente y asequible.

En esta guía, veremos cómo se relacionan los conceptos Byzantine Fault Tolerance (BFT) y Practical Byzantine Fault Tolerance (pBFT) con la fiabilidad de una red o ecosistema basado en tecnología blockchain.

¿Qué es la tolerancia a fallas bizantinas (BFT)?

La capacidad de un sistema informático para detectar y rechazar información falsa se conoce como “tolerancia a fallas bizantinas” (Byzantine Fault Tolerance, BFT). Se dice que una red descentralizada como Bitcoin es “tolerante a las fallas bizantinas” cuando supera el “problema de los generales bizantinos” (Byzantine Generals Problem).

Hay diversas aproximaciones a este problema. En el caso de Bitcoin, se resuelve a través de la distribución de la red. ¿Pero por qué es tan importante la BFT? En un ecosistema descentralizado sin acceso limitado, cualquiera podría emitir información ilegítima, poniendo en peligro su estabilidad y fiabilidad.

¿Qué es el problema de los generales bizantinos?

Un sistema que resuelve el problema de los generales bizantinos (BGP, por sus siglas en inglés) es tolerante a este y otros tipos de ataques. El BGP es una analogía de la teoría de juegos usada para poner a prueba la capacidad de consenso de un sistema sin la necesidad de recurrir a una entidad centralizada.

Se trata de un problema que describe una situación donde varias unidades de un ejército bizantino se encuentran acampadas en diferentes localizaciones alrededor de la ciudad que están sitiando. Cada unidad está dirigida por un general que debe decidir cuándo atacar o retirarse.

La decisión de los generales es determinante, ya que perderán la batalla si no atacan al mismo tiempo. Para atacar a la vez, los generales deben ponerse de acuerdo, pero la línea de comunicación que usan no depende de una entidad central.

Es decir, los mensajes pueden ser interceptados por el bando contrario. Los enemigos pueden interceptar los mensajes para manipularlos o destruirlos. También podrían perderse por el camino. La cuestión es si los mensajes son fiables o no: los generales no pueden saber con total certeza si la información recibida es legítima.

Para resolver este problema, todos los generales leales necesitarían seguir un plan que garantice las siguientes condiciones:

• Se pondrán de acuerdo y ejecutarán la misma orden.
• Seguirán las mismas reglas establecidas.
• Alcanzarán un consenso a pesar de las acciones de generales traidores.
• No implementarán un plan ilegítimo debido a la influencia de generales traidores.

Relación entre BFT y blockchain

Como sistema descentralizado, una red blockchain debe resolver el problema de consenso que conlleva la ausencia de una entidad centralizada. Comparando una red compuesta por nodos con un ejército dividido en unidades dirigidas por generales, tenemos el mismo problema de confianza a la hora de llegar a un consenso: se necesita un sistema de comunicación seguro y confiable.

El dilema de los generales es el dilema de los nodos, que deben ponerse de acuerdo a la hora de implementar el mismo plan y ejecutarlo simultáneamente. En el whitepaper de Bitcoin, Satoshi Nakamoto ofreció una solución al BGP: el algoritmo de consenso Proof-of-Work (PoW).

Gracias a este algoritmo, los miembros de la red aceptan como válido un bloque si tiene asociado un hash. Los nodos de la red llegan a un consenso que permite la inclusión en la red de nuevos bloques. Los hash PoW prueban que se han usado recursos (trabajo) para generar los bloques: los mineros aportan energía y equipamiento.

En teoría, esta inversión necesaria para la generación de bloques disuade a los hackers. En cierta forma, la prevención de ataques a la red se basa en el coste asociado al proceso de minería. El mecanismo PoW resuelve el BGP, aportando seguridad y confiabilidad al ecosistema.

La solución de Nakamoto se ha popularizado, pero no es la única. Otras redes recurren a mecanismos alternativos, como es el caso de Ethereum y el algoritmo Proof-of-Stake (PoS), donde los miembros “bloquean” sus ETH como prueba de participación (32 ETH o menos, dependiendo del método de staking).

Los sistemas, cuya seguridad se basa en PoS, minimizan la probabilidad de sufrir ataques, penalizando a los actores maliciosos con la pérdida de parte o la totalidad de los fondos en staking.

¿Qué es Practical Byzantine Fault Tolerance (pBFT)?

Practical Byzantine Fault Tolerance (pBFT) es un algoritmo de consenso propuesto en 1999 por Barbara Liskov y Miguel Castro. Se trata de un mecanismo heredero de algoritmos BFT previos, siendo su premisa principal la aceptación de la existencia de nodos que pueden difundir información errónea.

¿Cómo funciona pBFT?

El algoritmo pBFT asume que se van a producir fallas, por lo que basa su funcionamiento en la comprobación de los mensajes, que deben estar asociados a nodos concretos. Los propios nodos deben verificar los mensajes que emiten, asegurando que no han sido alterados.

Pero, si el algoritmo da por sentado que se van a producir errores, ¿cuál es su nivel de tolerancia? Liskov y Castro proponen que en un sistema lo suficientemente grande, no puede producirse una falla que implique más de un tercio de la red. Es decir, es matemáticamente improbable que más de un tercio de los nodos actúen de forma maliciosa.

Además, una red pBFT cuenta con un nodo principal (“nodo líder”). El resto de nodos son secundarios (“nodos backup”). Lo interesante es que cualquier nodo secundario puede funcionar como líder en el caso de que el nodo principal falle. La seguridad se refuerza forzando el cambio del nodo principal en cada proceso de consenso, un cambio que puede producirse mediante votación de los nodos secundarios si identifican un error en el nodo líder.

Proceso de consenso pBFT

• Un cliente envía una solicitud al nodo principal.
• El nodo líder envía el mensaje a los nodos secundarios.
• Todos los nodos (primario y secundarios) ejecutan la petición
• Los nodos responden al cliente (“m+1” significa que el proceso se ha realizado con éxito).

Tipos de fallas bizantinas

Existen dos tipos de fallas bizantinas: error fail-stop y error de nodo arbitrario. En el primer caso, el nodo deja de funcionar. En un error de nodo arbitrario el proceso es algo más complejo:

• La respuesta del nodo es errónea.
• Los nodos no consiguen responder.
• Un nodo vuelve a responder de forma errónea intencionadamente.
• Los nodos responden de forma diferente en varias partes de la red.

Ventajas de pBFT

El algoritmo pBFT presenta numerosas ventajas en comparación con otros mecanismos de consenso, especialmente el PoW:

• Las transacciones se finalizan sin confirmación. Si los nodos se ponen de acuerdo en cuanto a la validez de un bloque, este se acepta. En el caso del mecanismo PoW, cada nodo verifica las transacciones individualmente.
• Se requiere menos energía. Los nodos no tienen que resolver problemas matemáticos complejos, como ocurre en las redes PoW.
• La red en su conjunto implementa la solicitud del cliente, por lo que todos los nodos reciben una recompensa.

Limitaciones de pBFT

Uno de los puntos negativos de las redes pBFT es la falta de escalabilidad debido a la comunicación constante entre nodos. En este sentido, existe una correlacion directa entre el tiempo de respuesta y el tamaño del sistema. El tamaño es importante también a la hora de evitar ataques Sybil, ya que las redes pBFT son especialmente vulnerables a estos hacks.

BFT y mecanismos de consenso

Gran parte del éxito de una red blockchain reside en su mecanismo de consenso. Los más usados para resolver el BGP son los algoritmos PoW y PoS-BFT. En este sentido, las decisiones tomadas por los desarrolladores son decisivas, ya que el nivel de BFT guarda relación con el mecanismo de consenso.

Estos son algunos de los algoritmos de consenso más populares:

• Proof-of-Work (PoW).
• Proof-of-Stake (PoS).
• Delegated Proof-of-Stake (DPoS)
• Leased Proof-of-Stake (LPoS)
• Practical Byzantine Fault Tolerance (pBFT).
• Delegated Byzantine Fault Tolerance (dBFT)
• Proof-of-Importance (PoI).
• Proof-of-Authority (PoA).
• Direct Acyclic Graph (DAG).
• Proof-of-Capacity (PoC).
• Proof-of-Identity (PoI).
• Proof-of-Activity (PoA).
• Proof-of-Elapsed-Time (PoET).

Preguntas frecuentes