El ACDE Ethereum anuncia 205: actualizaciones importantes Ethereum el 24 de febrero, el 5 de marzo y el 8 de abril

Los desarrolladores Ethereum han finalizado el cronograma para las próximas actualizaciones de la red. Los cambios importantes se implementarán el 24 de febrero, el 5 de marzo y el 8 de abril. Se tomaron decisiones clave durante la reciente convocatoria 205 de la ACDE (All Core Developers Execution Call), celebrada el 13 de febrero de 2025.

Las reuniones quincenales por Zoom fueron dirigidas por Ethereum (EF). Los desarrolladores confirmaron que la actualización Pectra se activaría en la red de prueba Holesky el 24 de febrero. Posteriormente, la red de prueba Sepolia se pondrá en marcha el 5 de marzo. Tim Beiko, responsable de soporte de protocolos de la Fundación

Si ambos lanzamientos se realizan sin problemas, la red principal de Ethereumrecibirá la actualización alrededor del 8 de abril. 

Beiko dijo que coordinaría con los equipos para encontrar un voluntario para implementartraccontratos del sistema Pectra en ambas redes de prueba.

Debates sobre futuras bifurcaciones Ethereum y la velocidad de actualización

Además, el equipo de desarrolladores discutió la próxima actualización prevista tras Pectra y Fusaka. Beiko propuso congelar el alcance de Fusaka hasta el lanzamiento de Pectra en la red principal.

La línea de tiempo permite a los desarrolladores comenzar a trabajar en Fusaka mientras también planifican la bifurcación posterior Glamsterdam. 

El equipo de desarrollo de Geth no quiere trabajar con este cronograma. Argumentan que era prematuro consolidar el alcance de Fusaka. La inclusión de la Propuesta de Mejora Ethereum (EIP) EOF en Fusaka ha generado un debate considerable. Un grupo de desarrolladores aboga por su exclusión de la próxima actualización.

EOF (Ethereum Object Format) es una actualización detracse estructuran y ejecutan los contratos inteligentes en la Ethereum .

Lightclient, desarrollador de Geth, se opuso a la aceleración del bloqueo del alcance de Fusaka. Argumenta que Ethereumpodrían cambiar en los próximos dos años. Señaló que, si bien los desarrolladores buscan ciclos de actualización de seis meses, los retrasos en el mundo real podrían extenderlos a ocho meses o más. Esto significa que las mejoras importantes podrían no implementarse durante años. 

Lightclient expresó su preocupación por la incorporación de EOF, destacando el rápido progreso de la tecnología de acumulación de conocimiento cero (zkEVM) de Ethereum. Los desarrolladores desconocen la interacción de estos cambios con la máquina virtual.

Durante el debate, Marius van der Wijden, desarrollador de Geth, mencionó su alcance preferido para Fusaka, que incluía PeerDAS, FOCIL, EOF y límites superiores para modexp. Parithosh Jayanthi, ingeniero de operaciones del desarrollador de EF, contradijo la postura, afirmando que FOCIL no estaba tan listo para su implementación como PeerDAS y EOF.

Actualizaciones de la red de pruebas del software Pectra y comentarios de la comunidad

Los desarrolladores superaron sus desacuerdos sobre Fusaka y expresaron su confianza en el despliegue de Pectra. Parithosh Jayanthi, ingeniero de desarrollo y operaciones de EF, informó que Pectra Devnet 6 estaba funcionando bien, con tasas de participación de validadores casi perfectas. 

Además, la red de pruebas Ephemery de Ethereumactivó la actualización de Pectra unas horas después de la llamada ACDE, lo que permitió a los desarrolladores realizar más pruebas.

Beiko solicitó a los autores de Pectra EIP que trasladaran sus propuestas a la fase de "última llamada" en GitHub. Esto indica los pasos finales antes de la implementación en la red principal. También analizó los comentarios de la Ethereum . En ese sentido, observó que la solicitud más común era acelerar los ciclos de actualización. 

En respuesta, sugirió que los desarrolladores Ethereum deberían intentar finalizar el alcance de cada actualización tan pronto como la anterior entre en funcionamiento en la red principal.

El cronograma propuesto por Beiko para definir el alcance de Fusaka establece que, antes del 13 de marzo, los desarrolladores deberán proponer mejoras de rendimiento (EIP) para su inclusión en la actualización. Dos semanas después, el 27 de marzo, los equipos de clientes compartirán sus preferencias sobre qué EIP deberían considerarse para Fusaka. Finalmente, el 10 de abril se definirá el alcance de la actualización. 

Sin embargo, el investigador de EF, Ansgar Dietrichs, añadió una excepción al plazo. Señaló que las mejoras del código de PeerDAS, un componente crucial de la actualización de Pectra, deberían subirse a la red principal Ethereum tan pronto como se completen. Nadie se opuso a este requisito.

Preocupaciones sobre los estándares de pruebas EELS y EIP

Otro punto de preocupación durante la llamada de ACDE fue una propuesta del ingeniero de pruebas de EF, Mario Vega. Esta se refería al marco de pruebas de la capa de ejecución Ethereum . Vega sugirió que las especificaciones EELS (Ethereum Execution Layer Specification) y EEST (Ethereum Execution Specification Test Cases) fueran obligatorias para cualquier EIP incluido en una bifurcación dura. 

Sugirió que esto mejoraría el flujo de trabajo de pruebas y estandarizaría cómo se evalúan los EIP antes de su adopción.

Sin embargo, varios desarrolladores se opusieron a la propuesta. ¿El motivo? El requisito podría ralentizar el proceso de actualización. Van der Wijden argumentó que los mantenedores de EELS podrían convertirse en los guardianes de facto de la inclusión de EIP. ¿Por qué? No todos los desarrolladores son capaces de escribir implementaciones de sus propuestas basadas en Python. 

Wijden propuso un enfoque alternativo. ETH debería contar con implementaciones de EELS que pudieran enviarse como solicitudes de extracción sin fusionar. Esto evitaría que el equipo de EELS tuviera la potestad de aprobación final sobre las actualizaciones.

Justin Florentine, del Ethereum Besu, recomendó a la comunidad considerar la creación de un lenguaje de scripting adicional. Esto aclararía si se puede incluir un EIP sin casos de prueba EELS o EEST.