-
Clientes de la capa de ejecución omitieron incluir la correcta dirección del contrato de depósito.
-
Holesky está inactiva desde hace al menos 7 horas.
La red de prueba Holesky de Ethereum (ETH) enfrentó inconvenientes durante la implementación de la actualización Pectra, llevada a cabo el 24 de febrero de 2025. Aunque la bifurcación se activó a las 21:55 UTC, la red no logró alcanzar el estado de «finalidad», en el que las transacciones se consolidan como inmutables e irreversibles en la red.
Al tiempo de este artículo, Holesky lleva al menos siete horas inactiva y sin procesar bloques, como se observa en la siguiente imagen:
La experiencia en esta red de prueba de Ethereum refuerza la importancia de estas fases experimentales, permitiendo que los fallos se detecten y corrijan sin comprometer la estabilidad de la cadena principal.
¿Cuál fue la falla en la red de prueba de Ethereum?
Georgios Konstantopoulos, CTO de Paradigm, explicó que el fallo se originó en un error dentro de algunos clientes en la Capa de Ejecución (Execution Layer, EL). Según sus declaraciones, estos clientes omitieron incluir la dirección correcta del contrato de depósito, un componente que cobra relevancia con Pectra debido a su impacto en el cálculo del hash de solicitudes.
Ese hash es fundamental para procesar operaciones como depósitos y retiros, funciones que la actualización traslada de la capa de consenso (CL) a la capa de ejecución.
Konstantopoulos señaló que, aunque el error fue sencillo de detectar, afectó el desempeño de algunos clientes en Holesky. Sin embargo, destacó que equipos como Reth y Erigon, dos implementaciones de clientes EL, funcionaron correctamente durante la prueba.
Ethereum tiene una estructura compuesta por distintas capas, además de la EL: Consensus Layer (Capa de Consenso), Application Layer (Capa de Aplicación), Data Availability Layer (Capa de Disponibilidad de Datos), Network Layer (Capa de Red) e Infrastructure Layer (Capa de Infraestructura).
Esta arquitectura multicapa permite distribuir las funciones clave de la red en distintos estratos, optimizando su rendimiento general sin comprometer su integridad.
Los clientes EL deben gestionar el contrato de depósito
En una respuesta que complementa aquella explicación, timbeiko.eth, un desarrollador prominente dentro del ecosistema Ethereum, profundizó en el contexto técnico del problema.
Antes de Pectra, los clientes de ejecución no necesitaban reconocer la relevancia especial del contrato de depósito, ya que la capa de consenso se encargaba de leerlo directamente. Esto cambió con Pectra: ahora, los depósitos pueden ser iniciados por la capa de ejecución sin el retraso de 2048 bloques que se implementaba en la era pre-Merge para mitigar reorganizaciones en la Prueba de Trabajo (PoW).
Como resultado, los clientes EL deben gestionar directamente el contrato de depósito, lo que exige que su dirección esté correctamente configurada.
El fallo en Holesky, conforme a timbeiko.eth, se desencadenó porque las direcciones del contrato de depósito en esta red de prueba, al igual que en Sepolia, difieren de las utilizadas en la red principal de Ethereum. Algunos clientes no actualizaron esta dirección para reflejar las especificidades de Holesky, lo que provocó inconsistencias en las verificaciones de hash y, en consecuencia, impidió que la red alcanzara la finalidad.
Aunque timbeiko.eth admitió no saber por qué las direcciones son distintas entre las redes, subrayó que este tipo de discrepancias son parte de los desafíos que surgen al probar actualizaciones en entornos controlados.
El ecosistema Ethereum espera por Pectra
La actualización Pectra introduce cambios importantes, como en el staking, en la interacción de las EOA (cuentas controladas externamente) y las cuentas de contratos inteligentes y la posibilidad de activar depósitos directamente desde la capa de ejecución, aparte de otras mejoras. Sin embargo, su implementación requiere que todos los clientes estén alineados con las nuevas especificaciones, algo que no ocurrió de manera uniforme en esta ocasión.
La diferencia en las direcciones del contrato de depósito entre la red principal y las testnets, combinada con una configuración inadecuada en algunos clientes EL, expuso una vulnerabilidad que ahora está siendo abordada.
El próximo paso para los desarrolladores será ajustar estos errores antes de la siguiente prueba programada en Sepolia, prevista para el 5 de marzo de 2025, y posteriormente en la red principal de Ethereum, el 8 de abril.
