Objetivamente hablando, durante el último tiempo, la percepción intuitiva de muchos usuarios sobre Ethereum a menudo no proviene del roadmap o de las reuniones de desarrolladores, sino de operaciones específicas en la cadena.
Por ejemplo, en los últimos dos años, todos hemos experimentado de primera mano que el Gas para transferencias es cada vez más bajo, la experiencia de interoperabilidad entre cadenas ha mejorado, etc. Es por eso que la expansión de Ethereum nunca ha sido un simple problema de "competencia de rendimiento".Para los usuarios comunes, un TPS más alto, bloques más grandes y una arquitectura subyacente más compleja 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 la complejidad que antes asumían las billeteras, las DApps, los relés de terceros y los propios usuarios hacia la capa de protocolo.
Entre ellos, se incluyen los "Keyed Nonces" en los que participa Vitalik, el consenso direccional formado en torno al límite mínimo (floor) de Gas Limit de 200 millones en la actualización de Glamsterdam, y las pistas continuas en el roadmap de 2026 que enfatizan la abstracción de cuentas nativa, la interoperabilidad entre L2s, el fortalecimiento de la seguridad de L1 y más.
一、¿Gas Limit incrementado a 200 millones?
Primero, veamos el punto más fácilmente perceptible para los usuarios: el Gas Limit.
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 Gas Limit de cada bloque de Ethereum es fija, es decir, hay espacios limitados:cuantos más espacios, más pasajeros se pueden transportar en el mismo período; cuanto más limitados sean los espacios, más tendrán que pujar por el mismo asiento, y la tarifa de Gas también aumentará.
En teoría, la expansión del límite máximo de Gas por bloque mejoraría directamente y significativamente el rendimiento de la red principal de Ethereum. Sin embargo, en el pasado, Ethereum, en el contexto del gran desarrollo de rutas como L2, ha sido bastante cauteloso y restringido al respecto, dirigiendo deliberadamente la mayor parte de la presión de escalabilidad hacia la pista de las L2.
Al revisar la curva de expansión del Gas Limit de Ethereum, se puede ver que desde que el Gas Limit de la red de Ethereum superó por primera vez los 10 millones en septiembre de 2019 desde los 8 millones, hasta este año, en 7 años, el Gas Limit solo pasó de 8 millones a 60 millones.Especialmente en 2025 fue cuando realmente entró en una fase de aceleración: de 30 millones a 36 millones en febrero, luego a 45 millones en julio, y después de la actualización de Fusaka en diciembre, se aumentó a 60 millones.
Podría decirse que la mayor parte de la expansión se concentró en el año 2025. Por supuesto, como mencionamos antes, 2025 también fue un año crucial en la historia del desarrollo de Ethereum. Solo 7 meses después de la actualización de Pectra en mayo, la actualización de Fusaka demostró que EF, tras un importante ajuste en el liderazgo, todavía tenía la capacidad de impulsar actualizaciones importantes, y también marcó la entrada oficial de Ethereum en el ritmo de desarrollo acelerado de "bifurcaciones duras (hard forks) dos veces al año" (lectura extendida "Ethereum 2026: Interpretando el último mapa de ruta de protocolo de EF, ¿entrando oficialmente en la era de las 'actualizaciones de ingeniería'?").
Fuente: Etherscan
Según el "Soldøgn Interop Recap" publicado por la Ethereum Foundation el 2 de mayo, más de 100 contribuidores principales de Ethereum participaron en una conferencia de interoperabilidad en las islas Svalbard, Noruega, centrada en la actualización de Glamsterdam, con el objetivo principal de avanzar en la implementación multicliente, pruebas y alineación de parámetros para Glamsterdam. Al final de la conferencia, los desarrolladores ya habían formado un consenso direccional en torno a un Gas Limit 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 actual Gas Limit de aproximadamente 60 millones a un nivel de 200 millones. En una dimensión temporal más larga, la actitud públicamente discutible del ecosistema de Ethereum hacia el Gas Limit se ha vuelto claramente mucho más "agresiva". Incluso la propuesta EIP-9698 sugiere "aumentar diez veces cada dos años", elevando el Gas Limit a 3.6 mil millones para 2029, 50 veces el nivel actual.
Pero es importante enfatizar aquí que aumentar el Gas Limit no es simplemente agrandar los bloques.
Si solo se aumenta brutalmente la capacidad de cómputo que puede contener cada bloque,a corto plazo podría reducir las tarifas, pero a largo plazo conduciría a una mayor carga para los nodos y a una inflación de los datos de estado, lo que también significaría que sería más difícil para los usuarios comunes ejecutar nodos, debilitando finalmente 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 (enshrined Proposer-Builder Separation) incorpora de manera más clara el proceso de construcción y verificación de bloques en las reglas del protocolo, permitiendo a los validadores procesar bloques más grandes de manera más segura;
- Block-Level Access Lists (BAL) registra de antemano las cuentas y ubicaciones de almacenamiento a las que se accederá durante la ejecución del bloque, permitiendo así lecturas de disco en paralelo, verificación de transacciones en paralelo y cálculo de raíces de estado en paralelo;
- Y EIP-8037, al aumentar el costo de las operaciones relacionadas con la creación de estado, evita un crecimiento excesivo del estado después de aumentar el Gas Limit;
En resumen, Ethereum no solo quiere "acomodar más transacciones", sino que también está pensando en cómo, al acomodar más transacciones, no hacer que el umbral para ejecutar un nodo 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. Siempre ha buscado no sacrificar el costo de verificación por un rendimiento superficial, sino mejorar la capacidad de carga de la red principal manteniendo, en la medida de lo posible, la capacidad de participación de los nodos comunes y la verificabilidad del sistema.
二、Keyed Nonces: convertir "una sola fila" en "múltiples canales"
Si el Gas Limit resuelve "cuánto puede contener un bloque", entonces Keyed Nonces se enfoca en otro problema más detallado pero crucial: ¿cómo deben hacer cola las transacciones?
Como es sabido, en Ethereum, 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 asegurar que las transacciones enviadas desde una misma cuenta se procesen en orden.
Este mecanismo es fácil de entender en escenarios de transferencias comunes: la primera transacción, la segunda, la tercera, en orden secuencial.
Pero el problema es que cuando las capacidades de una cuenta se vuelven más complejas, como en transacciones de privacidad, billeteras inteligentes, claves de sesión, operaciones por lotes o pagos por terceros, un nonce lineal único puede convertirse en un cuello de botella. Por lo tanto, la idea central de Keyed Nonces, propuesta en EIP-8250, es cambiar de una sola cola de nonce por cuenta a que una cuenta pueda tener múltiples dominios de nonce.
En concreto, reemplaza el nonce único del emisor (sender nonce) en las Frame Transactions de EIP-8141 por una estructura (nonce_key, nonce_seq), donde nonce_key == 0 corresponde al nonce de cuenta tradicional, y las claves distintas de cero pueden elegir secuencias de nonce gestionadas de forma independiente por el protocolo. Las transacciones bajo diferentes claves son independientes entre sí y no se afectan mutuamente en cuanto a prevención de replay.
Esto suena muy técnico, pero puede entenderse con una analogía de la vida cotidiana:antes, una cuenta era como tener una sola ventanilla en un banco, todos los trámites tenían que hacer cola en la misma fila; Keyed Nonces es como asignar diferentes trámites a diferentes ventanillas: transferencias, retiros de privacidad, autorizaciones de sesión, ejecuciones por lotes pueden seguir sus propios canales.
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 emisor compartida. Pero bajo un mecanismo de nonce único, una vez que se confirma una transacción de un usuario, puede hacer que las transacciones de otros usuarios que aún esperan fallen o se bloqueen.
Mientras que Keyed Nonces permite que cada gasto elija su propio dominio de nonce, derivado por ejemplo de un nullifier de privacidad, reduciendo desde la capa de protocolo este tipo de conflictos de cola.
El propio Vitalik le da un posicionamiento aún más grandioso. Al presentar EIP-8250, declaró explícitamente que Keyed Nonces "no solo es un apoyo más fuerte a las soluciones de privacidad en la capa de protocolo, sino que también podría ser el primer paso hacia una nueva estrategia de escalabilidad de estado para Ethereum: al crear tipos de almacenamiento específicamente optimizados para diferentes casos de uso, se logra una escalabilidad extrema manteniendo la descentralización del protocolo".
En otras palabras, se podría entender de manera simplificada: Gas Limit resuelve el "tamaño del bloque", Keyed Nonces explora la "forma del estado" — lo que Ethereum necesita soportar en el futuro no son solo más transacciones, sino más tipos de transacciones.
三、¿Cómo afectará esto al usuario común?
Para el ecosistema de Ethereum, muchas actualizaciones de protocolo parecen estar lejos del usuario común, pero finalmente se traducen 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, operación entre cadenas e interacción con DApps dentro de la billetera. Es decir,los cambios en la capa de protocolo solo completan realmente la transformación de una actualización técnica a una actualización de la experiencia del usuario cuando se traducen en una experiencia operativa más clara, fluida y segura en la capa de la billetera.
Por ejemplo, la ya muy conocida abstracción de cuentas (account abstraction) no es 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, transacciones por lotes, pago de Gas por terceros, mecanismos de recuperación, diferentes métodos de firma, autorizaciones de sesión y estrategias de seguridad más flexibles se han convertido gradualmente en capacidades básicas dentro de las billeteras.
Tomemos Keyed Nonces como ejemplo nuevamente. Suena 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, pueden haberse encontrado con escenarios similares: una transacción tarda mucho en confirmarse, las transacciones posteriores se bloquean, quieren cancelar o acelerar una transacción pero no entienden la relación entre nonce, Gas y reemplazo de transacciones, especialmente cuando hay múltiples operaciones en paralelo, un paso fallido afecta todo el flujo posterior.
Para el usuario común, estos problemas parecen ser de "billetera que no funciona bien" o "cadena que 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 que representan los Keyed Nonces es permitir que una cuenta ya no ejecute todas sus operaciones siguiendo una sola cola secuencial, sino que pueda dividirse en múltiples canales paralelos según diferentes escenarios de uso.
En el futuro, operaciones como transferencias comunes, autorizaciones de DApps, transacciones de privacidad, transacciones por lotes, pago de Gas por terceros, teóricamente podrían 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 para 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 traer riesgo de fallo operativo y pérdida de activos.
Y lo que Ethereum está intentando hacer ahora es precisamente trasladar parte de esta complejidad hacia la capa de protocolo, permitiendo que las billeteras, basadas en capacidades subyacentes más estandarizadas y nativas, proporcionen una mejor abstracción de interacción para los usuarios.
Es por eso que Gas Limit, BAL, ePBS, Keyed Nonces, Frame Transactions, la abstracción de cuentas nativa y la interoperabilidad entre L2s, aunque parecen pertenecer a diferentes módulos técnicos, en realidad están sirviendo a lo mismo: permitir que Ethereum soporte escenarios de uso en cadena más complejos sin sacrificar la descentralización y la seguridad.
Analizándolo en concreto, al poner juntos estos desarrollos, se puede ver que el enfoque reciente de Ethereum no está disperso:
- El aumento del Gas Limit resuelve la capacidad de ejecución y la presión de costos de la red principal;
- BAL, ePBS, EIP-8037 resuelven cómo mantener la verificabilidad de los nodos y el crecimiento controlado del estado durante el proceso de escalabilidad;
- Keyed Nonces y Frame Transactions resuelven los cuellos de botella en la capa de protocolo para el modelo de cuentas, los protocolos de privacidad y las billeteras inteligentes;
- La abstracción de cuentas nativa y la interoperabilidad entre L2s apuntan aún más a las mejoras de experiencia que los usuarios comunes 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 de Blob y las narrativas de modularidad, y los usuarios se han ido acostumbrando a transferir activos entre diferentes L2s, buscando entornos de interacción de menor costo. Pero a medida que el Gas Limit 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 las transacciones más baratas", sino "cómo hacer que la experiencia en cadena se sienta más como un todo".
En este proceso, la importancia de las billeteras sin duda también 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 ser traducidas por las billeteras 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 para todos.
