Escrito por: imToken
Objetivamente hablando, en los últimos tiempos, la percepción intuitiva de muchos usuarios sobre Ethereum no provenía de su hoja de ruta o de las reuniones de desarrolladores, sino de operaciones concretas en la cadena.
Por ejemplo, en los últimos dos años, todos hemos experimentado personalmente la disminución del Gas al realizar transferencias y la mejora en la experiencia de interoperabilidad entre cadenas, entre otros aspectos. Es por eso que la escalabilidad de Ethereum no es un simple problema de "competencia de rendimiento": para el usuario promedio, un mayor TPS, bloques más grandes y arquitecturas subyacentes más complejas solo tienen sentido cuando se traducen realmente en costos más bajos, operaciones más fluidas y una experiencia de billetera más segura.
Y una serie de nuevos desarrollos recientes en Ethereum apuntan precisamente a intentar trasladar sistemáticamente al nivel de protocolo la complejidad que antes recaía en las billeteras, las DApps, los retransmisores de terceros y los propios usuarios.
Entre estos, se incluye la participación de Vitalik en los Keyed Nonces, la formación de un consenso direccional en torno al "piso" de 200 millones de Gas Limit en la actualización Glamsterdam, y una serie de indicios en la hoja de ruta 2026 que enfatizan continuamente la abstracción de cuentas nativa, la interoperabilidad entre L2 y el fortalecimiento de la seguridad de L1, entre otros.
1. ¿Límite de Gas aumentado a 200 millones?
Primero, veamos el punto más fácilmente perceptible para los usuarios: el Límite de Gas.
Como es sabido, en la red Ethereum, cada transacción (ya sea una transferencia o una interacción con un contrato) consume una cierta cantidad de Gas, y la capacidad del Límite de Gas de cada bloque de Ethereum es fija, es decir, hay un número limitado de espacios: cuantos más espacios, más pasajeros se pueden transportar en el mismo período de tiempo; cuanto más limitados sean los espacios, más tendrán que pujar por el mismo asiento, y la tarifa de Gas aumentará.
En teoría, aumentar el límite de Gas por bloque efectivamente mejoraría directamente y de manera significativa el rendimiento de la red principal de Ethereum. Sin embargo, en el pasado, Ethereum, en el contexto del gran desarrollo de rutas como L2, había sido bastante cauteloso y reservado al respecto, dirigiendo intencionalmente la mayor parte de la presión de escalabilidad hacia el ecosistema L2.
Si observamos la curva de expansión del Límite de Gas de Ethereum, veremos que desde septiembre de 2019, cuando el Límite de Gas de la red Ethereum superó por primera vez los 10 millones desde los 8 millones, hasta este año, pasaron 7 años para que el Límite de Gas pasara de 8 millones a 60 millones. Especialmente en 2025, cuando realmente entró en una fase de aceleración: en febrero, de 30 millones a 36 millones, en julio aumentó a 45 millones y, después de la actualización Fusaka en diciembre, se incrementó a 60 millones.
Podría decirse que la mayor parte de la expansión se concentró en el año 2025. Por supuesto, como hemos mencionado antes, 2025 también fue un año crucial en la historia del desarrollo de Ethereum. La actualización Fusaka, solo 7 meses después de la actualización Pectra en mayo, demostró que la Ethereum Foundation, incluso después de importantes ajustes en su liderazgo, todavía tiene la capacidad de promover actualizaciones importantes, marcando también la entrada oficial de Ethereum en el ritmo acelerado de desarrollo de "hard forks dos veces al año" (lectura adicional: "Ethereum 2026: Interpretando la última hoja de ruta del protocolo de la EF, ¿entrando oficialmente en la era de las 'actualizaciones de ingeniería'?").
Fuente: Etherscan
Y según el "Soldøgn Interop Recap" publicado por la Ethereum Foundation el 2 de mayo, más de 100 contribuyentes principales de Ethereum participaron en una conferencia de interoperabilidad en torno a la actualización Glamsterdam en las Islas Svalbard, Noruega. El objetivo principal fue impulsar la implementación, pruebas y alineación de parámetros multi-cliente para Glamsterdam. Al final de la conferencia, los desarrolladores ya habían formado un consenso direccional en torno a un Límite de Gas de 200 millones después de Glamsterdam.
Esto significa que, si los procesos posteriores avanzan sin problemas, la capacidad de ejecución de L1 de Ethereum podría aumentar desde el límite actual de aproximadamente 60 millones de Gas a un nivel de alrededor de 200 millones. En una dimensión de tiempo más larga, la actitud del ecosistema Ethereum hacia la discusión pública del Límite de Gas se ha vuelto notablemente más "agresiva". Incluso la propuesta EIP-9698 sugiere "aumentar diez veces cada dos años", elevando el Límite de Gas a 3.6 mil millones para 2029, 50 veces el nivel actual.
Sin embargo, es importante enfatizar que aumentar el Límite de Gas no es simplemente agrandar el bloque.
Si solo se aumenta bruscamente la cantidad de cálculo que cada bloque puede contener, a corto plazo podría reducir las tarifas, pero a largo plazo aumentaría la carga sobre los nodos y la inflación de datos de estado, lo que también significa que sería más difícil para los usuarios promedio ejecutar nodos, debilitando eventualmente la base de descentralización más central de Ethereum.
Por lo tanto, el enfoque de escalabilidad de Glamsterdam es un conjunto de medidas combinadas:
- ePBS (Proposer-Builder Separation integrado en el protocolo) incorpora de manera más clara el proceso de construcción y verificación de bloques en las reglas del protocolo, permitiendo que los validadores procesen bloques más grandes de manera más segura;
- Las Block-Level Access Lists (BAL) registran de antemano las cuentas y ubicaciones de almacenamiento que se accederán durante la ejecución del bloque, permitiendo así lecturas paralelas de disco, verificación paralela de transacciones y cálculo paralelo de la raíz de estado;
- Y EIP-8037, al aumentar el costo de las operaciones relacionadas con la creación de estado, evita un crecimiento de estado demasiado rápido después de que se aumente el Límite de Gas.
En resumen, Ethereum no solo quiere "contener más transacciones", sino que también está pensando en cómo, al contener más transacciones, no permitir que el umbral de ejecución de nodos se vuelva cada vez más alto.
Esta es también la diferencia fundamental entre la ruta de escalabilidad de Ethereum y las narrativas de muchas cadenas de alto rendimiento: no ha buscado sacrificar el costo de verificación a cambio de un rendimiento superficial, sino mejorar la capacidad de carga de la red principal en sí, manteniendo en la medida de lo posible la capacidad de participación de los nodos promedio y la verificabilidad del sistema.
2. Keyed Nonces: Convertir "una sola fila" en "múltiples canales"
Si el Límite de Gas resuelve "cuánto puede contener un bloque", entonces los Keyed Nonces se centran en otro problema más detallado pero crucial: ¿cómo deben hacer cola las transacciones?
Como es sabido, en Ethereum, el nonce puede entenderse simplemente como el "número de secuencia" de las transacciones de una cuenta. Su función es evitar que una misma transacción se ejecute repetidamente y garantizar que las transacciones enviadas desde la misma cuenta se procesen en orden.
Este mecanismo es fácil de entender en escenarios de transferencia comunes: la primera transacción, la segunda, la tercera, y así sucesivamente.
Pero el problema es que cuando las capacidades de la cuenta se vuelven más complejas, como en transacciones privadas, billeteras inteligentes, claves de sesión, operaciones por lotes o pagos de terceros, el nonce lineal único puede convertirse en un cuello de botella. Por lo tanto, los Keyed Nonces propuestos por EIP-8250 tienen como idea central cambiar el modelo en el que una cuenta tiene solo una cola de nonce, para que pueda tener múltiples dominios de nonce.
En concreto, reemplaza el nonce único del remitente en las Frame Transactions de EIP-8141 por una estructura (nonce_key, nonce_seq), donde nonce_key == 0 corresponde al nonce de cuenta tradicional, mientras que las claves distintas de cero pueden elegir secuencias de nonce gestionadas por el protocolo de forma independiente. Las transacciones bajo diferentes claves son independientes entre sí y la protección contra reproducción no se afecta mutuamente.
Esto suena muy técnico, pero se puede entender con una analogía de la vida cotidiana: antes, una cuenta era como tener una sola ventanilla en el banco, donde todos los trámites tenían que hacer la misma fila; los Keyed Nonces son como asignar diferentes trámites a diferentes ventanillas: transferencias, retiros privados, autorizaciones de sesión, ejecuciones por lotes pueden cada uno tomar su propio canal.
Esto es especialmente importante para los protocolos de privacidad, porque para evitar vincular directamente la actividad en cadena de un usuario a una dirección pública específica, los protocolos de privacidad pueden hacer que múltiples usuarios inicien transacciones a través de una misma dirección de remitente compartida. Pero bajo el mecanismo de nonce único, una vez que se incluye la transacción de un usuario en un bloque, puede hacer que las transacciones de otros usuarios que aún están esperando fallen o se bloqueen.
Y los Keyed Nonces permiten que cada gasto elija su propio dominio de nonce, por ejemplo, derivado de un nullifier de privacidad, reduciendo este conflicto de colas desde el nivel del protocolo.
La visión del propio Vitalik al respecto es aún más amplia. Al presentar el EIP-8250, expresó claramente que los Keyed Nonces "no solo son un mayor apoyo para las soluciones de privacidad a nivel de protocolo, sino que también podrían ser el primer paso hacia una nueva estrategia de escalabilidad de estado para Ethereum, logrando una escalabilidad extrema manteniendo la descentralización del protocolo, mediante la creación de tipos de almacenamiento específicamente optimizados para diferentes casos de uso".
En otras palabras, se podría simplificar diciendo que el Límite de Gas resuelve "el tamaño del bloque", mientras que los Keyed Nonces exploran la "forma del estado": lo que Ethereum debe soportar en el futuro no son solo más transacciones, sino más tipos de transacciones.
3. ¿Cómo afectará esto al usuario promedio?
Para el ecosistema Ethereum, muchas actualizaciones de protocolo parecen estar lejos del usuario promedio, pero eventualmente se reflejan en la experiencia de la billetera.
Porque la entrada real del usuario a Ethereum no son los EIPs, los clientes o las reuniones de desarrolladores, sino cada transferencia, autorización, firma, interacción entre cadenas y con DApps dentro de su billetera. Es decir, los cambios a nivel de protocolo solo completan realmente la transición desde una actualización técnica hasta una actualización de la experiencia del usuario cuando se traducen en una experiencia de operación más clara, fluida y segura a nivel de la billetera.
Por ejemplo, la abstracción de cuentas, algo con lo que todos estamos familiarizados ahora, no existe para que los usuarios comprendan más términos técnicos, sino para que en el futuro puedan usar sus cuentas en cadena de manera más natural. Por eso, en los últimos años, las transacciones por lotes, el pago de Gas por terceros, los mecanismos de recuperación, los diferentes métodos de firma, las autorizaciones de sesión y las estrategias de seguridad más flexibles se han ido convirtiendo gradualmente en capacidades básicas dentro de las billeteras.
Del mismo modo, tomando como ejemplo los Keyed Nonces, suenan como una optimización muy de bajo nivel del mecanismo de cola de cuentas, pero en el lado del usuario, su impacto potencial no es abstracto. Porque hoy muchos usuarios, al operar en cadena, probablemente han encontrado escenarios similares: una transacción que tarda mucho en confirmarse, bloqueando las transacciones posteriores; querer cancelar o acelerar una transacción sin entender la relación entre nonce, Gas y reemplazo de transacciones, especialmente durante múltiples operaciones paralelas, donde un paso fallido afecta todo el flujo posterior.
Para el usuario promedio, estos problemas parecen ser "la billetera no funciona bien" o "la cadena no funciona bien", pero en realidad están relacionados con el diseño del nonce lineal único en el modelo de cuentas de Ethereum. Y la dirección representada por los Keyed Nonces es permitir que las cuentas ya no ejecuten todas las operaciones secuencialmente en una sola fila, sino que puedan dividirse en múltiples canales paralelos según diferentes escenarios de uso.
En el futuro, las transferencias comunes, las autorizaciones de DApps, las transacciones privadas, las transacciones por lotes, los pagos de Gas por terceros y otras operaciones podrían, en teoría, tener espacios de ejecución más independientes, reduciendo la probabilidad de bloqueos y conflictos mutuos.
Esto sin duda abrirá aún más el espacio de diseño de las billeteras inteligentes.
Lo más importante es que, en el pasado, estas capacidades a menudo requerían que la billetera, la DApp, los servicios de retransmisión y el usuario asumieran juntos la complejidad. Los usuarios tenían que entender el alcance de las autorizaciones, juzgar si el Gas era razonable, saber exactamente qué estaban firmando, y confirmar repetidamente en operaciones de múltiples pasos como puentes entre cadenas, intercambios, staking, reclamo de recompensas, etc. Cualquier malentendido en cualquier paso podía conllevar riesgo de fallo operativo y pérdida de activos.
Y lo que Ethereum está intentando hacer ahora es precisamente trasladar parte de esa complejidad al nivel del protocolo, permitiendo que las billeteras, basadas en capacidades subyacentes más estandarizadas y nativas, ofrezcan una mejor abstracción de interacción para los usuarios.
Es por eso que el Límite de Gas, las BAL, el ePBS, los Keyed Nonces, las Frame Transactions, la abstracción de cuentas nativa y la interoperabilidad entre L2, aunque aparentemente pertenecen a diferentes módulos técnicos, en realidad están al servicio de lo mismo: permitir que Ethereum soporte escenarios de uso en cadena más complejos sin sacrificar la descentralización y la seguridad.
Concretamente, al observar juntos estos desarrollos, se ve que los puntos focales recientes de Ethereum no están dispersos:
- El aumento del Límite de Gas resuelve la capacidad de ejecución de la red principal y la presión sobre las tarifas.
- Las BAL, el ePBS y el EIP-8037 resuelven cómo mantener la verificabilidad de los nodos y el crecimiento controlado del estado durante el proceso de escalabilidad.
- Los Keyed Nonces y las Frame Transactions abordan los cuellos de botella a nivel de protocolo en el modelo de cuentas, los protocolos de privacidad y las billeteras inteligentes.
- La abstracción de cuentas nativa y la interoperabilidad entre L2 apuntan aún más a las mejoras de experiencia que los usuarios promedio realmente pueden sentir.
Esto también significa que Ethereum está entrando en una nueva etapa.
Después de todo, en los últimos años, el mercado se ha centrado más en la escalabilidad de L2, la reducción de costos con Blobs y las narrativas de modularidad, y los usuarios se han ido acostumbrando gradualmente a transferir activos entre diferentes L2 y a buscar entornos de interacción de menor costo. Pero a medida que el Límite de Gas de la red principal continúa aumentando, se avanza en actualizaciones como Glamsterdam, y evolucionan continuamente las soluciones de abstracción de cuentas e interoperabilidad, la pregunta que Ethereum está respondiendo ya no es solo "cómo hacer que las transacciones sean más baratas", sino "cómo hacer que la experiencia en cadena sea más como un todo unificado".
En este proceso, la importancia de las billeteras sin duda se amplificará aún más.
Porque la billetera no es solo la entrada del usuario a Ethereum, sino también la interfaz a través de la cual las capacidades del protocolo son realmente comprendidas y utilizadas por los usuarios. En el futuro, cuanto más complejas sean las actualizaciones subyacentes, más necesitarán traducirse, a través de la billetera, en indicaciones de firma más claras, rutas de transacción más comprensibles, identificación de riesgos más anticipada y una experiencia de interacción en cadena más fluida.
Un saludo a todos.
