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ó breves anomalías durante dos noches consecutivas. El análisis muestra que esto se debió principalmente a que algunos nodos de cliente de la capa de consenso de Ethereum estaban sobrecargados, lo que provocó que los nodos validador se cayeran y se desconectaran. Esto afectó directamente a la votación de Epoch, que no pudo alcanzar el 2/3 requerido, lo que impidió que la capa de consenso confirmara la finalización. Sin embargo, la red se recuperó rápidamente por sí misma, lo que refleja que el algoritmo de consenso PoS de Ethereum tiene una buena resiliencia y capacidad de auto-reparación.
Revisión de eventos
En las noches del 11 y 12 de mayo, se produjo un retraso en la confirmación del Epoch de la red de consenso PoS de Ethereum:
11 de mayo: Se confirma un retraso de aproximadamente 20 minutos en el Epoch (3 Epochs)
12 de mayo: La Epoch se confirmó con un retraso de aproximadamente 51 minutos (8 Epochs)
Es importante destacar que, durante este período, la red de Ethereum pudo seguir generando bloques y procesando transacciones. La causa fundamental de la anomalía fue que un gran número de nodos de validación estaban fuera de línea, lo que resultó en una tasa de votación insuficiente para alcanzar el consenso necesario para la finalización de Epoch.
Se observó que los nodos de validación fuera de línea presentaban una sobrecarga anormal de CPU, lo que se considera la causa directa de que los nodos estuvieran fuera de línea.
En el segundo evento, debido a que la confirmación de Epoch se retrasó más allá del umbral preestablecido, se activó el mecanismo de penalización del algoritmo de consenso de Ethereum:
Castigar a los validadores fuera de línea, reduciendo aproximadamente 28 ETH de los fondos apostados.
Se cancelan las recompensas de Attestation, aproximadamente 50 ETH no han sido emitidos
Este mecanismo asegura que los validadores en línea puedan controlar finalmente más del 2/3 de los fondos apostados, lo que permite que el estado de la red vuelva a la normalidad.
Análisis de causas
La causa directa de esta anomalía es que algunos nodos de clientes de la capa de consenso de Ethereum estaban sobrecargados, lo que llevó a la caída de los validadores y a su desconexión, impidiéndoles participar normalmente en la votación de consenso. El análisis específico es el siguiente:
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, lo que consumirá una gran cantidad de recursos de CPU y memoria.
Al mismo tiempo, al recibir una gran cantidad de testigos que apuntan a bloques obsoletos, los recursos del nodo se agotan, lo que provoca que los validadores se caigan y se desconecten.
Aunque se pueden resolver este tipo de problemas mediante el caché, el aumento de la escala de los validadores y la aparición de una gran cantidad de tales atestaciones han llevado a que el caché de ciertas implementaciones de clientes se rompa, obligando a los nodos a consumir grandes recursos para recalcular el estado.
Actualmente, los clientes de la capa de consenso Teku y Prysm han lanzado versiones de reparación para abordar este problema. Las versiones de reparación filtrarán los testigos obsoletos, es decir, ignorarán el testigo cuando este apunte a un Slot antiguo o a un Checkpoint que el nodo no ha visto.
Ventajas del diseño de Ethereum
Este evento destaca dos ventajas de diseño de Ethereum:
Diversidad de clientes:
Las diferencias de diseño en las implementaciones de diferentes clientes hicieron que algunos clientes (como Lighthouse) no se vieran afectados en este evento, garantizando el funcionamiento continuo de la red.
Diseño del algoritmo de consenso Gasper:
Separar la producción de bloques de la confirmación, de modo que, incluso si la confirmación se ve obstaculizada, la producción de bloques pueda continuar.
El mecanismo de fuga por inactividad asegura que la red pueda volver a alcanzar el consenso incluso en situaciones extremas.
Experiencia y Revelaciones
La diversidad de clientes aún necesita fortalecerse:
La diversidad de los clientes de Ethereum aún tiene espacio para mejorar. Si Prysm y Teku representan menos de 1/3, este evento podría no haber ocurrido.
Es necesario mejorar el mecanismo de cambio de cliente:
Cuando un cliente tiene problemas, cómo cambiar de manera segura y eficiente a otro cliente normal es un problema que necesita ser resuelto.
Fortalecer la monitorización de la red de consenso:
Se necesita desarrollar un servicio similar a Safe Head, que monitoree continuamente el estado de la red PoS de Ethereum y detecte y advierta sobre anomalías de manera oportuna.
Fortalecer la educación del usuario:
Difundir el conocimiento sobre el mecanismo de consenso PoS de Ethereum, para evitar que los usuarios generen pánico innecesario.
Impacto a nivel de aplicación:
El tiempo de depósito de Layer1 a Layer2 puede extenderse
El tiempo de recarga en el intercambio puede extenderse
Los datos del oráculo pueden enfrentar el riesgo de retroceso.
Las aplicaciones DeFi necesitan ajustar adecuadamente sus estrategias operativas.
Resumen
Este evento mostró la resiliencia y la capacidad de autorreparación del algoritmo de consenso PoS de Ethereum, así como la rápida capacidad de respuesta del equipo de desarrollo. En el futuro, el ecosistema de Ethereum también necesitará seguir esforzándose en aspectos como la diversidad de clientes, la monitorización de la red, la educación de los usuarios y los planes de emergencia, para mejorar aún más la estabilidad y la fiabilidad de la red.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
14 me gusta
Recompensa
14
6
Compartir
Comentar
0/400
JustHereForAirdrops
· 07-07 00:55
¡eth volvió a tener problemas, estoy impresionado!
Ver originalesResponder0
GasWaster69
· 07-06 09:44
¿Eso es todo? ¿Por qué Vitalik no ha tuiteado para responder?
Ver originalesResponder0
LowCapGemHunter
· 07-04 05:37
¿Te has equivocado? Sabía que PoS no era muy estable.
Ver originalesResponder0
ForkMonger
· 07-04 05:19
el caos es una característica, no un error... la gobernanza de eth necesita más estrés sistémico, para ser honesto
Ver originalesResponder0
degenwhisperer
· 07-04 05:18
pos tampoco es muy estable.
Ver originalesResponder0
TideReceder
· 07-04 05:16
Mecanismo de consenso todavía no es muy estable...
Análisis y reflexiones sobre la breve anomalía en la capa de consenso de Ethereum
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ó breves anomalías durante dos noches consecutivas. El análisis muestra que esto se debió principalmente a que algunos nodos de cliente de la capa de consenso de Ethereum estaban sobrecargados, lo que provocó que los nodos validador se cayeran y se desconectaran. Esto afectó directamente a la votación de Epoch, que no pudo alcanzar el 2/3 requerido, lo que impidió que la capa de consenso confirmara la finalización. Sin embargo, la red se recuperó rápidamente por sí misma, lo que refleja que el algoritmo de consenso PoS de Ethereum tiene una buena resiliencia y capacidad de auto-reparación.
Revisión de eventos
En las noches del 11 y 12 de mayo, se produjo un retraso en la confirmación del Epoch de la red de consenso PoS de Ethereum:
Es importante destacar que, durante este período, la red de Ethereum pudo seguir generando bloques y procesando transacciones. La causa fundamental de la anomalía fue que un gran número de nodos de validación estaban fuera de línea, lo que resultó en una tasa de votación insuficiente para alcanzar el consenso necesario para la finalización de Epoch.
Se observó que los nodos de validación fuera de línea presentaban una sobrecarga anormal de CPU, lo que se considera la causa directa de que los nodos estuvieran fuera de línea.
En el segundo evento, debido a que la confirmación de Epoch se retrasó más allá del umbral preestablecido, se activó el mecanismo de penalización del algoritmo de consenso de Ethereum:
Análisis de causas
La causa directa de esta anomalía es que algunos nodos de clientes de la capa de consenso de Ethereum estaban sobrecargados, lo que llevó a la caída de los validadores y a su desconexión, impidiéndoles participar normalmente en la votación de consenso. El análisis específico es el siguiente:
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, lo que consumirá una gran cantidad de recursos de CPU y memoria.
Al mismo tiempo, al recibir una gran cantidad de testigos que apuntan a bloques obsoletos, los recursos del nodo se agotan, lo que provoca que los validadores se caigan y se desconecten.
Aunque se pueden resolver este tipo de problemas mediante el caché, el aumento de la escala de los validadores y la aparición de una gran cantidad de tales atestaciones han llevado a que el caché de ciertas implementaciones de clientes se rompa, obligando a los nodos a consumir grandes recursos para recalcular el estado.
Actualmente, los clientes de la capa de consenso Teku y Prysm han lanzado versiones de reparación para abordar este problema. Las versiones de reparación filtrarán los testigos obsoletos, es decir, ignorarán el testigo cuando este apunte a un Slot antiguo o a un Checkpoint que el nodo no ha visto.
Ventajas del diseño de Ethereum
Este evento destaca dos ventajas de diseño de Ethereum:
Diversidad de clientes: Las diferencias de diseño en las implementaciones de diferentes clientes hicieron que algunos clientes (como Lighthouse) no se vieran afectados en este evento, garantizando el funcionamiento continuo de la red.
Diseño del algoritmo de consenso Gasper:
Experiencia y Revelaciones
La diversidad de clientes aún necesita fortalecerse: La diversidad de los clientes de Ethereum aún tiene espacio para mejorar. Si Prysm y Teku representan menos de 1/3, este evento podría no haber ocurrido.
Es necesario mejorar el mecanismo de cambio de cliente: Cuando un cliente tiene problemas, cómo cambiar de manera segura y eficiente a otro cliente normal es un problema que necesita ser resuelto.
Fortalecer la monitorización de la red de consenso: Se necesita desarrollar un servicio similar a Safe Head, que monitoree continuamente el estado de la red PoS de Ethereum y detecte y advierta sobre anomalías de manera oportuna.
Fortalecer la educación del usuario: Difundir el conocimiento sobre el mecanismo de consenso PoS de Ethereum, para evitar que los usuarios generen pánico innecesario.
Impacto a nivel de aplicación:
Resumen
Este evento mostró la resiliencia y la capacidad de autorreparación del algoritmo de consenso PoS de Ethereum, así como la rápida capacidad de respuesta del equipo de desarrollo. En el futuro, el ecosistema de Ethereum también necesitará seguir esforzándose en aspectos como la diversidad de clientes, la monitorización de la red, la educación de los usuarios y los planes de emergencia, para mejorar aún más la estabilidad y la fiabilidad de la red.