Desarrolladores de Ethereum Programan la Actualización Fusaka para Diciembre

Por Vince Dioquino

La decisión se tomó después de las pruebas en Fusaka Devnet-5, que destacaron algunos errores de software y configuración que acortaron el tiempo que los desarrolladores tenían para medir la capacidad de datos, según un resumen de la investigadora Christine Kim.

Durante el breve período en que la red de prueba estaba estable, los desarrolladores acordaron aumentar la capacidad de blobs en dos pasos: primero a 10/15 blobs por bloque, luego a 14/21. Un blob en Ethereum es un paquete de datos temporal que los rollups, o soluciones de agrupación y escalado en la red, utilizan para publicar datos de transacciones en la cadena de bloques a costos más bajos.

Otra red de prueba de Ethereum, llamada Devnet-6, se lanzará pronto para verificar esos números antes de que se implementen en las redes de prueba públicas y en la red principal, según los registros de la llamada.

Los desarrolladores encontraron que el cliente Prysm, uno de los principales clientes validadores de Ethereum, tuvo dificultades bajo cargas elevadas, creando bloques huérfanos.

Los clientes validadores son el software que ejecuta el sistema de prueba de participación de Ethereum, responsable de proponer y verificar bloques. Un bloque queda "huérfano" cuando fue producido correctamente por un validador, pero fue rechazado porque la red eligió un bloque diferente para el mismo lugar en la cadena.

El investigador de Ethereum Justin Traglia dijo que se había corregido un error en la biblioteca ckzg, utilizada para verificar bloques, y agregó que se está preparando una versión más ligera para facilitar las actualizaciones de los equipos de clientes.

La Fundación Ethereum no respondió de inmediato a la solicitud de comentarios de Decrypt.

Según las notas de Kim, el cronograma más rápido tiene como objetivo brindar a las rollups más espacio de blob para manejar transacciones y mantener las tarifas bajas, con la capacidad aumentada paso a paso para reducir el riesgo de sobrecargar la red. Durante la llamada, los desarrolladores también confirmaron que los equipos de clientes enviarán versiones combinadas para las actualizaciones de la red de prueba de octubre y ejecutarán bifurcaciones en paralelo, o copias de la red principal de Ethereum, antes de la implementación. Los desarrolladores luego acordaron que los retrasos siguen siendo posibles si aparecen nuevos errores o si las pruebas no son suficientes.

La actualización Fusaka sigue a Pectra, que fue lanzada en mayo y ayudó a que la red de Ethereum sea más fácil de usar, aumentó los límites de participación y aumentó la capacidad de datos para reducir los costos de las rollups.

En ese momento, los observadores de la industria elogiaron a Pectra como un punto de inflexión en la hoja de ruta de Ethereum, pero también advirtieron que las presiones de escalabilidad persistirían, con las rollups necesitando mucha más capacidad de blob para mantenerse sin congestiones a medida que aumenta el uso.

Fusaka está diseñado para abordar esa demanda, implementando límites de blob más altos mucho antes a medida que la actividad de la red continúa aumentando.

Noticias recomendados