y pasé algún tiempo leyendo sobre blockchain, afortunadamente no desde una perspectiva de cripto-hermano, sino más bien por una curiosidad genuina sobre cómo funciona realmente. Y mientras bajaba por esa madriguera del conejo, seguí topándome con un concepto del que nunca antes había oído hablar. Esa fue la tolerancia a fallas bizantinas.
En pocas palabras, Byzantine Fault Tolerance es una propiedad del sistema que permite que un sistema continúe funcionando correctamente, incluso cuando se incluyen algunos actores maliciosos en el sistema. Entonces, esta pequeña charla sobre enfriadores de agua tratará sobre la tolerancia a fallas bizantinas: qué es, de dónde viene, por qué es importante y cómo blockchain terminó siendo una de las soluciones más elegantes a un problema muy antiguo.
Entonces, ¡echemos un vistazo!
de los generales bizantinos a las computadoras
Entonces, la tolerancia a fallas bizantinas es una propiedad del sistema que debe su nombre al siguiente problema de teoría de juegos, a saber, el problema de los generales bizantinos:
Un grupo de generales bizantinos ha rodeado una fortaleza. Deben llegar a una decisión colectiva de atacar o retirarse. Tanto la decisión de retirarse como la de atacar pueden funcionar, pero sólo si todos actúan en coordinación. Un ataque coordinado tiene éxito. Una retirada coordinada también tiene éxito. Pero si algunos generales atacan mientras otros se retiran, el resultado es la derrota.
La comunicación entre los generales es de todos a todos y los generales sólo pueden comunicarse enviándose mensajeros entre sí. Sin embargo, algunos de los generales pueden ser traidores. En particular, un traidor no sólo vota de manera incorrecta, sino que también intenta engañar a los demás generales enviando mensajes contradictorios a diferentes generales. Por ejemplo, un traidor puede decirle a un general que ataque y a otro que se retire, intentando deliberadamente crear una división. Mientras tanto, los generales leales no tienen forma de saber de antemano quiénes son los traidores.
El problema es: ¿es posible, y en caso afirmativo, cómo y bajo qué condiciones, tal organización de generales puede llegar a un consenso?
Este problema fue descrito formalmente por primera vez por los científicos informáticos Leslie Lamport, Robert Shostak y Marshall Pease en su artículo de 1982. Y si bien el escenario es medieval y militar, el problema descrito es uno de los desafíos más fundamentales de la informática. Es decir, ¿cómo se llega a un consenso confiable en un sistema distribuido cuando algunos de los participantes podrían estar enviando información falsa?
En un sistema informático distribuido, en lugar de generales tenemos nodos: ordenadores o servidores individuales, cada uno de los cuales contiene una copia de algún estado compartido (una base de datos, un libro mayor, un registro de transacciones). Todos los nodos de un sistema distribuido deben ponerse de acuerdo sobre cuál es ese estado de verdad compartido. Al igual que los generales, se comunican enviándose mensajes entre sí y, al igual que los generales, algunos de esos nodos pueden estar defectuosos.
¿Pero por qué no simplemente votar? Intuitivamente, uno puede suponer que cada general podría simplemente enviar su voto (ataque o retirada) a todos los demás generales, luego contar los votos y hacer lo que propone la mayoría. Ataca si más de la mitad dice atacar, retírate si más de la mitad dice retirada.
El problema es que esto sólo funciona si cada general (nodo) realmente confía en los mensajes que recibe. Pero en dicha red también pueden estar incluidos traidores, que pueden enviar diferentes votos a diferentes generales, con el objetivo de crear una decisión dividida. El General A podría recibir un mensaje que diga “Voto ataque”, mientras que el General B recibe un mensaje del mismo traidor que diga “Voto retirada”. Por lo tanto, los generales A y B pueden terminar con ideas diferentes sobre lo que la mayoría de la red decidió hacer. En otras palabras, ya no podemos confiar simplemente en el voto mayoritario porque la mayoría de cada nodo podría estar contando mensajes diferentes. Y esta incapacidad para llegar a un consenso es un problema real para esos hipotéticos generales bizantinos, tanto como para las redes informáticas distribuidas.
Básicamente, esta es la definición de lo que es una falla bizantina. Una falla bizantina es una falla en un sistema distribuido donde un componente no simplemente falla, sino que se comporta de manera impredecible. Esto significa enviar información contradictoria a diferentes nodos, parecer que funciona correctamente para algunos nodos mientras que funciona mal para otros, producir activamente resultados falsos, etc. Sin embargo, una falla bizantina no necesariamente se origina por un actor malicioso en la red, ya que también puede ocurrir por fallas eléctricas, errores de software o fallas de hardware que hacen que un nodo produzca salidas arbitrarias. Un nodo con tal comportamiento se denomina nodo bizantino.
En cualquier caso, en el artículo original de 1982, los autores prueban matemáticamente que para que un sistema con n nodos continúe funcionando normalmente (es decir, tolere) f nodos bizantinos (traidores), se necesita al menos n ≥ 3f + 1 número total de nodos. En otras palabras, si más de un tercio de los nodos son bizantinos, es matemáticamente imposible que dicho sistema alcance un consenso confiable y no existe ningún algoritmo para hacer que dicho sistema continúe funcionando. Un sistema que tiene al menos dos tercios del total de nodos intactos y que también puede funcionar normalmente, llegando a un consenso, tiene la propiedad de Tolerancia a Fallas Bizantinas, o se denomina sistema Tolerante a Fallas Bizantinas.
¿Qué pasa con la cadena de bloques?
Durante décadas después del artículo de 1982, la tolerancia a fallos bizantinos siguió siendo un problema teórico con soluciones prácticas sólo en entornos estrictamente controlados como sistemas aeroespaciales, plantas de energía nuclear o cualquier otro lugar donde cada nodo pudiera ser examinado de antemano y garantizar que menos de un tercio se descompusiera. En otras palabras, se necesitaba cierta confianza entre los nodos que componen la red, por lo que incluso si algunos de los nodos recurrieran a traidores, esos traidores todavía estarían por debajo del umbral de 1/3 (con suerte).
1. Bitcoin y prueba de trabajo
Este fue el caso hasta 2008, cuando se publicó el documento técnico de Bitcoin, evitando por completo el enfoque de votación clásico. A diferencia de las redes distribuidas que existían hasta este momento, donde el consenso se alcanza por mayoría de votos de (con suerte) partes confiables, el documento técnico de Bitcoin propuso un mecanismo para operar un sistema distribuido sin confianza. Esto significa que, a diferencia de las centrales nucleares, donde había confianza entre los nodos de antemano, Bitcoin puede operar sin que ninguno de los nodos confíe entre sí, porque el propio mecanismo de consenso de Bitcoin garantiza las transacciones.
El mecanismo específico a través del cual Bitcoin logra hacer esto se llama Prueba de Trabajo (PoW). En pocas palabras, PoW hace que sea computacionalmente costoso participar en el proceso de consenso, y aún más costoso (prácticamente imposible) ser un traidor. Más específicamente, para agregar una nueva transacción, un nodo debe resolver un rompecabezas criptográfico que requiere enormes cantidades de potencia informática. Este rompecabezas es difícil de resolver para el nodo que propone la transacción, pero es fácil para otros nodos verificar si la solución del rompecabezas es correcta.
Un nodo traidor que quiera corromper el sistema y proponer una transacción falsa necesitaría rehacer el trabajo computacional, no sólo para la transacción que quiere corromper, sino para cada transacción posterior. ¡Esto es MUCHOS cálculos! Además de esto, tendría que hacerlo más rápido que el resto de la red honesta combinada. En la práctica, esto requeriría controlar más del 50% de la potencia computacional total de la red, lo cual es extraordinariamente costoso, prácticamente imposible. De esta manera, el costo de hacer trampa excede cualquier beneficio potencial que uno podría esperar de hacer trampa, volviéndolo económicamente irracional. Dicho esto, incluso si PoW permite transacciones confiables en un sistema descentralizado y sin confianza, también conlleva altos costos y alta latencia (las transacciones de Bitcoin pueden tardar hasta 10 minutos en finalizar), debido al cómputo masivo requerido.
2. blockchains modernas y prueba de participación
Partiendo de este concepto de “hacer que hacer trampa sea económicamente irracional”, pero también tratando de hacer que el sistema sea más rápido, otro enfoque de consenso es la Prueba de Participación (PoS). PoS se ha utilizado en la cadena de bloques de Ethereum desde 2022 y en otras cadenas de bloques modernas como Solana y Sui. La lógica detrás de PoS es la misma que la de PoW, pero en lugar de hacer que las trampas sean económicamente costosas indirectamente a través de la computación, las hace costosas directamente al hacer que los nodos de la red presenten garantías económicas. En particular, en una cadena de bloques PoS, los validadores (nodos que proponen transacciones) deben bloquear una cantidad significativa del token de la cadena de bloques para tener la capacidad de proponer y verificar transacciones. Si un nodo propone una transacción incorrecta, el sistema lo penaliza y se queda con parte de la garantía enviada. La diferencia con PoW es que en PoS, el comportamiento bizantino se castiga económicamente en lugar de volverlo computacionalmente inviable.
Otra cosa acerca de PoS es que hace que el sistema se parezca más a BFT. A diferencia de la Prueba de trabajo, que elude por completo el modelo clásico de votación BFT y establece el umbral de corrupción en el 50% del poder computacional total, la Prueba de participación nos acerca al marco original de Tolerancia a fallas bizantinas. En un sistema PoS, los validadores votan sobre la validez de las transacciones utilizando sus tokens apostados como peso. Esto significa que el umbral de 1/3 del documento original de 1982 se aplica nuevamente: si más de 1/3 del valor total apostado está controlado por validadores bizantinos, el consenso puede fracasar. PoS es explícitamente tolerante a fallas bizantinas en el sentido clásico, mientras que PoW no lo es; simplemente resuelve una versión diferente del mismo problema.
En mi mente: BFT más allá de blockchain
Lo que más me llamó la atención sobre BFT es la antigüedad del problema y cuánto tiempo llevó pasar de documentar el problema teórico a las soluciones prácticas. En particular, el problema se identifica y formaliza en el artículo original de 1982, pero el primer algoritmo práctico para manejarlo en sistemas informáticos reales, llamado Tolerancia práctica a fallos bizantinos (PBFT), no apareció hasta 1999. Y el primer sistema que realmente lo implementó en una configuración del mundo real (Bitcoin) no llegó hasta 2008.
La otra cosa en la que sigo pensando es en cuán universal es el problema. Más allá de blockchain, la tolerancia a fallas bizantinas, o más generalmente, el problema de alcanzar un consenso entre participantes potencialmente poco confiables, está en todas partes a nuestro alrededor. Cada vez que tienes varias partes independientes que necesitan ponerse de acuerdo en algo y no puedes confiar plenamente en todas ellas, tienes una versión del problema de los generales bizantinos.
En las bases de datos distribuidas, los protocolos BFT garantizan que un grupo de servidores de bases de datos puedan acordar el estado actual de los datos incluso si algunos servidores están dañados o envían información incorrecta. En el sector aeroespacial, las computadoras de control de vuelo utilizan votación estilo BFT para garantizar que un solo sensor defectuoso no pueda causar una falla catastrófica. Un comité tomando una decisión con algunos miembros de mala fe. Una cadena de suministro donde algunos proveedores pueden enviar información fraudulenta. Una configuración de entrenamiento de IA distribuida donde algunos dispositivos pueden enviar actualizaciones envenenadas. Los generales están por todas partes. La pregunta es siempre la misma: ¿cómo se llega a un consenso fiable cuando no se puede confiar en todos los presentes?
✨ ¡Gracias por leer! ✨
Si llegó hasta aquí, es posible que le resulten útiles los pialgoritmos: una plataforma que hemos estado creando y que ayuda a los equipos a gestionar de forma segura el conocimiento organizacional en un solo lugar.
¿Te encantó esta publicación? Únase a mí en 💌 Substack y 💼 LinkedIn
Todas las imágenes del autor, salvo que se indique lo contrario.