Interoperabilidad sin confianza entre rollups: visión general, construcción y desafíos

Autor: Marshall Vyletel Jr. Fuente: *1kx Traducción: Shanooba, Golden Finance

Introducción

La cantidad de rollups en la red Ethereum ha experimentado un crecimiento explosivo. Según los datos de L2Beat, actualmente hay 91 L2 y L3 en funcionamiento, y otros 82 están por ser lanzados. Por lo tanto, también existe una gran fragmentación en términos de liquidez, experiencia de usuario y herramientas de desarrollo. Las soluciones de interoperabilidad actuales aún necesitan mejoras, ya que dependen de una combinación de conectores de terceros, activos envueltos externos y marcos de intención, y cada solución tiene sus propios problemas.

2. Los activos empaquetados externamente no son populares, los datos muestran que la gente prefiere mantener los activos en su forma nativa siempre que sea posible (por ejemplo, según los datos de L2Beat, el valor de los activos puente es de 22 mil millones de dólares, mientras que el valor de los activos empaquetados externamente es de solo 3 mil millones de dólares).
3. El marco de intención depende de terceros, los cuales requieren una cantidad significativa de confianza y cobran tarifas adicionales para facilitar las actividades entre Rollups (por ejemplo, los usuarios de la cadena Degen perdieron más del 80% de sus Tokens debido a la falta de normas en el puente oficial). La centralización del marco de intención también implica una competencia reducida, lo que podría resultar en precios y rendimiento subóptimos.

En este artículo, exploramos las perspectivas de interoperabilidad sin confianza investigando las soluciones de interoperabilidad en seis niveles entre los ecosistemas de Rollup descentralizados, definiéndolos y discutiéndolos.

Comenzaremos desde la configuración predeterminada, que implica retirar asincrónicamente desde el rollup fuente hasta L1 y luego conectarse manualmente al rollup de destino, y terminaremos con una arquitectura hipotética de composabilidad entre rollups en una sola transacción. Discutiremos cómo la interoperabilidad en cada nivel afectará la experiencia del usuario, del desarrollador, el potencial de MEV y el rollup en sí (según los cambios en la infraestructura específicos).

Este artículo discute principalmente Ethereum y su L2, y solo la interoperabilidad sin confianza. En este caso, “interoperabilidad sin confianza” se refiere a canales dentro del protocolo que no requieren una infraestructura adicional necesaria que la mayoría de los rollups ya requieren para facilitar las transferencias.

Preparación

Definición

En última instancia, la interoperabilidad sin confianza requiere algunos recursos compartidos, a los que cualquier dos protocolos que deseen interoperar deben poder acceder. En el caso de la capa L1 de Ethereum, todos los contratos inteligentes existen en el mismo entorno de estado completo compartido de Ethereum, por lo que siempre tendrán el más alto nivel de interoperabilidad. Sin embargo, en L2, la interoperabilidad está muy limitada ya que solo comparten una capa de liquidación a través de contratos puente independientes.

Los componentes clave de la infraestructura compartida que nos impulsan a avanzar en la escalera de interoperabilidad sin confianza son el clasificador compartido, el superconstructor y el Asentamiento compartido. Las garantías y las nuevas funcionalidades abiertas por estas capas compartidas están relacionadas, pero fundamentalmente son ortogonales.

1. Compartir secuenciador/Superconstructor: principalmente mejorar la velocidad y la experiencia del usuario.
2. 共享 Asentamiento：无需外部包装和protocolo内消息传递的intercambio de activos。

En primer lugar, definiremos los seis niveles de interoperabilidad sin confianza mencionados en la introducción:

1. Asincronía L1: →通过汇总 Asentamiento的 L1 进行手动资产转移，实现互操作性。
2. Atom contains: → Asegúrese de que todas las transacciones en el paquete Cross Rollup estén incluidas en el siguiente bloque de cada Rollup involucrado en el paquete, o no estén incluidas.
3. Compartir Asentamiento: → Con el mismo contrato puente, varios rollup se conectan a L1.
4. Ejecución atómica: → Asegúrese de que todas las transacciones en el paquete combinado de Rollup cruzado se incluirán en el próximo Bloquear de cada Rollup involucrado en el paquete combinado y se ejecutarán con éxito; de lo contrario, no se ejecutará ninguna transacción. La ejecución exitosa es cuando cada transacción se ejecuta sin Retroceso y se refleja en el estado actualizado de cada Rollup en el paquete combinado.
5. Nivel de composabilidad a nivel de bloque: → El próximo Bloquear de Bundle de Rollup Cross puede garantizar que incluya transacciones dependientes (la tx B en Rollup B depende del resultado de la tx A en Rollup A)
6. Compatibilidad a nivel de transacción: El nivel de interoperabilidad de los contratos inteligentes solo requiere una transacción para causar simultáneamente cambios de estado entre múltiples rollups (sin enlace). Utilizar cualquier protocolo en cualquier rollup es lógicamente equivalente a utilizar diferentes contratos inteligentes en la misma cadena. Es importante que esto signifique que cualquier cambio de estado antes de cualquier llamada puede ser revertido al regresar.

Para comprender mejor cada nivel, presentaremos los siguientes casos de uso clave para mostrar las funciones de cada nivel y su impacto en los usuarios, desarrolladores, agrupadores y buscadores de MEV.

Ejemplo:

1. Transferencia de Token idéntico → Enviar a uno mismo: intercambiar Eth por Eth entre dos Rollups, o intercambiar ERC-20 por ERC-20
2. Compra de Token → Orden de límite de traspaso Rollup: compre Eth/ERC-20 en Rollup A, compre diferentes ERC-20 en el DEX de Rollup B y (opcional) envíelos de vuelta a Rollup A

Significado:

Todavía responderemos a las siguientes preguntas para comprender mejor el impacto en los accionistas clave en cualquier ecosistema de agregación.

1. Experiencia del usuario
   ¿Cómo cambiará la experiencia del usuario al lograr este nivel de interoperabilidad?
2. Experiencia del desarrollador
   ¿Cómo cambiará la experiencia de los desarrolladores al implementar este nivel de interoperabilidad?
3. Potencial de MEV Si logramos este nivel de interoperabilidad, ¿es posible que surjan nuevas oportunidades de MEV?
4. El impacto de Rollup ¿Es necesario seleccionar cualquier nueva infraestructura para lograr esto? ¿Cuáles son los cambios en la estructura de costos de Rollup? ¿Qué beneficios potenciales puede aportar la participación de Rollup en esta infraestructura?

Descripción avanzada

Seis etapas hacia la interoperabilidad sin confianza

1. L1 asíncrono

Infraestructura requerida:

No aplicable

Según la definición, esto se refiere al modo de interoperabilidad sin confianza predeterminado actual. Todos los rollup se definen de esta manera, ya que se construyen como capas de liquidación en L1 y solo se puede acceder a L1 a través del contrato puente, y publican actualizaciones de estado periódicamente para proteger la red.

En este caso, la única forma específica de llevar a cabo cualquier actividad de Rollup cruzado sin confianza es extraer los activos del Rollup fuente a través de un puente específico y depositarlos manualmente en el Rollup de destino una vez que estén disponibles en L1.

Para Optimistic Rollup, considerando la ventana de seguridad, la latencia de retiro es de aproximadamente 7 días. En ZK Rollup, la latencia de retiro no es muy segura, pero podría estar entre 15 minutos y un día completo, ZkSync es un ejemplo de esta situación.

Además, es posible realizar intercambios atómicos punto a punto utilizando contratos inteligentes, pero este es un caso de uso menor y no es escalable de manera eficiente.

Vale la pena mencionar las soluciones de terceros actuales:

1. Puente de liquidez
2. Marco de intención

Ambos de nuestros ejemplos requieren soluciones de terceros para ayudar.

Enviar a uno mismo:

1. Procedimiento estándar: → Extraer activos de Rollup A →Depósito manual Rollup B
2. Terceros: Puente de Liquidez / Red de Resolución de Problemas

Orden de límite de desplazamiento cruzado

1. Norma: → Extraer activos de Rollup A →手动存入 Rollup B Ejecutar orden de límite de precio →To return, the target ERC-20 must be externally wrapped
2. Terceros → El espacio emergente de soluciones para la consolidación de órdenes limitadas → Hay un diseño abierto que se centra en la intención de uso para promover esto

Debido a que esto es el caso por defecto, no hay necesidad de discutir los cambios en UX, DevEx, MEV y agregación.

2. Contenido atómico

Infraestructura requerida

Compartir serializador *

Los átomos garantizan que solo los paquetes de resumen cruzado se incluirán en el siguiente bloque.

Esto requiere un ordenador compartido, pero en teoría, si los ordenadores en dos rollups dados no alcanzan el máximo rendimiento, se puede implementar manualmente (solo es necesario enviar dos transacciones a cada rollup). Esto es por qué hemos agregado asteriscos en la infraestructura requerida.

Sin embargo, no asumimos que el ordenador compartido funcione como un nodo completo para cada rollup conectado, por lo que no se puede garantizar la ejecución exitosa de un conjunto de transacciones. En este caso, el ordenador compartido solo puede garantizar que el formato de la transacción sea correcto y se incluya en el siguiente bloque, pero no necesariamente puede ejecutarse con éxito.

Debido a la falta de ejecución garantizada, no es posible aprovechar de manera significativa la inclusión atómica en la programación sin correr el riesgo de que una transacción sea revertida. Por lo tanto, estamos efectivamente en la misma situación que la interoperabilidad L1 Async.

Considerar el lanzamiento de un intercambio de suma cruzada simple con garantía de inclusión atómica:

1. Intercambio de agrupación cruzada de Rollup → Tx 1: Bloqueo / destrucción de tokens en la Rollup de origen → Tx 2：将Token acuñar到目标 Rollup 上的用户 DIRECCIÓN

Podemos tener la garantía de que las transacciones atómicas, es decir, ambas transacciones están incluidas en el siguiente bloque consolidado, pero si la primera transacción falla y la segunda transacción no falla, los usuarios asignarán incorrectamente los fondos en on-chain objetivo sin necesidad de bloquearlos o quemarlos en on-chain fuente, nos enfrentaremos al problema de Doble gasto.

Cualquier solución de interoperabilidad, ya sea un puente de liquidez, un marco de intenciones o un intercambio xERC-20, es susceptible a este tipo de riesgo y no puede mitigarlo. Debido a este riesgo, las soluciones actuales requieren que la transacción se haya ejecutado con éxito y esté incluida en el Bloquear on-chain de origen antes de que se pueda utilizar un relé para transmitir el mensaje enviado y ejecutar una segunda transacción en el Bloquear on-chain de destino.

Importante: la inclusión de Atomic no tendrá un impacto significativo en el potencial de interoperabilidad.

3. 共享 Asentamiento

Infraestructura requerida:

Capa de agregación de prueba//Contrato de puente compartido

Aquí es donde las cosas empiezan a ponerse más interesantes. Gracias a la existencia del contrato de puente compartido, toda la Liquidez depositada desde L1 en el ecosistema rollup puede moverse libremente entre todos los rollup conectados. Antes de esto, no podíamos intercambiar entre rollup sin pasar por canales específicos, envolver activos externos o utilizar soluciones de terceros.

¿Por qué construir un contrato de puente compartido? Para entender por qué un contrato de puente compartido nos permite transferir activos a través de Rollup de manera confiable, primero consideremos qué sucedería si pudiéramos poseer Eth en Rollup A, destruirlo y luego acuñarlo nativamente en Rollup B sin necesidad de establecer un contrato de puente compartido en Layer1.

Vemos que cada rollup está fuera de sincronía con el contrato puente en Mainnet. El contrato puente del rollup B todavía tiene 50 ETH, por lo que los usuarios no pueden retirar 1 ETH a L1.

Para resolver este problema, hemos establecido un protocolo externo de emisión de activos, que recopila versiones empaquetadas externas de Token que representan las versiones nativas de otros lugares en la red.

Con la capa de liquidación compartida, la situación es diferente. Dado que toda la liquidez de cada rollup conectado está bloqueada en un solo contrato de puente, las personas pueden moverse libremente entre rollups, ya que el valor total en el contrato de puente se mantiene constante y siempre es accesible.

Es realmente necesario actualizar a nivel de contrato L1 para comprender dónde está la Liquidez, para permitir a los usuarios retirar de cualquier lugar, pero es simple ya que todos los agregados conectados pueden leer/escribir en el contrato compartido.

Utilizando una capa de liquidación compartida, el proceso puede parecer algo así para casos simples de envío a uno mismo.

Enviar a uno mismo:

1. Usuario crea transacción inicial: →Tx 1：Extraer Eth en rollup A (y acuñar en rollup B) Las operaciones se dividen y se envían al contrato L1 →它被聚合到交易根中，该交易根将所有共享 Asentamiento rollup 分组
2. Importar la raíz de esta transacción en Rollup B
3. El relé envía la transacción a la fábrica de acuñación y presenta la prueba de Merkle a rollup B
4. Rollup B utiliza Prueba de Merkle y raíz de transacción para verificar transacciones de destrucción
5. El usuario ha acuñado Eth en Rollup B
6. Rollup B向 L1提交证明

Podemos extender este proceso a cualquier ERC-20 que tenga un contrato en todas las liquidaciones dentro del ecosistema de Asentamiento compartido.

Podemos considerar el contrato de puente compartido como la capa de transferencia de mensajes internos entre todas las conexiones agregadas, por lo que en teoría este proceso podría expandirse a cualquier estándar de transferencia de mensajes arbitrario.

Esto nos acerca más a la composabilidad, pero debido a que solo se requiere agregar pruebas y transmitir mensajes después de que los cambios de estado se reflejen en L1, la latencia es alta (aunque claramente menor que en el caso asincrónico de L1). Además, cualquier actividad compleja de Rollup cruzado (como usar un DEX en Rollup B para realizar una orden de límite cruzado desde un activo en Rollup A) sigue siendo un proceso engorroso para los usuarios, ya que aún deben enviar a sí mismos y cambiar manualmente los activos en el Rollup objetivo. En este caso, no se pueden crear paquetes atómicos de Rollup cruzado.

Otro beneficio importante de Asentamiento compartido es que hay menos fricción para los Proveedores o solucionadores de Liquidez que ejecutan órdenes en varios entornos. Dado que su Liquidez en todos los Rollups conectados se refleja en un mismo contrato puente, no necesitan esperar una ventana completa de retiro para gestionar la Liquidez entre Rollups.

Impacto en las partes interesadas:

1. Usuario: Ahora es posible transferir activos en su forma nativa sin necesidad de un período de retiro L1
2. Desarrollador: Los cambios están limitados a los emisores de Token, ahora pueden utilizar la mensajería interna del protocolo para emitir versiones nativas de ERC-20 en todos los Rollup conectados
3. Buscador de MEV: Dado que esto sucede en varios bloques por rollup, no hay ningún nuevo potencial de MEV
4. Rollups： Los rollups deben seleccionar el uso del contrato de puente compartido y pueden agregar precompilación para manejar mensajes entre rollups.

Importante: El Asentamiento compartido permite la transferencia de activos no envueltos externamente y la transmisión de mensajes arbitrarios en todas las recopilaciones de puentes compartidos y de capas de agregación de pruebas, pero aún existe una latencia significativa (aunque mucho más corta que L1 Async) y no se pueden crear haces atómicos transversales a la recopilación.

4. Ejecución atómica

Infraestructura requerida:

Ordenador compartido // Súper constructor

La ejecución atómica nos permite garantizar la ejecución exitosa de paquetes de enlace cruzado, pero como veremos, la cantidad de casos de uso de paquetes de enlace cruzado sin dependencia de transacciones es menor de lo esperado inicialmente.

Si se revierte una transacción individual dentro de un conjunto de transacciones dependientes, todas las demás transacciones se volverán inválidas y también deberán revertirse, al igual que en el caso de destrucción y acuñación de Token en rollup cruzado. La acuñación de Token en el rollup de destino depende de si ya han sido destruidos o bloqueados en el rollup de origen, por lo que podríamos decir que un conjunto de transacciones de destrucción y acuñación son transacciones dependientes.

Si no hay un intermediario (por ejemplo, un superconstructor) que pueda crear la transacción objetivo, no se puede crear este paquete vinculado.

Al considerar la construcción de paquetes de intercambio cruzado entre Rollups sin la participación de otras partes que no sean los usuarios, debe cumplirse ciertas condiciones. Se debe crear un paquete para bloquear / grabar activos en el Rollup fuente y acuñar activos en el Rollup de destino, pero nos encontramos con un problema:

1. Los contratos en rollup de origen solo pueden enviar mensajes al bloquear / destruir activos de origen originales, no pueden invocar y crear transacciones en rollup de destino. → Esta es la razón por la que existe el protocolo de mensajes y la red Repetidor. → La información que se puede utilizar para construir la llamada en el objetivo debería ser correcta, pero en realidad no puede crear la transacción en sí misma.
2. En el rollup objetivo, crea una segunda transacción para acuñar: → Los usuarios no pueden crear esta transacción por sí mismos, ya que no tienen el derecho de acuñar tokens en el rollup B. → Es decir, la cadena de destino necesita una prueba de que el token ha sido quemado/bloqueado en la cadena de origen, pero esta prueba no estará disponible hasta que se ejecute la transacción inicial, lo que comprometerá nuestro requisito de atomicidad. → En teoría, cualquier otra cosa que pueda … Cualquiera de las partes que crea la segunda transacción con derecho de acuñar puede crear una transacción de “acuñar” en el objetivo on-chain en cualquier momento, sin necesidad de crear primero un “quemado” o bloqueo en el origen on-chain, lo cual es una gran vulnerabilidad.

Podemos ver que, aunque podemos garantizar la ejecución de los paquetes de consolidación cruzada, hemos tenido dificultades en cómo construirlos primero para transferir activos de valor.

Pero todavía hay algunos casos de uso de ejecución atómica que no dependen de los paquetes de cross-rollup. Uno de ellos es el arbitraje cross-rollup: 01928374656574839201

Dado que no hay una dependencia estricta entre estas transacciones, cualquier persona puede crear este paquete atómico y enviarlo a un secuenciador compartido que garantiza la ejecución atómica.

Sin embargo, para garantizar la ejecución atómica primero, rollup debe elegir un ordenador compartido y un superconstructor para ejecutar todos los rollup conectados como un Nodo completo, por lo que el paso de ejecución atómica a la composabilidad de nivel de Bloquear es muy pequeño, y todas las soluciones de ordenación compartida lo lograrán. El único cambio necesario es que el constructor de Bloquear u otro tercero debe poder crear transacciones en nombre de los usuarios para completar paquetes de rollup dependientes.

Es poco probable construir una infraestructura que permita solo ejecuciones atómicas sin lograr la composabilidad. Dado que la infraestructura ya tiene capacidades de ejecución atómica, los beneficios relativos de lograr una composabilidad completa a nivel de bloque superan con creces la dificultad de lograr este objetivo.

Impacto en las partes interesadas:

1. Usuario: Es posible que no haya cambios, aunque los terceros pueden proporcionar soluciones como la intención, aún no está claro cómo se implementará.
2. Desarrollador：
   Puede que no cambie
3. Buscador de MEV: Teniendo en cuenta la ejecución atómica, el arbitraje entre rollups es más seguro.
4. Rollup： Rollup debe optar por utilizar un ordenador compartido/superconstructor y presentar Bloquear que incluya transacciones de cada Rollup que se espera que sean interoperables, lo que podría cambiar la estructura de ingresos de Rollup. Aún no está claro cómo cambiará. El mercado de clasificación puede aumentar los ingresos de Rollup permitiendo a los constructores maduros comprar espacio ToB.

Importante: Aunque el paquete vinculado de rollup garantiza la ejecución atómica, no está claro cómo se construirán estos paquetes si no se crea un superconstructor para la parte de empaquetamiento, por lo que la ejecución atómica en sí misma es poco probable que afecte a la interoperabilidad. Por defecto, el secuenciador compartido/superconstructor debería construir la composabilidad a nivel de bloque.

5. Composabilidad a nivel de bloque

Infraestructura requerida:

Ordenador compartido // Super constructor // Capa de agregación de prueba* // Contrato de puente compartido*

（* = opcional）

En la mayoría de las discusiones sobre el compartimiento de secuenciadores y la capa de liquidación compartida, el término utilizado para describir este nivel de interoperabilidad es “combinabilidad sincronizada”.

Hemos modificado ligeramente este término para que sea más descriptivo. Actualizar el término a “Bloquear级可组合性” significa que los paquetes de transacciones que se pueden combinar entre dos rollups estarán incluidos y ejecutados con éxito en el próximo Bloquear. La composabilidad sincrónica puede ser confundida con la composabilidad a nivel de transacciones, discutiremos esto en la siguiente sección. Es importante tener en cuenta que esto requiere un intermediario (infraestructura de ordenación compartida), que puede actuar como ejecutor y creador dependiente de los paquetes de transacciones.

En este nivel, empezamos a ver la verdadera composabilidad entre los Rollup, no solo enviando a sí mismos para participar en otro dapp en Rollup.

Al agregar un serializador compartido que puede crear transacciones, ahora podemos crear paquetes de resúmenes cruzados que los desarrolladores pueden utilizar programáticamente.

Hay dos situaciones que deben tenerse en cuenta:

1. Composabilidad a nivel de bloque
2. Combinabilidad y compartición a nivel de bloque + Capa de liquidación

En ambos casos, podemos crear paquetes de consolidación cruzada para actividades más complejas, pero en el segundo caso, mediante el uso compartido de Asentamiento, podemos utilizar activos nativos, lo que puede tener un mejor impacto del precio en las actividades DEX de consolidación cruzada.

Con la granularidad de los bloques, tenemos la ventaja de la ejecución atómica y la capacidad adicional de crear paquetes de transacciones dependientes. Veamos dos ejemplos ilustrativos.

Transferir el mismo Token a través de xERC-20 (sin compartido Asentamiento):

1. El usuario posee ERC-20
2. Los usuarios crean tx a través de dapp: → Deposite ERC-20 en la caja fuerte xERC-20 para recibir la versión empaquetada de xERC-20. → Destrucción de xERC-20 Envíe un mensaje a la infraestructura de ordenación compartida indicando que se ha iniciado la transferencia entre rollups y adjunte los datos correspondientes para facilitar el intercambio.
3. Superbuilder recoge transacciones y crea paquetes cruzados de Rollup → Tx 1: transacciones de embalaje y eliminación mencionadas anteriormente → Tx 2：acuñar xERC-20 en Rollup B
4. Superbuilder presenta este rollup cruzado al ordenador compartido Debido a que Superbuilder está ejecutando un Nodo completo de dos rollup conectados, están simulando el comercio para garantizar que el paquete se ejecute correctamente. Si alguna transacción retrocede, todo el paquete se retrocederá.
5. El ordenador compartido enviará las transacciones de dos Bloquear a la capa DA y realizará cambios de estado en el Nodo
6. xERC-20 acuñando en Rollup B para usuarios

Con la capa de liquidación compartida, el proceso se simplifica aún más ya que no es necesario intercambiar primero ERC-20 por xERC-20.

Ahora echemos un vistazo a la orden limitada de Rollup cruzado, es decir, comprar ERC-20 en Rollup B con ERC-20 inicial (diferente) en Rollup A y enviar el ERC-20 generado de vuelta a Rollup A. En este caso, no asumimos que tenemos una capa de liquidación compartida, aunque existe un proceso similar cuando hay una capa de liquidación compartida. La única diferencia es que no es necesario envolver externamente los activos.

A continuación se presentan las transacciones requeridas en este caso:

1. Empaquetar y destruir ERC-20 en A
2. Mint xERC-20 en B
3. Intercambie el xERC-20 inicial por el ERC-20 objetivo en B.
4. En B, empaquetar y destruir el objetivo ERC-20
5. Mint xERC-20 en A

A continuación se muestra su posible flujo de trabajo:

Flujo:

1. El usuario realiza su primera transacción: → Empaquetar y destruir xERC-20, y enviar un mensaje con los parámetros de intercambio especificados (cadena de destino, DEX  DIRECCIÓN, ERC-20 a intercambiar, precio de la orden límite, valor booleano de devolución)
2. Los superconstructores ven la transacción y crean un paquete vinculado: → Tx 1: El usuario crea la transacción mencionada anteriormente → Tx 2: acuñando xERC-20 en el destino (el Superconstructor debe tener permisos de acuñado) → Tx 3: Utilizando los datos de tx 1 para realizar una orden limitada → Tx 4：En B, empaquetar y destruir ERC-20, asumiendo que la orden de límite de precio se ha completado completamente y enviar un mensaje en la cadena de origen para acuñar → Tx 5: Acuñando la meta xERC-20 desde la salida del intercambio en la cadena de origen

Dado que el súper constructor creará y ordenará transacciones en Bloquear, puede simular cada transacción y omitir el paquete de enlace en caso de que se cancele cualquier transacción. Por ejemplo, si se encuentra que el usuario no puede cumplir completamente su orden de límite de precio, se omitirá el paquete de enlace antes de ejecutar Bloquear.

En ausencia de una infraestructura de ordenación compartida Asentamiento, es necesario utilizar versiones empaquetadas externas de Eth y xERC-20, lo que podría llevar a un deterioro de las condiciones del mercado de DEX, ya que los pools de liquidez de activos empaquetados se volverían más delgados. En este caso, los usuarios podrían tener que aceptar restricciones más flexibles, una mayor tolerancia al Deslizamiento y posiblemente recibir precios subóptimos. Sin embargo, hay una excepción en el caso de USDC. Los ordenadores de clasificación compartida sin Asentamiento pueden colaborar con Circle para obtener derechos exclusivos sobre contratos USDC inter-rollup, facilitando la transferencia y el intercambio nativos de USDC entre rollups.

Con la capa de liquidación compartida, este envoltorio externo ya no es necesario, y debido a que la piscina de liquidez nativa de intercambio de activos es más profunda, es posible que ofrezca mejores precios, pero el proceso es básicamente el mismo.

Confíe en el secuenciador con optimismo

Rollup requires optimistic trust in shared sorters/superbuilders to create efficient cross-rollup bundles. This is mainly because the cross-rollup bundle contains dependent transactions that cannot be verified by individual rollups until the blocks are added to the on-chain of each rollup and aggregated to the settlement layer on L1. An example is the initial destruction and minting of Eth from source to destination. It is crucial that Eth is actually destroyed on the source on-chain before being minted on the target on-chain, otherwise double spending may occur.

Pero, para ejecutar este paquete completo de transacciones en un Bloquear, todas las transacciones deben existir en ese Bloquear, incluso si representan un estado inválido antes del propio Bloquear (por ejemplo, si un usuario no tiene Eth antes del Bloquear, pero tiene Eth en el destino de la transacción on-chain). Por lo tanto, debemos confiar en que el ordenador de transacciones realmente incluyó relaciones de dependencia válidas en el paquete de transacciones cruzadas. Se pueden presentar pruebas posteriormente para demostrar la validez de cada transacción.

Sin embargo, esto no es tan importante cuando se utilizan activos envueltos, ya que no afectan a la Liquidez nativa almacenada en L1, pero aún así debe haber un mecanismo de retroceso para contrarrestar el riesgo de ordenadores malintencionados o errores en el código que permiten la ejecución de paquetes de transacciones vinculadas junto con transacciones dependientes revertidas.

Impacto en las partes interesadas:

1. Usuario Se ha realizado una gran actualización de la experiencia del usuario, permitiendo órdenes limitadas de resumen cruzado en un solo Bloquear.
2. Desarrollador Es necesario tener conciencia de Rollup cruzado para las actividades cruzadas, y es posible que se necesite utilizar precompilaciones personalizadas. Los desarrolladores deben pensar desde la perspectiva del paquete, no solo de las transacciones, pero los superconstructores y la infraestructura personalizada de Rollup podrían eliminar la complejidad para la mayoría de los desarrolladores.
3. Buscador de MEV Los buscadores de MEV tienen oportunidades básicamente iguales para utilizar estrategias L1 en paquetes de consolidación cruzada, pero esto depende de la forma en que se implemente PBS (Proposer-Builder Separation). → Los paquetes de resumen de intercambio cruzado se consideran en esencia como una sola transacción, por lo que se pueden encontrar inversiones ventajistas o aprovechar estos paquetes de resumen para MEV, siempre y cuando no hagan que el precio supere la cantidad de deslizamiento aceptable (ya que esto haría que todo el paquete de resumen se recupere y el intento de MEV fallaría)
4. Rollups Necesita seleccionar unirse a la infraestructura de ordenación compartida (incluyendo Super Builder) y permitir el acceso a la destrucción/acuñación de Eth en la capa de liquidación compartida del ordenador compartido. → Se puede internalizar MEV vendiendo espacio Bloquear al constructor

6. Composabilidad a nivel de transacción

Infraestructura requerida:

VM nivel de cambio // Compartido Asentamiento // superconstructor

La composabilidad a nivel de transacción se refiere a la funcionalidad de nivel similar compartida por un contrato inteligente EVM on-chain. En este caso, una sola transacción puede actualizar simultáneamente el estado de múltiples rollups y garantizar la reversión de cualquier cambio de estado anterior si la llamada no se realiza con éxito. De hecho, los paquetes de transacciones atómicas en un entorno de composabilidad a nivel de bloque pueden completarse en una sola transacción que cruza rollups y VMs. Además de compartir capas de liquidación y constructores, esto también requiere cambios a nivel de VM para todos los rollups conectados.

Aquí describimos a alto nivel un posible mecanismo (que conocemos gracias al equipo de Espresso). En primer lugar, los usuarios envían simulación de comercio a los constructores de bloques superiores que pueden construir Bloquear en todos los rollup relacionados o en los rollup cuyo estado se modifique por la transacción. Los constructores de bloques superiores forman una lista de pares de entradas y salidas para cada rollup relacionado, que especifica los mensajes necesarios y esperados de cruce de rollup en la transacción (ten en cuenta que los constructores de bloques superiores solo pueden hacer esto si tienen un orden seguro sobre todos los rollup relacionados durante un cierto período de tiempo). Luego, los constructores de bloques superiores envían el Bloquear simulado junto con la lista de pares de entradas y salidas esperadas de cada transacción de cruce de rollup a los proponentes de cada rollup. Durante la ejecución, cada rollup ejecuta normalmente su propia función de cambio de estado, asumiendo que las entradas de la lista de transacciones de cruce de rollup son correctas. Durante el asentamiento, las listas de entradas y salidas se pueden comparar y demostrar que son seguras en la fase de agregación de pruebas en la capa de asentamiento compartida. Específicamente, si alguna entrada esperada de la transacción de cruce de rollup no coincide con una salida especificada por otro rollup, el proceso de asentamiento rechazará toda la transacción de cruce de rollup.

Aunque las nuevas características que se pueden desbloquear en términos de composabilidad de transacciones son limitadas, aparte de los Flash Loans, la experiencia de los desarrolladores para crear aplicaciones cruzadas de Rollup puede mejorar significativamente. Ser capaz de crear dapps que interactúen con todas las cadenas conectadas sin tener que considerar paquetes de Rollup cruzados hará que sea mucho más fácil innovar en entornos de múltiples Rollup. Además, pueden surgir nuevos casos de uso y comportamientos.

En cuanto a la composabilidad a nivel de transacciones, existen muchos problemas de diseño no resueltos. En primer lugar, es necesario considerar cuidadosamente cómo los desarrolladores eligen unirse o salir de sus llamadas cruzadas de Contrato inteligente en Rollup. Permitir la composabilidad arbitraria sin restricciones significa que volvemos a un único Rollup. Creemos que la respuesta aquí es que los desarrolladores indiquen claramente en sus contratos qué partes necesitan composabilidad cruzada en Rollup, por ejemplo, marcando ciertos puntos de entrada del contrato como llamables a través de Rollup con modificadores de Solidity (como ‘componible’).

Impacto en las partes interesadas

1. Usuario: Tiene el mismo significado de composabilidad a nivel de bloques, y también cuenta con otras funciones avanzadas como Flash Loans → La UX y el uso de dapp de selección se parecen mucho a una cadena
2. Desarrolladores: Dado que los desarrolladores de dapp pueden llamar a los contratos localmente para la agregación cruzada y utilizar las salidas de estas llamadas (como llamadas de agregación individuales), por lo tanto, Los desarrolladores tienen una gran experiencia La infraestructura de Superbuilder/Sequencer de mejora todavía debe colocar las transacciones en bloques agregados afectados por llamadas cruzadas de agregación, pero no es necesario construir paquetes de agrupación idénticos como en la composibilidad a nivel de bloque.
3. Buscador de MEV: El paquete de enlace cruzado ahora es básicamente equivalente a una transacción única en la cadena, por lo que el potencial de MEV es muy alto
4. Rollups： Necesita cambios a nivel de Máquina virtual, así como seleccionar un clasificador compartido y una capa de liquidación compartida →Antes de poder verificar el estado mediante pruebas, es necesario confiar en las entradas y salidas de otros rollups, lo que implica supuestos de confianza adicionales, pero el mecanismo de reducción puede aliviar la carga de confianza

Resumen y diagrama del ecosistema

Después de comprender los detalles técnicos de cada nivel de interoperabilidad definido aquí, podemos resumirlo como sigue:

1. 共享 Asentamiento允许跨 rollup 交换而无需外部包装资产，并在所有连接的 rollup 之间创建protocolo内消息传递路径
2. Los Superbuilders de ordenación compartida permiten ofrecer garantía de ejecución Bloquear en paquetes cruzados de rollup siguientes
3. La composabilidad a nivel de bloque permite crear ecosistemas combinables casi a nivel de Contratos inteligentes, lo que permite la creación de paquetes de Rollup complejos, rápidos y dependientes entre sí. → Al agregar liquidaciones compartidas, puede crear estos paquetes vinculados transversalmente sin necesidad de utilizar activos de envoltura externos
4. La interoperabilidad a nivel de transacciones es posible, aunque los nuevos casos de uso pueden estar dirigidos a usuarios más avanzados, existe la posibilidad de mejorar enormemente la experiencia de desarrollo en la agregación transfronteriza.

Actualmente, hay muchos proyectos emergentes con el objetivo de crear sistemas ecológicos nativos interoperables. A continuación se presenta un resumen de alto nivel en este campo:

Mapa del ecosistema

Mapa del ecosistema

Conclusión

Existen todavía algunas cuestiones pendientes relacionadas con los detalles técnicos de los marcos mencionados en este artículo. Por ejemplo, puede ser necesario un diseño más detallado para construir paquetes de órdenes limitadas cruzadas en un ecosistema componible a nivel de bloque para manejar casos de tolerancia al deslizamiento para órdenes parcialmente cumplidas y de mercado. Aquí proporcionamos una solución potencial en la que se puede recuperar un paquete de órdenes limitadas cruzadas si no se ha completado por completo, pero el espacio de diseño está abierto.

Además, vale la pena mencionar que esto está relacionado con el creciente intercambio de ideas en el campo de AppChain. AppChain es un L2 de cola larga, ya sea general o con licencia, con el objetivo de aislar protocolos específicos en un L2. Cuando logremos la composabilidad a nivel de bloque, es muy probable que también empecemos a ver un atractivo significativo en el entorno de AppChain debido a la composabilidad nativa entre todas las redes interconectadas.

Actualmente, sigue siendo muy difícil introducir Liquidez en estas cadenas de aplicaciones, pero una vez que las cadenas más grandes se conecten como puerta de entrada a un entorno interoperable, es probable que veamos un ecosistema de jardines amurallados en torno a la infraestructura compartida.

Otra cuestión crucial pendiente es cómo se abordará el espacio de diseño alrededor de los superconstructores. Este desarrollo está aún en sus primeras etapas, y aún no está claro cómo crear de manera más efectiva una red de superconstructores compleja que pueda crear paquetes de consolidación cruzada. Estos paquetes de consolidación cruzada se incluirán de la mejor manera en Bloquear, y el impacto en los ingresos consolidados sigue siendo una cuestión pendiente, con muchos equipos explorando diferentes estrategias.

Finalmente, en el futuro, puede haber una combinación de soluciones de puente tanto internas como externas del protocolo, que trabajarán juntas para ofrecer un proceso de interoperabilidad mejorado para todos. Creemos que los avances definidos en este documento pueden servir como guía para desarrolladores y constructores que se centran en proporcionar una interoperabilidad más fluida para los usuarios finales a través de Rollup.