De Glamsterdam a Hegotá: ¿Qué resolverá Ethereum en su próxima fase tras la expansión?

Después de un período de construcción, Ethereum finalmente ha comenzado a abordar esas experiencias en cadena que vuelven locos a los usuarios comunes.

Escrito por: imToken

Si conectamos las actualizaciones de Ethereum de los últimos años, la palabra clave sin duda es "expansión".

Desde la introducción de Blob en Dencun que reduce drásticamente los impuestos de Rollup, hasta la mejora de la eficiencia de los validadores y el mecanismo de staking en Pectra, y la implementación de PeerDAS en Fusaka para reducir la carga de distribución de datos, la capa de protocolo ha concentrado casi toda su energía en una sola cosa: permitir que Ethereum procese más datos sin elevar demasiado el umbral para los nodos.

Este conjunto de medidas ha sido efectivo; los costos de datos de Rollup han disminuido, el límite de Gas de la red principal está aumentando de manera constante, y Ethereum ya no presenta tarifas de transacción de decenas de dólares que desanimen a los usuarios como en la última corrida alcista.

Sin embargo, aunque la carretera se ha ampliado, la forma de conducir sigue siendo incómoda:

• Aún tenemos que mover activos entre tres o cuatro L2, y con un descuido podemos elegir la cadena equivocada;
• Una transferencia que claramente se empaquetó en segundos, los puentes y los intercambios requieren que esperes más de diez minutos para confirmar;
• Los constructores profesionales casi monopolizan el empaquetado de bloques, y si deseas realizar una transacción sensible, podrías ser rechazado por reglas no escritas fuera del protocolo;
• Sin mencionar que hasta hoy, un usuario recién llegado que solo quiera transferir unos cientos de USDC aún tiene que entender por qué su billetera debe tener ETH, qué es un Nonce y qué es Gas;

Estos problemas se manifiestan superficialmente como fricciones en la experiencia del usuario, pero en el fondo están relacionados con reglas de confirmación, construcción de bloques, resistencia a la censura y modelos de cuentas, entre otros mecanismos de protocolo más fundamentales.

Y este es precisamente el nuevo problema que Ethereum comenzará a abordar de manera concentrada desde Glamsterdam hasta Hegotá, desde el cuarto trimestre de 2026 hasta 2027.

I. La expansión continúa, pero comienza a "coser" L1 y L2

Por supuesto, la expansión no se detendrá.

Glamsterdam sigue teniendo un fuerte enfoque en el rendimiento, y dos de sus aspectos más destacados son ePBS (EIP-7732) y BAL (Listas de Acceso a Nivel de Bloque, EIP-7928), que se pueden entender de manera simple:

• ePBS consiste en formalizar la división de trabajo entre Proposer y Builder, que ya existe en gran medida fuera del protocolo, y dividir de manera más científica la ventana de tiempo para la creación de bloques y la verificación, dejando un margen para bloques más grandes en el futuro;
• BAL permite que el bloque enumere una "lista de acceso" al principio, de modo que los nodos puedan prefetch datos o incluso procesarlos en paralelo, tratando así el cuello de botella de almacenamiento I/O;

Sin embargo, más allá de la expansión, el verdadero dolor de la mayoría de las personas hoy no es si el TPS de Ethereum es lo suficientemente alto, sino que "hay demasiadas cadenas".

Por ejemplo, ETH está en la red principal, los memes se juegan en Robinhood Chain, el USDC utilizado para pagos puede estar en Arbitrum, y el USDC que deseas comprar puede estar en Base...

Para la Fundación Ethereum, los Rollups son parte del mapa de Ethereum, pero para los usuarios, esto no es diferente de cambiar divisas internacionales o solicitar visas.

Por lo tanto, para volver a coser los rompecabezas dispersos en una red, además de que los protocolos cruzados hagan su magia, una nueva mecánica de base que el protocolo ha estado promoviendo merece atención: FCR (Regla de Confirmación Rápida).

Muchos piensan que una transacción se considera completada una vez que se empaqueta en un bloque, pero en términos de criptografía y consenso, un bloque recién creado puede experimentar una pequeña reorganización, y la verdadera "finalidad" irreversible requiere que Ethereum complete dos Epochs, lo que lleva aproximadamente 13 minutos.

Esto no importa para transferencias cotidianas, pero para puentes intercadena, liquidaciones de grandes montos y exchanges centralizados, es una tortura; para evitar el riesgo de reorganización, solo pueden hacerte esperar.

La idea de FCR es que no es necesario esperar los diez minutos de finalidad completa, sino utilizar las atestaciones que los validadores generan continuamente para juzgar más temprano si un bloque ha obtenido suficiente apoyo de consenso basado en el peso de los votos acumulados.

Según los objetivos establecidos por la Fundación Ethereum, en condiciones de sincronización normal de la red, FCR podría anticipar esta "confirmación fuerte" a aproximadamente 15-30 segundos; aunque no es equivalente a la finalidad completa, para muchos puentes, comunicaciones intercadena e infraestructuras que hoy deben esperar la finalidad, ya es suficiente para proporcionar una señal de confirmación más temprana y con un modelo de seguridad claro.

Más notablemente, FCR no necesita esperar a un hard fork para activarse; se asemeja más a un conjunto de reglas de confirmación que pueden ser adoptadas gradualmente por los clientes de consenso y la infraestructura.

Una vez que varios L2, puentes intercadena y billeteras comiencen a utilizar esta señal, la gran cantidad de retrasos intercapas causados por "esperar la finalidad de L1" podría reducirse de minutos a segundos.

Esto también significa que en el futuro, cuando muevas un activo, el backend podría estar cruzando dos o más cadenas, pero en el frontend, solo necesitarás hacer clic en confirmar y pronto estará en tu cuenta.

II. Un tema más fundamental: ¿quién tiene el poder de decidir si una transacción puede ser incluida en la cadena?

Sin embargo, a medida que los bloques se vuelven más grandes y los Builders más profesionales, Ethereum enfrenta otro dilema típico.

Dado que los Builders profesionales han llevado la eficiencia de construcción de bloques a su máxima expresión gracias a su potencia de cálculo y flujo de órdenes, el control sobre la mayoría de los bloques naturalmente recae en unas pocas grandes instituciones.

Esto plantea un peligro extremo: la censura.

Si algunos Builders, debido a presiones regulatorias, competencia comercial o simplemente porque no les gusta ciertos protocolos de privacidad, deciden ignorar y rechazar tus transacciones legítimas en el pool de memoria, incluso si tienes la clave privada y pagas el Gas, tu transacción podría quedar atrapada fuera de la cadena (lectura extendida "Incluir la resistencia a la censura en el protocolo: ¿quién decide si una transacción de Ethereum puede ser incluida en la cadena?").

Si la descentralización no puede garantizar ni siquiera el acceso a las transacciones resistentes a la censura, no importa cuán alta sea la capacidad de procesamiento, será un castillo en el aire.

Esta es también la razón por la que en la planificación de Hegotá, FOCIL (Listas de Inclusión Impuestas por la Elección de Fork, EIP-7805) ocupa un lugar tan crucial.

Su lógica es extremadamente simple y directa: poner un grillete a los Builders.

En cada Slot, el protocolo seleccionará aleatoriamente un grupo de validadores independientes, quienes llenarán una "lista de inclusión" con las transacciones legítimas que ven en su pool de memoria. Los Builders aún pueden organizar el orden de las transacciones para ganar su MEV, pero el bloque que entreguen debe incluir las transacciones de la lista.

Si un Builder se atreve a ignorar maliciosamente esta lista, todos los validadores de la red lo excluirán directamente en las reglas de selección de forks. En otras palabras, puedes ganar dinero con tu habilidad, pero no puedes decidir quién tiene derecho a usar Ethereum.

Una vez que se establezca este mecanismo, también se abordará una de las debilidades que Ethereum ha estado tratando de resolver durante mucho tiempo, que es la tan esperada privacidad.

Como todos saben, cuando se habla de privacidad, se menciona constantemente la prueba de conocimiento cero, direcciones invisibles y pools de mezcla, pero si un Builder reconoce que "esta es una llamada a un contrato de privacidad" y decide rechazarla, tu magia matemática se desmorona instantáneamente.

Y actualmente, en la ruta de privacidad de Ethereum, FOCIL aborda precisamente el punto más vulnerable; después de todo, mientras la capa de protocolo pueda garantizar el derecho de acceso a cada transacción legítima, la exploración de la privacidad en la capa superior tendrá una oportunidad de sobrevivir.

Actualmente, propuestas de privacidad más agresivas como EIP-8182 (intento de introducir un pool protegido nativo a nivel de protocolo) aún están en discusión (Propuesto), pero la tendencia ya es clara: la privacidad no puede seguir siendo una función marginal de alguna DApp de terceros, debe convertirse gradualmente en un servicio básico de la infraestructura de Ethereum.

III. El último paso, AA nativo y billeteras que ya no son antinaturales

Los ajustes de arquitectura discutidos anteriormente ocurren principalmente bajo la superficie, mientras que la tercera cosa estará estrechamente relacionada con la experiencia real de uso de los usuarios comunes.

Es decir, Ethereum finalmente ha decidido realizar una cirugía mayor en el modelo de cuenta EOA que ha persistido durante más de diez años.

Honestamente, el modelo de firma con clave privada que Ethereum ha mantenido hasta ahora es extremadamente antinatural para los usuarios de Internet más comunes:

Si pierdes tu clave privada, es el fin; si tienes miles de monedas estables en tu billetera, pero te falta 0.001 ETH para la tarifa de Gas, tus activos no se pueden transferir temporalmente; para jugar en DeFi, primero debes aprobar y luego intercambiar, haciendo clic tres veces para completar una acción; el Nonce de las transacciones debe seguir un estricto orden, si una se atasca, todas se detienen.

En las dos primeras actualizaciones, la comunidad ha intentado varias soluciones intermedias. Por ejemplo, se creó ERC-4337, utilizando billeteras de contrato fuera del protocolo como una solución alternativa; o en Pectra se introdujo EIP-7702, permitiendo que direcciones comunes monten temporalmente una lógica de contrato para obtener algo de flexibilidad.

Pero el 7702, en última instancia, es un puente; el enfoque principal de Hegotá es la verdadera abstracción de cuentas nativa EIP-8141 (Transacciones de Marco).

Se puede entender de manera simple que, una transacción de Ethereum solía atar tres cosas juntas: quién prueba que eres tú (verificación) + quién paga esta cantidad (pago de Gas) + qué se va a hacer (ejecución), mientras que EIP-8141 separa estas tres cosas en diferentes "marcos" desde la capa de protocolo.

• Marco de verificación: ya no está bloqueado en una firma de curva elíptica ECDSA fija, puede admitir métodos de verificación más flexibles como Passkey, combinándose aún más con capacidades como huellas dactilares y Face ID, haciendo que el cambio de claves y la recuperación de cuentas sean más naturales;
• Marco de pago: la financiación de Gas se vuelve nativa. Las aplicaciones pueden pagar directamente el Gas por nuevos usuarios, o puedes especificar que se deduzca directamente de la transferencia de USDC, ya no necesitas intermediarios que compren y vendan fuera de la cadena;
• Marco de ejecución: admite de forma nativa el procesamiento por lotes atómicos, autorizando e intercambiando en un solo paso; si tiene éxito, se aplican todos juntos, si falla, se revierte todo de manera limpia;

Si además se suma la discusión en curso sobre EIP-8250 (Nonces Claveadas), las cuentas del futuro incluso podrían tener múltiples pistas de Nonce paralelas.

Una vez que estas capacidades se integren de manera nativa en el protocolo, para billeteras como imToken, la forma del producto experimentará una liberación cualitativa.

Hay que recordar que la mayor parte de la energía de las billeteras en el pasado se gastaba en recordar a los usuarios que prepararan Gas, explicar por qué una transacción se atascó, educar a los usuarios sobre cómo anotar frases de recuperación y ayudar a los usuarios a cambiar entre diferentes cadenas RPC.

En el futuro, cuando los algoritmos de firma, el pago de Gas, el control de permisos y el enrutamiento de transacciones puedan ser programables, las billeteras finalmente podrán regresar a su lugar adecuado, convirtiéndose en un sistema operativo silencioso entre los usuarios y el mundo descentralizado.

Seguirá estando completamente bajo el control del usuario, pero su uso será tan natural como pagar con un código QR en Alipay o desbloquear con huellas dactilares.

Escribiendo al final

Mirando hacia atrás en las huellas de las actualizaciones de Ethereum en los últimos años, el camino es extremadamente claro.

Dencun resolvió Blob; Pectra continúa expandiendo mientras mejora las capacidades de validadores y cuentas; Fusaka utiliza PeerDAS para seguir allanando el camino para un mayor rendimiento de datos; el próximo Glamsterdam, a través de cambios estructurales como ePBS y BAL, sentará las bases para un límite de Gas más alto y ejecución paralela.

La expansión aún no ha terminado, pero ya no es el único problema.

Ethereum finalmente ha liberado sus manos para enfrentar esos problemas más fundamentales y molestos, y por eso la EF, al reorganizar la dirección de desarrollo del protocolo en 2026, los resumió en tres objetivos muy simples:

Escalar, mejorar la experiencia del usuario y fortalecer L1.

Ethereum ya ha demostrado al mundo que puede convertirse en una computadora mundial que nunca se detiene; lo que sigue es permitir que las personas comunes realmente puedan usarla de manera fluida.