Saltar al contenido

Tolerancia a las fallas bizantinas

En 2008, cuando Bitcoin comenzó a existir, varias otras criptomonedas también ingresaron al mercado de las criptomonedas. Todas estas criptomonedas tienen Blockchain como elemento central de su arquitectura. Las blockchains son sistemas descentralizados que funcionan como libros de contabilidad distribuidos, mantenidos por una red distribuida de nodos de computadora.

Estos nodos tienen las mismas versiones y versiones únicas del historial de transacciones. Cuando se transmite una nueva transacción a la red, estos nodos de computadora tienen el poder de incluirla en su copia o simplemente ignorarla. Si la mayoría de los nodos están de acuerdo con una decisión, se llega a un consenso.

La pregunta que surge aquí es que, ¿qué pasa si algunos nodos no están de acuerdo con la decisión? ¿Qué pasa si es probable que fallen o actúen deshonestamente?

Estas preguntas surgen del problema del general bizantino que creó la tolerancia a la falla bizantina. Dejemos entender estos conceptos en detalle.

Encabezado de WorldMarkets

Problema del general bizantino

Lamport, Shostak y Pease presentaron un documento titulado "El problema de los generales bizantinos" que ilustraba la gravedad del problema.

Hace mucho tiempo, el Imperio Bizantino quería atacar y tomar el control de una ciudad. Hay muchas posibilidades de esta historia, en este artículo consideremos un escenario de cuatro generales en el imperio. Estos cuatro generales rodean la ciudad y cada general puede atacar o retirarse.

Si todos los generales deciden atacar, lo hacen y ganan la ciudad. Si todos los generales deciden retirarse, siguen ganando ya que nadie muere. Estos son los dos resultados de este escenario.

Pero, aquí está el giro. Solo si todos los generales acuerdan un acuerdo mutuo, pueden ganar. ¿Qué pasa si uno de los generales no está de acuerdo con los otros tres? ¿Y si es un traidor?

En tal caso, el enemigo que custodia la ciudad destruirá al ejército.

Hay un general al mando en este ejército, llamado Comandante, mientras que los otros 3 son tenientes. Entre estos cuatro generales, podría haber un traidor que no sigue las órdenes y comunica información incorrecta que podría destruir toda la misión. Además, ninguno de los generales sabe quién es el traidor.

La forma pictórica del escenario está aquí:

Tolerancia a fallos bizantinos de bitcoin (BFT)

Los generales solo pueden entregar mensajes orales entre sí a través de un mensajero. Si la mayoría de ellos actúan maliciosamente, todo el ejército colapsará.

Consideremos ahora un escenario en el que uno de los lugartenientes es un traidor.

Escenario 1: si uno de los tenientes es un traidor

Hay posibilidades de que el comandante también sea el traidor. Consideremos este escenario más adelante.

Supongamos que el comandante es leal y emite una orden de "ataque". Como nadie sabe quién es el traidor, los fieles lugartenientes no saben en quién confiar. En tal caso, todos los lugartenientes acordaron un algoritmo que representa que cada general evaluará todos los mensajes que reciba. Más tarde, dependiendo de la mayoría de las acciones recibidas, él decidirá su acción.

El comandante ordena atacar. Como está implícito, el mensaje se transmite a todos los lugartenientes. Consideremos al teniente 1 como el traidor. Después de recibir el comando "Ataque" del comandante, dice que recibió "Retirada" y hace lo mismo. El teniente 2 es leal y dice que le dijeron que "atacara". El teniente 3 también dice que recibió una orden de "ataque" del comandante y hace lo mismo.

El comandante es leal, por lo que atacará. El teniente 1 es un traidor, por lo que puede o no atacar. Si se retira, los tenientes leales han recibido dos órdenes de "Ataque" y una de "Retiro". Los tenientes leales aceptan "Atacar". 3 de cada 4 tenientes están de acuerdo con el consenso. De ahí se logra el consenso.

Escenario 2: si el comandante es un traidor

Cuando el comandante es un traidor, puede estropear las cosas dando diferentes órdenes a diferentes lugartenientes. Estos se llaman fallas bizantinas. Al recibir órdenes incorrectas, los lugartenientes pueden no llegar a un consenso.

tolerancia a fallos bizantinos "class =" wp-image-10695 "srcset =" https://bitcoinik.com/wp-content/uploads/2020/06/image-22.png 746w, https://bitcoinik.com/wp -content / uploads / 2020/06 / image-22-300x168.png 300w "tamaños =" (ancho máximo: 746px) 100vw, 746px

Si consideramos el ejemplo anterior de 1 Comandante y 3 Tenientes, entonces el Comandante es un traidor que arruinará las cosas al ordenar al Teniente 1 y 3 que "ataquen" y al Teniente 2 a "retirarse".

Como todos los lugartenientes son leales, cada uno de ellos recibió 2 ataques y 1 orden de retirada. Por lo tanto, todos atacan y aceptan el consenso, incluso si el comandante es un traidor.

Supongamos que hay 2 generales leales y 2 traidores, no hay posibilidad de que se llegue a un consenso. Por lo tanto, de acuerdo con el trabajo de investigación, el algoritmo es válido solo cuando el número de traidores no excede más del 33%, que es 1/3 de los generales.

Ahora apliquemos este contexto a blockchains donde cada general es un nodo de red y la ciudad es la red blockchain. Tienen que llegar a un consenso sobre el estado actual del sistema. En el caso de un sistema distribuido, la única forma de llegar a un consenso es tener 2/3 de los nodos de red leales y honestos. Si no, el sistema puede experimentar fallas y ataques.

Cuando un sistema puede tolerar las fallas bizantinas y aún llegar a un consenso, entonces se dice que es tolerante a fallas bizantinas.

Comprendamos la tolerancia bizantina a las fallas mucho más profundamente.

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

La tolerancia a fallas bizantinas es una característica de un sistema distribuido que tolera todas las fallas bizantinas y acepta el consenso. Su objetivo es disminuir el efecto de los nodos maliciosos en los nodos honestos y ayudar al sistema a alcanzar el consenso. BFT se deriva del problema del general bizantino.

Tolerancia a las fallas bizantinas es aplicable en sistemas de motores de aviones, plantas de energía nuclear y casi cualquier sistema con acciones que dependen de muchos sensores. Los sistemas basados ​​en blockchain también usan la tolerancia bizantina de fallas para establecer la confianza entre sus nodos.

Si bien tenemos una visión general del concepto BFT, comprendamos cómo el consenso encaja en el contexto de la tecnología blockchain.

Consenso en Blockchain

La tecnología Blockchain es conocida por su seguridad, transparencia y privacidad. No hay una autoridad central que controle las transacciones en la cadena de bloques, incluso entonces se considera la plataforma más segura y verificada. Se debe al protocolo de consenso presente como la parte central de la red Blockchain.

Un algoritmo de consenso es aquel a través del cual todos los nodos de la red blockchain acuerdan una decisión común que ayuda a lograr el consenso. Estos algoritmos crean confianza entre los nodos desconocidos de la red blockchain. Los objetivos del protocolo de consenso son llegar a un acuerdo, colaboración, cooperación, igualdad de derechos para cada nodo y participación obligatoria de cada nodo en el proceso de consenso.

Todos los nodos aceptan un acuerdo común debido al Algoritmo de consenso. Hay varios tipos de algoritmos de consenso:

Prueba de trabajo es el algoritmo de consenso original en la red Blockchain que confirma las transacciones y crea nuevos bloques para la cadena. El algoritmo de Prueba de trabajo (PoW) necesita potencia computacional para resolver acertijos digitales para encontrar el hash requerido. Una vez que se encuentra el hash requerido, se agrega, se agrega un nuevo bloque a la cadena de bloques. Bitcoin es la famosa aplicación de Prueba de trabajo. Bitcoin logra el consenso utilizando el algoritmo de consenso de Prueba de trabajo. Vamos a entender cómo es posible.

Bitcoin logra consenso

En la etapa inicial de agregar un bloque a la cadena, un nodo debe someterse a un cálculo costoso para demostrar que tiene un valor hash válido para el bloque. El resto de los nodos que reciben este bloque pueden verificar que el bloque sea válido.

Todos los nodos que realizan el proceso de validación trabajan en paralelo, pero el que es más rápido y tiene la mayor capacidad de computación gana la carrera. Por lo tanto, el ganador es recompensado con Bitcoins.

En este escenario, los nodos que realizan la tarea se llaman mineros, mientras que el proceso se llama minería. Por lo tanto, el consenso en Bitcoin se logra a través del proceso de minería.

La criptomoneda, Ethereum pronto planea cambiar a Prueba de participación de Prueba de trabajo. Las dos plataformas tienen mecanismos similares, donde ofrecen recompensas de criptomonedas a los nodos que verifican y almacenan transacciones. La diferencia es que la Prueba de participación depende de la cantidad de criptomonedas que tenga el usuario. Además, el proceso de minería reemplaza a los mineros con validadores.

Ethereum logra consenso

Ethereum utiliza el protocolo Casper del algoritmo PoS para lograr el consenso. Los validadores sostienen una porción de sus éteres como estaca. Más tarde, comienzan a validar los bloques, y una vez que encuentran un bloque que encaja en la cadena, lo validan colocando una apuesta en él.

Si el bloque se une con la cadena, los validadores serán recompensados ​​con la cantidad asociada con la apuesta. Por lo tanto, Ethereum logra el consenso. Si el validador actúa maliciosamente, su apuesta se cortará inmediatamente.

Prueba de participación delegada (DPoS)

En el algoritmo de Prueba de participación delegada, los titulares de tokens votarán por los productores de bloques. El grupo de productores que logran votos máximos puede organizar la generación de bloques. La criptomoneda, EOS usa este algoritmo para aumentar a millones de transacciones por segundo.

EOS logra consenso

Los titulares de tokens seleccionan a los productores de bloques a través del proceso de votación. Cualquiera puede ser un contendiente de la elección del productor de bloques y, si ganan, pueden producir bloques. Se eligen 21 productores de bloques en este proceso. Entre ellos, se eligen automáticamente 20, mientras que el 21 se elige proporcionalmente al número de sus votos en relación con los otros productores.

Para equilibrar la conectividad entre todos los demás productores, se mezclan usando un número pseudoaleatorio que se deriva del tiempo de bloqueo. El tiempo de bloqueo es de 3 segundos y si el productor no participa dentro de ese tiempo, serán eliminados de la consideración. Para tener en cuenta, el productor debe producir al menos un bloque cada 24 horas.

Por lo general, el sistema DPoS tiene una participación del 100% de los productores de bloques. La transacción se confirma dentro de 1,5 segundos desde el momento de la retransmisión con un 99,9% de certeza. Para lograr una certeza absoluta, los nodos deben esperar solo a 15/21 productores de bloques para aceptar el consenso.

Prueba de tiempo transcurrido (PoET)

El algoritmo Prueba de tiempo transcurrido es una alternativa al algoritmo Prueba de trabajo. Las redes de blockchain autorizadas usan el algoritmo PoET. Este algoritmo sigue una estrategia en la que cada participante de la red recibe un objeto de temporizador aleatorio y el primer temporizador que expira será el líder del nuevo bloque.

Para verificar la lealtad de cada participante, es necesario comprender si el ganador eligió su propio tiempo de espera y si realmente terminó la cantidad especificada de tiempo de espera. Por lo tanto, para garantizar esta lealtad, PoET utiliza las Extensiones de protección de software de Intel, que permiten a las aplicaciones ejecutar un código confiable en un entorno protegido.

Para lograr el consenso, un nodo descarga el código y genera una clave para el código. Luego, el nodo reenvía esta clave a la red participante, donde los nodos existentes verificarán la clave. Este nuevo nodo recibirá un objeto de temporizador aleatorio con el valor aleatorio asociado a él. La aleatoriedad del objeto temporizador está garantizada por la protección de código que ofrece SGX.

El primero en terminar el temporizador será el ganador, que puede crear un nuevo bloque y adjuntarlo a la cadena de bloques actual para ser recompensado. Los nodos se inicializan nuevamente.

Prueba de autoridad (PoA)

El algoritmo de prueba de autoridad inicia soluciones prácticas y eficientes para redes blockchain. En este algoritmo, los validadores están apostando su reputación en lugar de sus activos digitales. El algoritmo se basa en un grupo de "Autoridades" donde solo los validadores preaprobados pueden producir nuevos bloques.

Los usuarios que deseen formar parte de las autoridades deben revelar sus identidades. Pueden hacerlo, registrándose en la base de datos de notario público con la misma identidad que tienen en la plataforma. El proceso de selección se basa en reglas estándar para garantizar que todos los candidatos tengan las mismas oportunidades de alcanzar una posición privilegiada. El concepto de PoA es válido para redes privadas en lugar de una red pública.

Para mejorar los mecanismos BFT originales, surgió la Tolerancia práctica a la falla bizantina. Comprendamos este mecanismo en detalle.

Tolerancia práctica a fallas bizantinas (pBFT)

El aumento de ataques maliciosos y errores de software se debe al crecimiento en el tamaño y la complejidad del software. Estos errores y ataques pueden causar que los nodos defectuosos exhiban un comportamiento bizantino. Por lo tanto, para evitar esto, es necesaria la tolerancia bizantina a las fallas.

Tolerancia práctica a fallas bizantinas (pBFT)

Castro y Liskov publicaron un artículo en 1999 que presentaba la tolerancia práctica a las fallas bizantinas. pBFT ofrece una práctica réplica de máquina de estado bizantina de nodos maliciosos, suponiendo que haya fallas de nodos independientes y mensajes maliciosos enviados a través de nodos específicos. El objetivo de pBFT es resolver todos los problemas asociados con la tolerancia a fallos bizantinos.

¿Cómo funciona el físico Tolerancia a las fallas bizantinas (pBFT) trabajo?

El algoritmo pBFT funciona en sistemas asincrónicos como Internet y está optimizado para un bajo tiempo de sobrecarga. Además, hay un aumento mínimo en la latencia. Todos los nodos en el sistema pBFT están en orden secuencial, siendo un nodo el nodo primario y el resto de los nodos de respaldo.

Estos nodos se comunican entre sí con el objetivo de que todos los nodos honestos acuerden un consenso utilizando la regla de la mayoría. Si bien estos nodos se comunican, deben demostrar que los mensajes provienen de un nodo par específico y también asegurarse de que no se modificaron durante la transmisión. El número de nodos maliciosos no debe ser igual o superior a un tercio de los nodos en el sistema. Similar al Algoritmo de Prueba de Consenso, es mejor tener más nodos en la red pBFT para garantizar una mejor seguridad.

De acuerdo con el documento práctico de tolerancia a fallas bizantinas:

"El algoritmo ofrece vitalidad y seguridad como máximo ((n-1) / ⅓) de un total de norte Las réplicas son simultáneamente defectuosas. Esto significa que los clientes eventualmente reciben respuestas a sus solicitudes y esas respuestas son correctas de acuerdo con la linealización ”.

Las rondas de consenso pBFT se reducen a 4 fases. Sigue el formato de "Comandante y Teniente" donde todos los generales son iguales debido a la presencia del nodo líder. Las fases incluyen:

  1. Un cliente envía una solicitud al nodo líder para realizar una operación específica.
  2. El nodo líder transmite la operación a los nodos de respaldo.
  3. Los nodos de respaldo realizan la operación solicitada y luego envían una respuesta al cliente.
  4. La operación es exitosa solo si el cliente recibe n + 1 respuestas de diferentes nodos de la red con el mismo resultado, donde n es el número máximo de nodos permitidos defectuosos.

Los nodos se liquidan y comienzan en el mismo estado. El resultado final es que todos los nodos honestos llegan a un acuerdo y lo aceptan o lo rechazan. El líder se cambia durante cada vista y se cambia mediante un protocolo de cambio de vista si el nodo líder no ha emitido la solicitud durante un período de tiempo predefinido. En caso de cualquier emergencia, la mayoría de los nodos honestos pueden votar sobre la credibilidad del nodo líder y reemplazarlo con el siguiente nodo en línea.

Ventajas de la tolerancia física a las fallas bizantinas

La tolerancia práctica a fallas bizantinas (pBFT) es más superior a varios otros modelos de consenso. Vamos a entender qué son:

Finalidad de la transacción: Las transacciones se pueden aprobar y finalizar sin la necesidad de confirmaciones como en los modelos de Prueba de trabajo. Supongamos que el bloque propuesto acordado por los nodos en un sistema pBFT, ese bloque está finalizado. Es posible porque todos los nodos honestos acuerdan el estado del sistema en ese momento específico después de comunicarse entre sí.

Mayor eficiencia energética: pBFT no necesita requerir cómputos intensivos en energía para lograr el consenso de la red. Proof-0f-work solo se usa para prevenir el ataque de Sybil, no de forma consensuada.

Baja varianza de recompensa: En PoW, solo el líder tiene la oportunidad de proponer el siguiente bloque, mientras que pBFT sigue la toma de decisiones colectiva donde cada respaldo puede votar para elegir al líder. Por lo tanto, cada nodo en el sistema pBFT será recompensado.

Limitaciones de Tolerancia práctica a fallas bizantinas (pBFT)

Si bien hay ventajas prometedoras de Tolerancia práctica a fallas bizantinas (pBFT), también debería haber algunas limitaciones. Vamos a entenderlos más profundamente:

  • El mecanismo pBFT funciona bien con grupos pequeños de consenso. Para mantener la red segura, cada nodo debe comunicarse con otros nodos, como resultado de lo cual se produce un enorme costo de comunicación a medida que aumenta el número de escalas de nodos.
  • Los modelos pBFT son vulnerables a los ataques de Sybil. En este ataque, una sola parte puede manipular una gran cantidad de nodos en la red para comprometer la seguridad. Cuando el tamaño de la red es mayor, esta amenaza puede reducirse. Pero, el mecanismo pBFT no admite redes grandes. Por lo tanto, se puede optimizar o debe usarse en combinación con otro mecanismo de consenso.

¿Qué plataformas implementan? Tolerancia práctica a fallas bizantinas (pBFT)?

Varias plataformas de blockchain usan una versión optimizada o híbrida de pBFT como su modelo de consenso o al menos una parte de él junto con otro mecanismo de consenso. Actualmente, Zilliqa e Hyperledger son los dos proyectos que utilizan Tolerancia física a las fallas bizantinas (pBFT). Profundicemos en el concepto:

Zilliqa

Zilliqa emplea la versión optimizada de pBFT clásica combinada con una ronda de consenso de PoW cada ~ 100 bloques para realizar el fragmentación de la red. Cada fragmento puede procesar transacciones en paralelo, lo que resulta en un alto rendimiento para la red. Esta red utiliza firmas múltiples para reducir la sobrecarga de comunicación de pBFT clásico. Además, en sus propios entornos de prueba, han alcanzado algunas transacciones por segundo.

Hyperledger

Hyperledger Fabric es un entorno colaborativo de código abierto para proyectos de blockchain. La Fundación Linux alojó estos proyectos utilizando una versión permitida de pBFT para la plataforma. Las cadenas de bloques autorizadas utilizan pequeños grupos de consenso y no requieren la misma descentralización que las cadenas de bloques públicas. Además, Practical Byzantine Fault Tolerance ofrece transacciones de alto rendimiento de manera más efectiva.

Las cadenas de bloques autorizadas generalmente tienen un elemento de confianza entre las partes. Por lo tanto, eliminando la necesidad del entorno sin confianza y permitiendo que la red obtenga el Tolerancia práctica a fallas bizantinas (pBFT) ventajas sin limitaciones.

Conclusión

El problema del general bizantino dio origen al sistema bizantino de tolerancia a fallas. Hoy en día, estos sistemas se utilizan ampliamente en el mercado. Además de la industria Blockchain, BFT tiene ciertos casos de uso que incluyen las industrias de aviación, espacio y energía nuclear. Bitcoin resuelve el problema general bizantino mediante su método de verificación descentralizado y se convierte en la criptomoneda más grande del mundo.

BFT en sistemas distribuidos y su integración a través del algoritmo práctico de tolerancia bizantina de fallas en los sistemas del mundo real sigue siendo un componente clave de infraestructura de las criptomonedas en la actualidad.

Encabezado de WorldMarkets