¿Puede Ethereum hacer que los rollups se sientan como una sola red?

Un trader en una demostración de Devcon firmó una orden en un rollup de Ethereum, compró tokens usando liquidez en la mainnet y los recibió de vuelta en el rollup. La operación muestra cómo los usuarios podrían acceder a un mercado más profundo sin mover fondos ellos mismos, un enfoque que Gnosis está apuntando para su configuración predeterminada en la primavera de 2027.

El equipo de Ethereum Economic Zone ha demostrado una operación en la que un usuario firmó una orden en la red experimental Rollup X, un solver de CoW Swap la ejecutó usando liquidez de la mainnet de Ethereum, y los tokens comprados llegaron de vuelta al rollup. La demostración muestra cómo un trader podría acceder a un mercado más profundo en la mainnet sin primero enviar fondos allí y esperar a que lleguen antes de realizar la orden.

El equipo presentó la operación en Devcon el 4 de noviembre, según informó crypto.news. La distinción importa cuando los precios se mueven rápidamente, ya que una cotización disponible cuando un trader comienza a mover fondos puede cambiar antes de que los fondos estén listos para operar.

Gnosis apunta a la primavera de 2027 para hacer del diseño su opción predeterminada. Para los traders, la prueba práctica será si sus billeteras y aplicaciones de trading pueden ofrecer la ruta y si el precio disponible en la mainnet sigue haciendo que valga la pena después de los costos de ejecución.

Cómo funcionaría la operación entre dos entornos de ejecución

El equipo de Ethereum Economic Zone comenzó con una transacción de octubre que involucraba 0.001 ETH y una actualización del estado del rollup. El swap de Devcon llevó el mismo problema de coordinación a un entorno que los traders reconocen. Tenía que cumplir una orden contra liquidez en otra cadena y entregar el activo resultante donde el usuario había comenzado.

Para un trader, la orden describe un resultado. Un vendedor quiere intercambiar un activo por otro, sujeto a los términos de la orden, y recibir el resultado en el rollup. El solver asume la responsabilidad de encontrar una ruta de ejecución. La distinción importa porque el usuario puede autorizar un resultado sin decidir qué pool usará el solver ni preparar una transacción separada para cada operación.

En el ejemplo de Devcon, esa ruta incluía la mainnet de Ethereum. La liquidez de trading permaneció allí, mientras que la orden del usuario se originó en Rollup X y los activos comprados regresaron a él. La demostración abordó así un problema que puede surgir incluso cuando las aplicaciones de cada red funcionan correctamente por sí solas. Un trader puede tener fondos en una cadena con un mercado poco profundo para el par deseado mientras la mejor ejecución está disponible en otro lugar.

Una ruta con pasos separados expone al usuario a decisiones a lo largo del camino. La primera transferencia puede completarse mientras la cotización que el usuario vio ha cambiado. En ese punto, el usuario debe aceptar el precio actual, esperar o mover los fondos nuevamente. Una ruta coordinada puede condicionar los movimientos de activos a la finalización de la orden completa, siempre que la infraestructura participante pueda llevar a cabo la operación en la ventana de ejecución acordada.

La distinción práctica es entre una ruta que promete entrega y una ruta que vincula las operaciones componentes entre sí. Un servicio puede hacer que una operación entre cadenas parezca simple asumiendo la responsabilidad de la entrega por sí mismo. El diseño en la demostración le da a la aplicación una forma de vincular el resultado en una cadena con la ejecución en otra. Qué enfoque ofrece la mejor experiencia depende del precio, los activos disponibles y los términos bajo los cuales cada servicio entrega la orden.

Todavía hay trabajo detrás de la firma del usuario. Una aplicación tiene que presentar los términos, el solver tiene que encontrar y cotizar la ruta, y las redes participantes tienen que ponerse de acuerdo sobre el estado relevante. Un sistema de producción debe manejar fallos en cada uno de esos lugares. La aplicación puede simplificar la interfaz sin hacer que esas tareas desaparezcan.

Para una billetera, una prueba igualmente práctica es el registro de transacciones que puede mostrar después de que la orden expire. Si un usuario firma una vez y una operación tiene éxito, el usuario debería poder ver el activo recibido y qué cuenta lo recibió. Si la ruta falla, la billetera aún necesita una forma de distinguir una orden expirada de una transacción que está pendiente de liquidación. Esto importa durante un movimiento de mercado, cuando un operador podría colocar una segunda orden y necesita saber si la primera aún puede ejecutarse.

En qué tienen que ponerse de acuerdo las redes antes de poder ejecutar juntas

Una cadena de bloques registra más que saldos. Su estado incluye información utilizada por las aplicaciones, como permisos de cuenta, saldos de contratos y el estado de las transacciones. Un contrato que quiera basarse en un resultado de otra cadena necesita evidencia sobre ese estado. La evidencia debe estar disponible cuando el contrato necesite usar el resultado.

Gnosis describe dos condiciones para las redes que se unen al diseño de EEZ. Necesitan producir una prueba dentro de un slot de Ethereum y seguir a Ethereum en caso de una reorganización. Gnosis presenta esas como condiciones para una red conectada, dejando algunas decisiones de implementación a los participantes individuales.

Un slot da a los ingenieros una fecha límite. Si una red tarda más que el tiempo disponible en producir la prueba requerida, el otro lado no puede confiar en ella dentro de la misma ventana. Un sistema de prueba que funciona bien en bloques típicos aún tiene que lidiar con cargas de trabajo inusualmente exigentes, interrupciones y competencia por recursos informáticos.

La segunda condición aborda qué sucede cuando cambia la historia reciente de Ethereum. Una transacción en otra red puede haberse basado en un evento en un bloque reciente de la mainnet. Si un bloque competidor lo reemplaza, el sistema conectado necesita reglas para manejar la transacción dependiente. La alineación limita la posibilidad de que un lado mantenga un resultado basado en un evento de la mainnet que ya no pertenece a la cadena aceptada.

Esa relación es importante para los usuarios porque una transacción coordinada y la liquidación final describen propiedades diferentes. La ejecución coordinada se refiere a si los pasos pueden completarse juntos. La liquidación final se refiere a cuándo los participantes pueden tratar el resultado como liquidado bajo las reglas de las redes involucradas. Una billetera puede ofrecer una vista de la operación mientras sigue distinguiendo una transacción incluida de una que ha alcanzado el estado de liquidación que requiere un negocio.

Trabajos de ingeniería anteriores de Gnosis abordaron compromisos de raíz de bloque, límites de gas y cómo se llevarían a cabo las actualizaciones. Esas elecciones afectan cómo las redes pueden reconocer los resultados de las demás y cuánto trabajo pueden pedirles a las aplicaciones que hagan. El hito de octubre puso una operación simple en la mainnet, mientras que las demostraciones de noviembre dieron a los desarrolladores cargas de trabajo más variadas para probar.

Hacia dónde podría ir el diseño más allá del trading

La demostración de Safe aplicó el mismo enfoque a la propiedad de la billetera. Una tesorería que utiliza cuentas separadas en distintas cadenas puede enfrentar una brecha entre eliminar un firmante en una red y actualizar los permisos en otra. El ejemplo mostró cómo un rollup podría verificar un cambio de propiedad realizado en la mainnet dentro de la misma transacción.

Una tercera demostración verificó una firma post-cuántica Falcon en el rollup y utilizó el resultado para autorizar una transferencia en la mainnet. El equipo informó un consumo de gas un 91% menor en su comparación con realizar la verificación directamente en la mainnet. El ahorro medido fue para ese ejercicio de verificación, y una aplicación en producción tendría que tener en cuenta sus costos completos de ejecución y liquidación.

Una sola firma todavía deja un mercado para la ejecución

La ruta de intercambio aleja parte del trabajo de la persona que coloca una orden. Un solver tiene que decidir dónde llenarla, tener en cuenta las comisiones y enviar las operaciones necesarias para completarla. Un usuario puede recibir una única cotización aunque el solver haya incluido varios pasos en el precio del monto ofrecido.

Ese arreglo es más útil cuando la liquidez disponible en otra red mejora la operación lo suficiente como para cubrir el costo de llegar a ella. Una orden pequeña en un mercado local profundo puede ser más barata de llenar localmente. Una orden más grande en un pool poco profundo podría recibir un mejor precio de la liquidez de la mainnet incluso después de los costos adicionales de ejecución.

También importa qué sucede con los intentos fallidos. Revertir los movimientos de activos evita que el operador quede con solo una parte de la operación prevista. Una aplicación o un solver aún puede incurrir en costos al organizar o intentar la ejecución, dependiendo de cómo se implemente la ruta. En un mercado en producción, esos costos pueden afectar qué órdenes los solvers están dispuestos a llenar y cómo cotizan sus precios.

Una buena comparación para los traders utilizaría el mismo tamaño de orden, par de tokens y ventana temporal. El precio recibido después de las comisiones puede entonces compararse con un swap local o con una ruta que puentea fondos en pasos separados. El número de clics captura la conveniencia. La cantidad neta recibida captura la operación en sí.

Cómo el proyecto pasó de una propuesta a una devnet

El proyecto fue presentado públicamente en EthCC en primavera por Gnosis y ZisK, con el apoyo de la Ethereum Foundation. La propuesta original concernía a la liquidez y a las aplicaciones que se habían distribuido entre diferentes redes de capa 2. Rollup X ofrece a los desarrolladores un entorno en el que probar cómo una transacción compartida puede utilizar esas aplicaciones.

Hay una razón por la que la elección de la demostración importa. Mover una pequeña cantidad de ETH entre entornos prueba una operación relativamente directa. Un swap introduce la necesidad de satisfacer una orden contra la liquidez del mercado y devolver un activo. Un cambio en la propiedad de una Safe implica permisos. La verificación de firmas requiere que un entorno realice una comprobación y otro actúe sobre su resultado. Cada uno sondea una dependencia diferente.

Una ruta que funciona para una de estas operaciones puede ser poco práctica para otra. Un swap tiene que lidiar con precios y liquidez que se mueven continuamente. Un cambio de propiedad es menos sensible al precio de mercado pero puede tener modos de fallo más consecuentes. Una aplicación de verificación puede beneficiarse de realizar trabajo computacional en otro lugar incluso cuando no hay una razón económica para mover fondos entre redes.

El requisito común es que el contrato receptor pueda confiar en la información en el momento en que la necesita. Eso ejerce presión sobre el software que mantiene los enlaces. Una aplicación puede ofrecer una interfaz sencilla solo si la ruta de ejecución maneja el estado requerido y devuelve el resultado esperado. En un producto en vivo, los desarrolladores tendrían que decidir qué operaciones merece la pena colocar en esa ruta y cuáles pueden ejecutarse de forma independiente.

El argumento de Gnosis para hacer de la tecnología la opción por defecto se basa en parte en lo que las aplicaciones podrían evitar duplicar. Un equipo que construye sobre una nueva red podría, de otro modo, necesitar financiar liquidez local para una larga lista de mercados. La capacidad de alcanzar los pools de mainnet podría permitirle ofrecer trading en un par antes de que un pool local dedicado sea viable. Para un proveedor de liquidez local, la misma elección crea competencia desde otra fuente de ejecución.

El efecto sobre los usuarios se mide más fácilmente en productos que divulgan ambas rutas. Una cartera podría comparar una ejecución local con una ejecución en mainnet para la misma orden y mostrar la cantidad neta en la misma cadena de destino. Una herramienta de tesorería podría documentar cuántas transacciones separadas se requieren para aplicar un cambio de autoridad. Esas pruebas mostrarían dónde el enfoque cambia los costes de ejecución reales o el trabajo operativo.

El calendario importa porque una demostración exitosa puede ser mucho más fácil de operar que un servicio con muchos usuarios y aplicaciones. Un sistema en vivo debe manejar solicitudes simultáneas, condiciones de mercado cambiantes y cambios de software. Llevar las aplicaciones existentes de Gnosis Chain a través del movimiento probaría más de esas dependencias que los ejemplos de Devcon por sí solos.

Qué tendría que cubrir el precio en un swap entre cadenas

Un trader compara la cantidad del activo comprado que llega después de los costes. Un pool local tiene su propia comisión de trading e impacto en el precio. Una ruta por mainnet puede ofrecer mayor liquidez, pero puede requerir más trabajo de ejecución e incurrir en costes por usarla. Un solver que decide entre rutas tiene que sopesar el mejor precio del pool frente a esos costes.

Imaginemos que un pool local entregaría 9.900 dólares en valor de un activo después de todos los cargos en una orden con un valor de referencia de 10.000 dólares. Una ruta entre cadenas que puede llenar la operación por 9.980 dólares antes de los costes de ejecución tiene hasta 80 dólares de margen antes de que la cotización local sea mejor. Si alcanzar el mejor pool cuesta 30 dólares, la ruta entre cadenas entrega 9.950 dólares. Con 100 dólares de coste añadido, la ruta local ofrece más. Los números ilustran la comparación y no describen ninguna cotización en vivo.

El tamaño de la orden cambia ese cálculo. Una operación más grande puede mover el precio más lejos en un pool poco profundo, dando al solver más razones para llegar a un mercado más profundo. Una operación pequeña puede causar poco impacto en el precio local y dejar pocos ahorros para cubrir la ruta entre cadenas. Incluso para el mismo par de tokens, la ruta útil puede cambiar a lo largo de un día a medida que se mueven la liquidez y los costos de red.

Los solvers también deben poner precio a los intentos fallidos y al tiempo que dedican a encontrar rutas. Una operación fallida puede dejar revertidos los movimientos de activos del usuario, mientras que las partes que organizan la orden aún pueden enfrentar gastos asociados con intentar la ejecución. El efecto del diseño sobre el spread que ve un trader depende de cómo una implementación en vivo asigna esos costos y de cuánta competencia hay entre las firmas que ofrecen cotizaciones.

Para una billetera que integra este diseño, la información importante es lo que el usuario puede comparar. Una cotización que informa el monto mínimo entregado y la red en la que llegará le da al trader una forma de evaluar el resultado. Una interfaz que enfatiza un clic o una firma muestra algo sobre la conveniencia, mientras que el precio y las condiciones de entrega muestran si la ruta sirve a la orden.

Un venue de trading que considere el diseño tendría que decidir qué mostrar a los clientes sobre las dependencias de una cotización. Una ruta podría llenarse completamente donde el usuario tiene fondos. Otra podría invocar liquidez de mainnet y depender de que una prueba esté lista dentro de un slot. Incluso si ambas cotizaciones muestran el mismo token y el mismo monto, pueden tener reglas de expiración diferentes y razones diferentes para fallar. La interfaz tendría que comunicar el monto mínimo que un cliente acepta y qué sucede si el solver no puede entregarlo.

Las aplicaciones también tienen que determinar cómo recopilarían suficientes datos comparables para identificar por qué una ruta cuesta más. Una serie útil incluiría el mismo par y tamaños de operación en las mismas redes, con las cotizaciones capturadas muy cerca en el tiempo. Una sola operación de un par inusualmente ilíquido podría hacer que la capacidad de llegar a otro mercado parezca más valiosa de lo que es para las órdenes cotidianas. El problema opuesto puede surgir con un par importante que ya se negocia barato en el rollup del usuario. El precio de ejecución, las comisiones incluidas y las condiciones de expiración tienen que viajar juntos en la comparación.

Safe hace que la autoridad entre cadenas forme parte del problema

Una tesorería puede usar una cuenta para pagos regulares y otra para mantener activos en una red diferente. Si cambia a las personas autorizadas para aprobar gastos, alguien tiene que asegurarse de que el cambio se refleje donde se guardan los activos. Las actualizaciones separadas crean oportunidades para que una lista de firmantes desactualizada siga activa en una cuenta usada con menos frecuencia.

La demostración de Safe mostró cómo una aplicación podría usar un cambio de propiedad en mainnet dentro de una transacción coordinada que involucra un rollup. Su beneficio depende de cómo la tesorería haya elegido asignar la autoridad. Una organización podría querer que mainnet determine un conjunto compartido de firmantes, mientras mantiene una política separada para una cuenta de gasto local que sirve a un equipo en particular.

Una estructura de autoridad compartida puede reducir el trabajo duplicado. También hace más importante el manejo de errores porque un cambio puede tener consecuencias en varios lugares. Una tesorería necesitaría entender cómo se recuperan sus cuentas si una actualización es incorrecta, quién puede autorizar una corrección y cómo se comporta una cadena conectada si no puede obtener un resultado actual.

Una organización que evalúe el diseño, por lo tanto, preguntaría qué operación quiere coordinar. Leer una lista de firmantes, actualizar la propiedad y mover activos de la tesorería tienen consecuencias diferentes. El valor de hacer una dentro de una transacción compartida no establece que una organización deba delegar cada decisión a la misma cuenta.

El interés institucional va más allá del escenario de Devcon. Consensys anunció un sistema de interoperabilidad para bancos y dijo que planea apoyar el estándar EEZ. Para un banco, la compatibilidad se situaría junto a preguntas sobre quién puede usar el sistema, qué controles se aplican a cada operación y cómo registra el resultado en los sistemas existentes.

El caso de Safe sugiere un conjunto diferente de pruebas de producto. Un equipo podría querer que los firmantes en una red aprueben una operación que solo afecta activos en otra. Eso plantea la cuestión de si un firmante eliminado localmente aún puede autorizar una operación entre redes enviada anteriormente. La respuesta depende de cómo la aplicación lee el estado de la cuenta y qué trata como el momento de autorización. Esos son asuntos que una aplicación necesita especificar incluso cuando el protocolo subyacente es capaz de transportar el mensaje.

Lo que la demostración de Falcon dice sobre hacer cómputo en otro lugar

La demostración insignia utilizó un rollup para verificar una firma Falcon y suministró ese resultado a una acción en la mainnet. El equipo informó una reducción del 91% en el consumo de gas en su comparación con la verificación en la mainnet. El ejemplo tiene un alcance más limitado que una afirmación sobre el costo de cada transacción que podría usar el diseño. Compara una operación específica entre dos rutas de ejecución.

La oportunidad consiste en ejecutar una verificación computacionalmente costosa en un entorno adecuado para ello, mientras se permite que otro contrato dependa de la respuesta. Una aplicación que realiza una verificación solo rara vez puede valorar los ahorros de manera diferente a una que la repite en cada orden. La decisión también depende de cómo la aplicación valida el resultado y qué otros pasos debe completar para usarlo.

La verificación post-cuántica es una aplicación de ese patrón. Un contrato podría necesitar otra información de un entorno conectado antes de poder continuar, como si una cuenta tiene derecho a realizar una operación. El problema compartido es hacer que un resultado esté disponible dentro de la misma ventana de ejecución. Diferentes verificaciones pueden tener requisitos de cómputo y prueba muy distintos.

Para un usuario, el soporte de un esquema de firma en una aplicación no determina la seguridad de cada billetera o transacción en la cadena. La demostración abordó la verificación y autorización para la transferencia específica. Cambiar las reglas por las cuales las billeteras firman generalmente las transacciones implicaría otras decisiones sobre software, compatibilidad y qué cuentas adoptan los cambios.

Existe una distinción similar para los desarrolladores que evalúan la demostración de Falcon. El gas gastado por el contrato al leer un resultado de verificación y el costo de producir ese resultado en otro lugar pertenecen a entornos de ejecución diferentes. Medir el primero captura una restricción real para una aplicación que de otro modo tiene que ejecutar la verificación en la mainnet. Un servicio que decide si puede ofrecer la función necesita tener en cuenta también el segundo. También necesita saber si la verificación puede completarse bajo carga, cuando muchas solicitudes pueden competir por la misma capacidad.

Gnosis tendrá que llevar las aplicaciones existentes a través de la transición

GnosisDAO autorizó el traslado de una red independiente a un rollup EEZ mediante GIP 153 en agosto. La migración importa porque los usuarios y aplicaciones existentes tienen saldos, direcciones y dependencias vinculadas a la cadena activa. Para ellos, adoptar un nuevo arreglo de ejecución y liquidación es un cambio en la infraestructura que ya utilizan.

Las preguntas que una aplicación activa tiene que responder difieren de las de una red de desarrollo. Sus usuarios necesitan saber cómo se transfieren los saldos, qué billeteras y proveedores de infraestructura apoyan la migración y dónde obtener un registro confiable de la actividad mientras la transición está en curso. Las plataformas de trading necesitan tener en cuenta la posibilidad de que las integraciones estén disponibles en momentos diferentes.

Un rollup que puede acceder a los mercados de la mainnet podría ofrecer rutas antes de construir fondos de liquidez profundos propios para cada par de tokens. Una cadena con liquidez establecida tiene una decisión diferente. Sus aplicaciones pueden elegir entre ejecución local y una ruta compartida, y los proveedores de liquidez que ya están en la cadena pueden ver cómo esas elecciones afectan la actividad en sus fondos.

La migración también pondrá a prueba la diferencia entre lanzar una red y hacer que una función sea la predeterminada para los usuarios. Un primer bloque puede demostrar que la nueva cadena está funcionando. Una ruta de usuario predeterminada requiere que las billeteras, aplicaciones y otros proveedores usen la nueva ruta en la actividad ordinaria. Informes anteriores describieron un objetivo alrededor del cambio de año para un despliegue inicial. La actualización de noviembre de Gnosis da la primavera de 2027 como objetivo para la operación predeterminada.

Gnosis da a los desarrolladores un lugar para plantear esas preguntas contra un despliegue con aplicaciones existentes. La migración pondría la ejecución, el soporte de billeteras y los procedimientos operativos bajo el mismo calendario, haciendo posible seguir cómo el equipo maneja los retrasos o las integraciones parciales. Su actualización de noviembre identifica la primavera de 2027 como el objetivo para hacer que el diseño sea el predeterminado. Las operaciones de Devcon tuvieron lugar en Rollup X.

Qué observar

• Rutas compatibles. Carteras y aplicaciones que publican las redes en las que la misma operación está disponible.
• Cotizaciones de ejecución. Producción neta comparable y tasas de órdenes fallidas para operaciones locales y entre redes.
• Rendimiento de slots. Pruebas repetidas que muestran la disponibilidad de pruebas y la recuperación cuando Ethereum se reorganiza.
• Permisos de tesorería. Alcance publicado, caducidad y reglas de revocación para las integraciones de Safe.
• Hitos de Gnosis. Pruebas públicas de migración y progreso hacia el objetivo de primavera de 2027.

Preguntas frecuentes