El Problema de los Generales Bizantinos, también llamado Byzantine Fault, es una condición de los sistemas informáticos distribuidos, desarrollado para describir una situación de consistencia e integridad, en la que, para evitar una falla catastrófica del sistema, los actores deben acordar una estrategia concertada, pero sabiendo que algunos de estos actores podrían no ser confiables.
En una falla bizantina, un componente como un servidor, puede aparecer fallado y funcionando de manera inconsistente, pero no detectable por los sistemas de detección, siendo difícil para los otros componentes declarar que falló para excluirlo de la red. La Tolerancia a Fallas Bizantina (BFT), es la resistencia de un sistema informático a tales condiciones.
El Problema de los Generales Bizantinos fue planteado por el informático estadounidense Robert Shostak, a finales de la década de 1970, y luego desarrollado en 1982 en colaboración con Leslie Lamport y Marshall Pease, en el centro de investigación científica y tecnológica SRI International.
El Planteo del Problema
Los Generales de un ejército Bizantino rodean una ciudad enemiga. Se posicionan con sus respectivas tropas en los alrededores, a cierta distancia entre sí, y no se deciden entre ordenar un ataque o una replegada. La coordinación es necesaria para el plan de guerra, pues de lo contrario es muy probable que pierdan la batalla.
Los altos cargos militares sospechan que entre ellos hay al menos un traidor, lo que hace difícil tomar la decisión en conjunto.
Un general podría enviar un mensaje a los demás anunciando que va a atacar, cuando en realidad pretende ordenar el repliegue, y hacer que el resto falle.
Pero ¿cómo ponerse de acuerdo?
El problema es encontrar un algoritmo que garantice que los Generales leales lleguen a un acuerdo, y sean la mayoría coordinada.
Se muestra que, usando solo mensajes, este problema es solucionable, si y sólo si, más de dos tercios de los Generales son leales. Por ejemplo, el problema se presenta cuando un solo traidor puede confundir a dos Generales leales sobre un total de seis, es decir la mitad de generales, explicaron los mencionados autores en su estudio.
La solución a esta sencilla expresión es problemática, y para resolverlo, los investigadores ofrecieron una serie de ecuaciones y algoritmos que se transmiten a través de un sistema de mensajes “inviolables”, o sea encriptados.
El Problema de los Generales Bizantinos en Blockchain
Las fallas bizantinas son prácticamente inevitables dentro de cualquier sistema informático distribuido. Digamos que hay un corte de energía y los nodos se desconectan repentinamente, o existe un actor malicioso que quiere provocar daños en el sitema. ¿Puede la red seguir funcionando con normalidad y seguir admitiendo comunicaciones fiables? ¿O todo el sistema deja de funcionar repentinamente o se vuelve vulnerable a los ataques?
En una red moderadamente segura, algo tan simple como que algunos nodos se desconecten no tiene ningún impacto notable en la red. La capacidad de defenderse de estos escenarios se conoce como tolerancia a Fallas Bizantinas. Se considera que las redes que pueden manejar más Fallas Bizantinas tienen una mayor tolerancia, lo que significa que son más seguras que las que no pueden manejarlas.
El ledger está distribuido en una red blockchain, con un número de computadoras (nodos) alrededor del mundo, que se actualizan instantáneamente con cada bloque, de manera que cada parte interesada puede confiar en las transacciones registradas de esa red.
Así, la idea es que cada General Bizantino (cada nodo) tenga la copia completa de los planes de cada uno de sus colegas (el ledger en la blockchain), entonces habría prácticamente un margen nulo para las fallas Bizantinas, producto de una traición.
Cuando todos están de acuerdo de que tienen el mismo resultado, entonces los nodos validan un bloque. Aunque alguien quisiera introducir información equivocada — y aquí entra el Problema de los Generales Bizantinos — no lo va a poder lograr, porque todos disponen de la misma información, y la consideran la verdad, y eso lleva al consenso. Este es un sistema BFT, y se logra con el algoritmo de consenso que corre en cada uno de los nodos de la red que almacena toda la información del ledger.
La consecuencia típica de un sistema que no sea tolerante a la Byzantine Fault es la bifurcación de la blockchain. Si un sistema es tolerante a los fallos, significa que a pesar de existir fallos (en este caso nodos maliciosos) el éxito del sistema será posible, claro, siempre que estos fallos no sean “demasiados”.
Resolviendo el Problema de los Generales Bizantinos con la Prueba de Trabajo y la Prueba de Participación
La prueba de trabajo (PoW) fue pionera en la tecnología blockchain, y la prueba de participación (PoS) es un algoritmo de consenso de creación posterior, alternativo.
PoS fue implementado por primera vez por PeerCoin y Nxt en 2012 y 2013, respectivamente, y tiene como objetivo evitar algunas de las debilidades percibidas de PoW, sobre todo lo que refiere al costo de hardware y consumo energético.
En el protocolo PoW, las nuevas transacciones y la emisión de criptomonedas se asientan en el libro mayor a través de la minería, donde los mineros compiten con poder computacional por ser los encargados de forjar cada bloque.
En cambio, en PoS, los nodos validadores son elegidos al azar, pero con mayor “suerte” para los nodos que tienen mayor cantidad de delegación asignada, y así los operadores de pool compiten por atraer nuevos delegantes con sus fondos de criptomonedas, compartiendo con ellos las recompensas de cada bloque forjado.
PoW genera un incentivo desmedido, en el que los mineros, únicos participantes del consenso, se llevan la emisión de las criptomonedas y los fees de transacciones de cada bloque. Tienen el esquema “the winner takes all”.
En lugar de costosos equipos de minería, los validadores de PoS no necesitan nada más que una computadora estándar, una conexión a Internet y mantener la delegación con estrategias activas.
Al igual que PoW, PoS resuelve el Problema de los Generales Bizantinos , aunque por medios diferentes. La tolerancia al Fallo Bizantino está determinada en el algoritmo.
PoS faculta a los “Generales” distribuidos y descoordinados (los nodos productores) a ponerse de acuerdo, a partir del algoritmo de consenso, que para Cardano es Ouroboros, a pesar de que la comunicación no sea instantánea y se envíen señales potencialmente contradictorias:
- Los Generales se convierten en validadores depositando sus bienes.
- El algoritmo preestablecido selecciona un General para que se convierta en un validador para el siguiente bloque.
- Posteriormente, el protocolo elige a otro General para que se convierta en validador, referenciando el bloque anterior para formar una cadena en crecimiento. Como resultado, queda claro que la mayoría de los Generales contribuye a forjar y validar la cadena más larga, y la más densa en bloques.
- Los Generales saben que, tan rápido se crea cada bloque bajo el algoritmo de consenso PoS, después de un período de tiempo, podrán saber si suficientes Generales están trabajando en la misma cadena.
Esto resuelve el Problema de los Generales Bizantinos de una manera más eficiente y respetuosa con el medio ambiente, erradicando los altos costos de energía y hardware asociados con PoW. Al hacerlo, también elimina las economías de escala de las que se benefician los mineros más grandes en PoW, concentrados en grandes granjas mineras.
PoS brinda a todos los usuarios la oportunidad para recibir una recompensa, que resulta proporcional a sus fondos.
Mientras que los mineros PoW pueden deshacerse de las criptomonedas minadas de inmediato, por ejemplo para pagar sus altos costos, PoS incentiva a que los validadores dejen sus fondos en el nodo, para el uso en el consenso de la red, y así tener más chances de ser elegidos como forjadores de bloques. Además, mantener las recompensas de validación resulta viable, ya que no tienen que pagar altos costos de mantenimiento de nodo, como en PoW.
Pero No Todo es Positivo en PoS
Aunque PoS es teóricamente más democrático, ya que brinda a todos los usuarios la misma oportunidad de participar en el consenso de red (en forma directa o delegando), y evita los problemas de economías de escala que sufre PoW, tiende a crear cierta concentración, donde los grandes se hacen más grandes y los pequeños se diluyen cada vez más en la participación. Este problema se conoce como Plutocracia, que es el gobierno de una minoría con mayor poder.
A medida que estos grandes intereses se acumulan, es probable que comiencen a actuar en connivencia en lugar de competir.
Esta concentración de participación también significa la formación de un escenario en el que es posible un ataque del 51 %, cuando el consenso es dominado por actores maliciosos.
Para el ataque del 51%, en PoW, un atacante necesita comprar suficiente equipo de minería para ganar hash-power para apoderarse de la red. En PoS un atacante tendría que comprar el 51% del circulante total delegado.
Los defensores del protocolo PoS argumentan que la red podría bifurcarse en caso de un ataque, y así destruir la cantidad delegada por el atacante. Sin embargo, esto depende en gran medida de que la red bifurcada pueda sobrevivir a la pérdida de confianza que traería un ataque.
Muchas redes PoS también requieren que los validadores posean una cantidad de criptomonedas de la blockchain bloqueadas en el nodo, generalmente significativa, prevaleciendo stakepools con grandes sumas de dinero, normalmente instituciones, con un impacto similar al de las granjas mineras en PoW, lo que conduce a una mayor centralización.
No es el caso de Cardano, que no requiere pledge mínimo, y que además incide de forma insignificante para el sorteo de slot leader. La consecuencia negativa de esto es que se presentan actores “sin piel en el juego”, que son los validadores que no tienen nada que perder.
La mitigación de estos problemas en PoS puede abordarse con cambios en los parámetros del protocolo de consenso, incentivando a la participación honesta, donde podría establecerse, por ejemplo, una relación entre la cantidad delegada y el pledge requerido, para que el leverage se mantenga en valores no exagerados, es decir que la cantidad de pledge no sea inferior a cierto valor respecto de la delegación, y así pueda existir “piel en el juego”.
Este artículo de mi autoría se publicó originalmente en AdaPulse.
