Interoperabilidad sin confianza entre Rollups: Paisaje, Construcciones y Desafíos

IntroducciónHa habido una explosión cámbrica de rollups en Ethereum. En el momento de escribir esto, hay 91 L2 & L3 en vivo y 82 próximos según L2Beat. Como resultado, también hay una cantidad significativa de fragmentación en cuanto a liquidez, experiencia de usuario y herramientas para desarrolladores. Las soluciones actuales para la interoperabilidad dejan mucho que desear, ya que se basan en una combinación de puentes de terceros, activos envueltos externamente y marcos de intención, cada uno con su propio conjunto de problemas.

• Los puentes de liquidez son a menudo los objetivos de los mayores hacks de criptomonedas (por ejemplo, el hack de $321 millones del puente de agujero de gusano)- Los activos envueltos externamente son indeseables, y los datos han demostrado que las personas preferirían mantener los activos en su forma nativa siempre que sea posible (por ejemplo, hay $22 mil millones de activos puenteados canónicamente y solo $3 mil millones de activos envueltos externamente, según L2Beat)- Los marcos de intención dependen de terceros que requieren cierta confianza no despreciable, y vienen con tarifas adicionales para facilitar la actividad entre rollups cruzados (por ejemplo, el usuario de Degen chain perder >80% de tokensdebido a que el puente oficial no es canónico) a. Los marcos de intención centralizados también significan una menor competencia y esto podría llevar a precios y rendimiento subóptimosEn este artículo, exploramos el panorama de interoperabilidad sin confianza definiendo y discutiendo seis niveles de soluciones de interoperabilidad entre ecosistemas de rollup fragmentados.

Comenzamos con el caso predeterminado de retirarse de forma asincrónica del rollup fuente a L1 y de pasar manualmente al rollup de destino, y terminamos con una arquitectura hipotética para la composabilidad entre rollups en una sola transacción. Exploraremos cómo afectará cada nivel de interoperabilidad a la experiencia del usuario, la experiencia del desarrollador, el potencial de MEV y los propios rollups (específicamente relacionados con los cambios de infraestructura).

Nos mantenemos principalmente dentro del alcance de Ethereum y sus L2s para este artículo y nos enfocamos únicamente en la interoperabilidad sin confianza. En este caso, la “interoperabilidad sin confianza” se refiere a canales en protocolo que no requieren terceros para facilitar transferencias fuera de la infraestructura necesaria que la mayoría de los rollups ya requieren.

Preliminares## DefinicionesFundamentalmente, la interoperabilidad sin confianza requiere algún recurso compartido al que cualquier dos protocolos que deseen interoperar deben tener acceso. En el caso de Ethereum L1, todos los contratos inteligentes residen en el mismo entorno compartiendo el estado completo de Ethereum, por lo que siempre tendrán el más alto nivel de interoperabilidad. Sin embargo, los L2 solo comparten una capa de liquidación a través de contratos de puente separados y, por lo tanto, la interoperabilidad es mucho más limitada.

Los componentes de infraestructura compartida crucial que pueden avanzarnos a lo largo de la escalera de interoperabilidad sin confianza son secuenciadores compartidos, superconstructores y liquidación compartida. Las garantías y nuevas funcionalidades abiertas por estas capas compartidas están relacionadas, pero esencialmente ortogonales en su naturaleza.

• Secuenciadores/Supercronstructoras compartidas: Principalmente actualizaciones de velocidad y experiencia de usuario.- Liquidación compartida: Intercambio de activos sin envolver externamente, así como mensajería en el protocolo.Para comenzar, primero definiremos los seis niveles de interoperabilidad sin confianza aludidos en la introducción:

• L1 Asincrónico: → Interoperabilidad a través de la transferencia manual de activos a través del L1 al que las rollups se liquidan.- Inclusión atómica: → Una garantía de que todas las transacciones en un paquete de interconexión de rollups se incluirán en el próximo bloque para cada rollup involucrado en el paquete, o ninguna lo hará.- Liquidación compartida: → Múltiples rollups conectándose al L1 a través del mismo contrato de puente.- Ejecución atómica: → Una garantía de que todas las transacciones en un paquete cruzado de rollups se incluirán y ejecutarán con éxito en el siguiente bloque para cada rollup involucrado en el paquete, o ninguna se ejecutará. La ejecución exitosa se refiere a que cada transacción se ejecute sin revertir y se refleje en el estado actualizado para cada rollup en el paquete.- Composabilidad a nivel de bloque: → Los bloques siguientes garantizan paquetes de interconexión enrollados transversalmente que pueden contener transacciones dependientes (la tx B en el rollup B depende del resultado de la tx A en el rollup A)- Composabilidad a nivel de transacción: → Interoperabilidad a nivel de contrato inteligente que solo requiere una transacción que puede causar cambios de estado en muchos rollups simultáneamente (sin paquetes). Utilizar cualquier protocolo en cualquier rollup es lógicamente equivalente a usar diferentes contratos inteligentes en una cadena. Es importante destacar que esto implica que los cambios de estado anteriores a cualquier llamada pueden revertirse cuando regresa.Para comprender cada nivel más a fondo, recorreremos los siguientes casos de uso clave para demostrar el poder de cada nivel, así como las implicaciones para los usuarios, desarrolladores, rollups y buscadores de MEV.

Ejemplos ilustrativos:- Transferencia del Mismo Token

→ Enviar a uno mismo: Cambiar Eth por Eth o ERC-20 por ERC-20 entre dos rollups- Compra de tokens → Orden límite de cruce de Rollup: utilizando Eth/ERC-20 de Rollup A, compra un ERC-20 diferente de un DEX en Rollup B y (opcionalmente) envíalo de vuelta a Rollup A## Implicaciones:Las siguientes preguntas también se responderán para comprender mejor el impacto en los principales accionistas en cualquier ecosistema de rollup.

• Experiencia del usuario ¿Cómo cambia la experiencia del usuario al lograr este nivel de interoperabilidad?- Experiencia del desarrollador ¿Cómo cambia la experiencia del desarrollador al alcanzar este nivel de interoperabilidad?- Potencial de MEV ¿Existe el potencial de nuevas oportunidades de MEV si logramos este nivel de interoperabilidad?- Implicaciones de Rollup ¿El rollup tiene que optar por alguna nueva infraestructura para lograr esto? ¿Cuáles son los cambios en las estructuras de tarifas para el rollup? ¿Cuáles podrían ser los beneficios potenciales para que los rollups participen en esta infraestructura?## Visión general de alto nivel

Resumen de los cambios para las partes interesadas clave

La progresión de seis niveles hacia la interoperabilidad sin confianza## 1. Asincrónico L1## Infraestructura requerida:N/A

Según lo definido, esto se refiere al modo predeterminado actual de interoperabilidad sin confianza. Todos los rollups se definen como tales porque se construyen en una capa L1 como capa de liquidación y solo tienen acceso a esa L1 a través de los contratos de puente donde periódicamente publican actualizaciones de estado para asegurar la red.

La única forma canónica de realizar cualquier actividad sin confianza de intercambio entre rollups en este caso es retirar los activos del rollup fuente a través del puente canónico y depositarlos manualmente en el rollup de destino una vez que estén disponibles en L1.

Para rollups optimistas, esta latencia de retiro es de aproximadamente ~7 días para tener en cuenta la ventana de prueba de fallos. En un rollup ZK, la latencia de retiro es menos segura pero podría ser de 15 minutos a un día completo, como es el caso de ZkSync.

Además, los intercambios atómicos de igual a igual mediante contratos inteligentes son posibles, pero este es un caso de uso más pequeño y no escala de manera efectiva.

Vale la pena señalar las soluciones de terceros que actualmente existen:

• Puentes de liquidez- marcos de intenciónAmbos de nuestros ejemplos ilustrativos requieren soluciones de terceros para facilitar.

Enviar a uno mismo:

• Canónicamente: Retirar activos de Rollup A → Depositar manualmente en Rollup B- Terceros: → Puentes de liquidez / Redes de resoluciónPedido limitado de transferencia cruzada

• Canónicamente: → Retirar activos de Rollup A → Depositar manualmente en Rollup B → Realizar orden limitada Para devolver, uno tendría que envolver externamente el ERC-20 objetivo- Terceros Espacio de soluciones naciente para órdenes límite cruzadas entre rollups → Hay diseños abiertos sobre el uso de intenciones para facilitar estoDado que este es el caso por defecto, no es necesario discutir cambios en UX, DevEx, MEV y rollups.

2. Inclusión atómica## Infraestructura requeridaSecuenciador compartido *

La inclusión atómica solo garantiza que un paquete inter-rollup se incluirá en el próximo bloque.

Esto requiere un secuenciador compartido, pero teóricamente se puede lograr sin uno manualmente si los secuenciadores de dos resúmenes dados no están al máximo rendimiento (simplemente se podrían enviar dos transacciones a cada resumen individualmente). Es por eso que hemos agregado un asterisco a la infraestructura requerida.

Sin embargo, no asumimos que el secuenciador compartido esté ejecutando un nodo completo de cada uno de los rollups conectados, por lo que no puede garantizar la ejecución exitosa de un conjunto de transacciones. En este caso, el secuenciador compartido solo puede garantizar que las transacciones están bien formadas y que serán incluidas en el próximo bloque, pero no necesariamente que se ejecutarán con éxito.

Debido a que no hay garantías de ejecución, es imposible aprovechar programáticamente la inclusión atómica de manera significativa sin correr el riesgo de que una de las transacciones se revierta. Como resultado, estamos básicamente en el mismo caso exacto que la interoperabilidad asincrónica de L1.

Considerar iniciar un intercambio simple entre rollups con solo garantías de inclusión atómica:

• Paquete de intercambio entre rollups → Tx 1: Bloquear/Grabar tokens en el rollup de origen → Tx 2: Emitir tokens a la dirección del usuario en el rollup de destinoPodemos tener garantías de inclusión atómica en que ambas transacciones estén incluidas en los próximos bloques para cada rollup, pero si la primera transacción revierte y la segunda no, el usuario recibiría erróneamente fondos asignados en la cadena de destino sin haberlos bloqueado o quemado en la cadena de origen y nos encontraríamos con un problema de doble gasto.

Cualquier solución de interoperabilidad, ya sea un puente de liquidez, un marco de intención o un intercambio xERC-20, sería vulnerable a este riesgo y es imposible mitigarlo. Debido a este riesgo, las soluciones actuales requieren que la transacción iniciadora se haya ejecutado con éxito y se haya incluido en un bloque en la cadena de origen antes de usar relayers para pasar un mensaje emitido y ejecutar la segunda transacción en la cadena de destino.

Mensaje importante: La inclusión atómica no afecta significativamente el potencial de interoperabilidad

3. Liquidación compartida## Infraestructura requerida:Capa de agregación de pruebas // Contrato puente compartido

Aquí es donde las cosas comienzan a ponerse más interesantes. Como resultado del contrato de puente compartido, toda la liquidez depositada en el ecosistema de rollups desde la L1 se puede mover libremente entre todos los rollups conectados. Hasta este punto, no podíamos realizar intercambios entre rollups sin pasar por canales canónicos, envolver activos externamente o usar una solución de terceros.

¿Por qué construir un contrato de puente compartido? Para entender por qué tener un contrato de puente compartido nos permite mover activos de forma confiable a través de rollups, primero consideremos qué sucedería si fuera posible tener Eth en Rollup A, quemarlo y generarlo nativamente en Rollup B sin un contrato de puente compartido en L1.

Vemos que cada rollup se desincronizaría con su contrato puente en mainnet. El contrato puente del rollup B todavía tiene 50 Eth, por lo que el usuario no podría retirar sus 1 Eth a la L1.

Para resolver esto, se construyen protocolos de envoltura de activos externos que emiten una versión envuelta externamente de tokens a través de rollups que simbolizan una versión nativa en otro lugar de la red.

Con una capa de liquidación compartida, la situación parece diferente. Debido a que toda la liquidez para cada rollup conectado está bloqueada en el mismo contrato puente, uno puede moverse libremente entre rollups, ya que la cantidad total de valor en el contrato puente permanece igual y siempre se puede retirar.

Debe haber una actualización a nivel de contrato L1 sobre*dónde *la liquidez es permitir a los usuarios retirar desde cualquier lugar, pero esto es trivial porque todos los rollups conectados pueden leer/escribir en el contrato compartido.

Con una capa de liquidación compartida, el flujo puede verse como el siguiente para un caso simple de enviar a uno mismo.

Enviar a uno mismo:

• El usuario crea la transacción inicial: → Tx 1: retirar Eth en rollup A (con mensaje para acuñarlo en rollup B) → Las transacciones se agrupan y se envían al contrato L1 → Se agrega en la raíz de la transacción que agrupa todos los rollups de liquidación compartidos- Rollup B importa esta raíz de transacción- El relayer envía la transacción para acuñar junto con la Prueba de Merkle para rollup B- Rollup B verifica la transacción de quema utilizando Prueba de Merkle y raíz de transacción- El usuario está acuñando Eth en Rollup B- Rollup B presenta prueba a L1Podemos extender este flujo a cualquier ERC-20 que tenga contratos en todos los rollups en el ecosistema de liquidación compartido.

Uno puede pensar en un contrato de puente compartido como una capa de mensajería en protocolo entre todos los rollups conectados, por lo que teóricamente este flujo realmente se puede extender a cualquier estándar de mensajería arbitrario.

Esto nos acerca más a la composabilidad, pero debido a los pasos necesarios de agregación de pruebas y retransmisión de mensajes solo después de que los cambios de estado se reflejen en L1, hay altas latencias (aunque notablemente más bajas que el caso asíncrono de L1). Además, cualquier actividad compleja de cruce de rollups como usar un DEX en rollup B comenzando con activos en rollup A para una orden límite de cruce de rollups seguiría siendo un proceso tedioso para el usuario, ya que aún tendrían que enviar a sí mismos e intercambiar manualmente activos en el rollup de destino. En este caso, no se pueden crear paquetes atómicos de cruce de rollups.

Otro beneficio importante con liquidación compartida es que hay menos fricción para los proveedores de liquidez o solucionadores que están llenando pedidos en múltiples entornos. Debido a que su liquidez en todos los rollups conectados se refleja en el mismo contrato puente, no tienen que esperar a la ventana completa de retiro para gestionar su liquidez entre rollups.

Implicaciones para las partes interesadas:- Usuarios:

Ahora se pueden transferir activos en su forma nativa sin período de retiro de L1- Desarrolladores: Los cambios están limitados a los emisores de tokens que ahora pueden utilizar mensajes en el protocolo para emitir versiones nativas de ERC-20 en todos los rollups conectados- Buscadores de MEV: Debido a que esto ocurre en varios bloques para cada rollup, no hay un nuevo potencial de MEV- Rollups: Los rollups tendrán que optar por usar un contrato de puente compartido y probablemente agregar precompilados para manejar mensajes entre rollupsPunto clave importante: El acuerdo compartido permite transferencias de activos no envueltos externamente y mensajería arbitraria a través de todos los rollups que comparten el contrato puente y la capa de agregación de pruebas, pero seguirá habiendo latencias no despreciables (aunque mucho más cortas que en L1 Async) y no se puede crear paquetes atómicos entre rollups.

4. Ejecución Atómica## Infraestructura requerida:Secuenciadores compartidos // Súper constructores

La ejecución atómica nos permite garantizar la ejecución exitosa de paquetes de transferencia entre rollups, pero como veremos, el número de casos de uso para paquetes de transferencia entre rollups que no tienen transacciones dependientes es menor de lo que uno podría esperar inicialmente.

Si una sola transacción en un paquete de transacciones dependientes revierte, entonces todas las demás transacciones se vuelven inválidas y también deben revertir, como es el caso de quemar y acuñar tokens a través de rollups. Acuñar tokens en un rollup de destino depende de que hayan sido quemados o bloqueados en el rollup de origen, por lo que podríamos decir que un paquete de transacciones de quemado y acuñado es un paquete de transacciones dependientes.

Crear este paquete es imposible sin un tercero como un superconstructor que pueda crear la transacción de destino.

Considera qué tendría que ser verdad para que los paquetes de intercambio entre rollups se construyan sin otra parte más allá del usuario. Se tendría que crear un paquete para bloquear/quemar el activo en el rollup de origen y acuñar el activo en el rollup de destino, pero nos encontramos con problemas:

• Los contratos en el rollup de origen solo pueden emitir un mensaje al bloquear/quemar el activo de origen original, no pueden llamar y crear una transacción en el rollup de destino. → Por eso existen protocolos de mensajes y redes de retransmisión. → El mensaje se puede utilizar para estructurar lo que debería ser la llamada en el destino, pero en realidad no puede crear la transacción en sí.- Creación de la segunda transacción en el paquete acumulativo de destino para acuñar: El usuario mismo no puede crear esta tx porque no tiene derechos de acuñación para el token en rollup B → Es decir, la cadena de destino necesita una prueba de que los tokens han sido quemados/bloqueados en la cadena de origen, pero esta prueba no está disponible hasta después de que la transacción inicial se haya ejecutado, lo que rompería nuestro requisito de atomicidad. → Cualquier otra parte que teóricamente podría crear la segunda transacción con derechos de acuñación podría crear una transacción de “acuñación” en la cadena de destino en cualquier momento sin haber creado primero una “quema” o bloqueo en la fuente, lo cual es una gran vulnerabilidad.Podemos ver que, aunque podríamos garantizar la ejecución de paquetes de transferencia inter-rollup, nos encontramos con dificultades en cómo podríamos construirlos en primer lugar para transferir activos de valor.

Sin embargo, todavía hay algunos casos de uso para la ejecución atómica sin paquetes cruzados de rollup dependientes. Uno de ellos es el arbitraje cruzado de rollup:

Arbitraje DEX de Cross-Rollup con Ejecución Atómica

Debido a que no hay dependencias estrictas entre estas transacciones, cualquiera puede crear este paquete atómico y enviarlo a un secuenciador compartido que garantizará una ejecución atómica.

Sin embargo, para tener garantías de ejecución atómica en primer lugar, los rollups deben optar por un secuenciador compartido y un superconstructor que ejecutaría nodos completos de todos los rollups conectados, por lo que el paso de la ejecución atómica a la composabilidad a nivel de bloque es bastante pequeño y todas las soluciones de secuenciación compartida harán esto. El único cambio requerido es que el constructor de bloques u otra tercera parte debe poder crear transacciones en nombre del usuario para completar paquetes dependientes entre rollups.

Es poco probable que se construya una infraestructura que solo permita la ejecución atómica sin ir un paso más allá para tener composabilidad. La ganancia relativa de saltar a la composabilidad a nivel de bloque completo supera con creces la dificultad de lograrlo dada la infraestructura que ya tiene la ejecución atómica.

Implicaciones para las partes interesadas:- Usuarios:

Probablemente no haya cambios, aunque es posible que soluciones de terceros como intenciones puedan ser atómicas, pero específicamente no está claro- Desarrolladores: Probablemente sin cambios- Buscadores de MEV: El arbitraje entre rollups cruzados es mucho más seguro dada la ejecución atómica- Rollups: Los Rollups deben optar por utilizar un secuenciador compartido/superconstructores que envíen bloques con transacciones de cada Rollup que desee interoperar, lo que puede cambiar la estructura de ingresos del Rollup. Aún no está claro cómo cambiará.- Los mercados de secuenciación pueden aumentar los ingresos de los rollups al permitir que el espacio ToB sea comprado por constructores sofisticadosMensaje importante: Si bien los paquetes cruzados de rollup están garantizados para ejecutarse de manera atómica, no está claro cómo se construirán estos paquetes si no hay un superconstructor que cree parte del paquete, por lo que es poco probable que la ejecución atómica por sí sola afecte a la interoperabilidad. Los secuenciadores/superconstructores compartidos deberían construir por defecto para la composabilidad a nivel de bloque.

5. Composabilidad a nivel de bloque## Infraestructura requerida:Secuenciador compartido // Superconstructor // Capa de agregación de pruebas* Contrato de puente compartido*

(* = opcional)

En gran parte del discurso en torno a secuenciadores compartidos y capas de liquidación compartidas, el término que se usa con frecuencia para describir este nivel de interoperabilidad es "composabilidad sincrónica".

Hemos modificado ligeramente este término para ser más descriptivo. Actualizar la nomenclatura a Composabilidad a Nivel de Bloque implica que es posible componer entre dos rollups en un paquete de transacciones entre rollups que se incluirán y ejecutarán con éxito en el siguiente bloque. La composabilidad sincrónica podría confundirse con la composabilidad a nivel de transacción, que exploramos en la siguiente sección. Es importante señalar que esto requiere una parte intermedia (la infraestructura de secuenciación compartida) que puede ser el conductor y creador de paquetes de transacciones dependientes.

En este nivel, comenzamos a ver una verdadera composabilidad entre rollups más allá de simplemente enviar a uno mismo para participar en una dapp en otro rollup.

Con la adición de un secuenciador compartido que puede crear transacciones, ahora podemos crear paquetes de paquetes acumulativos cruzados que los desarrolladores pueden aprovechar mediante programación.

Hay dos casos a considerar:

• Composabilidad a nivel de bloque- Composición a nivel de bloque + capa de liquidación compartidaEn ambos casos, podemos crear paquetes cruzados de rollup para actividades más complejas, pero en el segundo caso con liquidación compartida podemos usar activos nativos, lo que podría tener mejores implicaciones de precios para la actividad DEX cruzada de rollup, por ejemplo.

Con la composabilidad a nivel de bloque, tenemos tanto las ventajas de la ejecución atómica con la capacidad adicional de crear paquetes de transacciones dependientes. Examinemos nuestros dos ejemplos ilustrativos.

Transferencia del mismo token a través de xERC-20 (sin liquidación compartida):

• El usuario tiene ERC-20- El usuario crea tx a través de dapp: → Deposite ERC-20 en la caja de seguridad xERC-20 para recibir la versión envuelta xERC-20 → Quemar xERC-20 → Emitir un mensaje que signifique a la infraestructura de secuenciación compartida que se ha iniciado una transferencia entre rollups junto con datos relevantes para facilitar el intercambio- Superconstructor recoge la transacción y crea un paquete de intercambio entre rollups → Tx 1: La transacción de envoltura y quemado mencionada anteriormente → Tx 2: Acuñar xERC-20 en rollup B- Superbuilder presenta este cross-rollup al secuenciador compartido → Debido a que el súper constructor está ejecutando un nodo completo de los dos rollups conectados, simulan las transacciones para garantizar la ejecución exitosa del paquete. Si alguna de las transacciones se revirtiera, todo el paquete se revertiría.- El secuenciador compartido envía el bloque que contiene ambas transacciones a la capa DA y a los nodos que ejecutan el cambio de estado- xERC-20 se acuña para el usuario en Rollup BCon una capa de liquidación compartida, el flujo se simplifica aún más porque no sería necesario envolver primero el ERC-20 como un xERC-20 para intercambiar.

Ahora examinemos la orden límite de cruce de rollup para comprar un ERC-20 en Rollup B con un ERC-20 inicial (diferente) de Rollup A y hacer que el ERC-20 resultante se envíe de vuelta a Rollup A. En este caso, no asumimos que tenemos una capa de liquidación compartida, aunque un flujo similar existe en el caso con una. La única diferencia es que no tenemos que envolver los activos externamente adicionalmente.

Aquí están las transacciones requeridas en este caso:

• Envolver y quemar ERC-20 en A- Mint xERC-20 en B- Intercambiar xERC-20 inicial con ERC-20 objetivo en B- Envuelva y queme el objetivo ERC-20 en B- Mint xERC-20 en AAquí hay un flujo potencial de cómo esto podría funcionar:

Orden límite de intercambio en cruz en un entorno componible a nivel de bloque

Flujo:

• El usuario inicia la primera transacción: → Envuelva y Queme xERC-20 con mensaje emitido para especificar los parámetros de intercambio (cadena de destino, dirección de DEX, ERC-20 para intercambiar, precio de orden límite, booleano para enviar de vuelta o no)- Superbuilder ve la transacción y crea el paquete: → Tx 1: El usuario crea la tx descrita anteriormente → Tx 2: Crear xERC-20 en destino (el superconstructor debe tener privilegios de creación) → Tx 3: Orden limitada utilizando datos de tx 1 → Tx 4: Envolver y Quemar ERC-20 en B asumiendo el cumplimiento total de la orden límite con mensaje para acuñar en la cadena de origen → Tx 5: Crear xERC-20 objetivo a partir de la salida del intercambio en la cadena fuentePorque el superconstructor crea el bloque y ordena las transacciones, puede simular cada transacción y omitir el paquete si alguna de las transacciones se revierte. Por ejemplo, si se descubre que el usuario no recibiría un cumplimiento completo en su orden límite, el paquete se omitiría antes de que se ejecute el bloque.

En este caso de infraestructura de secuenciación compartida sin una capa de liquidación compartida, se necesitaría utilizar una versión envuelta externamente de Eth y xERC-20, lo que podría resultar en peores condiciones del mercado en el DEX debido a piscinas de liquidez más delgadas para activos envueltos. En este caso, un usuario podría tener que usar un límite más suave con más deslizamiento tolerado y podría recibir precios subóptimos. Una excepción a esto es si USDC está involucrado. Es posible que un secuenciador compartido sin liquidación compartida pueda trabajar con Circle para obtener derechos exclusivos sobre los contratos de USDC en todos los rollups para facilitar transferencias y swaps nativos de USDC entre rollups.

Con una capa de liquidación compartida, este envoltorio externo no es necesario y probablemente ofrecería mejores precios debido a piscinas de liquidez más profundas para intercambios de activos nativos, pero el flujo es esencialmente el mismo.

Optimista Secuenciador Sin confianzaLos rollups necesitarían confiar optimistamente en el secuenciador/superconstructor compartido para crear paquetes válidos de cross-rollup. Esto se debe principalmente al hecho de que este paquete de cross-rollup contiene transacciones dependientes que los rollups individuales no pueden verificar hasta después de que el bloque se agregue a la cadena de cada rollup y se agregue a una capa de liquidación en L1. Un ejemplo es la quema inicial y la acuñación de Eth desde la fuente hasta el destino. Es crucial que Eth se queme realmente en la cadena de origen antes de ser acuñada en la cadena de destino, o de lo contrario las dobles transacciones son posibles.

Sin embargo, para que este paquete completo se ejecute en un solo bloque, todas las transacciones deben estar presentes en ese bloque, incluso si la transacción representa un estado que es inválido antes del bloque en sí (como tener Eth en la cadena de destino para el intercambio si el usuario no tiene ninguno antes del bloque). Por esa razón, debemos confiar en el secuenciador de que realmente ha incluido las dependencias válidas en el paquete de interconexión entre rollups. Uno podría presentar pruebas después del hecho para demostrar la validez de cada transacción.

Esto es ligeramente menos importante al usar activos envueltos, sin embargo, porque no tienen impacto en la liquidez nativa almacenada en el L1, pero aún deben estar en su lugar mecanismos de respaldo para contrarrestar el riesgo de un secuenciador malintencionado o un error en el código que permitió que un paquete de transacciones se ejecutara con una transacción dependiente que fue revertida.

Implicaciones para las partes interesadas:- Usuarios

Actualizaciones masivas en la experiencia de usuario que permiten órdenes límite entre rollups en un solo bloque- Desarrolladores Necesitaría ser consciente de la interoperabilidad entre rollups para la actividad de interoperabilidad entre rollups, probablemente aprovechando precompilaciones personalizadas. En lugar de solo transacciones, los desarrolladores tienen que pensar en términos de paquetes, pero es probable que los superconstructores y la infraestructura de rollup personalizada puedan abstraer la mayor parte de la complejidad del desarrollador.- Buscadores de MEV Los buscadores de MEV tienen una oportunidad esencialmente equivalente para utilizar estrategias L1 en paquetes cruzados de rollup, pero depende de cómo se implementa PBS (Separación de Proposer-Builder). Los paquetes de rollup cruzado se consideran esencialmente como una sola transacción, por lo que el MEV podría ser encontrado mediante la anticipación o el sandwiching de estos paquetes siempre y cuando no muevan los precios fuera de los montos de deslizamiento tolerados (porque entonces todo el paquete se revertiría y los intentos de MEV fallarían)- Rollups Necesitaría optar por la infraestructura de secuenciación compartida (incluidos los superconstructores) y permitir el acceso a la quema/acuñación de Eth al secuenciador compartido en caso de una capa de liquidación compartida. → Podría internalizar el MEV vendiendo espacio de bloque a los constructores## 6. Composabilidad a nivel de transacción## Infraestructura requerida:Cambios a nivel de VM // Liquidación compartida // Superconstructores

La composabilidad a nivel de transacción se refiere al mismo nivel de funcionalidad que comparten los contratos inteligentes en una cadena EVM. En este caso, una sola transacción podría actualizar el estado en múltiples rollups simultáneamente, y asegurar que cualquier cambio de estado antes de cualquier llamada pueda ser revertido si la llamada no devuelve con éxito. De hecho, un paquete atómico de transacciones en un entorno componible a nivel de bloque se puede realizar dentro de una sola transacción cruzada de rollup y de VM. Esto requiere cambios a nivel de VM para todos los rollups conectados, además de una capa de liquidación compartida y un superconstructor.

Describimos aquí a un nivel alto un mecanismo posible. (Esta construcción se debe al equipo de Espresso según nuestro conocimiento). Primero, un usuario envía una transacción de cross-rollup a todos los rollups cuyo estado es cambiado por la transacción o a un superbuilder que puede construir bloques a través de todos los rollups involucrados. Un superbuilder simula la transacción y forma listas de pares de entrada-salida, una para cada rollup involucrado, que especifican los mensajes de cross-rollup necesarios y esperados dentro de la transacción. (Cabe destacar que el superbuilder solo puede hacerlo si tiene derechos de secuenciación seguros en todos los rollups involucrados por un período de tiempo). Luego, el superbuilder envía el bloque simulado al proponente de cada rollup, junto con las listas de pares de entrada-salida esperados para cada transacción de cross-rollup. Durante la ejecución, cada rollup ejecuta su propia función de transición de estado como de costumbre, asumiendo que las entradas de la lista de transacciones de cross-rollup son correctas. Durante el proceso de liquidación, las listas de entrada-salida pueden ser comparadas entre sí y demostradas seguras durante la fase de agregación de pruebas en la capa de liquidación compartida. Específicamente, si alguna entrada esperada para una transacción de cross-rollup no coincide con lo que otro rollup ha especificado como salida, el proceso de liquidación rechazará toda la transacción de cross-rollup.

Aunque hay una funcionalidad limitada desbloqueada con la composabilidad a nivel de transacción más allá de los préstamos instantáneos, la experiencia del desarrollador para crear aplicaciones cruzadas de rollup puede mejorar significativamente. La capacidad de crear dapps que interactúen con todas las cadenas conectadas sin necesidad de razonar sobre los paquetes cruzados de rollup facilitará mucho la innovación en un entorno multi-rollup. Además, es posible que surjan nuevos casos de uso y comportamientos como resultado.

Hay muchas preguntas de diseño abiertas para la composabilidad a nivel de transacción. Por ejemplo, cómo los desarrolladores pueden optar por participar o no en las llamadas entre rollups para las necesidades de sus contratos inteligentes debe considerarse cuidadosamente. Permitir la composabilidad arbitraria sin restricciones significa que retrocedemos a un rollup monolítico. Creemos que la respuesta aquí es que los desarrolladores indiquen explícitamente dónde es necesaria la composabilidad entre rollups en sus contratos, por ejemplo, a través de un modificador de Solidity como componibleque marca ciertos puntos de entrada del contrato como invocables cross rollup.

Implicaciones para las partes interesadas- Usuarios:

Mismas implicaciones que la composabilidad a nivel de bloque con capacidades avanzadas adicionales como flashloans
→ UX es virtualmente idéntica a usar una cadena para dapps que optan por participar- Desarrolladores: La experiencia del desarrollador mejora enormemente a medida que los desarrolladores de dapp pueden llamar nativamente a contratos entre rollups y utilizar salidas de estas llamadas como llamadas individuales de rollup → La infraestructura de Superbuilder/Sequencer todavía tendrá que colocar la transacción en bloques para los rollups que afecta la llamada entre rollups, pero no tendrá que construir los mismos paquetes que en el caso de la composabilidad a nivel de bloque.- Buscadores de MEV: Alto potencial de MEV ya que los paquetes cruzados de rollup ahora son esencialmente equivalentes a transacciones individuales en una cadena- Rollups: Requeriría cambios a nivel de VM, así como optar por un secuenciador compartido y una capa de liquidación compartida \ → Supuestos de confianza adicionales implicados en tener que confiar en las entradas y salidas de otros rollups antes de poder verificar el estado a través de pruebas, pero los mecanismos de reducción podrían disminuir la carga de confianza## Resumen y Mapa del EcosistemaDespués de caminar a través de los detalles técnicos de cada nivel de interoperabilidad definido aquí, podemos resumir:

• El Acuerdo Compartido permite intercambios cruzados entre rollups sin envolver activos externamente y crea vías de mensajería en el protocolo entre todos los rollups conectados- La secuenciación compartida/Superbuilders permite garantizar la ejecución del siguiente bloque en paquetes de paquetes de acumulación cruzada- La Composabilidad a Nivel de Bloque permite la creación de paquetes complejos, rápidos y dependientes entre rollups cruzados, logrando un ecosistema componible a nivel de contrato inteligente casi igual a contrato inteligente a contrato inteligente. Con la adición de liquidación compartida, estos paquetes de interconexión de rollup pueden crearse sin utilizar activos envueltos externamente- La Composabilidad a Nivel de Transacción es posible, y aunque los nuevos casos de uso abiertos pueden ser para usuarios más sofisticados, tiene el potencial de mejorar masivamente la experiencia de desarrollo entre rollups.En el momento actual, hay muchos proyectos emergentes para crear estos ecosistemas nativamente interoperables. Aquí hay una visión general a alto nivel del panorama:

Mapa del Ecosistema

Mapa del ecosistema

Pensamientos finalesTodavía hay preguntas abiertas sobre los matices técnicos dentro de los marcos establecidos en este artículo. Por ejemplo, la construcción de paquetes en un ecosistema componible a nivel de bloque para órdenes límite cruzadas entre rollups puede tener diseños más detallados para manejar el caso de cumplimiento parcial y tolerancia al deslizamiento para órdenes de mercado. Aquí ofrecimos una solución potencial para revertir un paquete de órdenes límite cruzadas entre rollups si la orden no se llena por completo, pero el espacio de diseño está abierto.

Además, vale la pena relacionar esto con la actual atención creciente en el espacio sobre las appchains. Las appchains son L2 de cola larga que son generalizadas o con permiso con el objetivo de aislar protocolos específicos relacionados en un L2. Es probable que cuando alcancemos la composabilidad a nivel de bloque, también comencemos a ver que los entornos de appchain ganen una tracción significativa como resultado de tener composabilidad nativa entre todas las redes conectadas.

En este momento, todavía es difícil impulsar la liquidez a estas appchains, pero una vez que una cadena más grande se conecta como una rampa de acceso al entorno interoperable, es probable que veamos ecosistemas de jardines amurallados en torno a la infraestructura compartida.

Otra pregunta abierta importante es cómo se resolverá el espacio de diseño alrededor de los superconstructores. El desarrollo en este frente todavía está bastante incipiente y aún no está claro cuál será la forma más eficiente y efectiva de crear una red de constructores sofisticados que puedan crear paquetes inter-rollup. Dónde se incluirán de forma óptima estos paquetes inter-rollup en un bloque, y el impacto en los ingresos de rollup es una pregunta abierta con diferentes estrategias que están siendo exploradas por muchos equipos.

En última instancia, es probable que el futuro involucre una combinación de soluciones de puente in-protocolo y fuera de protocolo y trabajarán en conjunto para proporcionar un proceso de interoperabilidad mucho mejor para todos. Creemos que la progresión definida en este artículo puede servir como guía para desarrolladores y constructores por igual que se centran en hacer que la interoperabilidad entre rollups sea más fluida para los usuarios finales.

También es probable que haya paradigmas completamente nuevos para la interacción entre rollups que aún no se han descubierto. Si eres un constructor que trabaja en enfoques que amplían los temas aquí o no están cubiertos arriba, por favor contactar(los mensajes directos están abiertos). La tecnología finalmente ha madurado lo suficiente como para ejercer una verdadera presión en la búsqueda de soluciones para la fragmentación de liquidez/ecosistemas, y siempre estamos buscando conectarnos con fundadores que estén tomando riesgos para construir soluciones creativas.

ReconocimientosEste artículo surgió de una mesa redonda de interoperabilidad de rollup increíblemente perspicaz organizada por 1kx en EthCC. Un agradecimiento especial va aNoah Pravecek, Ellie Davidson, y Terrypara leer las primeras versiones de este artículo y proporcionar comentarios, así como aMarti, mteamyBo Dupara más conversaciones sobre el tema.

Descargo de responsabilidad:- Este artículo es reimpreso de [[espejo](https://mirror.xyz/1kx.eth/pGddypDmRnIRwPjXHTpynVLpC2suidgl48ziwgT7To4], Reenviar el Título Original 'Interoperabilidad sin confianza entre Rollups: Panorama, Construcciones y Desafíos', Todos los derechos de autor pertenecen al autor original [Marshall Vyletel Jr.]. Si hay objeciones a esta reimpresión, por favor contacta al[Gate Learn](https://www.Gate.com/questionnaire/3967equipo y ellos lo manejarán rápidamente.

• Descargo de responsabilidad por responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.

• Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.