Título original: (Espera, ¿por qué necesitamos consenso nuevamente?)
Fuentes: Shresth Agrawal, Dionysis Zindros, k4m4, pod.network
Compilado por: Tia, Techub News
La idea errónea de que la Tierra es el centro del universo persistió durante siglos. La gente de aquella época creía que el sol, las estrellas y los planetas giraban alrededor de la Tierra. No fue hasta que pensadores valientes revelaron la verdad sobre el heliocentrismo que revolucionaron la astronomía, rompiendo así el modelo geocéntrico.
Al igual que en el mundo de la astronomía, en el mundo blockchain existe un malentendido de larga data: el consenso es una condición necesaria para establecer pagos descentralizados. Estamos atrapados en Bitcoin y Ethereum.
Las monedas descentralizadas requieren soluciones de consenso descentralizadas. —Libro blanco de Ethereum, 2014
El consenso es en realidad el enemigo. Al eliminar el consenso, podemos completar transacciones tan rápido como una búsqueda en Google.
Dilema del consenso
Eve ahorró sus Bitcoins para comprar su primer Tesla. Bob y Charlie son operadores de concesionarios Tesla.
Eve firma un mensaje para indicar que le está transfiriendo dinero a Bob. Bob recibe el pago firmado por Eve pero aún no se siente cómodo entregándole las llaves del auto. Porque Bob necesita asegurarse de que Eve no firme una transacción de pago a Charlie al mismo tiempo (gasto doble).
Figura 1: Eve intenta realizar un doble gasto para transferir las mismas fichas a Bob y Charlie.
Normalmente, el consenso de blockchain se utiliza para resolver el problema del doble gasto. El consenso toma las transacciones como entrada y las genera en algún orden global en el que la mayoría de los nodos están de acuerdo.
Figura 2: El consenso actúa como una caja negra, tomando como entrada un “mempool” desordenado de transacciones y generándolas en un orden en el que todos están de acuerdo.
Volvamos a Eva. La transacción que le paga a Eve a Bob se llama tx1 y la transacción que le paga a Charlie se llama tx2. La cadena de bloques garantiza el orden de las transacciones mediante consenso. Cuando se produce un doble gasto, la transacción que se empaqueta primero fuera del bloque es válida.
En una red donde sólo participa una parte, llegar a un consenso es sencillo: esa parte simplemente genera transacciones en el orden en que fueron recibidas. Pero en una red con dos o más partes involucradas, las diferencias en las condiciones de la red harán que las transacciones se reciban en un orden diferente. Más allá de esto, las partes malintencionadas pueden presentar deliberadamente puntos de vista contradictorios o introducir retrasos en la red. Entonces, ¿cómo llegamos a un acuerdo sobre un orden global?
Podemos utilizar un banco centralizado para gestionar todas las transacciones. Pero como no queremos depender de ningún intermediario confiable, elegimos un grupo de participantes llamados validadores y asumimos que más de dos tercios de ellos son honestos.
Los validadores llegan a un consenso a través de múltiples rondas de comunicación. De vez en cuando, se selecciona aleatoriamente un líder para proponer el orden global colocando las transacciones pendientes en bloques firmados por él. Los validadores restantes votan en los bloques del líder. Se consideran notariados los bloques que cuentan con las firmas de dos tercios de los validadores. Un líder malicioso podría censurar selectivamente las transacciones o incluso no crear bloques, lo que obligaría al proceso a comenzar de nuevo. Repetir este proceso iterativo varias veces permite que todos lleguen eventualmente a la misma secuencia. El proceso para llegar a un consenso es lento.
Por el contrario, las aplicaciones web son rápidas y solo requieren un único viaje de ida y vuelta: el cliente envía una solicitud HTTP y el servidor devuelve una respuesta HTTP.
¿Necesitamos una clasificación completa?
Reconsideremos: ¿es necesario que cada transacción sea parte del estado global?
Supongamos que hay dos transacciones de pago: Alice le paga a Bob y Charlie le paga a Dave. Dado que los dos pagos son independientes, en realidad se pueden ejecutar en cualquier orden. Es decir, no importa de qué manera se ejecute, el estado resultante permanece sin cambios.
Figura 3: El pago de Alice a Bob es independiente del pago de Charlie a Dave. Independientemente del orden en que se liquiden estas transacciones, los resultados siguen siendo los mismos.
El consenso puede resolver el problema del doble gasto, pero ¿podemos evitar los costos de demora que conlleva?
He aquí cómo. De manera similar al consenso, todavía se requiere un grupo de validadores y se supone que más de dos tercios de ellos son honestos. En lugar de acordar un pedido global, los validadores garantizan que las transacciones que reciben son válidas (según su vista local) al firmarlas. Siempre que la transacción sea confirmada por más de dos tercios de los validadores, es una transacción válida.
Eve envía dos transacciones de doble gasto al validador. En primer lugar, hay un grupo de validadores deshonestos que firmaron ambas transacciones al mismo tiempo. Luego, divide a los validadores honestos en dos grupos (asumiendo que cada grupo representa un tercio del número total de validadores) y envía diferentes transacciones a diferentes grupos (como una transacción a Bob al primer grupo y una transacción a Bob a el segundo grupo). grupo de transacciones enviadas a Charlie). Sin embargo, Eve todavía no pudo recolectar suficientes firmas para que estas dos transacciones realizaran un ataque de doble gasto.
Para visualizar nuevamente esta red distribuida, supongamos que la red tiene N validadores, menos de un tercio de los cuales son maliciosos.
Usuarios honestos: transmite una nueva transacción a todos los validadores y, después de recibir las firmas de más de dos tercios de los validadores, la transacción se considera completada y la transacción obtiene un certificado.
Validador honesto: mantiene una lista local de tokens no gastados y solo firma la primera transacción válida para el token.
Para completar un doble gasto, ambas transacciones de doble gasto deben obtener certificados, es decir, más de un tercio de los verificadores deben ser deshonestos.
Este protocolo sin consenso no requiere comunicación entre validadores, ¡solo un viaje de ida y vuelta por la red! Además, esta arquitectura ha sido bien estudiada en la literatura sobre blockchain, donde su término académico es transmisión por consenso.
¿Existen riesgos potenciales? Cuando Eve intenta gastar dos veces, el consenso ordenará sus transacciones globalmente y solo se aceptará la primera de las dos transacciones. Pero en el protocolo que describimos, no hay garantía de que todas las transacciones de Eve se completen finalmente. La cuenta de Eve puede incluso bloquearse permanentemente, ya que no tenemos que ofrecer ninguna garantía a las contrapartes.
Entonces, ¿por qué necesitamos nuevamente el consenso?
No tenemos un consenso.
Además de los pagos, protocolos de "bolsa" o de subconjuntos comunes (por ejemplo, subastas en cadena, votaciones, órdenes limitadas), flujos de información de solo anexo (social descentralizada, notarización) y protocolos que pueden expresarse como datos replicados libres de conflictos. Todos los tipos (gráficos sociales, sistemas de reputación, juegos) pueden ejecutarse sin un orden global. Muchos protocolos DeFi que se ejecutan actualmente y que dependen de pedidos también pueden ejecutarse sin pedidos globales.
Los pods eliminan el consenso, lo que permite un sistema descentralizado tan rápido como la búsqueda en Google y tan seguro como Bitcoin.
