La comunidad de Ethereum avanza hacia la actualización Fusaka, pero las expectativas ya giran en torno a Glamsterdam, una próxima mejora que llegará en 2026 y traerá transformaciones significativas dentro del ecosistema de la red blockchain.
Glamsterdam concentra el interés de los desarrolladores debido a dos propuestas específicas: EIP-7732 y EIP-7928, las cuales se perfilan como pilares centrales en la evolución tecnológica del proyecto Ethereum.
La actualización Glamsterdam introduce la EIP-7732, denominada Enshrined Proposer-Builder Separation, cuyo objetivo es redefinir el modelo de creación de bloques, asegurando mayor descentralización y fortaleciendo la neutralidad de la red Ethereum frente a intentos de censura.
En lugar de que el validador encargado arme y valide todo el bloque, la propuesta establece que el proponente se concentre en consensuar, mientras que un constructor especializado gestione la ejecución y ensamble de cada transacción.
Este rediseño responde directamente a inquietudes crecientes sobre censura de transacciones, ya que al dividir responsabilidades se reduce la posibilidad de que actores maliciosos interfieran, garantizando un ecosistema más transparente, confiable y resistente para la comunidad.
Los usuarios se beneficiarían directamente mediante una red más descentralizada y con mayor resistencia a exclusiones arbitrarias, consolidando así la importancia del principio de neutralidad como base del funcionamiento de Ethereum.
En paralelo, la EIP-7928, llamada Block-Level Access Lists, busca transformar el procesamiento de transacciones mediante un sistema que permita ejecutar operaciones de manera paralela, incrementando notablemente la velocidad y la eficiencia en la red.
Hoy los nodos procesan transacciones de forma secuencial, limitando capacidad de respuesta; con esta propuesta, múltiples operaciones podrían validarse simultáneamente, agilizando confirmaciones y optimizando recursos técnicos utilizados por cada nodo.
El impacto será significativo en la experiencia de los usuarios, que dispondrán de operaciones confirmadas con mayor rapidez, latencia reducida y menores costos, generando beneficios concretos en un contexto de alta demanda transaccional.
La combinación de mejoras introducidas por ambas propuestas se presenta como un punto de inflexión tecnológico, proyectando a Ethereum hacia un futuro con mayor seguridad, resiliencia, eficiencia y costos considerablemente más competitivos para toda la comunidad.
Durante la reunión All Core Devs realizada el 19 de junio, los desarrolladores de Ethereum definieron una serie de EIP que serán implementadas en la segunda red de prueba conocida como Devnet-2, vinculada al fork Fusaka.
Una de las medidas más relevantes anunciadas en ese encuentro fue el incremento del límite de gas por bloque a 45 millones de unidades, lo cual representa un aumento teórico superior al 11 % en capacidad transaccional.
Si bien esta modificación no forma parte formal del fork Fusaka, fue aprobada por todos los clientes que participan del ecosistema Ethereum y será implementada una vez que concluyan las pruebas de software correspondientes.
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 incremento en la capacidad de gas será validado mediante benchmarks específicos, que permitirán asegurar que la propagación de bloques no exceda los niveles de latencia que la comunidad técnica considera razonables y seguros para su operación.
Además del rendimiento, Fusaka suma mejoras estructurales como la EIP-7928, diseñada para optimizar la gestión de blobs, los paquetes de datos introducidos previamente con la EIP-4844 durante la actualización denominada Dencun.
La EIP-7892 limitará la cantidad de blobs permitidos por transacción, lo que busca impedir que un solo rollup utilice en exceso el espacio de datos disponible y afecte la distribución entre proyectos.
La EIP-7918 establece tarifas mínimas y un límite 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.