Análisis de las breves anomalías de Ethereum durante dos noches consecutivas

En las noches del 11 y 12 de mayo, la capa de consenso de Ethereum experimentó breves anomalías. El análisis indica que esto se debió principalmente a la sobrecarga de ciertos nodos de clientes de la capa de consenso de Ethereum, lo que llevó a que los nodos validadores se cayeran y se desconectaran. Esto afectó directamente a la votación de Epoch, que no pudo alcanzar el umbral de 2/3, impidiendo que la capa de consenso confirmara la finalización. Sin embargo, la red de Ethereum se recuperó por sí misma en un corto período de tiempo, lo que también refleja la resiliencia y capacidad de autorreparación del algoritmo de consenso PoS de Ethereum.

Revisión de eventos

Normalmente, el estado de la red de consenso PoS de Ethereum se establece en 2 Epochs. Sin embargo, la semana pasada hubo dos ocasiones de retraso en la confirmación de Epochs:

• 11 de mayo: La confirmación de Epoch se retrasó 3 Epochs, aproximadamente 20 minutos.
• 12 de mayo: La confirmación de Epoch se ha retrasado 8 Epoch, aproximadamente 51 minutos.

Durante este período, la red Ethereum continuó generando bloques y procesando transacciones. Sin embargo, debido a la insuficiencia en la tasa de votación de los nodos validadores, el Epoch no pudo ser confirmado, es decir, no pudo alcanzar el nivel de garantía de seguridad del consenso de la red PoS de Ethereum. Esto significa que, en casos extremos, las transacciones dentro de ese epoch podrían ser revertidas.

En realidad, durante este período, la red Ethereum no experimentó bifurcaciones, y los nodos validadores tampoco realizaron votaciones maliciosas. La falta de suficiente tasa de votación debido a la gran cantidad de nodos validadores fuera de línea es la razón directa por la que no se pudo confirmar el Epoch. Se observó que los nodos validadores fuera de línea presentaron situaciones anómalas de sobrecarga de CPU.

En el segundo evento, debido a que la confirmación se retrasó más de 4 Epochs, se activó el mecanismo de fuga de inactividad del algoritmo de consenso de Ethereum:

• Se penaliza a los nodos de validadores que están fuera de línea, reduciendo sus fondos de participación, aproximadamente 28 ETH fueron confiscados.
• Se cancelan las recompensas de Attestation, aproximadamente 50 ETH no fueron emitidos.
• Este mecanismo asegura que los validadores en línea finalmente puedan controlar 2/3 de los fondos totales de staking de Ethereum, lo que permite que el estado de la red se confirme finalmente.

Análisis de causas

La causa directa de este evento fue la sobrecarga de ciertos nodos de cliente de capa de consenso de Ethereum, lo que provocó que los nodos de validadores se cayeran y se desconectaran, impidiendo llevar a cabo la votación de consenso de manera normal. El análisis específico es el siguiente:

Cuando se recibe una atestación ( que apunta a un bloque antiguo, los nodos necesitan recalcular el estado de la cadena de balizas para verificar estas atestaciones, lo que consume una gran cantidad de recursos de CPU y memoria. Cuando se reciben muchas atestaciones que apuntan a bloques antiguos al mismo tiempo, los recursos de CPU y memoria de los nodos se agotan, lo que provoca que estos nodos validadores se caigan y se desconecten.

Teóricamente, este tipo de problemas se pueden resolver mediante un caché basado en las atestaciones que apuntan a bloques. Sin embargo, debido al crecimiento del número de validadores y la aparición de una gran cantidad de atestaciones de este tipo, el caché de la implementación del cliente que presenta problemas se ve sobrepasado, lo que obliga a los nodos a consumir una gran cantidad de recursos para recalcular el estado de la cadena de beacon.

Los clientes de la capa de consenso Teku y Prysm han lanzado versiones de parche para resolver este problema. La implementación del cliente de la versión de parche filtrará estos testigos obsoletos, es decir, ignorará el testigo cuando se cumplan las siguientes condiciones:

• El testigo apunta a un Slot obsoleto
• Un testigo señala un Checkpoint que nunca ha visto un nodo.

![¿Por qué Ethereum sufrió cortos periodos de inactividad durante dos noches consecutivas? Un análisis de las causas del evento])https://img-cdn.gateio.im/webp-social/moments-93dc511107c2b8ba99b85fe1c242b76b.webp(

Ventajas del diseño de Ethereum

En este evento, Ethereum mantuvo su disponibilidad, continuando produciendo bloques y procesando transacciones, solo retrasando la confirmación de Epoch. Esto se debe principalmente a dos puntos:

1. La diversidad de clientes de Ethereum
2. Diseño del algoritmo Gasper

) La diversidad de los clientes de Ethereum

Aunque los clientes Teku y Prysm tienen problemas, esto no afecta el funcionamiento normal de otros clientes de la capa de consenso. Por ejemplo, el cliente Lighthouse no se ve afectado en esta ocasión. Dado que existen diferencias en el diseño de implementación entre los diferentes clientes, todavía hay nodos de validadores que funcionan normalmente.

La diversidad de clientes de Ethereum asegura que: incluso si ciertos clientes tienen problemas ### e incluso conducen a que el Epoch no pueda ser confirmado (, no afectará a los clientes normales que generan bloques y procesan transacciones, garantizando así la disponibilidad de Ethereum.

) Diseño de la usabilidad del algoritmo de consenso Gasper

Garantizar la disponibilidad de Ethereum es uno de los puntos de partida del diseño del algoritmo Gasper, que separa la producción de bloques de la finalización. Por lo tanto, incluso si la finalización de bloques se ve obstaculizada, la producción de bloques no se detendrá. Teniendo en cuenta que en la mayoría de los casos la finalización de bloques finalmente se restaurará, el impacto real en los usuarios es muy pequeño.

En comparación, otros algoritmos de consenso BFT, cuando fallan en la confirmación del bloque, los nodos de consenso detendrán la producción del siguiente bloque, lo que resulta en que toda la cadena de bloques no esté disponible durante este período.

Además, el segundo evento activó el mecanismo de Inactivity Leak, el cual está diseñado para asegurar que Ethereum pueda volver a sellar bloques incluso bajo condiciones extremas donde ### una gran cantidad de validadores estén desconectados durante mucho tiempo (.

![¿Por qué Ethereum ha tenido cortos apagones durante dos noches consecutivas? Un análisis del origen del evento])https://img-cdn.gateio.im/webp-social/moments-3bbc1797156b2a00d2fe30c0b5c1a567.webp(

Experiencia y Revelaciones

) El desafío de múltiples clientes de Ethereum

La diversidad actual de los clientes de Ethereum aún necesita ser promovida y publicitada. Si los clientes logran ser lo suficientemente diversos, de modo que la proporción de Prysm y Teku sea inferior a 1/3, entonces este evento ni siquiera ocurriría ###2/3 clientes funcionando normalmente son suficientes para confirmar Epoch (.

Además, cuando un cliente tiene un problema, cómo los nodos validadores pueden cambiar de manera segura a una implementación de cliente normal también es un problema que necesita ser resuelto. Este proceso implica:

• Migrar de forma segura la clave de verificación del cliente con problemas al cliente normal
• Asegúrate de que el comportamiento del cliente antiguo sea consistente con el del cliente nuevo para evitar ser penalizado.

) Monitoreo del consenso de Ethereum

Se necesita un servicio similar a Safe Head para monitorear continuamente el estado en tiempo real de la red PoS de Ethereum, para detectar y advertir sobre tales eventos con anticipación, en lugar de esperar a que el Epoch no se confirme como se esperaba para darse cuenta de que el estado de la red es anormal.

Introducción al algoritmo de consenso de Ethereum

Este incidente expuso la necesidad de popularizar el mecanismo de consenso PoS de Ethereum. Muchos usuarios creyeron erróneamente que "Ethereum había caído", causando un pánico innecesario. En realidad, la red Ethereum ha estado generando bloques y procesando transacciones de manera continua. La divulgación de conocimientos sobre blockchain orientada al usuario sigue siendo una dirección en la que los profesionales deben esforzarse continuamente.

sobre las aplicaciones de Ethereum

Aunque la red de Ethereum es lo suficientemente robusta, la inestabilidad ocasional puede tener cierto impacto en las aplicaciones. Las aplicaciones necesitan manejar correctamente estos escenarios de inestabilidad:

• El tiempo de depósito de Layer1 a Layer2 puede alargarse.
• El tiempo de recarga en el intercambio puede prolongarse
• Existe el riesgo de que las cotizaciones en la cadena de Oracle sean revertidas, por lo que los servicios de alto valor que dependen de ellas deben ser suspendidos adecuadamente.
• Algunas aplicaciones DeFi pueden necesitar pausar ciertas funciones

Resumen

Este evento mostró la resiliencia y la capacidad de auto-reparación del algoritmo de consenso PoS de Ethereum, así como la rápida respuesta y capacidad de corrección de errores del equipo de clientes. Para el ecosistema de Ethereum, se necesita seguir invirtiendo en las siguientes áreas: aumentar la diversidad de clientes, optimizar el monitoreo y la alerta en tiempo real del estado de la red, profundizar la educación de los usuarios y mejorar los planes de emergencia de los participantes del ecosistema ante anomalías en la red.

![¿Por qué Ethereum ha tenido caídas breves durante dos noches consecutivas? Un análisis de las causas del evento]###https://img-cdn.gateio.im/webp-social/moments-b286aa6918497b555cf460e5c4e5f0cb.webp(