Los desarrolladores principales de Ethereum discuten sobre el proceso y el cronograma de Fusaka

La última reunión de All Core Devs de Ethereum se centró en el proceso, no solo en el código: si se debe respetar una ventana previamente establecida de 30 días entre las versiones de los clientes y el primer fork de testnet, mientras la actualización Fusaka avanza. Algunos participantes presionaron para reafirmar el compromiso, de modo que los equipos de infraestructura y aplicaciones tengan tiempo para adaptarse; otros argumentaron a favor de la flexibilidad para evitar retrasos más amplios en la hoja de ruta.

El debate se desarrolló en un contexto de resultados mixtos en devnet. En Devnet-3, un ejercicio planificado de no-finalidad se prolongó, según Barnabas Busa del equipo de Dev Ops. “Queríamos hacerlo aproximadamente durante dos días al principio, y ahora estamos llegando al quinto día”, dijo, señalando cómo la participación disminuyó y luego volvió a superar el 50%. La finalidad requiere que más de dos tercios del stake efectivo total estén de acuerdo.

En contraste, una testnet separada se recuperó rápidamente después de un reinicio coordinado: “La cadena se ha recuperado en, creo, dos horas”, dijo Busa. El ejercicio pone a prueba cómo interactúan las variables en un incidente en vivo, lo que puede ayudar a Ethereum a recuperarse en una crisis.

Leer más: La actualización Fusaka de Ethereum podría enfrentar retrasos

Con las correcciones llegando en los próximos días, el plan a corto plazo es restaurar Devnet-3 a plena salud, repetir la prueba y luego lanzar Devnet-5.

Pero el punto de mayor tensión fue la disciplina de programación para las redes públicas. Lightclient subrayó la promesa vigente: “Dice 30 días antes del primer testnet”. Advirtió en contra de cambiar los objetivos por conveniencia, basándose en la evaluación de los core devs sobre el tiempo que necesitan otros equipos que no están presentes en la llamada.

La preocupación práctica es cómo mejorar la cadencia de los hard forks. Comprimir los intervalos entre pruebas puede acelerar los forks, pero aumenta el riesgo de que los equipos posteriores lancen actualizaciones apresuradas. El argumento contrario es que los procesos prolongados retrasan todo lo demás en la cola, lo que podría desagradar a la comunidad más amplia de Ethereum.

“No creo que debamos elegir los plazos basándonos necesariamente en lo que quiere la comunidad”, dijo Lightclient. “Las personas que están entregando el software dijeron que quieren 30 días para entregar un software de alta calidad que la comunidad va a usar.”

Aun así, el intercambio algo tenso se inclinó hacia mantener el proceso escrito a menos que las partes interesadas soliciten explícitamente un cambio.

También hubo frustración por volver a tratar la misma cuestión en cada ciclo. “Simplemente creo que es un muy mal precedente seguir permitiendo que las decisiones cambien”, dijo Lightclient, señalando que los desarrolladores de aplicaciones y los L2 normalmente no están en las llamadas principales y dependen de ventanas predecibles para programar sus propios lanzamientos.

Por ahora, el consenso es proceder como si el margen de 30 días siguiera vigente, mientras se solicita proactivamente nueva información, dijo el coordinador Tim Beiko. “Deberíamos preparar el cronograma con lo que está en el documento [de proceso] y luego, en paralelo, consultar con las partes interesadas que se vean afectadas.” Si una vía más rápida realmente cuenta con un amplio apoyo, el grupo lo formalizaría por escrito.