Los desarrolladores de Ethereum CORE debaten los beneficios de bifurcaciones duras más frecuentes

¿Con qué frecuencia es demasiado frecuente alterar el consenso?

Un grupo de desarrolladores veteranos de código abierto de Ethereum discutió el tema en una reunión quincenal el viernes, en la que plantearon la posibilidad de que se puedan implementar actualizaciones de todo el sistema, también llamadas bifurcaciones duras, al software con una frecuencia de hasta cada tres meses.

Queriendo "verificar la temperatura", el desarrollador que hizo la pregunta explicó que ciertas propuestas de mejora de Ethereum (EIP) futuras, como alquileres estatalesSe necesitarían múltiples actualizaciones espaciadas secuencialmente para lograr el efecto completo.

Sin embargo, a ojos de Joseph Delong, ingeniero de software senior del estudio de capital de riesgo Consensys, tres meses es “demasiado QUICK para una recuperación”.

El líder del equipo de la Fundación Ethereum , Péter Szilágyi, estuvo de acuerdo y explicó:

Como desarrollador de clientes de software, si tu único trabajo es implementar bifurcaciones duras y realizarlas, tres meses está bien, pero normalmente los clientes requieren mucho mantenimiento. Por lo tanto, si empiezas a realizar bifurcaciones duras cada tres meses, básicamente perderás tiempo dedicado al mantenimiento general y a las mejoras de rendimiento.

El líder de seguridad de la Fundación Ethereum , Martin Hoste Swende, si bien estuvo de acuerdo en que una bifurcación dura cada tres meses "sería algo malo", señaló que los casos particulares con cambios simples acordados por unanimidad podrían tener tiempos de ejecución más cortos.

“La idea no sería programar una bifurcación dura cada tres meses, sino ver si la característica X está terminada, si existen casos de prueba y si está implementada en todos los clientes. De ser así, podríamos hacer una bifurcación dura muy pronto”, argumentó Swende durante la llamada.

Pero al alentar a los desarrolladores a llevar sus planes "paso a paso", Fredrik Harryson, director de tecnología de Parity Technologies, señaló que incluso un cronograma de seis meses para una bifurcación dura planificada de Ethereum nunca se ha cumplido.

Hay un par de cosas que probablemente necesitemos automatizar para que las bifurcaciones duras más cortas funcionen realmente bien. Gran parte del tiempo que se dedica a una bifurcación dura no se limita a crear el código, sino a todo lo que se genera”, dijo Harryson.

Además de esto, el asesor de la Fundación Ethereum , Greg Colvin, señaló que la mayoría de los equipos que crean clientes de software de Ethereum actualmente no tienen "la persona adecuada" para manejar trabajos esenciales para la implementación de la bifurcación dura, como "configurar redes de prueba, ejecutar casos de prueba, realizar pruebas", entre otras responsabilidades.

A esto, Harryson respondió que el problema era la falta de recursos económicos para incorporar a esos miembros del equipo. "Para nosotros, es cuestión de dinero. No tenemos suficiente dinero para respaldarlo", bromeó Harryson.

Actualizaciones de varios pasos

Pero no es sólo una cuestión de si debería haber bifurcaciones duras más frecuentes o no.

Los desarrolladores durante la llamada de hoy también discutieron si había una necesidad de cambios ambiciosos y de largo plazo en la actual cadena de bloques de Ethereum a la luz de un movimiento inminente hacia Ethereum 2.0, una nueva red de Ethereum que una vez que esté completamente activada, los usuarios migrarían desde la red principal actual.

Sugiriendo que desarrolladores como Alexey Akhunov y el fundador de Ethereum , Vitalik Buterin, han advertido contra "cambios que no son para la supervivencia de la cadena [actual de Ethereum]", Harryson preguntó:

“¿Cuánto podemos influir en esto, porque [el EIP 615] da lugar a una larga cadena de mejoras que se prolongará durante varios años antes de que podamos ver beneficios masivos?”

La EIP 615 es una de las cinco propuestas consideradas para su inclusión en la próxima bifurcación dura de Ethereum , llamada Estambul. Su objetivo es introducir mejoras en el núcleo del código base de Ethereum , conocido como la Máquina Virtual de Ethereum (EVM), responsable de ejecutar todas las líneas de código autoimplementables (también llamadas contratos inteligentes) en la plataforma.

La EVM también es una Tecnología clave que otras iniciativas de blockchain empresarial como HipercontadorSe ha informado en el pasado que se ha creado interoperabilidad con.

El diseño del EVM dificulta la ejecución de alto rendimiento con bajo coste de gas. Proponemos avanzar con propuestas para resolver estos problemas reforzando las garantías de seguridad y ampliando los límites de rendimiento del EVM.escribelos autores de EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic y Christina Reitwiessner.

Sin embargo, como señaló Swende durante la llamada de hoy, la EIP 615 tal como se propone requeriría al menos dos bifurcaciones duras para ejecutarse completamente y "un efecto de velocidad positivo" en los cálculos de código reales en la EVM no se notaría hasta que se ejecute la última bifurcación dura.

Esa es mi principal preocupación sobre este EIP: implica mucho trabajo, pero no creo que conduzca a una EVM mucho mejor. Podría ser mejor para las herramientas externas, como si se estuviera realizando un análisis inverso de las propiedades de seguridad de un contrato inteligente, dijo Swende.

Zelenka sugirió que estas herramientas son esenciales para garantizar una "compatibilidad futura" continua con las futuras actualizaciones de EVM como eWASM y una experiencia de incorporación fluida para los desarrolladores de contratos inteligentes en vista de "una fecha de lanzamiento indeterminada de Ethereum 2.0".

"Existen otras opciones para los desarrolladores de contratos inteligentes. Necesitamos KEEP Ethereum 1.x activo, y eso significa seguir avanzando", argumentó Zelenka en la llamada de hoy.

Al aceptar continuar el debate y la discusión sobre el EIP en las próximas semanas, Swende concluyó que en la actualidad sigue siendo escéptico sobre "implementar cambios tan grandes en el viejo motor que básicamente requiere un par de bifurcaciones duras antes de que finalmente se asiente".

Pero coincidiendo con el sentimiento incierto sobre el futuro de Ethereum 2.0, Harryson, quien planteó la pregunta inicial sobre las ambiciosas actualizaciones de múltiples bifurcaciones, dijo:

“No deberíamos ajustar nuestra hoja de ruta o nuestro pensamiento en función de lo que Ethereum 2.0 pueda o no ser”.

Imagen de una horquilla vía Shutterstock