Cómo llegar a un acuerdo: Diferentes tipos de consenso para Blockchain

En términos sencillos, una cadena de bloques son datos procesados y registrados por un grupo de ordenadores que trabajan juntos para garantizar la autenticidad y seguridad de estas transacciones de datos.

Pero, ¿cómo podemos asegurarnos de que estas transacciones son, de hecho, verificadas y seguras? Las cadenas de bloques son, por naturaleza, descentralizadas y distribuidas, lo que significa que no existe una autoridad central que ejerza el gobierno del sistema. Para garantizar que se siguen las normas del protocolo y evitar cualquier comportamiento poco ético, las cadenas de bloques aplican varios algoritmos para lograr lo que se conoce como consenso entre entidades sin confianza.

Definición rápida de consenso

El consenso puede definirse como el acuerdo de un grupo de agentes sobre sus estados comunes a través de la interacción local.

En el contexto de blockchain, el consenso es un procedimiento en el que los pares de una red Blockchain llegan a un acuerdo sobre el estado actual de los datos en la red. Son estos algoritmos de consenso los que establecen la fiabilidad y la confianza en los sistemas Blockchain.

Mientras que el consenso es bastante fácil de alcanzar en las redes centralizadas, en las que se confía en una autoridad de gobierno para validar las transacciones y salvaguardar los registros, es mucho menos sencillo en el caso de los sistemas descentralizados.

Consenso en Blockchain

La cadena de bloques funciona añadiendo bloques de datos y la esencia del consenso es garantizar que cada bloque que se añade a la cadena es la única versión de la verdad acordada por todos los nodos del sistema. Es una característica clave de la naturaleza descentralizada de blockchain.

Las reglas básicas para el consenso en blockchain incluyen:

• El objetivo de llegar a un acuerdo
• Colaboración, cooperación e igualdad de derechos para todos los nodos/pares, y
• Participación obligatoria de cada nodo en el proceso

Existen muchos enfoques diferentes para alcanzar el consenso en los sistemas descentralizados. Aquí examinamos distintas formas de ponerse de acuerdo y formar consenso.

Consenso Nakamoto

La madre de todos los consensos de blockchain, el protocolo de consenso Nakamoto fue ideado por Satoshi Nakamoto en 2009 como un nuevo medio para verificar la autenticidad de una red de blockchain y evitar el doble gasto. Es un algoritmo de consenso bizantino tolerante a fallos que funciona junto con la prueba de trabajo (PoW) para gobernar la blockchain de Bitcoin.

La tolerancia bizantina a fallos (Byzantine fault tolerance, BFT) es una condición en la que un sistema distribuido puede seguir siendo tolerante a fallos en presencia de agentes maliciosos e imperfecciones de la red.

Mientras que PoW se refiere al mecanismo criptográfico por el que los mineros compiten entre sí para resolver enigmas computacionales extremadamente complejos (y caros) con el fin de ganarse el derecho a validar un nuevo bloque y obtener una “recompensa por bloque”. Esta recompensa monetaria incentiva a los mineros a seguir las reglas y ser honestos, mientras que los costes de participación sirven como desincentivo económico para que ataquen la red Bitcoin, asegurando aún más la blockchain.

Mediante la combinación de BFT y PoW, Nakamoto trató de eludir algunos de los problemas inherentes a la escalabilidad de BFT, al tiempo que disuadía a los malos actores. Al crear una medida estándar para la validez de la cadena de bloques -en este caso, la cantidad de recursos computacionales (o “poder de hashing”) gastados en ella-, Nakamoto abrió una nueva vía para resolver el Problema del General Bizantino en una configuración sin permisos. Una que llevaría a la aparición de muchos nuevos algoritmos de consenso, como la prueba de participación (PoS), la prueba de autoridad (PoA), la prueba de reputación (PoR) y la prueba de importancia (PoI).

Prueba de X

La idea detrás de esta prueba de algo (PoX) consenso es utilizar algunos recursos escasos X donde los atacantes maliciosos no pueden obtener X fácilmente. De este modo, el sistema puede permanecer seguro de forma descentralizada y sin permisos. Así es como suele funcionar.

Para obtener el privilegio de validar transacciones y minar nuevas monedas, los nodos de una red PoX deben demostrar que han cumplido X criterios. A menudo, este proceso implica algún tipo de sacrificio. Por ejemplo, potencia y esfuerzo computacional en PoW, y monedas apostadas en PoS. De distintas maneras, sirven de incentivo para que los mineros sigan siendo honrados.

En general, PoX pertenece a la clase de consenso Nakamoto. El consenso Nakamoto normalmente toma las siguientes opciones de diseño:

• Tolerancia bizantina a fallos: las redes pueden seguir funcionando aunque algunos nodos fallen o actúen de forma maliciosa.
• Sincrónico: los mensajes se entregan en un plazo determinado.
• Probabilístico – los nodos se ponen de acuerdo sobre la probabilidad de que el valor sea correcto
• Basado en los líderes: los líderes son elegidos para validar las transacciones

Y, por tanto, puede conseguir las siguientes propiedades:

• Los compañeros pueden entrar y salir cuando quieran
• Se centra en la capacidad de respuesta (es decir, un compañero siempre puede producir nuevos bloques) a costa de la seguridad (es decir, la decisión tomada puede revertirse).
• Autofinanciación: los pares tienen incentivos para mantener la red.

Hay demasiados protocolos PoX para presentarlos todos. Los lectores interesados pueden leer nuestra guía para principiantes sobre mecanismos de consenso para obtener un resumen de los consensos PoX más conocidos en la actualidad.

Consenso clásico

El consenso clásico, en cambio, se alcanza mediante votación. Estos protocolos confirman las transacciones más rápido que los tipos de consenso Nakamoto comentados anteriormente, ya que el tamaño de la red de consenso es fijo y se puede avanzar en cuanto se ven los votos necesarios.

He aquí algunos ejemplos importantes de consenso clásico:

Tolerancia práctica bizantina a fallos (pBFT)

Introducida a finales de los años 90 por Barbara Liskov y Miguel Castro, la tolerancia práctica a fallos bizantinos(pBFT) pretende resolver muchos de los problemas asociados a las soluciones de tolerancia a fallos bizantinos (BFT) antes mencionadas.

pBFT utiliza una máquina de estados trifásica y una elección por bloques para seleccionar al líder. Las tres fases de la pBFT se conocen como pre-preparación, preparación y compromiso. Donde En el caso habitual, el consenso se consigue intercambiando mensajes entre nodos que aportan una transición progresiva a su estado local. De lo contrario, en caso de fallo de un nodo, se activará un “cambio de vista” que conducirá a una nueva selección del líder de forma rotatoria. pBFT es capaz de manejar menos de ⅓ de fallos bizantinos, esto puede verse como 3f+1= Total de nodos donde f=cantidad de fallos bizantinos.

Sin embargo, tiene algunas desventajas:

• Liderazgo débil – los nodos pueden rechazar las peticiones del líder y proponer la reelección, pero requiere servicios de autoridad para la selección del líder.
• Tolerancia bizantina a fallos: el 33% de los nodos pueden ser maliciosos.
• Baja escalabilidad de la red: debido a la elevada sobrecarga de comunicación y a la latencia de las rondas de mensajes múltiples, aumentar el número de nodos también incrementaría cuadráticamente la complejidad del sistema.
• Rendimiento de las transacciones: hasta 50.000 tx por segundo con un tiempo de confirmación de 1 segundo.
• Caso de uso – blockchain de consorcio con un validador autorizado limitado.

Tolerancia a fallos bizantina delegada (dBFT)

La tolerancia a fallos bizantina delegada (dBFT) fue propuesta por el proyecto NEO en 2014. A diferencia de pBFT, que requiere servicios de autoridad para seleccionar al líder, el sistema de votación de dBFT permite la participación a gran escala, de forma similar a la prueba delegada de participación (DPoS).

El procedimiento general de consenso es muy similar al de la pBFT, en lo que difiere es en la forma de contar los votos… En dBFT, el peso del voto es proporcional al número de fichas que los participantes poseían en el momento de la votación. Los participantes pueden delegar sus fichas (votos) en representantes de confianza. Esto mejora el rendimiento, pero también significa que podría centralizarse más con el tiempo debido a esta capa extra de representación. Una desventaja de este método es que los delegados elegidos ya no pueden ser anónimos. Los delegados en la blockchain NEO trabajan con identidades reales.

Acuerdo Bizantino Federado (ABF)

El acuerdo bizantino federado (FBA) es un algoritmo que admite la afiliación abierta, lo que permite a los validadores unirse libremente a la red. Destaca por su alto rendimiento, escalabilidad y bajos costes de transacción.

FBA puede considerarse un BFT sin permisos. Sin embargo, se requiere que una transacción sea firmada por un grupo específico de firmantes. En un sistema FBA, los validadores pueden elegir en qué otros validadores confían y a partir de ahí forman lo que se conoce como una porción de quórum. En un sistema con muchos validadores puede haber varios quorum slices y con múltiples quorum slices se produce solapamiento con algunos nodos que son de confianza en múltiples slices. Estos solapamientos se unen para formar el quórum general. Que se utiliza como método para llegar a un consenso en la FBA. Proyectos notables que utilizan FBA son Ripple(XRP) y Stellar(XLM).

Algunas ventajas de FBA son:

• Barrera de entrada baja, ya que la afiliación está abierta siempre que se pueda confiar en ella y unirse a una porción de quórum.
• Cualquiera puede entrar y salir en cualquier momento sin que el sistema deje de funcionar.

Balsa

Desarrollado por Diego Ongaro y John Ousterhout en 2014, Raft se basa en el protocolo Paxos y fue diseñado para ser más fácil de comprender e implementar. En comparación con muchos otros algoritmos de consenso, Raft tiene una mayor dependencia del líder. Los nodos confiarán en el líder una vez que los temporizadores aleatorios lo elijan, y será reelegido sólo si el líder actual falla.

Esto mejoró considerablemente las cosas:

• Liderazgo fuerte – los nodos no rechazarían las peticiones del líder, no hay reelección hasta que el líder no esté disponible.
• Tolerancia a fallos: el 49% de los nodos pueden bloquearse o dejar de estar disponibles.
• Alta escalabilidad de la red – La complejidad de este algoritmo de consenso es linealmente proporcional al número de nodos.

Ejemplos:

Consenso sin líderes

El último tipo de consenso que presentaremos es una nueva dirección emergente: el consenso sin líderes.

Como ya se ha dicho, por consenso se entiende el acuerdo de un grupo de agentes sobre sus estados comunes a través de la interacción local.

En un problema de consenso sin líder, no se necesita un líder virtual, mientras que en un problema de consenso con líder, se requiere un líder virtual que especifique el objetivo para todo el grupo. Más concretamente, el consenso con un líder virtual estático se denomina problema de regulación del consenso, y el consenso con un líder virtual dinámico se denomina problema de seguimiento del consenso.

Algunos ejemplos de proyectos de consenso sin líder son Avalanche, IOTA y NKN. Aquí presentaremos Avalanche e IOTA a alto nivel.

Avalancha

El whitepaper de Avalanche fue publicado de forma anónima a mediados de mayo de 2018 por un equipo que se identifica solo como Team Rocket. Más tarde, se fundó AVA Labs para desarrollar el token Avalanche (AVA), y se cree que un grupo de informáticos de la Universidad de Cornell (Emin Gün Sirer, Kevin Sekniqi, Ted Yin) están estrechamente relacionados con el proyecto.

Team Rocket calificó el protocolo de consenso de “nueva familia de protocolos de consenso metaestable para criptomonedas” y lo describió como “una nueva familia de protocolos de tolerancia a fallos bizantinos sin líder, construidos sobre un mecanismo metaestable”.

Avalanche utiliza un submuestreo aleatorio repetido para votar y llegar a un consenso. Cada nodo necesita muestrear un cierto número de vecinos para verificar sus estados y ver si se alinea con la mayoría. Si no, cambiarán de Estado siguiendo a la mayoría. El proceso se repetirá una y otra vez, de modo que, a la larga, toda la red llegará a una conclusión omnipresente.

Avalanche afirmó que su mecanismo de consenso podía alcanzar los 1.300 tps con una latencia de 4 segundos.

Según el equipo, se espera que la red principal de Avalanche se lance en septiembre de 2020.

IOTA

IOTA fue fundada en 2015 por David Sonstebo, Sergey Ivancheglo, Dominik Schiener y el doctor Serguei Popov. IOTA es una de las primeras monedas en proponer el uso de un grafo acíclico dirigido (DAG) como estructura de datos subyacente para una tecnología de libro mayor distribuido (DLT) en lugar de blockchain.

La versión actual de IOTA utiliza un protocolo llamado Tangle. El Tangle tiene las siguientes propiedades que son diferentes de las del bitcoin:

• Utiliza una estructura de datos basada en DAG para formar el grafo de transacciones en lugar de agrupar las transacciones en bloques encadenados.
• Elimina el papel de los mineros y exige que el usuario verifique dos transacciones anteriores (no confirmadas) si pretende enviar nuevas transacciones a la red.
• El consenso/voto se basa en información local y no requiere la interacción con toda la red. En su lugar, se consigue mediante un proceso de paseo aleatorio ponderado denominado cadena de Markov Monte-Carlo (MCMC)
• Sin embargo, el libro blanco no especifica claramente cómo puede alcanzarse el consenso en un entorno distribuido. De ahí que la red dependa hasta hoy de un “coordinador” centralizado, algo que la comunidad criptográfica ha criticado ampliamente.

Recientemente, la Fundación IOTA ha declarado su hoja de ruta llamada “Coordicide” para renovar el protocolo y eliminar al coordinador. Se propusieron dos consensos: el consenso probabilístico rápido (CPR) y el consenso celular (CC). Ambas soluciones pertenecen a la clase de consenso sin líder.

Consenso y ampliación de la cadena de bloques

Y ahí lo tienen, una visión general de los mecanismos de consenso más utilizados. Como todas las partes que mantienen una cadena de bloques en movimiento, aquí también podemos ver una clara evolución, desde el concepto original hasta versiones más rápidas y ágiles que ayudan a escalar las cadenas de bloques para velocidades más rápidas y redes más grandes. Si quieres saber más sobre las funciones básicas de blockchain, consulta también nuestros artículos sobre sidechains y cómo ayudan a construir mucho más que un sistema de pagos en la cadena.