Interoperabilidad sin confianza entre rollups: descripción general, construcciones y desafíos

Autor: Marshall Vyletel Jr. Fuente:Traducción de 1KX: Shan Oppa, Visión de Bittain

introducir

El número de rollups en Ethereum ha visto un crecimiento explosivo.Según los datos de L2Beat, a partir de este artículo, se han lanzado 91 L2 y L3, y 82 están en movimiento.Por lo tanto, también hay mucha fragmentación en liquidez, experiencia del usuario y herramientas de desarrollador.Las soluciones de interoperabilidad actuales deben mejorarse porque dependen de una combinación de puentes de terceros, activos de empaque externos y marcos de intención, y cada solución tiene sus propios problemas.

1. Los puentes de liquidez son a menudo el objetivo de los ataques de piratas informáticos de criptomonedas más grandes (como el ataque de los piratas informáticos de Wormhole Hacker de $ 321 millones)

2. Los activos de envasado externos no son populares, y los datos muestran que las personas están más dispuestas a mantener activos en forma nativa siempre que sea posible (por ejemplo, de acuerdo con los datos de L2Beat, los activos del puente de especificaciones valen $ 22 mil millones, mientras que los activos de envasado externos valen solo un 30% .

3. El marco de la intención se basa en terceros que requieren cierta confianza que no puede ignorarse y cobrar tarifas adicionales para facilitar las actividades de rollo a fondo (por ejemplo, los usuarios de Degen Chain pierden más del 80% de sus tokens debido a irregularidades oficiales del puente).Un marco de intención centralizado también significa una competencia más baja, lo que puede conducir a precios y rendimiento deficientes.

En este artículo, investigamos la perspectiva de la interoperabilidad sin confianza definiendo y discutiendo seis niveles de soluciones de interoperabilidad entre los ecosistemas rollup descentralizados.

Comenzamos con el valor predeterminado, que es retirar asincrónicamente del rollup de origen a L1 y unir manualmente al acurrucado de destino, y terminar con la arquitectura de suposición de la composibilidad de rollup en una sola transacción.Exploraremos cómo cada nivel de interoperabilidad afectará la experiencia del usuario, la experiencia del desarrollador, el potencial MEV y el rollup en sí (específicamente relacionado con los cambios en la infraestructura).

Este artículo discute principalmente a Ethereum y su L2, y se centra solo en la interoperabilidad sin confianza.En este caso, la «interoperabilidad sin confianza» se refiere a los canales en el protocolo, que no requieren que un tercero facilite la transmisión fuera de la infraestructura necesaria que la mayoría de los rollups ya requieren.

Preparación

definición

Fundamentalmente, la interoperabilidad sin confianza requiere algunos recursos compartidos, y cualquier dos protocolos que deseen interoperar deben poder acceder a estos recursos.En el caso de Ethereum L1, todos los contratos inteligentes existen en el mismo entorno que comparte el estado completo de Ethereum, por lo que siempre tendrán el nivel más alto de interoperabilidad.Sin embargo, L2 comparte la capa de liquidación solo a través de un contrato de puente separado, por lo que la interoperabilidad es muy limitada.

Los componentes clave de infraestructura compartida que pueden llevarnos a la escalera de la interoperabilidad sin confianza son clasificadores compartidos, super constructores y facturación compartida.Las garantías y las nuevas características que están abiertas a estas capas compartidas están relacionadas, pero son esencialmente ortogonales.

1. Serializer/Super Builder compartido: mejora principalmente la velocidad y la experiencia del usuario.

2. Liquidación compartida: no hay necesidad de envoltura externa y mensajes en el protocol.

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

1. L1 Asíncrono:
   → Transferencia manual de activos a través de la liquidación de resumen L1 para lograr la interoperabilidad.

2. Los átomos contienen:
   → Asegúrese de que todas las transacciones a través del paquete de rollo se incluyan en el siguiente bloque de cada rollup involucrado en ese paquete, o no se incluyan.

3. Liquidación compartida:
   → Se conectan múltiples rollups a L1 a través del mismo contrato de puente.

4. Ejecución atómica:
   → Asegúrese de que todas las transacciones a través del paquete de rollo se incluirán en el siguiente bloque de cada acurrucado involucrado en el paquete y ejecutado con éxito, de lo contrario no se ejecutarán transacciones.La ejecución exitosa significa que cada transacción se ejecuta sin retroceso y se refleja en el estado actualizado de cada rollup en el paquete.

5. Composibilidad a nivel de bloque:
   → El siguiente bloque a través del paquete de rollo garantiza que puede contener transacciones dependientes (TX B en el encierro B depende del resultado de TX A en Rollup A)

6. Composibilidad de nivel de transacción:
   → La interoperabilidad de nivel de contrato inteligente requiere solo una transacción para causar cambios en el estado entre múltiples rollups (sin agrupación).El uso de cualquier protocolo en cualquier acurrucado es lógicamente equivalente a usar un contrato inteligente diferente en una cadena.Es importante destacar que esto significa que cualquier cambio de estado antes de que la llamada se pueda restaurar al regreso.

Para obtener más información sobre cada nivel, cubriremos los siguientes casos de uso clave para demostrar las capacidades de cada nivel y su impacto en los usuarios, desarrolladores, agregados y buscadores MEV.

Ejemplo:

1. Transferencia de la misma token
   → Envíe a sí mismo: canjee a ETH a ETH entre dos rollups, o intercambie ERC-20 a ERC-20

2. Compra de tokens
   → Orden de límite de reacción cruzada: use ETH/ERC-20 en Rollup A para comprar un ERC-20 diferente de Dex en Rollup B y (opcionalmente) envíe de regreso a Rollup A

significado:

También responderemos las siguientes preguntas para comprender mejor el impacto en los accionistas clave en cualquier ecosistema agregado.

1. Experiencia de usuario
   ¿Cómo cambiará la experiencia del usuario al lograr este nivel de interoperabilidad?

2. Experiencia del desarrollador
   ¿Cómo cambiará el desarrollador la experiencia de la experiencia al lograr este nivel de interoperabilidad?

3. Potencial MEV
   Si logramos este nivel de interoperabilidad, ¿es posible tener nuevas oportunidades de MEV?

4. El impacto del acurrucado
   ¿Tiene que optar por cualquier infraestructura nueva para lograr esto?¿Qué cambios se han realizado en la estructura de tarifas de Rollup?¿Cuáles son los beneficios potenciales de la participación del rollup en esta infraestructura?

Descripción general avanzada

Seis etapas de interoperabilidad sin confianza

1. L1 Asíncrono

Infraestructura requerida:

no aplicable

Por definición, esto se refiere al modo de interoperabilidad de confianza predeterminado actual.Todos los rollups se definen de esta manera porque se basan en L1 como capas de liquidación y solo se puede acceder mediante contratos de puente, y publiquen periódicamente actualizaciones de estado para proteger la red.

En este caso, la única forma canónica de realizar cualquier actividad de transmisión transversal sin confianza es extraer el activo del encierro de origen a través del puente canónico y depositarlo manualmente en el encierro objetivo una vez disponible en L1.

Para el encierro optimista, teniendo en cuenta la ventana a prueba de errores, el retraso de retiro es de aproximadamente 7 días.En el acurrucado de ZK, los retrasos de retiro no son bastante seguros, pero puede ser entre 15 minutos y un día completo, que es el caso con Zksync.

Además, también es posible usar contratos inteligentes para el intercambio atómico punto a punto, pero este es un caso de uso más pequeño y no se puede escalar de manera efectiva.

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

1. Puente de fluidez

2. Marco de intención

Ambos ejemplos requieren soluciones de terceros para ayudar.

Enviar a ti mismo:

1. Prácticas estandarizadas:
   → extraer activos del rollup a
   → Guardar manualmente el Rollup B

2. Tercero:
   → Red de liquidez puente / solucionador

Órdenes de límite a fondo

1. especificación:
   → extraer activos del rollup a
   → Guardar manualmente el Rollup B
   → Ejecutar órdenes de límite
   → Para devolver, el objetivo ERC-20 debe estar empaquetado externamente

2. Tercero
   → Espacio de solución emergente a través de órdenes límite agregadas
   → Hay diseños abiertos que promueven esto en torno a la intención de uso

Dado que este es el valor predeterminado, no hay necesidad de discutir cambios en UX, Devex, MEV y Resumen.

2. Atomic contiene

Infraestructura requerida

Serializador compartido *

La inclusión atómica solo se garantiza que el paquete de resumirización cruzada se incluirá en el próximo bloque.

Esto requiere un clasificador compartido, pero teóricamente, si los clasificadores en dos rollups dados no alcanzan el máximo rendimiento, se puede hacer manualmente (solo envíe dos transacciones a cada encierro por separado).Es por eso que agregamos asteriscos a la infraestructura requerida.

Sin embargo, no asumimos que el clasificador compartido ejecuta el nodo completo de cada encierro conectado, por lo que es imposible garantizar la ejecución exitosa de un conjunto de transacciones.En este caso, el clasificador compartido solo puede garantizar que la transacción esté formateada correctamente y se incluirá en el siguiente bloque, pero no puede ejecutarse con éxito.

Dado que no hay garantía de ejecución, es imposible explotar programáticamente la inclusión atómica de cualquier manera significativa sin incurrir en el riesgo de que una de las transacciones que se revocan.Por lo tanto, estamos esencialmente en la misma situación que la interoperabilidad de Async L1.

Considere comenzar un intercambio de suma cruzada simple con solo garantías de inclusión atómica:

1. Puntos de intercambio a través del acurrucado
   → TX 1: bloquear/destruir tokens en el encierro de la fuente
   → TX 2: Mint el token a la dirección del usuario en el encierro de destino

Es posible que tengamos garantías de inclusión atómica, es decir, ambas transacciones en realidad están incluidas en el siguiente bloque de cada resumen, pero si la primera transacción regresa y la segunda transacción no retrocede, el usuario será incorrecto en la cadena de destino, tendremos doble Problemas de pago mediante la asignación de fondos sin bloquearlos o quemarlos en la cadena fuente.

Cualquier solución de interoperabilidad, ya sea un puente de liquidez, marco de intención o intercambio XERC-20, es vulnerable a este riesgo y no puede mitigarlo.Debido a este riesgo, la solución actual requiere que el inicio de una transacción haya sido ejecutado con éxito e incluido en un bloque en la cadena de origen antes de que el relé pueda usarse para pasar el mensaje saliente y ejecutar una segunda transacción en la cadena de destino.

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

3. Liquidación compartida

Infraestructura requerida:

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

Aquí es donde las cosas comienzan a ser más interesantes.Debido a la existencia de un contrato de puente compartido, toda la liquidez depositada de L1 al ecosistema enrollable se puede mover libremente entre todos los rollups conectados.Hasta entonces, no podíamos intercambiar entre rollups sin pasar por canales estandarizados, activos de empaque externos o usar soluciones de terceros.

¿Por qué establecer un contrato de puente compartido?Para comprender por qué un contrato de puente compartido nos permite transferir los activos a través del acurrucado de una manera sin confianza, primero considere si puede tener ETH en el rollo A, destruirlo y luego en menta de forma nativa en el Rollup B sin construir en el contrato de puente compartido de Layer1, lo que sucede. .

Vemos que cada acurrucado está fuera de sincronización con el contrato de puente en la NETA MAIN.El contrato de puente Rollup B todavía tiene 50 ETR, por lo que el usuario no puede extraer 1 de sus ETH a L1.

Para resolver este problema, establecimos un protocolo de envasado de activos externos para emitir versiones de envasado externas de tokens en el resumen, que simboliza las versiones nativas en otras partes de la red.

Con una capa de asentamiento compartida, la situación es diferente.Dado que toda la liquidez de cada acurrucado conectado está bloqueada en el mismo contrato de puente, uno puede moverse libremente entre los rollups porque el valor total en el contrato del puente sigue siendo el mismo y siempre se puede extraer.

Debe actualizarse a nivel de contrato L1 para comprender dónde está la liquidez para permitir a los usuarios retirar dinero de cualquier lugar, pero esto es simple porque el resumen de todas las conexiones se puede leer/escribir en contratos compartidos.

Usando una capa de facturación compartida, el proceso puede parecer el siguiente para un simple envío a usted mismo.

Enviar a ti mismo:

1. El usuario crea una transacción inicial:
   → TX 1: Extraiga ETH en Rollup A (y fundido en Rollup B)
   → La transacción se envía en lotes y se envía al contrato L1
   → Se agrega en la raíz de transacción, que agrupa todos los rollups de asentamiento compartidos

2. Rollup B Importa esta raíz de transacción

3. El repetidor envía la transacción a la menta y envía el certificado de Merkle al rollup B

4. Rollup B utiliza la prueba de Merkle y la raíz de transacción para verificar la destrucción de las transacciones

5. ETH ETH EN ROLLUP B de los usuarios

6. Rollup B presenta pruebas a L1

Podemos extender este proceso a cualquier ERC-20 que tenga contratos en todos los agregados en el ecosistema de liquidación compartida.

Podemos pensar en un contrato de puente compartido como una capa de mensajería en el protocolo entre todas las agregaciones de conexión, por lo que, en teoría, este proceso en realidad puede extenderse a cualquier estándar de mensajería arbitraria.

Esto nos acerca más a la composibilidad, pero dado que la prueba de agregación y la entrega de mensajes se requieren solo después de que los cambios de estado se reflejen en L1, la latencia es alta (aunque significativamente menor que el caso asincrónico L1).Además, cualquier actividad compleja de rollo a través (como el uso de DEX en el rollup B para realizar órdenes de límite de rollo cruzado desde los activos en el rollo a) sigue siendo un proceso tedioso para los usuarios, ya que aún tienen que enviarse a sí mismos y al intercambiar activos manualmente en el acurrucado objetivo.En este caso, es imposible crear paquetes atómicos de rollo cruzado.

Otro beneficio importante de la liquidación compartida es que hay menos fricción para los proveedores de liquidez o solucionadores que ejecutan órdenes en múltiples entornos.Dado que su liquidez en todos los acurrucados conectados se refleja en el mismo contrato de puente, no tienen que esperar una ventana de retiro completo para administrar la liquidez de rollups.

Impacto en las partes interesadas:

1. usuario:
   Los activos ahora se pueden transferir en forma nativa sin la necesidad del período de retiro L1

2. Revelador:
   Los cambios se limitan a los emisores de token que ahora pueden emitir versiones nativas de ERC-20 en todos los rollups conectados utilizando mensajes en el protocolo

3. Mev Searcher:
   Dado que esto sucede en múltiples bloques por encierro, no existe un nuevo potencial MEV

4. Rollups:
   Los rollups deben optar por usar un contrato de puente compartido y pueden agregar precompilación para manejar los mensajes de rollo cruzado

IMPORTANTE: El asentamiento compartido permite un empaque no external de transferencias de activos y mensajes arbitrarios en todos los resúmenes de contratos de puentes compartidos y capas de agregación de prueba, pero todavía hay una latencia no negligible (aunque mucho más corta que L1 Async) y no se puede crear a través de Atomic vigas.

4. Ejecución atómica

Infraestructura requerida:

Clasificador compartido // Super Builder

La ejecución atómica nos permite garantizar la ejecución exitosa de los paquetes de volumen cruzado, pero como veremos, hay menos casos de uso para paquetes de volumen cruzado que no dependen de las transacciones de lo esperado originalmente.

Si se revoca alguna transacción única en un conjunto de transacciones de dependencia, entonces todas las demás transacciones se inválidas y también deben revocarse, como es el caso con la destrucción de tokens y la acuñación entre los rollups.Los tokens que acuñan los acumulaciones objetivo dependen de si han sido destruidos o bloqueados en los rollups de origen, por lo que podemos decir que un conjunto de transacciones de destrucción y acuñado son un conjunto de transacciones de dependencia.

Este paquete no es posible sin una parte intermedia (como Super Builder) que puede crear una transacción objetivo.

Considere qué condiciones deben cumplirse para una construcción en el paquete de intercambio de rollo sin la participación de otras partes que no sean usuarios.Se debe crear un paquete para bloquear/quemar activos en los activos de origen y menta en el encierro de destino, pero tenemos un problema:

1. Los contratos en los rollups de origen solo pueden enviar mensajes al bloquear/destruir los activos de origen originales, y no pueden llamar y crear transacciones en los acumulaciones de destino.
   → Esta es la razón por la cual existen el protocolo de mensajes y la red de retransmisión.
   → El mensaje se puede usar para construir cuál debería ser la llamada en el objetivo, pero en realidad no puede crear la transacción en sí.

2. Cree una segunda transacción en el acurrucado de destino a menta:
   → Los usuarios no pueden crear este TX ellos mismos porque no tienen los tokens correctos en el encierro B
   → es decir) la cadena objetivo debe demostrar que el token se ha quemado/bloqueado en la cadena de origen, pero esta prueba no está disponible hasta que se ejecute la transacción inicial, lo que destruirá nuestro requisito de atomicidad.→ En teoría, cualquier otro puede
   La parte que crea una segunda transacción con los derechos de lanzamiento puede crear una transacción de «reparto» en la cadena de destino en cualquier momento sin crear primero una «quemadura» o bloquear en la cadena fuente, que es una gran vulnerabilidad.

Podemos ver que a pesar de que podemos garantizar la ejecución de paquetes cruzados cruzados, tenemos dificultades para construirlos primero para transferir activos valiosos.

Sin embargo, todavía hay algunos casos de uso de ejecución atómica que no necesitan confiar en paquetes de rollo cruzado.Uno de ellos es el arbitraje de rollup:

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

Sin embargo, para obtener la garantía de ejecución atómica primero, el encierro debe seleccionar el clasificador compartido y el SuperBuilder para ejecutar el nodo completo de todos los rollups conectados, por lo que el paso de la ejecución atómica a la composición de nivel de bloque es muy pequeño, toda una clasificación compartida resuelve el plan hará esto.El único cambio requerido es que el constructor de bloques u otro tercero debe poder crear transacciones en nombre del usuario para completar el paquete de rollup de dependencia.

Es poco probable que construya una infraestructura que permita solo la ejecución atómica sin implementar más composibilidad.Dado que la infraestructura ya tiene capacidades de ejecución atómica, los beneficios relativos de lograr la composibilidad de nivel de bloque completo son mucho más difíciles que lograr este objetivo.

Impacto en las partes interesadas:

1. usuario:
   Es posible que no haya cambios, aunque terceros pueden ofrecer soluciones como Intent, no está claro cómo implementarlos

2. Revelador:
   Probablemente no cambie

3. Mev Searcher:
   El arbitraje de rollo cruzado es más seguro teniendo en cuenta la ejecución atómica

4. Rollup:
   El encierro debe optar por usar un clasificador/súper constructor compartido para enviar un bloque que contenga transacciones de cada encierro con el que desee interoperar, lo que puede cambiar la estructura de ingresos del rollup.No está claro cómo cambiará.-
   El mercado de la clasificación puede aumentar los ingresos del acurrucado al permitir que los constructores maduros compren espacio TOB

IMPORTANTE: Si bien los paquetes de rollo cruzado garantizan la ejecución atómica, no está claro cómo se construirán estos paquetes sin un súper constructor que cree las partes del paquete, por lo que es poco probable que la ejecución atómica en sí misma afecte la interoperabilidad.De manera predeterminada, el secuenciador/super constructor compartido debe construir composibilidad a nivel de bloque.

5. Composibilidad a nivel de bloque

Infraestructura requerida:

Clasificador compartido // Super Builder // Capa de agregación de prueba * // Contrato de puente compartido *

(* = opcional)

En la mayoría de la discusión sobre secuenciadores compartidos y capas de asentamiento compartidas, el término comúnmente utilizado para describir este nivel de interoperabilidad es «composibilidad sincrónica».

Modificamos el término ligeramente para hacerlo más descriptivo.Actualizar el término a «Composibilidad a nivel de bloque» significa que los paquetes de transacciones de rollo cruzada se pueden combinar entre dos rollups que se incluirán en el siguiente bloque y se ejecutarán con éxito.La composibilidad sincrónica puede confundirse con la composibilidad a nivel de transacción, que exploraremos en la siguiente sección.Es importante destacar que esto requiere una parte intermedia (infraestructura de clasificación compartida) que puede convertirse en el ejecutor y creador de confiar en los paquetes de transacciones.

En este nivel, comenzamos a ver una verdadera composibilidad entre los rollups, no solo enviándolo a usted mismo para participar en el DAPP en otro rollup.

Al agregar un secuenciador compartido que puede crear transacciones, ahora podemos hacer un paquete de resumen SPAN que los desarrolladores pueden aprovechar programáticamente.

Hay dos situaciones a considerar:

1. Composibilidad a nivel de bloque

2. Composibilidad a nivel de bloque + capa de asentamiento compartido

En ambos casos, podemos crear un paquete de resumen de SPAN para actividades más complejas, pero en el segundo caso podemos usar activos nativos a través de la facturación compartida, por ejemplo, esto puede dar como resultado una actividad de DEX resumida de un amplio impacto en el precio.

Con la composibilidad de nivel de bloque, tenemos las ventajas de la ejecución atómica y la capacidad adicional de crear paquetes de transacciones dependientes.Echemos un vistazo a nuestros dos ejemplos ilustrativos.

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

1. El usuario posee ERC-20

2. Los usuarios crean TX a través de DAPP:
   → Guardar ERC-20 en la caja de bloqueo XERC-20 para recibir la versión empaquetada XERC-20
   → destruir XERC-20
   → Enviar un mensaje a la infraestructura de clasificación compartida que indica que se ha iniciado una transmisión a través de la transmisión y se adjuntan datos relevantes para facilitar el intercambio

3. SuperBuilder recoge transacciones y crea paquetes de rollo cruzado
   → TX 1: Las transacciones de empaque y destrucción anteriores
   → TX 2: fundido XERC-20 en Rollup B

4. SuperBuilder envía este rollup cruzado al clasificador compartido
   → Dado que SuperBuilder ejecuta dos nodos completos conectados a los rollups, simulan transacciones para garantizar que el paquete se ejecute con éxito.Si se enrolla alguna transacción, todo el paquete se enrollará hacia atrás.

5. El clasificador compartido envía el bloque que contiene dos transacciones a la capa DA y el nodo que realiza los cambios de estado

6. XERC-20 ENCHIR A USUARIOS EN ROLLUP B

Con la capa de liquidación compartida, el proceso se simplifica aún más porque no es necesario empaquetar primero el ERC-20 como XERC-20 para el intercambio.

Ahora veamos las órdenes de límite de rollo cruzado, es decir, compre el ERC-20 con el ERC-20 inicial (diferente) en el rollo A en el rollup B y envíe el ERC-20 generado de regreso a Rollup A.En este caso, no asumimos que tenemos una capa de liquidación compartida, aunque existen procesos similares en el caso de una capa de liquidación compartida.La única diferencia es que no hay necesidad de un embalaje externo adicional de los activos.

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

1. Empacar y destruir ERC-20 en un

2. Menta XERC-20 en B

3. Intercambie el XERC-20 inicial con el objetivo ERC-20 en B

4. Empacar y destruir el objetivo ERC-20 en B

5. Menta XERC-20 en un

Aquí están sus posibles flujos de trabajo:

fluir:

1. El usuario inicia la primera transacción:
   → Empaque y destruya XERC-20 y envíe un mensaje para especificar los parámetros de intercambio (cadena de destino, dirección DEX, ERC-20 que se intercambiará, limita el precio del pedido, el valor booleano si se debe enviar)

2. Super Builder ve el trato y crea el paquete:
   → TX 1: el usuario crea la transacción anterior
   → TX 2: Cast XERC-20 en el destino (los super constructores deben tener permisos de lanzamiento)
   → TX 3: Use datos de TX 1 para realizar órdenes límite
   → TX 4: paquete y destruya ERC-20 en B, suponiendo que el orden límite se haya cumplido completamente y envíe un mensaje en la cadena de origen para la fundición
   → TX 5: Target de fundición XERC-20 desde la salida de intercambio en la cadena de origen

Dado que el Super Builder crea transacciones bloquea y clasifica, puede simular cada transacción y omite el paquete cuando se revoca cualquier transacción.Por ejemplo, si un usuario no puede cumplir completamente su orden de límite, el paquete se omite antes de ejecutar el bloque.

En ausencia de una infraestructura de clasificación compartida para la capa de liquidación compartida, se requieren versiones de envasado externo de ETH y XERC-20, lo que puede hacer que las condiciones del mercado de DEX empeoren a medida que el conjunto de liquidez de los activos de envasado se vuelve más delgada.En este caso, los usuarios pueden tener que usar restricciones más sueltas, mayor tolerancia al deslizamiento y pueden recibir precios subóptimos.Si el USDC está involucrado, hay una excepción.Un clasificador compartido sin facturación compartida puede funcionar con Circle para obtener derechos exclusivos a los contratos de USDC en los acurrucados para facilitar las transferencias e intercambios nativos del USDC en los rollups.

Con una capa de liquidación compartida, este empaque externo es innecesario, y dado que el conjunto de liquidez de los intercambios de activos nativos es más profundo, puede ofrecer mejores precios, pero el proceso es básicamente el mismo.

Confía optimistas en el secuenciador

El rollup requiere una confianza optimista en clasificadores/super constructores compartidos para crear paquetes eficientes de rollo a fondo.Esto se debe principalmente a que este paquete de rollo cruzado contiene transacciones dependientes que los rollups individuales no pueden verificar hasta que se agregan los bloques a cada cadena de rollo y se agregan a la capa de asentamiento en L1.Un ejemplo es la destrucción inicial y el lanzamiento de ETH desde el origen al destino.De manera crucial, ETH debe ser destruida en la cadena de origen antes de acuñar en la cadena objetivo, de lo contrario pueden ocurrir pagos dobles.

Sin embargo, para ejecutar este paquete completo en un bloque, todas las transacciones deben existir en ese bloque, incluso si la transacción representa un estado inválido antes del bloque en sí (por ejemplo, si el usuario no tiene alguna ETH antes del bloque, entonces hay ETH en la cadena objetivo del intercambio).Por lo tanto, debemos creer que el clasificador incluye dependencias válidas en el paquete de suma cruzada.Los certificados se pueden enviar luego para probar la validez de cada transacción.

Sin embargo, esto es menos importante cuando se usan activos empaquetados, ya que no tienen ningún efecto sobre la liquidez nativa almacenada en L1, pero aún debe haber un mecanismo de respaldo para compensar el riesgo de errores en clasificadores o código maliciosos, estos errores permiten el paquete de transacciones ser ejecutado junto con la transacción dependiente restaurada.

Impacto en las partes interesadas:

1. usuario
   Actualizaciones masivas a la experiencia del usuario, permitiendo pedidos límite cruzados en un solo bloque

2. Desarrolladores
   Debe tener una conciencia de rollup sobre las actividades de rollo cruzado y es posible que deba aprovechar la precompilación personalizada.Los desarrolladores tienen que pensar desde una perspectiva de paquete, no solo acuerdos, sino que los súper constructores y la infraestructura de rollo personalizada pueden eliminar la complejidad de la mayoría de los desarrolladores.

3. Mev Searcher
   Las posibilidades de que los buscadores de MEV usen estrategias L1 en paquetes de suma cruzada son básicamente las mismas, pero depende de cómo se implementen PBS (separación del propuesta-constructor).
   → Los paquetes de suma cruzada se consideran esencialmente una sola transacción, por lo que los MEV se pueden encontrar pretradiendo o sujetando estos paquetes, siempre que no hagan que el precio exceda la cantidad de deslizamiento tolerable (porque todo el paquete se recuperará, MEV El intento fallará)

4. Rollups
   Requiere opción de participar en la infraestructura de clasificación compartida (incluidos los súper constructores) y permite el acceso a la destrucción/fundición de ETH en el clasificador compartido en el caso de una capa de facturación compartida.
   → MeV se puede internalizar vendiendo espacio en bloque a los constructores

6. Composibilidad a nivel de transacción

Infraestructura requerida:

Cambio de nivel VM // Acuerdo compartido // Super Builder

La composibilidad de nivel de transacción se refiere al mismo nivel de funcionalidad compartida por los contratos inteligentes en una cadena EVM.En este caso, una sola transacción puede actualizar el estado de múltiples rollups simultáneamente y asegurarse de que cualquier estado cambie antes de que se pueda restaurar cualquier llamada si la llamada no regresa con éxito.De hecho, los paquetes de transacciones atómicas en entornos compuestos a nivel de bloque se pueden completar en una sola transacción cruzada y transacción de VM.Además de la capa de facturación compartida y el súper constructor, esto requiere cambios en el nivel de VM en todos los rollups conectados.

Por la presente describimos un posible mecanismo desde un alto nivel.(Hasta donde sabemos, esta construcción se atribuye al equipo de espresso).Primero, el usuario envía una transacción a través de un rollup cuyo estado ha cambiado o un súper constructor que puede construir bloques en todos los rollups relevantes.El Super Builder simula la transacción y forma una lista de pares de entrada y salida, uno para cada acurrucado relacionado, que especifica los mensajes de rollo transversal necesarios y esperados en la transacción.(Tenga en cuenta que los súper constructores pueden hacer esto solo si tienen derechos de clasificación seguros para todos los rollups relevantes durante un período de tiempo).El Super Builder luego envía los bloques simulados a cada propositor de rollup junto con los pares de entrada y salida esperados de cada transacción enrollada.Durante la ejecución, cada acurrucado ejecuta su propia función de transición de estado normalmente, suponiendo que la entrada de la lista de transacciones a fondo es correcta.Durante el asentamiento, las listas de entrada y salida pueden ser cruzadas y demostradas seguras durante la fase de agregación de prueba de la capa de liquidación compartida.Específicamente, si alguna entrada esperada a través de las transacciones enrollables no coincide con la salida especificada por otro rollup, el proceso de liquidación rechaza toda la transacción cruzada.

Aunque existen nuevas características limitadas que la composibilidad a nivel de transacción puede desbloquear además del préstamo de rayos, la experiencia de crear aplicaciones de rollo cruzada puede mejorarse enormemente.La capacidad de crear DAPPS que interactúen con todas las cadenas de enlaces sin considerar los paquetes de rollo cruzado hará que sea mucho más fácil innovar en múltiples entornos de acumulación.Además, pueden surgir nuevos casos de uso y comportamientos.

Hay muchos problemas de diseño sin resolver en la composibilidad a nivel de transacción.Primero, se necesita una consideración cuidadosa sobre cómo los desarrolladores optan por dentro o fuera de las llamadas a través de sus contratos inteligentes.Permitir composibilidad arbitraria sin estar restringido significa que volvemos a un solo rollup.Creemos que la respuesta aquí es permitir que los desarrolladores señalen claramente dónde necesitan la composibilidad de rollup en sus contratos, como marcar ciertos puntos de entrada de un contrato como rollup llamable a través de modificadores de solidez (como «compuesto»).

Impacto en las partes interesadas

1. usuario:
   El mismo significado que la composibilidad a nivel de bloque y tiene otras características avanzadas, como Lightning Loan
   → UX usa casi la misma cadena que Opt-In Dapp

2. Desarrollador: dado que los desarrolladores de DAPP pueden llamar localmente el contrato de sumarización cruzada y usar la salida de estas llamadas (como llamadas de resumen individuales),
   El desarrollador experimenta enormemente
   Mejora → Superbuilder/secuenciador Infra todavía tiene que colocar transacciones en un bloque resumido afectado por llamadas de resumirización cruzada, pero no tiene que construir el mismo paquete como la composibilidad a nivel de bloque.

3. Mev Searcher:
   Los paquetes de rollups ahora son básicamente equivalentes a una sola transacción en una cadena, por lo que el potencial MEV es alto

4. Rollups:
   Necesita un cambio de nivel de máquina virtual, así como la selección de un clasificador compartido y una capa de facturación compartida
   → Antes de poder verificar el estado a través de la prueba, se debe confiar en la entrada y la salida de otros rollups, lo que implica supuestos de confianza adicionales, pero el mecanismo de corte puede reducir la carga de confianza

Mapa abstracto y ecosistema

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

1. La facturación compartida permite el intercambio a través de los encierros sin activos de envoltura externa y crear rutas de mensajería en el protocolo entre todos los rollups conectados

2. Sort/superbuilders compartidos permiten las próximas garantías de ejecución de bloques en paquetes de rollo cruzado

3. La composibilidad a nivel de bloque permite la creación de paquetes de rollo de rollo complejos, rápidos e interdependientes, lo que permite un ecosistema compuesto que es casi un contrato inteligente al nivel de contrato inteligente.
   → Crear estos paquetes de rollo cruzado sin usar activos de embalaje externos agregando facturación compartida

4. La composibilidad a nivel de transacción es posible, y aunque los casos de uso recién abiertos pueden dirigirse a usuarios más complejos, tiene el potencial de actualizar en gran medida la experiencia de desarrollo cruzada.

Actualmente, están surgiendo muchos proyectos para crear estos ecosistemas interoperables nativos.Aquí hay una descripción general de alto nivel del campo:

Mapa del ecosistema

Conclusión

Todavía hay algunas preguntas sin respuesta con respecto a los detalles técnicos en el marco que figura en este artículo.Por ejemplo, la construcción de un paquete para órdenes de límite cruzado en un ecosistema compuesto a nivel de bloque puede requerir un diseño más detallado para manejar la tolerancia del deslizamiento para la realización parcial y los pedidos de mercado.Ofrecemos una solución potencial aquí para restaurar el paquete de pedido de límite de resumen cruzado si el pedido no está completamente completado, pero el espacio de diseño está abierto.

Además, vale la pena mencionar que esto está relacionado con el intercambio creciente de ideas en el campo de las cadenas de aplicaciones en la actualidad.La cadena de aplicaciones es un L2 de cola larga, ya sea universal o con licencia, con el objetivo de aislar un acuerdo relacionado específico en un L2.Cuando alcanzamos la composibilidad de nivel de bloque, lo más probable es que comiencemos a ver que los entornos de la cadena de aplicaciones obtengan un atractivo significativo debido a la composibilidad nativa entre todas las redes conectadas.

En la actualidad, la introducción de liquidez a estas cadenas de aplicaciones sigue siendo difícil, pero una vez que las cadenas más grandes están conectadas como una entrada a entornos interoperables, probablemente veremos un ecosistema de jardín amurallado que rodea la infraestructura compartida.

Otra pregunta importante sin respuesta es cómo se resolverá el espacio de diseño alrededor del Superbuilder.Este desarrollo todavía está en su infancia y no está claro cómo crear una red compleja de constructores que puedan crear en los paquetes agregados de la manera más eficiente.Estos paquetes cruzados se incluirán en el bloque de la mejor manera, y el impacto en los ingresos agregados es una pregunta abierta, y muchos equipos están explorando diferentes estrategias.

En última instancia, el futuro puede implicar una combinación de soluciones de puente de dentro y fuera del protocolo que funcionarán juntas para proporcionar a todos un mejor proceso de interoperabilidad.Creemos que el progreso definido en este artículo puede servir como una guía para los desarrolladores y constructores que se centran en proporcionar una interoperabilidad más transparente para los usuarios finales.