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

Si sueles moverte entre Base, Arbitrum u Optimism, seguramente hayas experimentado una sutil sensación de “desconexión”.

Aunque las transacciones en una sola L2 ya arrojan resultados casi instantáneos, cuando intentás transferir activos de la cadena A a la cadena B, a menudo tenés que esperar varios minutos o incluso más. Esto no se debe a que la L2 sea lenta, sino a que, en el proceso tradicional, una transacción que involucra capas y cadenas diferentes debe atravesar un camino largo y riguroso:

Ordenamiento 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 (alrededor de 13 minutos). Esto es necesario para la seguridad, pero para la interoperabilidad (Interop), resulta demasiado 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 funcionar como un todo coordinado. Por lo tanto, la clave está en reducir al máximo este tiempo de espera. 

Precisamente en este contexto, la hoja de ruta de Interop de Ethereum, en la etapa de aceleración (Acceleration), propone 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 acortamiento del ciclo de liquidación en L2 (Shorter L2 Settlement). 

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

I. Regla de confirmación rápida: dar una “respuesta confiable” antes de la Finality

Como es 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 actual de la cadena en cada slot, y la finalización (Finality) ocurre varios slots después.

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

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

El objetivo central es muy claro: permitir que aplicaciones y sistemas cross-chain reciban una señal de confirmación fuerte y verificable de L1 en 15–30 segundos, sin tener que esperar los 13 minutos que requiere la Finality completa.

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 irreversible bajo un modelo de ataque razonable”.

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

Actualmente, la preconfirmación (Preconfirmation) impulsada por la narrativa de Based Rollup cumple un papel de transición importante en esta dirección. Su lógica es simple, tal como sugiere el nombre. Imaginá lo siguiente: 

Cuando compramos un pasaje de tren en 12306, una vez que seleccionamos el viaje y hacemos el pedido (firmamos la transacción), el sistema de reservas primero nos da una preconfirmación, informándonos 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 pasaje confirma el vagón y el asiento (transacción publicada en L1), la compra se considera completada.

En resumen, en Based Rollup, la preconfirmación es un compromiso de incluir la transacción en el bloque antes de que sea enviada formalmente a L1 para su confirmación, dando 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 final viene 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 en L1: acelerar el “latido” de Ethereum

Complementando la regla de confirmación rápida, que es una “reconstrucción lógica a nivel de consenso”, hay un cambio aún 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 alcanzar el consenso final, reducir el tiempo del 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 a los validadores 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 bridges o market makers que gestionan 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 en ese tiempo, cobran comisiones más altas.

Cuando el ciclo de liquidación en L1 se acorta y la rotación de capital se duplica, la ocupación de capital en tránsito se reduce notablemente. El resultado es evidente: menores costos de fricción, menores comisiones para los usuarios y menor demora en la acreditación, lo que incentivará fuertemente a desarrolladores y usuarios a volver a la capa de liquidación segura de L1, en lugar de depender de relays de terceros vulnerables.

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

• Análisis de red: equipos de investigación (incluyendo a la investigadora Maria Silva, entre otros) están realizando análisis de datos rigurosos para asegurar que slots más cortos no generen riesgos graves de reorganización (Reorg) debido a la latencia de red, ni presionen a la centralización de nodos domésticos con menor ancho de banda;
• Implementación de 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 avance de ePBS, el plan de aceleración del latido puede avanzar por sí solo;

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

III. Acortamiento del ciclo de liquidación en 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 período de challenge 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. Siendo realistas, este diseño es impecable en términos de seguridad, pero en la interoperabilidad plantea un problema práctico:

Los activos y estados quedan “bloqueados por tiempo” entre cadenas. Esto no solo eleva el costo del cross-chain, sino que también aumenta la carga de rebalanceo de los Solvers, lo que finalmente se traduce en mayores tarifas para los usuarios. Por eso, acortar el ciclo de liquidación es clave para que la Interop pueda escalar. Las principales líneas de trabajo actuales incluyen (lectura recomendada: ZK Dawn: ¿La hoja de ruta final de Ethereum está acelerando?):

• Pruebas ZK en tiempo real: con la aceleración de hardware y la maduración 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 varias L2 realicen cambios de estado bajo una semántica de liquidación unificada, en lugar de “retiro-espera-depósito”;

Por supuesto, en el debate sobre Interop, una pregunta clave es inevitable: si para lograr confirmaciones cross-chain más rápidas, reducimos el período de challenge de 7 días a 1 hora, ¿no se abre una ventana para ataques?

En teoría, esta preocupación no es infundada. A diferencia de la “censura fuerte” (validadores actuando maliciosamente en conjunto), en la práctica lo más preocupante es la censura blanda liderada por los constructores de bloques: el atacante no necesita controlar el consenso, solo debe superar en precio a los defensores para impedir que transacciones clave entren en la cadena. 

Curiosamente, el único análisis económico sistemático sobre este escenario proviene del paper de Offchain Labs publicado en febrero de 2025, “Economic Censorship Games in Fraud Proofs”. El paper construye tres modelos, del más pesimista al más optimista, suponiendo: 

• Modelo G¹: el contenido del bloque lo decide solo quien paga más;
• Modelo G¹ₖ: algunos validadores siempre construyen bloques localmente;
• Modelo Gᵐ: varios validadores deciden el contenido del bloque, y basta con que uno elija la transacción del defensor;

En la práctica, como los validadores pueden perder slots (miss slots), algunos diseños pueden degradarse al caso más pesimista, G¹, por lo que el paper analiza el peor escenario. 

Sobre esta base, los investigadores proponen una defensa muy realista: un mecanismo de defensa diferida “apostando poco para ganar mucho”. Su lógica es que el defensor tiene el derecho de “demorar 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.

El propósito de esta transacción es claro: una vez en la cadena, extiende automáticamente el período de challenge de 1 hora a los tradicionales 7 días. Por ejemplo, si el defensor detecta un estado anómalo en L2, no necesita completar toda la verificación en 1 hora, solo debe enviar una transacción especial a L1, que actúa como una alarma antiaérea y extiende el período de challenge a 7 días.

Esto obliga al atacante a una guerra de desgaste muy asimétrica: para impedir que la transacción entre en la cadena, debe pagar una tarifa de prioridad superior a la del defensor en cada bloque, y mantener ese esfuerzo durante todo el período de challenge.

Los resultados cuantitativos del paper son claros: si un atacante poderoso planea gastar 10 billones 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 millones de dólares para contraatacar;
• Si logra activar el mecanismo de demora y extiende el período a 7 días, el costo de defensa cae a unos 200 mil dólares;

En otras palabras, esta es una ventaja estructural clave: el costo del atacante es lineal, mientras que el defensor solo necesita lograr una inclusión exitosa.

Esta desproporción entre el costo 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 la Interop, esto es fundamental: la confirmación rápida y los ciclos de liquidación más cortos no tienen por qué sacrificar la seguridad, y con un diseño institucional razonable, la interoperabilidad en segundos y la seguridad económica pueden coexistir, al menos brindando la confianza de base para lograr cross-chain en segundos.

Palabras finales

Algunos se preguntarán: ¿por qué tanto esfuerzo para optimizar unos segundos o minutos de latencia?

En la era geek de Web3, nos acostumbramos a esperar, incluso pensamos que “esperar” es el precio de la descentralización. Pero en el camino de Web3 hacia el público masivo, los usuarios no deberían, ni necesitan, preocuparse por en qué cadena están operando, ni calcular la lógica de finalización de L1.

La confirmación rápida, el latido de 6 segundos y los mecanismos de defensa asimétricos, en esencia, buscan una cosa: 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.