- Tras la caída de la red de pruebas Medalla, Prysmatic Labs ha aclarado que el lanzamiento de Ethereum 2.0 no se retrasará debido al fallo en el cliente de Prysm.
- Después de que la tasa de participación de la red en la Medalla testnet se estrelló por debajo del 2% el 15 de agosto, aumentó de nuevo ayer a más del 68%.
Como informó el CNF, la última red de pruebas multicliente para Ethereum 2.0 sufrió un revés hace unas semanas cuando un fallo provocó la aparición de nodos no sincronizados y la red Medalla casi se estrelló como resultado. Aunque el error, que sólo afectaba al cliente Prysm de Prysmatic Labs, ya ha sido solucionado, se ha planteado la preocupación en la comunidad de criptomonedas de que esto pueda retrasar el inicio de la fase 0 de Ethereum 2.0.
Prysmatic Labs ha tratado de disipar este rumor a través de una entrada de blog que describe la causa exacta del fallo. Raúl Jordan, editor de Prysmatic Labs escribió que el calendario para la introducción de la ETH 2.0 sigue en marcha a pesar del contratiempo. Según él, sigue apoyando el lanzamiento de mainnet dos o tres meses después del lanzamiento de Medalla, como se planeó originalmente:
Creemos que este incidente no afecta inherentemente a la fecha de lanzamiento. El equipo de Prysmatic Labs recomienda que la fecha de lanzamiento de ETH2 continúe sin retraso. El incidente de este fin de semana fue una buena prueba de estrés para muchos clientes y en realidad comprueba algunos requisitos de la lista de lanzamiento. Aunque no se ha fijado la fecha de lanzamiento, creemos que el objetivo de lanzamiento previsto de 2 a 3 meses a partir de la génesis de Medalla sigue siendo una línea de tiempo ideal.
Como explicó Jordan, el fracaso fue lo mejor que le pudo pasar a la red de pruebas. Así que toda la experiencia del incidente servirá para prevenir el problema en el futuro. Además, todas las lecciones aprendidas serán puestas en la lista pública de requisitos para un despliegue Eth2 para asegurar la resistencia, la seguridad y la correcta liberación de los clientes.
Jordan también subrayó que la red de pruebas «no está muerta». Mientras sea posible operar un nodo y mientras los validadores puedan validarlo, la red de pruebas puede volver a funcionar plenamente en cualquier momento. El 19 de agosto, Jordan declaró a este respecto:
Todavía tenemos esperanza. La participación ha subido de 0-5% a 40%. La blockchain necesita > 66% para finalizar.
Los datos de BeaconScan muestran actualmente que, después de caer al 1,63% el 15 de agosto, la tasa de participación volvió al 68,59% ayer, por encima del importante 66%. La red de pruebas de Medalla parece, por lo tanto, estabilizarse de nuevo, mientras que los bloques vuelven a validarse.
¿Qué causó la caída de la red de pruebas del Ethereum 2.0?
Como explica Jordan, el problema comenzó con la recepción de malas respuestas de 6 servidores de tiempo diferentes que repelían la mayoría de los nodos que ejecutaban el cliente Prysm simultáneamente. Posteriormente, el equipo de Prysmatic Labs trató de encontrar una solución rápida, pero contenía un error crítico que «eliminaba toda la funcionalidad necesaria para que nuestros nodos funcionaran».
Este problema resultó en particiones de red donde todos estaban sincronizando la blockchain al mismo tiempo, pero no podían encontrar un par sano. En última instancia, fue sólo la corrección de errores mal pensada la que causó el gran problema, que casi paralizó la red:
Preocupados por la urgencia del problema original, no pensamos demasiado en todas las implicaciones de un posible arreglo, y nos centramos más en liberarlo rápidamente que en comprobar cuidadosamente si rompería algo más en nuestros nodos. […] Aún peor, el error de tiempo difícil se había recuperado completamente ya, lo que probablemente habría arreglado los problemas en la red si no hubiéramos actuado tan rápidamente.
Para evitar que el problema se repita, los laboratorios Prysmatic harán los siguientes cambios en el cliente Prysm:
A partir de este incidente, nos basaremos únicamente en el tiempo del sistema. Si el tiempo de un validador está efectivamente apagado, podemos decírselo, pero no lo cambiaremos a la fuerza. Otras implementaciones de clientes eth2 sólo usan el tiempo del sistema y nosotros también lo haremos.
