La evolución de Ethereum a nivel de "segundos": ¿Cómo está eliminando la espera la interoperabilidad, desde confirmaciones rápidas hasta compresión de liquidaciones?

Autor: imToken

Si sueles hacer transferencias entre Base, Arbitrum u Optimism, seguramente has experimentado una sensación sutil de «ruptura».

Aunque las transacciones en una sola capa L2 ya casi se confirman en segundos, cuando intentas mover activos de la cadena A a la cadena B, a menudo debes esperar varios minutos o incluso más tiempo. Esto no se debe a que L2 sea más lento, sino a que en los procesos tradicionales, una transacción que involucra múltiples capas y cadenas debe atravesar un camino largo y riguroso:

Ordenador de L2 → Envío a L1 → Consenso y confirmación final (Finality), en resumen, en la arquitectura actual de Ethereum, la confirmación final en L1 suele requerir dos Epochs (aproximadamente 13 minutos). Esto es sin duda necesario para la seguridad, pero para la interoperabilidad (Interop), resulta demasiado lento.

Al fin y al cabo, si seguimos la visión a gran escala de Ethereum, en el futuro existirán cientos o incluso miles de L2, que no deberían ser islas aisladas de ejecución, sino que deberían colaborar como un todo. La clave del problema radica en si podemos acortar al máximo este tiempo de espera.

Es en este contexto que la hoja de ruta de Interoperabilidad de Ethereum, en su fase de aceleración, propone claramente tres direcciones de mejora altamente coordinadas: Reglas de confirmación rápida (Fast L1 Confirmation Rule), reducción del tiempo de slots en L1 (Shorter L1 Slots), y compresión del ciclo de liquidación en capa dos (Shorter L2 Settlement).

Podemos decir que esto no son simples optimizaciones dispersas, sino una reestructuración sistémica en torno a «confirmación, ritmo y liquidación».

1. Reglas de confirmación rápida: dar una «respuesta confiable» antes de la Finality

Como es bien sabido, en la arquitectura actual de Ethereum, el intervalo de bloques en la red principal es de unos 12 segundos. Los nodos validadores votan en cada slot sobre el estado actual de la cadena, y la confirmación final (Finality) se logra después de varios slots.

En pocas palabras, incluso si una transacción ya está incluida en un bloque, el sistema debe esperar un tiempo prolongado para estar seguro de que no será reorganizada o revertida. Actualmente, se considera que una transacción es irreversible aproximadamente después de dos Epochs (unos 13 minutos). Para la mayoría de los escenarios financieros en cadena, 13 minutos son demasiado.

¿Podemos antes de la llegada de la Finality, ofrecer a las aplicaciones y sistemas cross-chain una señal de confirmación «suficientemente rápida y confiable»? Esto es precisamente lo que el Proyecto #4 de la hoja de ruta de Interoperabilidad de Ethereum, Fast L1 Confirmation Rule (Reglas de confirmación rápida), busca lograr.

Su objetivo principal es muy directo: permitir que las aplicaciones y sistemas cross-chain obtengan en 15–30 segundos una señal de confirmación en L1 «fuertemente verificable», sin tener que esperar los 13 minutos completos de la Finality.

Desde el punto de vista mecánico, las reglas de confirmación rápida no introducen un nuevo proceso de consenso, sino que reutilizan las votaciones de los attesters en cada slot del sistema PoS de Ethereum. Cuando un bloque acumula en etapas tempranas suficientes votos dispersos de validadores, incluso antes de alcanzar la fase de confirmación final, puede considerarse «en un modelo de ataque razonable, extremadamente improbable que sea revertido».

En otras palabras, este nivel de confirmación no reemplaza la Finality, sino que proporciona una confirmación fuerte reconocida explícitamente por el protocolo antes de la Finality. Para la interoperabilidad, esto es especialmente crucial: los sistemas cross-chain, los Intent Solvers y las wallets ya no necesitan esperar pasivamente la confirmación final, sino que pueden avanzar con mayor seguridad en 15–30 segundos, basándose en una señal de confirmación a nivel de protocolo.

Actualmente, la preconfirmación (Preconfirmation), promovida por la narrativa de Based Rollup, cumple en esta etapa un papel de transición técnica importante. Su lógica es simple: imagina lo siguiente:

Cuando compramos un billete de tren en 12306, una vez que seleccionamos el itinerario y firmamos la transacción, el sistema de reserva nos da una preconfirmación, que indica que la compra ha sido aceptada y está en proceso de confirmación posterior. En ese momento, podemos planear el viaje, preparar el equipaje, etc. Solo cuando el billete confirma la cabina y el asiento (la transacción se publica en L1), se considera que la compra y reserva están completas.

En resumen, en Based Rollup, la preconfirmación significa que, antes de que la transacción se envíe formalmente a L1 para su confirmación, ya se promete incluirla en un bloque, dando al usuario una señal inicial de que la transacción ha sido aceptada y está en proceso.

«Te doy una promesa verbal fuerte ahora, y la confirmación definitiva llegará después», mediante esta lógica de confirmación en capas, la hoja de ruta de Ethereum para la interoperabilidad está diseñando una diferenciación fina entre «confianza» y «velocidad», construyendo una experiencia de interoperabilidad lo más fluida posible.

2. Reducir el tamaño del slot en L1: acelerar el «ritmo cardíaco» de Ethereum

Complementando las reglas de confirmación rápida, hay una modificación más fundamental y física: reducir el tamaño del slot.

Si la confirmación rápida es como un «pagar por adelantado» antes de la confirmación final, reducir el tiempo de slot en L1 equivale a acortar directamente el ciclo de liquidación del libro mayor. En la hoja de ruta de Interoperabilidad, el objetivo del Proyecto #5 es claro: reducir el tiempo de slot en la red principal de Ethereum de 12 segundos a 6 segundos.

Este «simple» recorte en la mitad en realidad desencadena una reacción en cadena en toda la cadena. Es fácil entenderlo: cuanto más corto sea el slot, más rápido será el proceso de incluir transacciones en bloques, distribuirlas para validación y confirmarlas, lo que reduce la latencia general del protocolo.

El impacto en la experiencia del usuario también es directo: confirmaciones más rápidas en interacciones en L1 (como transferencias de ETH), ciclos más ajustados para enviar estados desde L2 a L1, y cuando se combina con las reglas de confirmación rápida, se puede lograr una «retroalimentación en casi tiempo real en la cadena», permitiendo que las DApps, wallets y protocolos cross-chain construyan experiencias de confirmación en segundos.

Para los protocolos de interoperabilidad, acortar el ciclo también significa un aumento en la eficiencia del uso de fondos: actualmente, los puentes cross-chain o los market makers enfrentan riesgos de «capital en tránsito» que duran minutos o más, y para cubrir esa volatilidad, cobran tarifas más altas.

Cuando el ciclo de liquidación en L1 se acorta y la rotación de fondos se acelera, el capital en tránsito se reduce significativamente. El resultado es claro: menores costos de fricción, tarifas más bajas para los usuarios y menor retraso en las transferencias, lo que incentivará a desarrolladores y usuarios a volver a confiar en la capa de liquidación segura de L1, en lugar de depender de relés de terceros vulnerables.

Por supuesto, aumentar la frecuencia del «ritmo cardíaco» al doble no es tarea sencilla. Varios grupos de trabajo de la Fundación Ethereum están avanzando en esta compleja ingeniería:

• Análisis de red: equipos de investigación (incluyendo a Maria Silva y otros) realizan análisis de datos rigurosos para asegurar que slots más cortos no generen riesgos graves de reorganización (reorg) por latencia de red, ni presiones de centralización en nodos domésticos con menor ancho de banda;
• Implementación en clientes: un cambio profundo que involucra tanto la capa de consenso como la de ejecución. Es importante destacar que este trabajo es independiente de EIP-7732 (separación de validadores nativos y constructores en ePBS), lo que significa que, independientemente del progreso de ePBS, el plan de aceleración del ritmo cardíaco puede avanzar por separado;

En conjunto, cuando los slots de 6 segundos se combinan con las reglas de confirmación rápida, Ethereum podría lograr una «retroalimentación en la cadena casi en tiempo real», permitiendo a las DApps y wallets construir experiencias de confirmación en segundos sin precedentes.

3. Reducir el ciclo de liquidación en L2: hacer que los activos «se puedan retirar y usar al instante»

En la hoja de ruta de Interoperabilidad, el Proyecto #6: Shorter L2 Settlement, es quizás la más controvertida, pero también la que más espacio de imaginación ofrece.

En la arquitectura actual, los Optimistic Rollups dependen de un período de desafío de hasta 7 días, y aunque los ZK Rollups están limitados por la velocidad de generación y verificación de pruebas, en realidad, este diseño es impecable en seguridad, pero presenta un problema en interoperabilidad:

Los activos y estados quedan «bloqueados en el tiempo» entre cadenas. Esto eleva los costos de cross-chain y aumenta la carga de reequilibrio para los Solver, reflejándose en tarifas más altas para los usuarios. Por eso, acortar el ciclo de liquidación se considera una palanca clave para escalar la interoperabilidad. Las principales líneas de trabajo incluyen:

• Pruebas ZK en tiempo real: con hardware acelerado y pruebas recursivas, el tiempo de generación de pruebas se reduce de minutos a segundos;
• Mecanismos de liquidación más rápidos: por ejemplo, modelos de liquidación seguros 2-out-of-3;
• Capas de liquidación compartidas: permitir que múltiples L2 cambien de estado en una capa de liquidación unificada, en lugar de «retirar fondos — esperar — volver a depositar»;

Por supuesto, en las discusiones sobre interoperabilidad, surge una duda central: si para acelerar la confirmación cross-chain, se reduce el período de desafío de 7 días a 1 hora, ¿esto dejará espacio para que los atacantes hagan mal uso?

En teoría, la preocupación no es infundada. A diferencia de la «censura fuerte» (donde los validadores actúan colectivamente para censurar), en la práctica, lo que más preocupa es la «censura blanda» liderada por los constructores de bloques: los atacantes no necesitan controlar el consenso, sino que pueden presionar continuamente a los defensores en las pujas, impidiendo que transacciones clave lleguen a la cadena.

Curiosamente, el único análisis económico sistemático sobre este escenario proviene de Offchain Labs en un artículo de febrero de 2025, titulado «Economic Censorship Games in Fraud Proofs» (Juegos económicos de censura en pruebas de fraude). Este estudio propone tres modelos, desde el más pesimista hasta el más optimista:

• G¹: el contenido del bloque lo decide el que más puja;
• G¹ₖ: algunos validadores construyen bloques localmente en todo momento;
• Gᵐ: múltiples validadores deciden conjuntamente, y basta que uno elija la transacción de defensa.

En la práctica, dado que los validadores pueden optar por slots vacíos (miss slots), algunos diseños degeneran en el escenario más pesimista G¹. Por eso, el análisis parte del peor caso.

Con base en esto, los investigadores proponen una estrategia de defensa realista: la «estrategia de retraso con poco dinero», que consiste en que el defensor tenga el derecho de «retrasar con un clic». Es decir, no necesita completar en minutos todo el proceso de detección, sino que basta con que envíe una transacción clave.

Esta transacción clave tiene un efecto muy claro: una vez en la cadena, extiende automáticamente el período de desafío de 1 hora a los 7 días tradicionales. Por ejemplo, si el defensor detecta una anomalía en el estado de L2, no necesita completar toda la verificación en 1 hora, sino que solo debe enviar una transacción especial a L1. Esa transacción actúa como una alarma, extendiendo instantáneamente el período de desafío a 7 días.

Esto obliga a los atacantes a entrar en una guerra de desgaste asimétrica: para impedir que esa transacción se incluya, deben pagar tarifas prioritarias más altas en cada bloque, y mantener esa presión durante todo el período de desafío.

El estudio cuantifica que, si un atacante con recursos de 10 mil millones de dólares quiere realizar un ataque de censura sostenido, en un período de 1 hora, solo necesita unos 33 millones de dólares en gas para contrarrestar; pero si logra activar la extensión del período a 7 días, el costo de defensa cae a unos 200 mil dólares.

En otras palabras, esto representa una ventaja estructural clave: el costo del atacante crece linealmente, mientras que el costo del defensor solo requiere una acción exitosa para bloquear.

Esta disparidad en costos (Cost to Attack vs. Cost to Defend) garantiza que, incluso si se acorta mucho el ciclo de liquidación, Ethereum mantiene una seguridad económica robusta.

Para la interoperabilidad, esto también es fundamental: la confirmación rápida y ciclos de liquidación más cortos no tienen que sacrificar la seguridad. Con un diseño institucional adecuado, confirmaciones en segundos y seguridad económica pueden coexistir, brindando la base más sólida para una interoperabilidad en tiempo real.

Para concluir

Quizá algunos se pregunten: ¿por qué dedicar esfuerzos a optimizar unos pocos segundos o minutos de retraso?

En la era de los entusiastas de Web3, estamos acostumbrados a esperar, e incluso consideramos que «esperar» es un costo que la descentralización debe pagar. Pero en el camino hacia la adopción masiva, los usuarios no deberían, ni necesitan, preocuparse por en qué cadena operan, ni por la lógica de la finalización en L1.

Las confirmaciones rápidas, los ritmos de 6 segundos y los mecanismos de defensa asimétricos en esencia buscan hacer una cosa: eliminar la variable «tiempo» de la percepción del usuario.

Como he mencionado muchas veces, la mejor forma de tecnología es aquella que hace que la complejidad desaparezca en una confirmación ultrarrápida.