El comienzo y el final del evento "crash" de la red de prueba Ethereum Medalla

Nota del traductor:

Los usuarios que ejecutan el cliente Prysm deben actualizar a la versión Alpha.23 lo antes posible:

https://github.com/prysmaticlabs/prysm/releases

Este problema es una actualización fuera del plan wnie2 y revisará y analizará los episodios que ocurrieron en la red de prueba Eth2 Medalla durante el fin de semana.

Lanzamos Medalla hace casi dos semanas, el 4 de agosto, como una red de prueba grande, pública y multicliente que ejecuta la especificación de red principal Eth2. Para conocer la introducción de la red de prueba Medalla, consulte el número anterior.

La red de prueba funcionó sin problemas durante 10 días, a pesar de que la tasa de participación de los validadores fue más baja de lo que esperábamos (70%-80% de los validadores permanecen en línea durante mucho tiempo). Pero no duele, la red de prueba es más que capaz de manejarlo.

Sin embargo, el viernes por la noche, vi que la tasa de participación del validador caía por un precipicio en el tablero. En unos minutos, los validadores activos cayeron de 22 000 a alrededor de 5 000, y alrededor del 80 % de los validadores de la red desaparecieron.

Por lo tanto, este artículo revisará el incidente, incluidas sus consecuencias y los próximos pasos.

Descubrimos que todos los validadores que ejecutaban el cliente Prysm en la red desaparecieron repentinamente. Dado que Prysm es el cliente más utilizado, las consecuencias pueden imaginarse.

El equipo de Prysmatic abrió un informe documentado sobre el incidente y continúa actualizándolo con detalles del incidente y la respuesta del equipo. Aquí hay algunos puntos destacados con mis notas.

La causa del evento es un problema con la sincronización del reloj. El cliente de Prysm está configurado para usar Roughtime de Cloudflare para calcular el tiempo. La razón de esto no está muy clara (en mi opinión), pero está claro que Roughtime cambió el tiempo cuatro horas hacia el futuro y duró más de una hora. Los validadores de clientes de Prysm de repente descubrieron que su tiempo era cuatro horas más rápido y continuaron generando bloques y pruebas para una cadena de bloques que aún no existía.

Por sí solo, no es suficiente para ser catastrófico. Incluso con muchos bloques perdidos y enfrentando una gran cantidad de pruebas del futuro, los clientes restantes aún podrán construir sobre la cadena original. Gradualmente, a medida que los relojes de los nodos de Prysm se ajustaban, comenzaron a regresar a la red y la participación del validador comenzó a aumentar. La red parece estar volviendo a la normalidad.

La empresa de desarrollo de zkSync propuso implementar Aave V3 en la red de prueba de zkSync 2.0: el 25 de octubre, la empresa de desarrollo de zkSync, Matter Labs, lanzó una propuesta en la comunidad de Aave, proponiendo implementar Aave V3 en la red de prueba de zkSync 2.0. La propuesta se discutirá en la comunidad, después de lo cual el equipo de zkSync votará sobre la implementación de la red de prueba.

Según noticias anteriores, Matter Labs inició una propuesta en la comunidad de Uniswap sobre la implementación de Uniswap V3 en zkSync y ha sido aprobada. [2022/10/25 16:37:49]

Pero unas horas después, la situación empeoró bruscamente.

Cuatro horas después del tiempo inicial, sucedieron dos cosas más. Primero, las pruebas generadas por todos los clientes de Prysm en el futuro comienzan a tener validez. En segundo lugar, los nodos de Prysm que se reincorporaron a la red comenzaron a desaparecer nuevamente porque se activó el mecanismo de protección de barra para evitar que generaran pruebas contradictorias.

Esas dos cosas sucedieron al mismo tiempo, provocando un caos en la red. Los clientes restantes todavía luchaban por procesar la información que recibían, y la cadena de balizas se convirtió en una jungla ramificada. (Raúl del equipo de Prysmatic me dijo que un error en la primera solución de Prysm empeoró las cosas)

Durante un período de tiempo, la información en la red aún está bajo control. Pero durante las siguientes 24 horas más o menos, la memoria y la CPU requeridas para navegar por bifurcaciones cada vez más complejas y caóticas se volvieron abrumadoras. Vi un cliente Lighthouse que usaba 30 GB de memoria (alrededor de 100 veces lo que haría normalmente), y para el cliente Teku, incluso con un montón de memoria Java de 12 GB y maximizando el procesador, estaba teniendo problemas.

Tenga en cuenta que todo esto sucede los fines de semana. Gracias a todos los equipos de clientes que luchan en primera línea. Para que los nodos puedan hacer frente a la caótica red, necesitan optimizar constantemente la memoria y la eficiencia.

Hasta el momento, la red se está recuperando gradualmente. Los informes de los usuarios se han mezclado, pero las versiones más nuevas de Prysm y Lighthouse pudieron encontrar el encabezado de cadena correcto y continuar construyendo la cadena de balizas. Eth2Stats actualmente muestra algunos nodos en la cabeza de la cadena o en los nodos Lighthouse, Prysm y Teku cercanos. Continuaremos optimizando Teku para reducir los recursos que necesita sincronizar.

Una cosa que debe quedar clara es que no hay una falla de consenso entre los clientes, es decir, cuando se restablece la red, todos los clientes pueden llegar a un consenso sobre el estado de la cabeza de la cadena, lo que significa que la cadena de balizas no fallará fundamentalmente. , ni fallará. Se requieren bifurcaciones duras.

Pasaremos más tiempo para reflexionar y resumir completamente este episodio, las siguientes son algunas de mis opiniones personales.

La alta dependencia de los servicios de tiempo de terceros es un punto fatal para la red. Da la casualidad de que Alex Vlasov del equipo de investigación de ConsenSys TX/RX ha escrito previamente un artículo detallado que explica la sincronización del tiempo y su importancia en la red Ethereum 2.0. Su trabajo avanza rápidamente, quizás esta sea también una oportunidad para que todos presten atención a este aspecto. Aquí están sus artículos relacionados y publicaciones de ethresear.ch.

Idealmente, tendríamos cuatro o más clientes independientes, con cada nodo de cliente representando no más del 30% de la red. De esa manera, incluso si un cliente tuviera un problema, no tendría suficiente impacto para llamar nuestra atención.

Incluso si no podemos lograr este ideal, reducir el uso extremo por parte de clientes individuales hará que la red sea más sólida. Suponiendo que solo el 50 % de los validadores se desconecten esta vez en lugar del 80 %, la red se recuperará más fácilmente. Esto se debe a que cuando hay un problema con el cliente, afectará la generación de bloques de la red, el empaquetado de pruebas, la eficiencia de transmisión, la comunicación punto a punto y la sincronización, y estos factores también tendrán un efecto en cadena en el resto. validadores

Algunos participantes pueden cambiar las claves de firma a los nodos de respaldo en caliente de otros clientes. Esto sin duda constituye una gran red de seguridad, aunque se debe tener cuidado para evitar cortes: los nuevos validadores pueden no saber nada sobre el historial de votación de los validadores existentes y, por lo tanto, pueden votar en contra.

En el futuro, una vez que finalicemos la nueva API, debería ser posible implementar la capacidad de cambiar clientes de validación entre diferentes nodos de baliza, no solo claves. Por ejemplo, un validador Prysm puede desconectarse fácilmente de un nodo de baliza Prysm y volver a conectarse a un nodo de baliza Teku. Esto puede resolver el problema de corte mencionado anteriormente.

La participación en Eth2 no es una cosa "una y hecha" en este momento. Los participantes deben mantener cierta atención, deambular entre foros, proporcionar comentarios a los desarrolladores y poder actualizar el cliente en poco tiempo. Apoyo mucho a las personas que ejecutan sus propios validadores personales, pero solo si son conscientes de sus responsabilidades.

¿Por qué las cosas siempre salen mal los viernes por la noche?

Incluso en este momento, la respuesta del equipo de Prysmatic ha sido sorprendente. Consulte el informe de incidentes del equipo para obtener más detalles. Lo que digo a continuación no pretende arrojar una luz negativa sobre el equipo de Prysmatic, que ha hecho un trabajo realmente bueno, sino brindar experiencia al equipo de Teku cuando se enfrenta a una situación similar.

Cuando tantos usuarios pierden activos (incluso si es solo una moneda de prueba) y la red está bajo mucha presión, es natural querer reaccionar rápidamente, pero la prisa a veces puede ser un desperdicio.

En este incidente se pudieron evitar dos cosas. Primero, hubo un error en la versión de corrección inicial Alpha.21 que requería que los usuarios retrocedieran después de 17 horas.

Según Raúl del equipo de Prysmatic, esta falla fue la responsable del caos de la red que siguió. En segundo lugar, el equipo eliminó inadvertidamente su base de datos de registros a prueba de cortes de 1024 validadores mientras manejaba la situación, lo que provocó que la mayoría de los validadores fueran cortados.

Situaciones similares pueden ocurrir con cualquier cliente. Entonces, incluso bajo mucha presión, todos nosotros, ya sean desarrolladores o usuarios, debemos enfrentarlo con calma y no perseguir ciegamente la velocidad. Entonces, cuando intentamos restaurar la red, seguimos un enfoque lento y cuidadoso.

Al final, este episodio fue realmente necesario. ¿De qué sirve una red de prueba si no se prueba nada? Obviamente, no es realista funcionar sin problemas todo el tiempo.

¡Esta vez es una gran prueba! Este es quizás el peor tipo de impacto que puede sufrir una red, y probablemente no seríamos capaces de diseñar tal prueba si tuviéramos que diseñarla nosotros mismos. Exponer la red de prueba a este nivel de impacto es exactamente lo que necesitamos para fortalecer al cliente.

La semana pasada, The Block citó mi declaración en un artículo:

En el correo electrónico, el ingeniero de PegaSys, Ben Edgington, escribió que Medalla "es la primera red de prueba con la escala y configuración de la red principal".

"Esta es la primera prueba a gran escala, y antes de eso era solo una especificación en la pantalla o una red de juguete. Hay muchos aspectos de la red peer-to-peer que deben probarse y optimizarse. Hasta ahora, todo funciona normalmente, pero antes podemos asegurarnos de que no haya ningún error. Antes, tomaba más tiempo, más escala y más presión en la red".

Para ser honesto, tenía muchas ganas de lo que vendría.

Todos los equipos de clientes están trabajando actualmente para fortalecer el cliente para manejar situaciones de red extremas. No es un gran problema, deberíamos poder hacer que Medalla vuelva a la normalidad en los próximos días, puede afectar el equilibrio de todos los validadores, y algunos validadores enfrentarán recortes.

Si después de eso, a pesar de que la red funciona normalmente, la tasa de participación del validador no aumenta, entonces podemos considerar volver a implementar el contrato de depósito desde cero (la recreación también puede ser una buena opción). Pero esto es sólo una opción en esta etapa.

¡Viva la Medalla!

Enlace original: https://hackmd.io/@benjaminion/wnie2_200817

Fuente: Novedades en Eth2

Por Ben Edgington

Tags：

BTC