cointribune.com
Mientras el ecosistema Ethereum continúa su búsqueda de rendimiento, el fork Fusaka está a punto de marcar un paso decisivo. Sin fanfarrias ni rupturas tecnológicas, esta actualización apunta a optimizaciones precisas de la máquina virtual y de la gestión de blobs. Lejos de los anuncios grandilocuentes, podría sin embargo reforzar de forma duradera la eficiencia de la red.
En resumen
- El fork Fusaka se integra en una estrategia de optimización de Ethereum, sin añadir nuevas funcionalidades mayores.
- El límite de gas se eleva a 45 millones, lo que podría aumentar la capacidad transaccional en más del 11 %, sujeto a pruebas.
- La gestión de blobs está mejor regulada gracias a las EIP-7892 y EIP-7918, para evitar abusos y mejorar la eficiencia del espacio del bloque.
- El fork Fusaka ilustra una elección estratégica de sobriedad técnica, con una gobernanza centrada en la eficiencia y la estabilidad de la red.
Fusaka: optimizaciones técnicas aprobadas para Devnet-2
Mientras una nueva ola sopla en Ethereum con los numerosos efectos positivos aportados por la actualización Pectra, los contribuyentes de Ethereum finalizaron durante la reunión All Core Devs del 19 de junio un conjunto de propuestas de mejora (EIP) para integrar en la segunda red de prueba de Fusaka, Devnet-2.
Uno de los anuncios más importantes es el aumento del límite de gas a 45 millones de unidades, es decir, un incremento teórico de más del 11 % en la capacidad transaccional por bloque. Aunque este cambio no forma parte formalmente de Fusaka, ha sido validado por todos los clientes.
Parithosh Jayanthi, ingeniero de la Fundación Ethereum, declaró: «todos los clientes parecen estar de acuerdo en pasar a 45 millones una vez que las versiones de software estén finalizadas».
Este aumento queda condicionado a benchmarks precisos, especialmente para evitar que la propagación de los bloques supere los umbrales de latencia aceptables.
Además de esta mejora de rendimiento, varias EIP estructurales, como la EIP-7928, se han integrado en Devnet-2 con el fin de regular mejor la gestión de blobs, esos paquetes de datos introducidos con la EIP-4844 durante el fork Dencun. La EIP-7892 limita el número de blobs que una transacción cripto puede incluir, un salvaguarda para evitar que un solo rollup monopolice el espacio de datos.
La EIP-7918, por su parte, establece un mínimo de tarifas y un techo en el número total de blobs por bloque. «Establecer un tamaño mínimo para los blobs permite paradójicamente incluir un mayor número», explicó Ben Adams del equipo Nethermind. También subraya que sin este mínimo, el coste podría volverse casi nulo en periodos de baja demanda, haciendo ineficiente el uso del bloque.
Fusaka: un consenso sobre las prioridades, pero tensiones sobre los olvidos
Más allá de estas mejoras técnicas, Fusaka también introduce varias optimizaciones más discretas pero significativas para los desarrolladores. La EIP-7939 agrega un nuevo opcode CLZ (contar ceros a la izquierda), una instrucción ya presente en la mayoría de las máquinas virtuales modernas y útil en ciertos cálculos relacionados con pruebas o generación aleatoria.
El fork también integra la EIP-7951, esperada desde hace tiempo, que añade una precompilación muy utilizada en firmas digitales en dispositivos móviles y plataformas empresariales. Este avance abre el camino para una mejor integración de Ethereum con estándares de autenticación.
Sin embargo, estas elecciones, consideradas pragmáticas por la mayoría de los desarrolladores cripto, no han sido unánimes. Georgios Konstantopoulos, CTO de Paradigm, criticó públicamente la no integración de correcciones para los errores de Solidity «stack too deep» y el límite de 24 KB del bytecode, dos problemas recurrentes para los desarrolladores. «Estos problemas están entre los más bloqueantes hoy en día», recordó en X.
I'm still baffled that the Ethereum Core Dev community does not prioritize fixing the 2 most cited problem of EVM developers per the Solidity Lang survey despite our repeated efforts:
— Georgios Konstantopoulos (@gakonst) June 19, 2025
1. Stack too Deep: yes this is a Solidity skill issue a little bit but just add a SWAP/DUP17-32…
El desarrollador cripto Potuz, del equipo Prysm, le respondió aclarando que estos temas se habían abordado en EOF (EVM Object Format), un proyecto que en su día fue apoyado por el equipo Reth de Paradigm antes de su cambio de rumbo. Indica que algunas decisiones también son fruto de cambios políticos en el ecosistema.
A falta de proponer una innovación espectacular, Fusaka podría sin embargo marcar un punto de inflexión estratégico. Este fork demuestra que Ethereum es capaz de adaptarse, optimizarse y consolidarse sin arriesgar su consenso. Las miradas están ahora puestas en Devnet-2, esperado para este lunes, y en un posible Devnet-3 más ambicioso. Apostando por la sobriedad técnica y una gobernanza más reactiva, los core devs de Ethereum parecen querer sentar las bases para una escalabilidad controlada, una elección que podría resultar decisiva este año, como lo demuestra el auge de la criptomoneda tras la actualización Pectra.