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ó no solo en el código, sino también en el proceso: si se debe respetar la ventana previamente establecida de 30 días entre las versiones de los clientes y el primer fork en testnet, mientras avanza la actualización Fusaka. Algunos participantes impulsaron reafirmar el compromiso para que los equipos de infraestructura y aplicaciones tengan tiempo de 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 extendió más de lo previsto, según Barnabas Busa del equipo de Dev Ops. “Queríamos hacer aproximadamente dos días primero, y ahora estamos llegando al quinto día”, dijo, señalando cómo la participación bajó 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 mayor punto de conflicto fue la disciplina en la programación para las redes públicas. Lightclient subrayó la promesa vigente: “Dice 30 días antes del primer testnet”. Advirtió contra 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 las líneas de tiempo prolongadas retrasan todo lo demás en la cola, lo que podría disgustar 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 lanzando 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 derivó en 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. “Creo que es un muy mal precedente seguir permitiendo que las decisiones cambien”, dijo Lightclient, señalando que los desarrolladores de aplicaciones y las L2s 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 realmente existe un amplio apoyo para un camino más rápido, el grupo lo formalizaría por escrito.