Los días 11 y 12 de Mayo, la Beacon Chain de Ethereum dejó de finalizar transacciones. Esto es un suceso que nunca había sucedido en la red desde que se actualizó el mecanismo de consenso a PoS (Prueba de trabajo)
Para explicar bien el suceso, es importante entender previamente algunos conceptos que creo que vienen bien para ver clarificar este tema.
1️⃣ Clientes
2️⃣ Beacon Chain
3️⃣ Validadores
4️⃣ Finalización
5️⃣ El suceso
6️⃣ Fuga por inactividad
7️⃣ 3ra guerra mundial
8️⃣ Teorema del CAP
1️⃣ Clientes
Un cliente es un software o un hardware que permite a los usuarios interactuar de manera remota con otras entidades sobre la red. Conectarse al servidor en una arquitectura cliente-servidor o al resto de nodos de la red en entornos peer-to-peer.
Algunos ejemplos web2 son los web browsers como Chrome, Brave, Opera y demás. Estos hacen llamadas a servidores web para acceder a páginas, imágenes y demás. También las interfaces se podría considerar Gmail o Microsoft Outlook. Un ejemplo de cliente hardware podría sería un dispositivo Chromecast conectado a un VoD (Video On Demand)
En el mundo blockchain un cliente es un software que permite a los usuarios interactuar con una red actuando como nodos, los que permiten almacenar, transmitir y procesar transacciones y datos en la cadena de bloques.
Los clientes están escritos en diferentes lenguajes y los principales son:
Geth ➡️ escrito en Go
Parity ➡️ escrito en Rust
Nethermint ➡️ escrito en .NET
Asimismo, existen varios tipos de clientes:
Clientes completos: Tienen una copia completa de toda la cadena de bloques de la red. Suelen requerir bastantes recursos. Bitcoin core son 400Gb y Geth para Ethereum puede rondar varios Terabytes.
Los clientes ligeros: conocidos como SPV (Simplified Payment Verification) Solamente tienen cierta parte de la información. En ethereum normalmente incluyen: Cabeceras (nº de bloque, el hash del bloque anterior), transacciones y estados de cuentas.
Clientes remotos: Aunque es casi un cliente ligero, difiere en que no almacena una copia de la cadena de bloques de Ethereum. NO valida transacciones. Los clientes remotos dependen de clientes completos y ligeros para acceder a la red de Ethereum.
Actúan como wallets para enviar y recibir tokens . Un ejemplo: MetaMask. Una billetera «browser». Para seguridad, utiliza su cliente ligero para comunicarse con el cliente remoto.
2️⃣ Beacon Chain
La Beacon Chain fue el nombre que se le dio a la blockchain PoS (Proof of Stake) lanzada en 2020. Se creó para asegurar que la lógica del mecanismo de consenso PoS fuera sólido y sostenible antes de habilitarla en mainnet en paralelo con la red PoW de Ethereum.
El cambio de PoW a PoS requería orientar a la Beacon Chain para que aceptara transacciones de la cadena ppal, las agrupara en bloques y luego las organizara en una cadena. A la vez los clientes dejaron de minar y proponer bloques transfiriendo estas funciones a la Beacon Chain.
A este evento es el famoso «The Merge». Una vez que sucedió el merge, ya no había dos blockchains; solo existía una cadena de bloques basada en PoS.
3️⃣ Nodos
Se consideran a los nodos como «ordenadores». Estando la red compuesta por estos, que corren el software de un cliente para verificar bloques y Tx. Los nodos garantizan que se cumplan las reglas de consenso dentro de la red de Ethereum. Actualmente hay 415k.
Una red bien distribuida de nodos es importante para la seguridad de la red como veremos más adelante. Un mayor número de nodos significa una red más descentralizada (menos dependiente). Un mayor número de nodos es útil para reducir la latencia en el intercambio de bloques.
Alguno de los requisitos para montar un nodo completo en Ethereum sería: – 8 GB RAM – 2TB SSD – CPU multi-core (4 minimo) – 20/25 Mbit por segundo de ancho de banda – 32 Ethers. (60k euros aprox).
4️⃣ Finalización
La finalización se refiere a una propiedad fundamental de las blockchains donde al completarse un bloque, las transacciones que pertenecen a ese bloque, permanecen inmutables y almacenadas en la cadena junto con el resto de bloques anteriores.
Para poder validar transacciones en Ethereum, se tiene que conseguir que 2/3 de los validadores de la red estén de acuerdo y voten por los mismos bloques. Cuando esto no sucede, la finalización se retrasa como es el problema visto durante esta semana.
5️⃣ El suceso
Durante los días 11 y 12 de Mayo, la Beacon Chain dejó de «finalizar» y no se validaron Tx durante 3 y 8 epochs (30 minutos y 1h y 30 minutos) respectivamente. Esto supuso un retraso, NO un STOP, como se ha comentado. NO tuvo trascendencia en los usuarios.
Esto es un TEST Test en mainnet de la variedad de los clientes que tiene Ethereum. (Que no exista un cliente «caudillo») Con esto se intenta prevenir de que exista un cliente que tenga la inmensa mayoría de nodos a su merced y que pueda ocasionar problemas en la red, like now.
Para solucionar esto, los nodos cambiaron de cliente. Se actualizaron a otros clientes más pequeños con algún parche que solucionase el bug, aun desconocido, que tuvo en el código el software de ciertos cliente. Imagen de la parada del día 12.
De esta forma, si los nodos se cambian de cliente a uno que siga operativo, podrán: – Participar en la validación de los bloques – Solventar el problema de requerimiento de consenso (2/3 de la red deben «estar de acuerdos en el bloque») – Recibir recompensas «por su esfuerzo»
Los clientes afectados (uno de ellos de Consensys) han introducido parches sobre el código afectado para intentar mitigar el problema. Al resto de nodos se ha recomendado migrar a otros clientes que hayan podido finalizar y no hayan tenido estos problemas. Por ejemplo: Besu o Lodestar
¿Y POR QUÉ los nodos se cambian de cliente? Buena pregunta 🙂 Los nodos reciben recompensas por proponer y votar la inclusión de nuevos bloques en la cadena. dejan de ser recompensados si el cliente está abajo. No es algo que «llene de alegría» a los nodos que ven como
De hecho, no finalizar es una de las mayores preocupaciones de los nodos validadores (y de tantos otros). En Ethereum, existe un evento (como mínimo interesante) en el propio mecanismo de consenso que se activa cuando Ethereum no consigue finalizar transacciones durante 4 épochs.
6️⃣ Fuga por inactividad
¿Se puede quedar la red de Ethereum en un proceso de no finalización? Si, puede. Y se conoce por el nombre anterior.
La idea principal de esta fuga por inactividad fue propuesta en primera instancia en el paper de Casper de Vitalik (Donde de se habla de la modificación de la finalización de PoW a PoS en blockchains «activas».) arxiv.org/abs/1710.09437
La fuga por inactividad es una medida diseñada para incentivar a los validadores a mantenerse activos en la red y participar de manera continua en el consenso. Llegó en Ethereum 1.0 o PoW y se ha mantenido hasta ahora.
El objetivo es penalizar a los validadores que se desconectaban o no cumplían con sus labores: – Proponer bloques – Validar transacciones Se hace porque para llegar al threshold del consenso se necesitan 2/3 del stake de la red que estén de acuerdo y voten por lo mismo.
Si se llega al tiempo suficiente para entrar en este «modo» La penalización implica la disminución gradual del depósito (stake) de los validadores. DE TODOS. A medida que pase más tiempo sin actividad, el nodo validador va perdiendo parte de su participación.
Penalizando de manera exponencial (según un método matematico) a los que mantengan sin votar frente a los que si que cumplan con sus obligaciones. Es decir, pringas aunque sigas validando… Imagina si dejas de validar
Como en china vaya. Te ponen un «score» con tu puntuación de inactividad. Esto se hace, entre otras cosas, para quitar poder de validación a ciertos nodos (quemarles su stake) y así epoch a epoch poder volver a conseguir el consenso del 66%.
7️⃣ 3ra Guerra Mundial
Esta bacalá viene para preservar la integridad de la cadena a largo plazo contra eventos catastróficos. Con ello se consigue que la beacon chain pueda separase permanentemente en dos cadenas independientes.
Un outcome razonable para un evento que no pueda solucionarse en un par de semanas o meses. También se observa que la cadena prioriza la disponibilidad sobre la consistencia. Dos de los tres pilares del verdadero «trilema de la blockchain»
8️⃣ Teorema CAP
Formulado por el científico Eric Brewer en 2000. Establece que es IMPOSIBLE que un sistema distribuido (descentralizado) proporcione simultáneamente estas tres características: – Consistencia – Disponibilidad – Tolerancia a particiones en caso de fallas de red.
Consistencia: Se refiere a que todos los nodos de un sistema distribuido ven los MISMOS datos en TODO momento Si se realiza una operación de escritura, las lecturas posteriores deben reflejar ese cambio Puede haber lags temporales debido a la sincronización entre nodos.
Disponibilidad: Un sistema distribuido debe estar en todo momento disponible y responder a las solicitudes, incluso en caso de fallos o interrupciones parciales. Garantizar la disponibilidad puede implicar la posibilidad de tener datos no actualizados en algunos nodos.
Tolerancia a particiones: Capacidad de un sistema para seguir operando a pesar de la pérdida de conexión o fallas que pueden generar particiones en el sistema Es probable que pase esto, y un sistema tolerante a particiones puede continuar operando y brindando servicios.
