Análisis de anomalías breves en la capa de consenso de Ethereum durante dos noches consecutivas

Recientemente, la capa de consenso de Ethereum experimentó una breve anomalía, lo que generó una amplia atención en la industria. Este artículo realizará un análisis en profundidad del evento.

Resumen del evento

En las noches del 11 y 12 de mayo, se produjo una breve anomalía en la capa de consenso de Ethereum. El análisis muestra que esto se debió principalmente a una sobrecarga en ciertos nodos de clientes de la capa de consenso de Ethereum, lo que llevó a que el nodo de validación (Validator) se cayera y se desconectara. Esto afectó directamente la votación de Epoch, impidiendo que alcanzara el umbral necesario de 2/3, lo que provocó que la capa de consenso no pudiera confirmar la finalización.

Es importante señalar que, a pesar de las anomalías, la red Ethereum se recuperó a la normalidad en poco tiempo. Esto refleja la resiliencia y la capacidad de auto-reparación del algoritmo de consenso PoS de Ethereum.

Detalles del evento

Normalmente, el estado de la red de consenso PoS de Ethereum se confirma en 2 Epochs (Finalizado). Pero en los dos eventos de la semana pasada, hubo un retraso en la finalización del Epoch:

• 11 de mayo: La Epoch se ha retrasado 3 Epoch, aproximadamente 20 minutos.
• 12 de mayo: El Epoch se ha retrasado 8 Epoch, aproximadamente 51 minutos.

A pesar de que Epoch no pudo concretarse a tiempo, la red de Ethereum sigue generando bloques y procesando transacciones. Sin embargo, debido a la baja tasa de votación de los nodos de validación, Epoch no puede obtener la garantía de seguridad del nivel de consenso de la red PoS de Ethereum.

Cabe mencionar que, en el segundo evento, se activó el mecanismo de Inactivity leak del algoritmo de consenso de Ethereum debido a que el retraso en la conclusión superó el umbral preestablecido. Esto resultó en la confiscación de aproximadamente 28 ETH y en que aproximadamente 50 ETH no fueron emitidos.

Análisis de causas

La causa directa de estos dos incidentes es que ciertos nodos de cliente de la capa de consenso de Ethereum tienen una carga demasiado alta, lo que provoca que los nodos de validación se caigan y se desconecten, impidiendo que se realice la votación de consenso de manera normal. En concreto:

1. Cuando un nodo recibe una atestación ( que apunta a un bloque obsoleto, necesita recalcular el estado de la cadena de balizas para verificar estas atestaciones, y este proceso requiere una gran cantidad de recursos de CPU y memoria.

2. Cuando se reciben simultáneamente una gran cantidad de testimonios que apuntan a bloques antiguos, los recursos del nodo se agotan, lo que provoca que el nodo de validación se caiga y se desconecte.

3. Aunque este tipo de problemas se pueden resolver mediante el almacenamiento en caché basado en los testigos que apuntan a bloques, el crecimiento en la cantidad de nodos de validación y la aparición masiva de este tipo de attestations han llevado a que el almacenamiento en caché de las implementaciones de clientes problemáticos se rompa.

Actualmente, los clientes de la capa de consenso Teku y Prysm han lanzado versiones de parche para resolver este problema. Las versiones de parche filtrarán estos testimonios obsoletos, ignorando el testimonio cuando este apunte a un Slot obsoleto o cuando el nodo nunca haya visto un Checkpoint.

![¿Por qué Ethereum tuvo caídas breves 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 mostró sus ventajas de diseño:

1. Diversidad de clientes: La implementación de diferentes clientes tiene diseños distintos, incluso si ciertos clientes presentan problemas, no afectará el funcionamiento normal de otros clientes.

2. Diseño del algoritmo Gasper: separa la producción de bloques de la finalización, de modo que incluso si la finalización de bloques se ve obstaculizada, la producción de bloques no se detendrá, garantizando la disponibilidad de la red.

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

Experiencia y Reflexiones

1. La diversidad de clientes aún necesita mejorar: actualmente, la diversidad de clientes de Ethereum aún tiene margen de mejora, especialmente porque los clientes de la capa de ejecución están concentrados en Geth, que representa el 61%, lo que presenta un riesgo potencial.

2. Es necesario mejorar el mecanismo de cambio de cliente: cuando un cliente presenta problemas, cómo cambiar de manera segura a una implementación de cliente normal sigue siendo un desafío.

3. Es necesario mejorar la monitorización del consenso: se requieren servicios similares a Safe Head para monitorear continuamente el estado en tiempo real de la red PoS de Ethereum y detectar y advertir sobre anomalías de manera oportuna.

4. Fortalecer la educación del usuario: Popularizar el mecanismo de consenso PoS de Ethereum, evitando que los usuarios generen pánicos innecesarios.

5. La capa de aplicación debe estar preparada para hacer frente a: las aplicaciones de Layer2, exchanges, oráculos, etc., deben manejar correctamente los escenarios de inestabilidad de la red, como extender adecuadamente el tiempo de confirmación o suspender el servicio.

Resumen

Este evento mostró la resiliencia y la capacidad de auto-reparación del algoritmo de consenso PoS de Ethereum, al mismo tiempo que expuso algunos aspectos que necesitan mejoras. En el futuro, el ecosistema de Ethereum necesita continuar invirtiendo en la diversidad de clientes, la vigilancia de la red, la educación de los usuarios, entre otros aspectos, para mejorar la estabilidad y confiabilidad de toda la red.

![¿Por qué Ethereum tuvo 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(