Hechos clave:
Dos de los tres clientes de Ethereum más usados tuvieron este problema.
No se finalizaron bloques durante lapsos de media hora y una hora en dos días consecutivos.
Desarrolladores de Ethereum publicaron una actualización de machine para solucionar los problemas de finalización de bloques que afectaron a la Beacon Chain de la red en días pasados. Los clientes Prysm y Teku, dos de los más utilizados en Ethereum, ya cuentan con parches para solucionar la falla.
En una publicación que el desarrollador conocido como superphiz.eth compartió en Twitter, la Fundación Ethereum aseguró que este “escenario excepcional” podría haberse dado por una carga alta en algunos de los clientes de la capa de consenso, llamada también Beacon Chain. Sin embargo, aseguraron que todavía siguen investigando el episodio, que impidió la finalización de bloques durante 3 y 8 epochs en dos ocasiones: el jueves 11 y viernes 12 de mayo.
Asimismo, la organización que reúne a los principales desarrolladores de Ethereum destacó que la red “siguió funcionando, tal como está diseñada, y los usuarios podían seguir haciendo transacciones en ella”. En este sentido, fue importante la descentralización en la capa de consenso de la red, ya que no todos los clientes se vieron afectados, destacan.
Como se puede ver en el sitio clientdiversity.org, el cliente más usado en la capa de consenso de Ethereum, Lighthouse, no experimentó problemas. Sí los tuvieron el segundo y el tercero con más nodos ejecutándolos, Prysm y Teku, tal y como reportó CriptoNoticias ante el primero de los dos periodos de demora. Uno duró 25 minutos y el otro, casi una hora.
Porcentaje de adopción de clientes en la capa de consenso (izquierda) y la capa de ejecución (derecha) en Ethereum. Fuente: clientdiversity.org
La explicación de los desarrolladores de Prysm
En el mensaje en el que compartió su más reciente actualización, el equipo de Prysm aseguró que la nueva versión “contiene la optimización para evitar que Beacon Chain exercise muchos recursos durante tiempos turbulentos”. “Se recomienda encarecidamente actualizar si su nodo está bajo un uso intensivo”, agregaron.
Por otro lado, el desarrollador de Prysm Terence Tsao escribió un hilo en el que brinda detalles sobre los eventos del 11 y 12 de mayo.
“Los nodos Prysm recibieron muchas atestaciones para epochs previas en las que el bloque no reflejaba el último checkpoint en la elección de bifurcación. Los nodos conectados probablemente enviaron la atestación sin tener todos los bloques para el resto de la epoch, lo que provocó que Prysm gastara muchos recursos para volver a reproducir el estado, cayendo eventualmente en una espiral de muerte (picos de CPU / OOM)”.
La mayoría de los clientes tuvieron problemas similares, excepto Lighthouse, dice Tsao. No obstante, según el comunicado de Fundación Ethereum, solo Prysm y Teku experimentaron estas fallas.
El equipo de Prysm también admitió un “error sutil” en sus nodos, donde no se usó el estado correcto para calcular el mezclado durante el tiempo de la “espiral de muerte”. Como solución a ello, prometieron una nueva actualización para la próxima semana que subsane estas imperfecciones.
Clientes y finalización de bloques en Ethereum
La finalización de los bloques en una red que funciona con Proof of Stake (prueba de participación o PoS) se refiere al proceso mediante el cual un bloque de transacciones se considera validado y confirmado por la red. Así, se agrega de forma definitiva a la contabilidad en la cadena de bloques.
Para finalizar un bloque en una red con PoS, los validadores deben participar en un proceso de consenso. Si la mayoría están de acuerdo en que las transacciones son válidas, el bloque se considera finalizado y se agrega a la cadena de bloques de forma permanente.
Los nodos validadores usan clientes para interactuar con el resto de la red y poder así cumplir su rol en este proceso. Los clientes, por lo tanto, son aplicaciones de machine que conectan un nodo a Ethereum y permiten a los usuarios enviar y recibir transacciones, así como participar en el proceso de validación de bloques.