La próxima fase de Ethereum: Conectando L1 y L2, mejorando la privacidad y optimizando la experiencia de usuario

Si se conectan las actualizaciones de Ethereum de los últimos años en una línea, la palabra clave es sin duda «escalabilidad».

Desde la introducción de blobs con Dencun para reducir significativamente los costos de Rollup, hasta la ajuste de la eficiencia de los validadores y el mecanismo de staking en Pectra, y la implementación de Fusaka con PeerDAS para reducir la carga de distribución de datos, la capa de protocolo ha dedicado casi toda su energía a una sola cosa: permitir que Ethereum procese más datos sin elevar excesivamente el umbral para los nodos.

Este enfoque combinado realmente funciona: los costos de datos de Rollup se han reducido y el límite de Gas de la red principal está aumentando constantemente; Ethereum ya no impone tarifas de decenas de dólares como en el último ciclo alcista, que disuadían a los usuarios.

Pero aunque la carretera se amplió, conducir sigue siendo incómodo:

• Aún así, tenemos que mover activos entre dos o tres L2; si no prestamos atención, podemos retirarlos en la cadena equivocada;
• Una transferencia se empaqueta en unos segundos, pero el puente y el intercambio te hacen esperar minutos antes de confirmarla;
• Los profesionales Builder casi monopolizan la empaquetación de bloques; si deseas enviar una transacción sensible, podrías ser rechazado en cualquier momento por normas no oficiales fuera del protocolo;
• Ni que decir del hecho de que, hasta hoy, un usuario nuevo que solo quiera transferir unas pocas centenas de dólares en USDC aún debe entender por qué necesita ETH en su billetera, qué es Nonce y qué es Gas;

Estas preguntas se manifiestan superficialmente como fricciones en la experiencia de usuario, pero detrás están involucrados mecanismos de protocolo más fundamentales como reglas de confirmación, construcción de bloques, resistencia a la censura y modelos de cuenta.

Y también es precisamente este el nuevo problema que Ethereum comienza a abordar centralmente, desde Glamsterdam hasta Hegotá, desde el Q4 de 2026 hasta 2027.

Of course, scaling won't hit the brakes.

Glamsterdam aún tiene un fuerte enfoque en rendimiento, siendo las dos características más destacadas: una llamada ePBS (EIP-7732) y otra llamada BAL (Block-level Access Lists, EIP-7928). En términos simples:

• ePBS consiste en formalizar dentro del protocolo la división entre Proposers y Builders que ya existe en gran medida fuera del protocolo hoy en día, además de dividir de manera más científica las ventanas de tiempo para la creación y validación de bloques, dejando suficiente margen para bloques más grandes en el futuro;
• BAL equivale a listar al inicio del bloque una «lista de acceso», permitiendo que los nodos puedan anticipar y pre-cargar datos, e incluso procesarlos en paralelo, resolviendo específicamente cuellos de botella de E/S de almacenamiento;

Más allá de la escalabilidad, el dolor real de la mayoría de las personas hoy en día no es si la TPS de Ethereum es lo suficientemente alta, sino que «hay demasiadas cadenas».

Por ejemplo, ETH está en la red principal, los memes se juegan en Robinhood Chain, los pagos y liquidaciones se hacen con USDC que podría estar en Arbitrum, y los USDC que quieres comprar están en Base...

Para la Fundación Ethereum, los Rollups son parte del ecosistema de Ethereum, pero para los usuarios, es lo mismo que cambiar divisas internacionalmente o tramitar una visa.

Por lo tanto, para volver a unir los fragmentos del rompecabezas en una red, además de que los protocolos cruzados demuestren sus capacidades, un mecanismo subyacente recientemente impulsado por los protocolos merece mucha atención: el FCR (Fast Confirmation Rule, regla de confirmación rápida).

Mucha gente cree que una transacción se considera completa al ser incluida en un bloque, pero desde el punto de vista criptográfico y de consenso, un bloque recién generado podría sufrir una pequeña reorganización; la «finalidad» verdaderamente irreversible requiere que Ethereum complete dos Epoch, lo que lleva aproximadamente 13 minutos.

Esto puede ser insignificante en transferencias normales, pero es un verdadero tormento para puentes cruzados, liquidaciones de gran volumen y intercambios centralizados; para evitar el riesgo de reorganización, solo pueden hacerte esperar.

La inteligencia de FCR radica en no tener que esperar pasivamente los quince minutos completos de Finality, sino en aprovechar las Attestation que los validadores generan continuamente, y determinar antes si un bloque ya cuenta con suficiente apoyo de consenso según el peso de votos acumulado.

Según los objetivos establecidos por la Ethereum Foundation, con la red funcionando normalmente, el FCR tiene como objetivo anticipar esta «confirmación fuerte» a aproximadamente 15 a 30 segundos. Aunque no es equivalente a la finalidad completa, ya es suficiente para proporcionar una señal de confirmación más temprana y con un modelo de seguridad claro a muchos puentes, comunicaciones entre cadenas e infraestructuras que actualmente deben esperar la finalidad.

Más específicamente, FCR no requiere esperar un hard fork específico para activarse; es más bien un conjunto de reglas de confirmación que pueden adoptarse gradualmente por los clientes de consenso y la infraestructura.

Una vez que diversos L2, puentes cruzados y billeteras comiencen a utilizar esta señal, los retrasos intercapas actuales causados por la «espera de la finalidad de L1», que duran muchos minutos, podrán reducirse de varios minutos a unos pocos segundos.

Esto también significa que, en el futuro, al mover un activo, el sistema puede realizar transacciones en secreto a través de dos o más cadenas, pero en la interfaz de usuario, solo necesitas hacer clic en confirmar y recibirás los fondos rápidamente.

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

Dado que los constructores profesionales han llevado la eficiencia de construcción de bloques al límite gracias a su potencia de cálculo y flujo de órdenes de primera clase, el control absoluto sobre la mayoría de los bloques naturalmente ha caído en manos de unas pocas grandes instituciones.

Esto genera un riesgo extremadamente peligroso: la censura.

Si algunos Builders, por presiones regulatorias, competencia comercial o simplemente por desacuerdo con ciertos acuerdos de privacidad, deliberadamente hacen como que no ven tus transacciones legítimas en la memoria y se niegan a incluirlas en los bloques, incluso si posees tu clave privada y has proporcionado suficiente Gas, tu transacción podría quedar atrapada fuera de la cadena (lectura adicional: Escribir la censura resistente en el protocolo: ¿quién decide si una transacción de Ethereum se incluye en la cadena?).

Si la descentralización no puede proteger ni siquiera el acceso básico a transacciones censurables, cualquier nivel de rendimiento es un castillo en el aire.

Por eso, en la planificación de Hegotá, FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) ocupa un lugar tan crucial.

Su lógica es extremadamente simple y directa: ponerle un hechizo de restricción a Builder.

Para cada Slot, el protocolo selecciona aleatoriamente un grupo de verificadores independientes comunes para que incluyan las transacciones válidas pendientes que ven en su memoria en una «lista de inclusión (Inclusion List)». Tú, como Builder, aún puedes ordenar libremente las transacciones para obtener tu MEV, pero el bloque que entregues debe incluir sin falta las transacciones de la lista.

Si el Builder se atreve a ignorar maliciosamente esta lista, todos los validadores de la red descartarán directamente este bloque en las reglas de selección de bifurcación. En otras palabras, puedes ganar dinero con tu habilidad, pero no puedes decidir por toda la red quién tiene derecho a usar Ethereum.

Con la implementación de este mecanismo, finalmente se encontró un punto de apoyo para otra debilidad de Ethereum que se había reclamado durante mucho tiempo pero nunca se había podido impulsar: la privacidad que todos esperaban con ansia.

Como es bien sabido, antes, cuando se hablaba de privacidad, todo el mundo mencionaba pruebas de conocimiento cero, direcciones ocultas y pools de mezcla; pero tan pronto como un Builder identifica «esta es una llamada a un contrato de privacidad», te rechaza la transacción y tus magias matemáticas se desmoronan al instante.

Y actualmente, en la ruta de privacidad de Ethereum, lo que FOCIL cierra es precisamente el punto más vulnerable al cuello de botella, ya que siempre que el nivel de protocolo garantice incondicionalmente el derecho de acceso a cada transacción legítima, las exploraciones de privacidad en capas superiores tendrán posibilidad de sobrevivir.

Actualmente, propuestas más ambiciosas como EIP-8182 (que intenta introducir un Pool Nativo a nivel de protocolo) aún se encuentran en fase de propuesta, pero la tendencia ya es clara: la privacidad ya no puede considerarse una función secundaria de un dapp de terceros, sino que debe convertirse gradualmente en un servicio básico de la infraestructura de Ethereum.

Los cambios de estructura mencionados anteriormente ocurrieron principalmente por debajo de la superficie, mientras que el tercer punto estará directamente relacionado con la experiencia de uso de los usuarios comunes.

Eso significa que Ethereum finalmente ha decidido llevar a cabo una gran reforma al modelo de cuentas EOA que ha persistido durante más de una década.

Honestamente, el modelo de firma de clave privada que Ethereum ha mantenido hasta hoy es absolutamente antinatural para usuarios de internet un poco comunes:

Si pierdes tu clave privada, estás condenado; aunque tengas miles de dólares estables en tu billetera, si te faltan 0.001 ETH para la tarifa de transacción, tus activos quedan temporalmente bloqueados; jugar con DeFi requiere primero aprobar y luego intercambiar, y necesitas firmar tres veces para completar una sola operación; los Nonces de transacción deben seguir un orden estricto: si una se atasca, todas se bloquean.

En las dos primeras actualizaciones, la comunidad realizó varios compromisos. Por ejemplo, desarrolló ERC-4337, utilizando billeteras inteligentes fuera del protocolo para salvar la situación de forma indirecta; también, en Pectra, introdujo EIP-7702, que permite a las direcciones normales adjuntar temporalmente una lógica de contrato para obtener cierta flexibilidad.

Pero 7702 es, en esencia, un puente temporal; el verdadero plato fuerte bloqueado por Hegotá es la abstracción de cuentas nativas EIP-8141 (Frame Transactions).

Se puede entender simplemente como que, anteriormente, una transacción de Ethereum ataba fuertemente tres cosas juntas, por ejemplo: quién verifica que eres tú (verificación) + quién paga esta transacción (pago de Gas) + qué se pretende hacer exactamente (ejecución), mientras que EIP-8141 descompone estas tres acciones en distintas «tramas» desde la base del protocolo (lectura adicional: Account Abstraction nativa + amenaza cuántica: ¿por qué EIP-8141 aún no es el principal de Ethereum Hegotá?):

• Verificación de marco: ya no está limitada a firmas de curva elíptica ECDSA fijas, puede admitir métodos de verificación más flexibles como Passkey, y combinar aún más funciones como huella dactilar del teléfono y Face ID para hacer el cambio de claves y la recuperación de cuentas más natural;
• Frame de pago: Gas patrocinado de forma nativa. Los aplicativos pueden pagar directamente el gas para nuevos usuarios, o puedes especificar en el frame de pago que se deduzca directamente el USDC de la transferencia; ya no necesitas intermediarios que compren y vendan gas fuera de la cadena;
• Frame de ejecución: soporte nativo para lotes atómicos, autorización y canje en un solo paso; si tiene éxito, todos los cambios se aplican juntos; si falla, se revierten completamente y de manera limpia;

Si se añade además el EIP-8250 (Keyed Nonces) que actualmente se está discutiendo en cola, las cuentas futuras podrían tener múltiples vías paralelas de Nonce.

Una vez que estas capacidades se integren nativamente en el protocolo, los productos de billeteras como imToken experimentarán una liberación cualitativa.

Anteriormente, la mayor parte del esfuerzo del billetera se dedicaba a recordar a los usuarios que prepararan Gas, explicar por qué esta transacción estaba atascada, educar a los usuarios sobre cómo copiar la frase de recuperación y ayudar a los usuarios a cambiar entre RPC en diferentes cadenas.

En el futuro, cuando los algoritmos de firma, el pago de Gas, el control de permisos y la enrutación de transacciones puedan ser programados, las billeteras finalmente podrán regresar a su lugar adecuado como una capa de sistema operativo silenciosa entre los usuarios y el mundo descentralizado.

Sigue estando completamente bajo el control del usuario, pero su uso será tan natural como escanear un código de pago de Alipay o desbloquear con huella digital.

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

Dencun resuelve los Blob; Pectra continúa escalando mientras mejora las capacidades de los validadores y las cuentas; Fusaka prepara el camino para mayor capacidad de datos mediante PeerDAS; el próximo Glamsterdam sentará las bases para límites de Gas más altos y ejecución paralela mediante cambios estructurales como ePBS y BAL.

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

Ethereum finalmente tiene tiempo para enfrentar los problemas más fundamentales y más complicados, por eso, cuando la EF reorganizó las direcciones de desarrollo del protocolo en 2026, las resumió en tres objetivos muy simples:

Escalar, mejorar la experiencia de usuario y fortalecer la L1.

Ethereum ya ha demostrado al mundo que puede ser una computadora mundial ininterrumpida; ahora, es hacer que las personas comunes puedan usarla con total fluidez.