La llamada ACDE de Ethereum 205: Principales actualizaciones de Ethereum el 24 de febrero, 5 de marzo y 8 de abril
- La actualización Pectra de Ethereum está programada para el 24 de febrero en la red de prueba Holesky, con un despliegue en la red principal esperado para el 8 de abril de 2025.
- Se discutieron desacuerdos sobre el cronograma de la actualización Fusaka y la inclusión de EIP EOF, con los desarrolladores de Geth pidiendo más flexibilidad.
- Se plantearon preocupaciones sobre las pruebas obligatorias de EELS y EEST para las EIPs, con algunos desarrolladores temiendo retrasos en el proceso de actualización.
Los desarrolladores de Ethereum han finalizado el calendario para las próximas actualizaciones de la red. Los cambios principales están programados para tener lugar el 24 de febrero, 5 de marzo y 8 de abril. Las decisiones clave se finalizaron durante la reciente llamada All Core Developers Execution (ACDE) 205, celebrada el 13 de febrero de 2025.
La reunión semanal en Zoom las discusiones fue dirigida por Tim Beiko, líder de Soporte de Protocolo de la Fundación Ethereum (EF). Los desarrolladores confirmaron que la actualización Pectra se activaría en la red de prueba Holesky el 24 de febrero. Después, la red de prueba Sepolia se activará el 5 de marzo.
Si ambos despliegues proceden sin problemas, la red principal de Ethereum recibirá la actualización alrededor del 8 de abril.
Beiko dijo que se coordinaría con los equipos para encontrar un voluntario para desplegar los contratos del sistema Pectra en ambas redes de prueba.
Debates sobre futuras bifurcaciones de Ethereum y velocidad de actualización
Además, el equipo de desarrolladores discutió la próxima actualización planificada después de Pectra y Fusaka. Beiko proyecto congelando el alcance de Fusaka para cuando Pectra se lance en la red principal.
La línea de tiempo permite a los desarrolladores comenzar a trabajar en Fusaka mientras también planifican la siguiente bifurcación dura Glamsterdam.
El equipo de desarrollo de Geth no quiere trabajar con esta línea de tiempo. Argumentan que fue prematuro cementar el alcance de Fusaka. La inclusión de la Propuesta de Mejora de Ethereum (EIP) EOF en Fusaka ha provocado un considerable debate. Una facción de desarrolladores aboga por su exclusión de la próxima actualización.
EOF (Formato de Objeto Ethereum) es un actualización dirigido a mejorar la forma en que los contratos inteligentes están estructurados y ejecutados en la blockchain de Ethereum.
El desarrollador de Geth Lightclient se opuso a la aceleración de la congelación del alcance de Fusaka. El desarrollador argumenta que las prioridades de Ethereum podrían cambiar en los próximos dos años. Señaló que, aunque los desarrolladores apuntan a ciclos de actualización de seis meses, los retrasos del mundo real podrían extenderlos a ocho meses o más. Esto significa que mejoras importantes podrían no implementarse durante años.
Lightclient planteó preocupaciones sobre la incorporación de EOF, destacando el rápido progreso de la tecnología de rollup de prueba cero de Ethereum (zkEVMs). Los desarrolladores permanecen en la oscuridad respecto a la interacción de estos cambios con la máquina virtual.
Durante la discusión, el desarrollador de Geth Marius van der Wijden enumeró su alcance preferido para Fusaka, que incluía PeerDAS, FOCIL, EOF y límites superiores para modexp. El ingeniero de Operaciones de Desarrollo de la EF, Parithosh Jayanthi, se opuso, afirmando que FOCIL no estaba tan listo para la implementación como PeerDAS y EOF.
Actualizaciones de la red de prueba del software Pectra y comentarios de la comunidad
Los desarrolladores superaron sus desacuerdos sobre Fusaka para expresar confianza en la continua implementación de Pectra. El ingeniero de Desarrollo y Operaciones de la EF, Parithosh Jayanthi, informó que Pectra Devnet 6 estaba funcionando bien, con tasas de participación de validadores casi perfectas.
Además, la red de prueba Ephemery de Ethereum activó la actualización Pectra unas horas después de la llamada ACDE, permitiendo a los desarrolladores realizar pruebas adicionales.
Beiko pidió a los autores de EIPs de Pectra que movieran sus propuestas a la fase de "última llamada" en GitHub. Esto señala los pasos finales antes de la implementación en la red principal. También investigó los comentarios de la comunidad de Ethereum. Al respecto, señaló que la solicitud más común fue acelerar los ciclos de actualización.
En respuesta, sugirió que los desarrolladores de Ethereum deberían apuntar a finalizar el alcance de cada actualización tan pronto como la anterior se active en la red principal.
La línea de tiempo propuesta por Beiko para finalizar el alcance de Fusaka establece que, para el 13 de marzo, los desarrolladores deben proponer EIPs 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é EIPs deben considerarse para Fusaka. Finalmente, para el 10 de abril, se finalizará el alcance de la actualización.
Sin embargo, el investigador de la EF, Ansgar Dietrichs, añadió una excepción al cronograma. Señaló que las mejoras del código PeerDAS, un componente crítico de la actualización Pectra, deberían subirse a la red principal de Ethereum tan pronto como estén completas. Nadie se opuso a este requisito.
Preocupaciones sobre los estándares de prueba de EELS y EIP
Otro punto de preocupación durante la llamada ACDE fue una propuesta del ingeniero de pruebas de la EF, Mario Vega. Esto ocurrió en relación con el marco de pruebas de la capa de ejecución de Ethereum. Vega sugirió hacer obligatorias las EELS (Especificaciones de la Capa de Ejecución de Ethereum) y EEST (Casos de Prueba de Especificación de Ejecución de Ethereum) para cualquier EIP incluida en una bifurcación dura.
Sugirió que esto mejoraría el flujo de trabajo de pruebas y estandarizaría cómo se evalúan las EIPs antes de su adopción.
Sin embargo, varios desarrolladores se opusieron a la propuesta. ¿La razón? El requisito podría ralentizar el proceso de actualización. Van der Wijden argumentó que los mantenedores de EELS podrían convertirse en los porteros de facto de la inclusión de EIPs. ¿Por qué? No todos los desarrolladores son capaces de escribir implementaciones basadas en Python de sus propuestas.
Wijden sugirió un enfoque alternativo. ETH debería tener implementaciones de EELS que podrían presentarse como solicitudes de extracción (pull requests) no fusionadas. Esto evita que el equipo de EELS tenga el poder de aprobación final sobre las actualizaciones.
Justin Florentine con Ethereum el cliente Besu aconsejó a la comunidad considerar la creación de un lenguaje de scripting adicional. Esto aclararía si una EIP puede incluirse sin casos de prueba EELS o EEST.
Las mentes más inteligentes del mundo cripto ya leen nuestro boletín. ¿Quieres unirte? Únete a ellos.
Aviso de responsabilidad. La información proporcionada no es un consejo de trading. Cryptopolitan.com no asumimos responsabilidad alguna por las inversiones realizadas basándose en la información proporcionada en esta página. Recomendamos encarecidamente la investigación independiente y/o la consulta con un profesional calificado antes de tomar cualquier decisión de inversión.
Florence Muchai
Florence ha estado cubriendo durante los últimos 6 años noticias sobre criptomonedas, juegos, tecnología e inteligencia artificial. Sus estudios de Ciencias de la Computación en la Universidad de Ciencias y Tecnología de Meru y Gestión de Desastres y Diplomacia Internacional en MMUST la dotan adecuadamente de habilidades lingüísticas, de observación y técnicas. Florence ha trabajado en VAP Group y como editora en varias casas de medios de criptomonedas.
