Romper los silos de liquidez de las L2: la lógica fundamental de la Zona Económica de Ethereum (EEZ) y una nueva solución entre cadenas
En la arquitectura de la Zona Económica de Ethereum (EEZ), el objetivo central del mecanismo entre cadenas es lograr la «componibilidad síncrona» (Synchronous Composability). Para comprenderlo a fondo, podemos desglosar todo el proceso en dos dimensiones clave: «por qué se necesita un mecanismo entre cadenas» y «por qué debe completarse dentro del mismo bloque de Ethereum».
I. ¿Cómo funciona el mecanismo entre cadenas? (Los tres pilares de la EEZ)
En los puentes tradicionales entre cadenas, las cadenas A y B son asíncronas: hay que bloquear fondos en la cadena A, esperar a que confirmen los firmantes múltiples o validadores y, después, acuñar activos en la cadena B. El proceso es lento y propenso a fallos. En cambio, la EEZ emplea un mecanismo de «cooperación síncrona basada en pruebas y proxies», que depende principalmente de tres componentes:
Pruebas en tiempo real (Real-time proving):
Antes, generar una prueba de validez para un Rollup podía llevar desde varios minutos hasta varias horas.
La EEZ aprovecha el hardware más reciente y las tecnologías de pruebas en tiempo real para reducir la generación de pruebas y completarla dentro de un slot de Ethereum (12 segundos). La red principal de Ethereum no necesita volver a ejecutar el código del Rollup: solo tiene que verificar esta prueba generada en tiempo real para confirmar que el estado del Rollup es correcto.
Composer y tabla de ejecución (Execution Table):
El Composer es un operador clave. Antes de que se produzca un bloque de Ethereum, ejecuta de antemano la transacción en varias cadenas que participan en las llamadas entre cadenas y registra el resultado de cada llamada en una «tabla de respuestas precalculadas» (la tabla de ejecución).
Contratos proxy (Proxy):
Cada contrato de un Rollup tiene una dirección proxy conocida de antemano en Ethereum L1 (y viceversa).
Cuando se produce una llamada entre cadenas, el código se escribe igual que una llamada local a un contrato, sin necesidad de protocolos complejos de mensajería asíncrona. El proxy consulta el contrato de la EEZ y comprueba los resultados de ejecución que el Composer calculó previamente; si coinciden, autoriza la operación directamente.
II. ¿Por qué debe completarse dentro de un mismo bloque de Ethereum? (La razón fundamental)
«Completarlo dentro del mismo bloque de Ethereum» (es decir, mediante llamadas síncronas) es el alma de todo el mecanismo. Hay tres razones principales:
Resolver la falta de «atomicidad» y lograr un verdadero «todo o nada»
En las operaciones financieras y en las operaciones complejas con contratos inteligentes, la atomicidad es fundamental: una transacción que consta de varios pasos debe completarse por entero o fallar por completo.
El problema de las operaciones asíncronas entre cadenas: si realizas las operaciones por etapas (pedir un préstamo en L1, transferir entre cadenas y operar en L2), y el segundo paso se atasca a mitad de camino o el mercado experimenta una gran volatilidad, tus activos quedan expuestos a un riesgo enorme. Por ejemplo, el dinero ya salió de L1, pero la operación falla por algún motivo en el pool de destino de L2 y los fondos quedan atrapados a medio camino.
La ventaja de la sincronización dentro del mismo bloque: si todas las operaciones se agrupan en un mismo bloque de Ethereum, toda la cadena de transacciones es absolutamente atómica. Durante la simulación previa, si el Composer detecta que algún paso (por ejemplo, un deslizamiento excesivo o un saldo insuficiente) puede fallar, el paquete completo de transacciones se cancela antes de que se produzca el bloque. Si llega a incluirse en la cadena, cualquier problema en uno de los pasos provoca que todas las operaciones relacionadas en Ethereum y en el Rollup se reviertan de forma segura al instante. Así se elimina por completo el riesgo intermedio durante el proceso entre cadenas.
Eliminar la fragmentación de la liquidez y permitir que las L2 compartan en tiempo real los pools profundos de L1
Si las operaciones entre cadenas no se completan dentro del mismo bloque, es necesario transferir previamente los fondos a los pools de cada L2 y dejarlos bloqueados allí. Esto reduce gravemente la eficiencia del capital y fragmenta la liquidez.
Dentro de un mismo bloque de Ethereum, el Rollup puede «tomar prestada» directamente, en el instante en que inicia una llamada, la profunda liquidez de la red principal de Ethereum L1 (por ejemplo, Uniswap o Aave).
Por ejemplo: inicias una transacción en L2 y, dentro del mismo bloque de Ethereum, esta llama directamente a Uniswap en L1 para completar el intercambio y devolver el resultado mediante una llamada de retorno. Para el usuario, la experiencia es como operar en una sola cadena: no necesita «depositar fondos o moverlos entre cadenas» de antemano.
Evitar la desincronización del estado y los ataques de «reorganización» (Reorg)
En cualquier momento pueden producirse reorganizaciones de bloques (Reorg) en una cadena de bloques. Si las operaciones entre cadenas son asíncronas y abarcan varios bloques, la cadena A puede considerar que una transacción se ha completado y, posteriormente, una reorganización de la red principal de Ethereum puede hacer desaparecer parte del estado previo del que dependía la cadena A. Esto provocaría un caos contable catastrófico.
Exigir que todo se complete dentro del mismo bloque de Ethereum significa que todas las transiciones de estado, las verificaciones de pruebas y las llamadas de retorno de los proxies quedan vinculadas al mismo punto temporal de referencia (bloque síncrono).
Las cadenas que se incorporen a la EEZ deben cumplir una regla inquebrantable: cuando Ethereum sufra una reorganización, la cadena debe revertirse de forma sincronizada. Esta lógica fundamental garantiza que nunca haya discrepancias contables entre estados de distintas cadenas debido a una «diferencia temporal».
💡 En resumen:
Completarlo dentro del mismo bloque de Ethereum permite utilizar la «atomicidad» —la propiedad más sólida de la infraestructura de la cadena de bloques— en lugar de los frágiles y lentos puentes entre cadenas. Así, las aplicaciones distribuidas en distintas L2 pueden compartir al instante y de forma segura toda la liquidez y los recursos de cómputo de la red principal de Ethereum, como si se ejecutaran en un mismo núcleo de CPU.
En la arquitectura de la Zona Económica de Ethereum (EEZ), el objetivo central del mecanismo entre cadenas es lograr la «componibilidad síncrona» (Synchronous Composability). Para comprenderlo a fondo, podemos desglosar todo el proceso en dos dimensiones clave: «por qué se necesita un mecanismo entre cadenas» y «por qué debe completarse dentro del mismo bloque de Ethereum».
I. ¿Cómo funciona el mecanismo entre cadenas? (Los tres pilares de la EEZ)
En los puentes tradicionales entre cadenas, las cadenas A y B son asíncronas: hay que bloquear fondos en la cadena A, esperar a que confirmen los firmantes múltiples o validadores y, después, acuñar activos en la cadena B. El proceso es lento y propenso a fallos. En cambio, la EEZ emplea un mecanismo de «cooperación síncrona basada en pruebas y proxies», que depende principalmente de tres componentes:
Pruebas en tiempo real (Real-time proving):
Antes, generar una prueba de validez para un Rollup podía llevar desde varios minutos hasta varias horas.
La EEZ aprovecha el hardware más reciente y las tecnologías de pruebas en tiempo real para reducir la generación de pruebas y completarla dentro de un slot de Ethereum (12 segundos). La red principal de Ethereum no necesita volver a ejecutar el código del Rollup: solo tiene que verificar esta prueba generada en tiempo real para confirmar que el estado del Rollup es correcto.
Composer y tabla de ejecución (Execution Table):
El Composer es un operador clave. Antes de que se produzca un bloque de Ethereum, ejecuta de antemano la transacción en varias cadenas que participan en las llamadas entre cadenas y registra el resultado de cada llamada en una «tabla de respuestas precalculadas» (la tabla de ejecución).
Contratos proxy (Proxy):
Cada contrato de un Rollup tiene una dirección proxy conocida de antemano en Ethereum L1 (y viceversa).
Cuando se produce una llamada entre cadenas, el código se escribe igual que una llamada local a un contrato, sin necesidad de protocolos complejos de mensajería asíncrona. El proxy consulta el contrato de la EEZ y comprueba los resultados de ejecución que el Composer calculó previamente; si coinciden, autoriza la operación directamente.
II. ¿Por qué debe completarse dentro de un mismo bloque de Ethereum? (La razón fundamental)
«Completarlo dentro del mismo bloque de Ethereum» (es decir, mediante llamadas síncronas) es el alma de todo el mecanismo. Hay tres razones principales:
Resolver la falta de «atomicidad» y lograr un verdadero «todo o nada»
En las operaciones financieras y en las operaciones complejas con contratos inteligentes, la atomicidad es fundamental: una transacción que consta de varios pasos debe completarse por entero o fallar por completo.
El problema de las operaciones asíncronas entre cadenas: si realizas las operaciones por etapas (pedir un préstamo en L1, transferir entre cadenas y operar en L2), y el segundo paso se atasca a mitad de camino o el mercado experimenta una gran volatilidad, tus activos quedan expuestos a un riesgo enorme. Por ejemplo, el dinero ya salió de L1, pero la operación falla por algún motivo en el pool de destino de L2 y los fondos quedan atrapados a medio camino.
La ventaja de la sincronización dentro del mismo bloque: si todas las operaciones se agrupan en un mismo bloque de Ethereum, toda la cadena de transacciones es absolutamente atómica. Durante la simulación previa, si el Composer detecta que algún paso (por ejemplo, un deslizamiento excesivo o un saldo insuficiente) puede fallar, el paquete completo de transacciones se cancela antes de que se produzca el bloque. Si llega a incluirse en la cadena, cualquier problema en uno de los pasos provoca que todas las operaciones relacionadas en Ethereum y en el Rollup se reviertan de forma segura al instante. Así se elimina por completo el riesgo intermedio durante el proceso entre cadenas.
Eliminar la fragmentación de la liquidez y permitir que las L2 compartan en tiempo real los pools profundos de L1
Si las operaciones entre cadenas no se completan dentro del mismo bloque, es necesario transferir previamente los fondos a los pools de cada L2 y dejarlos bloqueados allí. Esto reduce gravemente la eficiencia del capital y fragmenta la liquidez.
Dentro de un mismo bloque de Ethereum, el Rollup puede «tomar prestada» directamente, en el instante en que inicia una llamada, la profunda liquidez de la red principal de Ethereum L1 (por ejemplo, Uniswap o Aave).
Por ejemplo: inicias una transacción en L2 y, dentro del mismo bloque de Ethereum, esta llama directamente a Uniswap en L1 para completar el intercambio y devolver el resultado mediante una llamada de retorno. Para el usuario, la experiencia es como operar en una sola cadena: no necesita «depositar fondos o moverlos entre cadenas» de antemano.
Evitar la desincronización del estado y los ataques de «reorganización» (Reorg)
En cualquier momento pueden producirse reorganizaciones de bloques (Reorg) en una cadena de bloques. Si las operaciones entre cadenas son asíncronas y abarcan varios bloques, la cadena A puede considerar que una transacción se ha completado y, posteriormente, una reorganización de la red principal de Ethereum puede hacer desaparecer parte del estado previo del que dependía la cadena A. Esto provocaría un caos contable catastrófico.
Exigir que todo se complete dentro del mismo bloque de Ethereum significa que todas las transiciones de estado, las verificaciones de pruebas y las llamadas de retorno de los proxies quedan vinculadas al mismo punto temporal de referencia (bloque síncrono).
Las cadenas que se incorporen a la EEZ deben cumplir una regla inquebrantable: cuando Ethereum sufra una reorganización, la cadena debe revertirse de forma sincronizada. Esta lógica fundamental garantiza que nunca haya discrepancias contables entre estados de distintas cadenas debido a una «diferencia temporal».
💡 En resumen:
Completarlo dentro del mismo bloque de Ethereum permite utilizar la «atomicidad» —la propiedad más sólida de la infraestructura de la cadena de bloques— en lugar de los frágiles y lentos puentes entre cadenas. Así, las aplicaciones distribuidas en distintas L2 pueden compartir al instante y de forma segura toda la liquidez y los recursos de cómputo de la red principal de Ethereum, como si se ejecutaran en un mismo núcleo de CPU.