La evolución "en segundos" de Ethereum: de confirmaciones rápidas a compresión de liquidaciones, ¿cómo Interop elimina los tiempos de espera?

Si sueles moverte entre Base, Arbitrum u Optimism, seguro que has experimentado una sutil sensación de "desconexión".

Aunque las transacciones en una sola L2 ya ofrecen resultados casi instantáneos, cuando intentas transferir activos de la cadena A a la cadena B, a menudo tienes que esperar varios minutos o incluso más. Esto no se debe a que la L2 no sea lo suficientemente rápida, sino a que, en el proceso tradicional, una transacción que implica múltiples capas y cadenas debe seguir un camino largo y riguroso:

Ordenación por el secuenciador de L2 → Envío a L1 → Consenso y finalización (Finality) en L1, en resumen, bajo la arquitectura actual de Ethereum, la finalización en L1 suele requerir dos Epochs (unos 13 minutos). Esto es necesario para la seguridad, pero para la interoperabilidad (Interop), resulta excesivamente lento.

Después de todo, según la gran visión de Ethereum, en el futuro existirán cientos o miles de L2, que no deberían ser islas de ejecución aisladas, sino trabajar en conjunto como un todo. Por lo tanto, la clave está en acortar al máximo este tiempo de espera. 

Precisamente en este contexto, la hoja de ruta de Interop de Ethereum, en la fase de aceleración (Acceleration), propone claramente tres direcciones de mejora altamente coordinadas: Regla de confirmación rápida (Fast L1 Confirmation Rule), reducción del tiempo de slot en L1 (Shorter L1 Slots), y compresión del ciclo de liquidación de la red de segunda capa (Shorter L2 Settlement). 

Se puede decir que esto no es una optimización dispersa, sino una reconstrucción sistémica en torno a "confirmación, ritmo y liquidación".

I. Regla de confirmación rápida: dar al sistema una "respuesta confiable" antes de la Finality

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

En resumen, incluso si la transacción ya ha sido incluida en un bloque, el sistema debe esperar un tiempo considerable para asegurarse de que no será reorganizada o revertida. Actualmente, se requieren aproximadamente dos Epochs (unos 13 minutos) antes de que una transacción se considere irreversible, lo cual es demasiado largo para la mayoría de los escenarios financieros on-chain. 

¿Podemos dar a las aplicaciones y sistemas cross-chain una señal de confirmación "lo suficientemente rápida y confiable" antes de que llegue la Finality? Esto es precisamente lo que pretende el Project #4 de la hoja de ruta Interop de Ethereum: Fast L1 Confirmation Rule (Regla de confirmación rápida).

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

En cuanto al mecanismo, la regla de confirmación rápida no introduce un nuevo proceso de consenso, sino que reutiliza las votaciones de los attesters que ocurren en cada slot del sistema PoS de Ethereum. Cuando un bloque acumula suficientes votos de validadores suficientemente distribuidos en los primeros slots, aunque aún no haya alcanzado la finalización, puede considerarse "razonablemente improbable de ser revertido bajo un modelo de ataque razonable".

En otras palabras, este nivel de confirmación no reemplaza la Finality, sino que proporciona una fuerte confirmación reconocida por el protocolo antes de la Finality. Para Interop, esto es especialmente clave: los sistemas cross-chain, los Intent Solvers y las wallets ya no necesitan esperar a ciegas la finalización, sino que pueden avanzar de forma segura al siguiente paso en 15–30 segundos, basándose en la señal de confirmación a nivel de protocolo.

Actualmente, la preconfirmación (Preconfirmation) promovida por la narrativa Based Rollup cumple un papel importante como transición técnica en esta dirección. Su lógica es simple, tal como sugiere el término. Imagina lo siguiente: 

Cuando compramos un billete de tren en 12306, una vez seleccionado el viaje y realizado el pedido (transacción firmada), el sistema de reservas primero nos da una preconfirmación, informándonos de que la compra (cada transacción) ha sido aceptada y está en proceso de confirmación. En ese momento, ya podemos planificar el viaje y preparar el equipaje. Solo cuando el billete se confirma finalmente (la transacción se publica en L1), la compra se considera completada.

En resumen, en Based Rollup, la preconfirmación es el compromiso de incluir la transacción en un bloque antes de que se envíe formalmente a L1 para su confirmación, proporcionando al usuario una señal preliminar de que la transacción ha sido aceptada y está en proceso.

"Primero te doy un compromiso verbal fuerte, la confirmación definitiva vendrá después". A través de esta lógica de confirmación por capas, la hoja de ruta Interop de Ethereum segmenta cuidadosamente diferentes niveles de confianza entre "seguridad" y "velocidad", construyendo una experiencia de interoperabilidad lo más fluida posible. 

II. Reducción del Slot de L1: acelerar el "latido" de Ethereum

Junto a la regla de confirmación rápida, que es una "reconstrucción lógica a nivel de consenso", hay un cambio más fundamental y físico: reducir el tamaño del Slot.

Si la confirmación rápida es como emitir un "vale" antes de que se alcance el consenso final, reducir el tiempo de Slot en L1 es acortar directamente el "ciclo de liquidación" del libro mayor. En la hoja de ruta Interop, el objetivo de la Project #5 es claro: reducir el tiempo de Slot de la red principal de Ethereum de los actuales 12 segundos a 6 segundos.

Esta aparente "reducción a la mitad" desencadenará una reacción en cadena en toda la red, lo cual es fácil de entender: cuanto más corto es el slot, más rápido se incluyen las transacciones en los bloques, se distribuyen para su validación y se confirman, lo que reduce la latencia general del protocolo.

El impacto en la experiencia del usuario también es directo: las interacciones en L1 (como transferencias de ETH) se confirman más rápido, el envío de estados de L2 a L1 es más frecuente, e incluso la combinación de slots más cortos y la regla de confirmación rápida permite una "retroalimentación on-chain casi en tiempo real", lo que significa que las DApps, wallets y protocolos cross-chain pueden ofrecer una experiencia de confirmación en segundos.

Para los protocolos de interoperabilidad cross-chain, la reducción del tiempo también implica un salto en la eficiencia del capital. Actualmente, los puentes cross-chain o los market makers, al gestionar activos entre diferentes cadenas, deben asumir el riesgo de "capital en tránsito" durante varios minutos o más. Para cubrir el riesgo de volatilidad durante ese tiempo, deben cobrar comisiones más altas.

Cuando el ciclo de liquidación de L1 se acorta y la rotación de capital se duplica, la ocupación de capital en tránsito se reduce significativamente. El resultado es evidente: menores costes de fricción, menores comisiones para el usuario y menor retraso en la recepción de fondos, lo que incentivará enormemente a desarrolladores y usuarios a volver a la capa de liquidación segura de L1, en lugar de depender de relays de terceros poco fiables.

Por supuesto, duplicar la "frecuencia del latido" no es tarea fácil. Varios equipos de trabajo de la Ethereum Foundation están avanzando en este complejo proyecto:

• Análisis de red: Equipos de investigación (incluida Maria Silva y otros investigadores) están realizando análisis de datos rigurosos para garantizar que slots más cortos no aumenten el riesgo de reorganización (Reorg) por latencia de red ni ejerzan presión de centralización sobre nodos domésticos con menor ancho de banda;
• Implementación en clientes: Esto implica una reconstrucción profunda tanto de la capa de consenso como de la de ejecución. Cabe destacar que este trabajo es independiente de EIP-7732 (separación nativa de stakers y builders, ePBS), lo que significa que, independientemente del progreso de ePBS, el plan de aceleración del latido puede avanzar por sí solo;

En general, cuando los slots de 6 segundos se combinan con la regla de confirmación rápida, Ethereum podrá ofrecer una "retroalimentación on-chain casi en tiempo real", permitiendo a las dApps y wallets construir una experiencia de confirmación en segundos sin precedentes.

III. Reducción del ciclo de liquidación de L2: activos "listos para retirar y usar"

En la hoja de ruta Interop, el Project #6: Shorter L2 Settlement es el más controvertido, pero también el que más potencial tiene.

Bajo la arquitectura actual, los Optimistic Rollups suelen depender de un periodo de desafío de hasta 7 días, y aunque los ZK Rollups son más rápidos, siguen limitados por el tiempo de generación y verificación de pruebas. En términos de seguridad, este diseño es impecable, pero en el plano de la interoperabilidad, plantea un problema real:

Los activos y estados quedan "bloqueados por tiempo" entre cadenas. Esto no solo aumenta el coste del cross-chain, sino que incrementa significativamente la carga de reequilibrio de los Solvers, lo que se traduce en mayores costes para el usuario. Por ello, acortar el ciclo de liquidación se considera una de las palancas clave para la escalabilidad de Interop. Las principales direcciones técnicas actuales incluyen (lectura adicional: ZK Dawn: ¿La hoja de ruta final de Ethereum está acelerando por completo?):

• Pruebas ZK en tiempo real: Con la aceleración de hardware y la madurez de las pruebas recursivas, el tiempo de generación de pruebas está pasando de minutos a segundos;
• Mecanismos de liquidación más rápidos: Por ejemplo, introducción de modelos de liquidación seguros 2-out-of-3;
• Capa de liquidación compartida: Permitir que múltiples L2 realicen cambios de estado bajo una semántica de liquidación unificada, en lugar de "retirar-esperar-depositar";

Por supuesto, en el debate sobre Interop, una pregunta central e inevitable es: si para lograr confirmaciones cross-chain más rápidas, el periodo de desafío de liquidación se reduce de los tradicionales 7 días a 1 hora, ¿se abre la puerta a ataques?

En teoría, esta preocupación no es infundada. A diferencia de la "censura fuerte" (colusión de validadores), en la práctica lo más preocupante es el ataque de censura blanda liderado por los constructores de bloques: el atacante no necesita controlar el consenso, solo debe mantener su oferta por encima de la del defensor para impedir que las transacciones clave se incluyan en la cadena. 

Curiosamente, el único análisis económico sistemático sobre este tipo de escenarios proviene del artículo de Offchain Labs publicado en febrero de 2025, "Economic Censorship Games in Fraud Proofs", que construye tres modelos, del más pesimista al más optimista, suponiendo: 

• Modelo G¹: El contenido del bloque lo decide completamente quien haga la oferta más alta;
• Modelo G¹ₖ: Algunos validadores siempre construyen bloques localmente;
• Modelo Gᵐ: Varios validadores deciden conjuntamente el contenido del bloque; basta con que uno elija la transacción del defensor.

En la práctica, dado que los validadores pueden elegir slots vacíos (miss slots), algunos diseños pueden degenerar en el caso más pesimista G¹, por lo que el artículo parte del peor escenario. 

Sobre esta base, los investigadores proponen un mecanismo de defensa retardada "apostar poco para ganar mucho", cuyo núcleo es que el defensor tiene derecho a "activar un retraso" con un solo clic, es decir, no necesita completar todo el proceso de verificación en poco tiempo, solo debe enviar una transacción clave con éxito.

El propósito de esta transacción clave es muy claro: una vez incluida en la cadena, el periodo de desafío se extiende automáticamente de 1 hora a los tradicionales 7 días. Por ejemplo, si el defensor detecta un estado anómalo en L2, no necesita completar todo el proceso de verificación en 1 hora, solo debe enviar una transacción especial a L1, que actúa como una alarma antiaérea, extendiendo instantáneamente el periodo de desafío a los 7 días tradicionales.

Esto significa que el atacante se ve obligado a entrar en una guerra de desgaste extremadamente asimétrica: para impedir que la transacción se incluya en la cadena, debe pagar continuamente una tarifa de prioridad superior a la del defensor en cada bloque, y este enfrentamiento debe mantenerse durante todo el periodo de desafío.

Los resultados cuantitativos del artículo son muy claros. Según los cálculos, si un atacante poderoso está dispuesto a gastar 10 billions de dólares en un ataque de censura sostenido, entonces:

• En una ventana de 1 hora, el defensor solo necesita un presupuesto de gas de 33 millions de dólares para contraatacar;
• Si logra activar el mecanismo de retraso y extender el periodo de desafío a 7 días, el coste de defensa puede caer a unos 200 mil dólares;

En otras palabras, esta es una ventaja estructural clave: el coste del atacante es acumulativo, mientras que el defensor solo necesita lograr una inclusión exitosa en la cadena.

Esta desproporción entre el coste de ataque y el de defensa (Cost to Attack vs. Cost to Defend) garantiza que, incluso si el ciclo de liquidación se acorta drásticamente, Ethereum siga siendo robusto en términos de seguridad económica. 

Para Interop, esto es crucial: la confirmación rápida y los ciclos de liquidación más cortos no tienen por qué sacrificar la seguridad, y en un diseño institucional razonable, la interoperabilidad en segundos y la seguridad económica pueden coexistir, al menos proporcionando la base más sólida para la confianza en la interoperabilidad cross-chain en segundos.

Palabras finales

Algunos pueden preguntarse: ¿por qué esforzarse tanto en optimizar unos segundos o minutos de retraso?

En la era geek de Web3, nos hemos acostumbrado a esperar, e incluso pensamos que "esperar" es una prima que hay que pagar por la descentralización. Pero en el camino de Web3 hacia el público general, los usuarios no deberían, ni necesitan, preocuparse por en qué cadena están operando, y mucho menos calcular la lógica de finalización de L1.

La confirmación rápida, el latido de 6 segundos y el mecanismo de defensa asimétrica, en esencia, buscan eliminar la "variable tiempo" de la percepción del usuario.

Como suelo repetir últimamente: la mejor forma de la tecnología es hacer que la complejidad desaparezca por completo en una confirmación ultrarrápida.