Introduction

Il y a eu une explosion cambrienne de rollups sur Ethereum. Au moment de l'écriture, il y a 91 L2 & L3 en direct et 82 à venir selon L2Beat. En conséquence, il y a également une quantité significative de fragmentation en termes de liquidité, d'expérience utilisateur et d'outils de développement. Les solutions actuelles en matière d'interopérabilité laissent beaucoup à désirer, car elles reposent sur une combinaison de ponts de tiers, d'actifs enveloppés de manière externe et de frameworks d'intention, chacun portant son propre ensemble de problèmes.

1. Les ponts de liquidité sont souvent les cibles des plus grandes attaques cryptographiques (par exemple, le piratage du pont du ver de 321 millions de dollars)
2. Les actifs enveloppés de manière externe sont indésirables, et les données ont montré que les gens préfèreraient détenir des actifs sous une forme native chaque fois que possible (par exemple, il y a 22 milliards de dollars d'actifs pontés de manière canonique et seulement 3 milliards de dollars d'actifs enveloppés de manière externe, selonL2Beat)
3. Les cadres d'intention reposent sur des tiers qui nécessitent une certaine confiance non négligeable et s'accompagnent de frais supplémentaires pour faciliter l'activité inter-rollup (par exemple, l'utilisateur de la chaîne Degen perdre plus de 80% des jetonsen raison du pont officiel étant non canonique)a. Les cadres d'intention centralisés signifient également une concurrence plus faible et cela pourrait conduire à des prix et des performances suboptimaux

Dans cet article, nous passons en revue le paysage de l'interopérabilité sans confiance en définissant et en discutant de six niveaux de solutions d'interopérabilité entre les écosystèmes de rollup fragmentés.

Nous commençons par le cas par défaut du retrait asynchrone du rollup source vers L1 et du pontage manuel vers le rollup cible, et nous terminons par une architecture hypothétique pour la composabilité inter-rollup dans une seule transaction. Nous explorerons comment chaque niveau d'interopérabilité affectera l'expérience utilisateur, l'expérience développeur, le potentiel de MEV et les rollups eux-mêmes (spécifiquement liés aux changements d'infrastructure).

Nous restons principalement dans le domaine d'Ethereum et de ses L2 pour cet article et nous concentrons uniquement sur l'interopérabilité sans confiance. Dans ce cas, l'« interopérabilité sans confiance » fait référence à des canaux en protocole qui ne nécessitent pas de tiers pour faciliter les transferts en dehors de l'infrastructure nécessaire que la plupart des rollups requièrent déjà.

Préliminaires

Définitions

Fondamentalement, l'interopérabilité sans confiance nécessite une ressource partagée à laquelle tous les deux protocoles souhaitant interopérer doivent avoir accès. Dans le cas d'Ethereum L1, tous les contrats intelligents vivent dans le même environnement partageant l'état complet d'Ethereum, ils auront donc toujours le plus haut niveau d'interopérabilité. Cependant, les L2 partagent seulement une couche de règlement via des contrats de ponts séparés et donc l'interopérabilité est beaucoup plus limitée.

Les composants d'infrastructure partagée cruciaux qui peuvent nous faire progresser le long de l'échelle d'interopérabilité sans confiance sont les séquenceurs partagés, les superconstructeurs et le règlement partagé. Les garanties et les nouvelles fonctionnalités ouvertes par ces couches partagées sont liées, mais essentiellement orthogonales par nature.

1. Séquenceurs partagés/Superconstructeurs : Principalement des améliorations de vitesse et d'expérience utilisateur.
2. Règlement partagé : Échanges d'actifs sans enveloppement externe et messagerie dans le protocole.

Pour commencer, nous allons d'abord définir les six niveaux d'interopérabilité sans confiance évoqués dans l'introduction :

1. L1 Asynchrone:
   → Interopérabilité via transfert d'actifs manuel à travers le L1 que les rollups règlent.
2. Inclusion atomique :
   → Une garantie que toutes les transactions dans un bundle cross-rollup seront incluses dans le prochain bloc pour chaque rollup impliqué dans le bundle, ou aucune ne le sera.
3. Règlement partagé:
   → Plusieurs rollups se connectant à la L1 via le même contrat de pont.
4. Exécution atomique :
   → Une garantie selon laquelle soit toutes les transactions dans un bundle de cross-rollup seront incluses et exécutées avec succès dans le prochain bloc pour chaque rollup impliqué dans le bundle, soit aucune ne sera exécutée. L'exécution réussie fait référence à ce que chaque transaction soit exécutée sans réversion et soit reflétée dans l'état mis à jour pour chaque rollup dans le bundle.
5. Composabilité au niveau du bloc :
   → Les blocs suivants garantissent des paquets inter-rollup qui peuvent contenir des transactions dépendantes (tx B sur rollup B dépend du résultat de tx A sur rollup A)
6. Composabilité au niveau de la Tx :
   → L'interopérabilité au niveau des contrats intelligents nécessitant une seule transaction pouvant provoquer des changements d'état simultanément sur de nombreux rollups (pas de bundles). Utiliser n'importe quel protocole sur n'importe quel rollup est logiquement équivalent à utiliser différents contrats intelligents sur une seule chaîne. Il est important de noter que cela implique que les changements d'état avant tout appel peuvent être annulés lors de son retour.

Pour comprendre chaque niveau plus en profondeur, nous passerons en revue les cas d'utilisation clés suivants pour démontrer la puissance de chaque niveau ainsi que les implications pour les utilisateurs, les développeurs, les rollups et les chercheurs MEV.

Exemples illustratifs :

1. Transfert du Même Jeton
   → Envoyer à soi-même : Échanger de l'Eth contre de l'Eth ou de l'ERC-20 contre de l'ERC-20 à travers deux rollups
2. Achat de jetons
   → Ordre à limite inter-rollup : Utilisant Eth/ERC-20 de Rollup A, acheter un ERC-20 différent d'un DEX sur Rollup B et (facultativement) renvoyer à Rollup A

Implications:

Les questions suivantes seront également abordées afin de mieux comprendre l'impact sur les principaux actionnaires dans tout écosystème de rollup.

1. Expérience utilisateur
   Comment l'expérience utilisateur change-t-elle en atteignant ce niveau d'interopérabilité ?
2. Expérience des développeurs
   Comment l'expérience des développeurs change-t-elle en atteignant ce niveau d'interopérabilité?
3. Potentiel de MEV
   Y a-t-il un potentiel pour de nouvelles opportunités MEV si nous atteignons ce niveau d'interopérabilité ?
4. Implications de Rollup
   Le rollup doit-il opter pour une nouvelle infrastructure pour y parvenir? Quels sont les changements dans les structures de frais pour le rollup? Quels pourraient être les avantages potentiels pour les rollups de participer à cette infrastructure?

Vue d'ensemble de haut niveau

Aperçu des changements apportés aux parties prenantes clés

La progression en six niveaux vers l'interopérabilité sans confiance

1. Asynchrone L1

Infrastructure requise :

N/A

Tel que défini, cela fait référence au mode par défaut actuel de l'interopérabilité sans confiance. Tous les rollups sont définis comme tels car ils sont construits sur une couche L1 en tant que couche de règlement et n'ont accès à cette L1 que via les contrats de pont où ils publient périodiquement des mises à jour d'état afin de sécuriser le réseau.

La seule façon canonique d'effectuer toute activité de cross-rollup sans confiance dans ce cas est de retirer des actifs du rollup source via le pont canonique et de les déposer manuellement dans le rollup cible une fois qu'ils sont disponibles sur le L1.

Pour les rollups optimistes, cette latence de retrait est d'environ 7 jours pour tenir compte de la fenêtre de preuve de faute. Dans un rollup ZK, la latence de retrait est moins certaine mais pourrait être de 15 minutes à une journée entière, comme c'est le cas avec ZkSync.

De plus, des swaps atomiques de pair à pair utilisant des contrats intelligents sont possibles, mais il s'agit d'un cas d'utilisation plus restreint et ne permet pas de scaler efficacement.

Il convient de noter les solutions tierces actuellement existantes :

1. Ponts de liquidité
2. Cadres d'intention

Nos deux exemples illustratifs nécessitent des solutions tierces pour faciliter.

Envoyer à soi-même :

1. De manière canonique :
   → Retirer des actifs de Rollup A
   → Déposer manuellement dans Rollup B
2. Tierce partie :
   → Pont de liquidité / Réseaux de résolution

Commande limite Cross-Rollup

1. Canoniquement:
   → Retirer des actifs de Rollup A
   → Déposer manuellement dans Rollup B
   → Effectuer un ordre à cours limité
   Pour renvoyer, il faudrait envelopper extérieurement l'ERC-20 cible
2. Tiers
   → Espace de solution naissant pour les ordres limités inter-rollup
   → Il existe des conceptions ouvertes autour de l'utilisation d'intentions pour faciliter cela

Comme il s'agit du cas par défaut, il est inutile de discuter des changements apportés à l'UX, au DevEx, au MEV et aux rollups.

2. Inclusion atomique

Infrastructure requise

Séquenceur partagé *

L'inclusion atomique garantit uniquement qu'un bundle cross-rollup sera inclus dans le bloc suivant.

Cela nécessite un séquenceur partagé, mais théoriquement, cela peut être réalisé sans celui-ci manuellement si les séquenceurs sur deux rollups donnés ne sont pas à pleine capacité (on pourrait simplement soumettre deux transactions à chaque rollup individuellement). C'est pourquoi nous avons ajouté un astérisque à l'infrastructure requise.

Cependant, nous ne supposons pas que le séquenceur partagé exécute un nœud complet de chacun des rollups connectés et ne pouvons donc pas garantir l'exécution réussie d'un ensemble de transactions. Le séquenceur partagé dans ce cas ne peut garantir que les transactions sont bien formées et qu'elles seront incluses dans le prochain bloc, mais pas nécessairement qu'elles s'exécuteront avec succès.

Parce qu'il n'y a pas de garanties d'exécution, il est impossible de profiter de l'inclusion atomique de manière significative de manière programmatique sans courir le risque qu'une des transactions soit annulée. En conséquence, nous sommes essentiellement dans le même cas que l'interopérabilité asynchrone de L1.

Envisagez d'initier un échange simple de rollup croisé avec uniquement des garanties d'inclusion atomique :

1. Bundle d'échange Cross-Rollup
   → Tx 1 : Verrouiller/Brûler des jetons sur le rollup source
   → Tx 2: Créer des jetons à l'adresse de l'utilisateur sur le rollup de destination

Nous pouvons avoir des garanties d'inclusion atomique selon lesquelles les deux transactions sont en fait incluses dans les blocs suivants pour chaque rollup, mais si la première transaction est annulée et que la seconde ne l'est pas, l'utilisateur se verrait attribuer incorrectement des fonds sur la chaîne de destination sans les avoir verrouillés ou brûlés sur la chaîne source et nous rencontrerions un problème de double dépense.

Toute solution d'interopérabilité, qu'il s'agisse d'un pont de liquidité, d'un cadre d'intention ou d'un échange xERC-20, serait vulnérable à ce risque et il est impossible de le mitigé. En raison de ce risque, les solutions actuelles nécessitent que la transaction initiale ait été exécutée avec succès et incluse dans un bloc sur la chaîne source avant d'utiliser des relais pour transmettre un message émis et exécuter la deuxième transaction sur la chaîne de destination.

Point important à retenir : l'inclusion atomique n'a pas d'incidence significative sur le potentiel d'interopérabilité

3. Règlement partagé

Infrastructure requise :

Couche d'agrégation de preuves // Contrat de pont partagé

C'est ici que les choses commencent à devenir plus intéressantes. En raison du contrat de pont partagé, toute liquidité déposée dans l'écosystème rollup depuis le L1 peut être déplacée librement entre tous les rollups connectés. Jusqu'à présent, nous ne pouvions pas effectuer d'échanges entre les rollups sans passer par des canaux canoniques, envelopper des actifs de manière externe ou utiliser une solution tierce.

Pourquoi construire un contrat de pont partagé? Pour comprendre pourquoi avoir un contrat de pont partagé nous permet de déplacer des actifs de manière sûre à travers les rollups, considérez d'abord ce qui se passerait s'il était possible d'avoir de l'ETH dans Rollup A, de le brûler et de le créer nativement sur Rollup B sans contrat de pont partagé sur L1.

Nous voyons que chaque rollup serait désynchronisé avec leur contrat de passerelle sur mainnet. Le contrat de passerelle du rollup B détient toujours 50 Eth, donc l'utilisateur ne pourrait pas retirer leur 1 Eth vers le L1.

Pour résoudre ce problème, des protocoles d'enrobage d'actifs externes sont construits qui émettent une version enrobée de manière externe des jetons à travers les rollups qui symbolisent une version native ailleurs dans le réseau.

Avec une couche de règlement partagée, la situation est différente. Parce que toute la liquidité pour chaque rollup connecté est verrouillée dans le même contrat de pont, on peut se déplacer librement entre les rollups, car le montant total de valeur dans le contrat de pont reste le même et peut toujours être retiré.

Il doit y avoir une mise à jour au niveau du contrat L1 à propos deoù la liquidité permet aux utilisateurs de retirer de n'importe où, mais cela est trivial car tous les rollups connectés peuvent lire/écrire dans le contrat partagé.

Avec une couche de règlement partagée, le flux peut ressembler à ce qui suit pour un cas simple d'envoi à soi-même.

Envoyer à soi-même :

1. L'utilisateur crée la transaction initiale :
   → Tx 1: retirer de l'Eth sur le rollup A (avec un message pour le mint sur le rollup B)
   → La transaction est regroupée et soumise au contrat L1
   → Il est agrégé dans la racine de transaction qui regroupe tous les rollups de règlement partagés
2. Le Rollup B importe cette racine de tx
3. Le relais soumet la transaction à émettre avec la preuve de Merkle pour le roulement B
4. Le Rollup B vérifie la transaction de gravure en utilisant la preuve de Merkle et la racine de transaction
5. L'utilisateur est minté Eth sur Rollup B
6. Rollup B soumet la preuve à L1

Nous pouvons étendre ce flux à tout ERC-20 qui a des contrats sur tous les rollups dans l'écosystème de règlement partagé.

On peut penser à un contrat de pont partagé comme une couche de messagerie en protocole entre tous les rollups connectés, donc théoriquement ce flux peut réellement être étendu à n'importe quel standard de messagerie arbitraire.

Cela nous rapproche de la composabilité, mais en raison des étapes nécessaires d'agrégation des preuves et de relais des messages uniquement après que les changements d'état sont reflétés sur L1, il y a des latences élevées (bien que notablement inférieures au cas asynchrone L1). De plus, toute activité complexe de cross-rollup comme l'utilisation d'un DEX sur le rollup B en commençant avec des actifs sur le rollup A pour un ordre limité cross-rollup serait toujours un processus fastidieux pour l'utilisateur car il devrait toujours envoyer à lui-même et échanger manuellement des actifs sur le rollup de destination. On ne peut pas créer de bundles atomiques cross-rollup dans ce cas.

Un autre avantage important avec le règlement partagé est qu'il y a moins de friction pour les fournisseurs de liquidité ou les solveurs qui remplissent des commandes dans plusieurs environnements. Parce que leur liquidité sur tous les rollups connectés est reflétée dans le même contrat de pont, ils n'ont pas à attendre la fenêtre de retrait complète pour gérer leur liquidité entre rollups.

Implications sur les parties prenantes :

1. Utilisateurs :
   Peut désormais transférer des actifs sous forme native sans période de retrait L1
2. Développeurs:
   Les changements sont limités aux émetteurs de jetons qui peuvent désormais utiliser la messagerie en protocole pour émettre des versions natives d'ERC-20s sur tous les rollups connectés
3. Chercheurs MEV :
   Parce que cela se produit sur plusieurs blocs pour chaque rollup, il n'y a pas de nouveau potentiel de MEV
4. Rollups:
   Les Rollups devront choisir d'utiliser un contrat de pont partagé et probablement ajouter des précompilations pour gérer les messages entre Rollups

Point important: Le règlement partagé permet des transferts d'actifs non enveloppés de manière externe et des messages arbitraires à travers tous les rollups partageant le contrat de pont et la couche d'agrégation de preuves, mais il y aura toujours des latences non négligeables (bien que beaucoup plus courtes que L1 Async) et on ne peut pas créer des ensembles atomiques croisés entre rollups.

4. Exécution Atomique

Infrastructure requise :

Séquenceurs partagés // Superconstructeurs

L'exécution atomique nous permet de garantir l'exécution réussie des bundles cross-rollup, mais comme nous le verrons, le nombre de cas d'utilisation pour les bundles cross-rollup qui n'ont pas de transactions dépendantes est plus petit que ce à quoi on pourrait s'attendre initialement.

Si une seule transaction dans un ensemble de transactions dépendantes est annulée, alors toutes les autres transactions deviennent invalides et doivent également être annulées, comme c'est le cas avec la combustion et la création de jetons à travers les rollups. La création de jetons sur un rollup de destination dépend du fait qu'ils aient été brûlés ou verrouillés sur le rollup source, nous dirions donc qu'un ensemble de transactions de combustion et de création est un ensemble de transactions dépendantes.

Créer ce bundle est impossible sans un tiers tel qu'un superconstructeur capable de créer la transaction de destination.

Considérez ce qui devrait être vrai pour que des bundles d'échange inter-rollup soient construits sans qu'une autre partie que l'utilisateur soit nécessaire. Un bundle devrait être créé pour verrouiller/brûler l'actif sur le rollup source et émettre l'actif sur le rollup de destination, mais nous rencontrons des problèmes :

1. Les contrats sur le rollup source ne peuvent émettre un message que lors du verrouillage/brûlage de l'actif source d'origine, ils ne peuvent pas appeler et créer une transaction sur le rollup de destination.
   → C'est pourquoi les protocoles de messagerie et les réseaux de relais existent.
   → Le message peut être utilisé pour structurer ce que l'appel à la destination devrait être, mais il ne peut pas réellement créer la transaction elle-même.
2. Créer la deuxième transaction sur le rollup de destination pour émettre :
   → L'utilisateur ne peut pas créer cette tx eux-mêmes car ils n'ont pas les droits de frappe pour le jeton sur le rollup B
   → C'est-à-dire) La chaîne de destination a besoin d'une preuve que les jetons ont été brûlés/bloqués sur la chaîne source, mais cette preuve n'est pas disponible avant l'exécution de la transaction initiale, ce qui violerait notre exigence d'atomicité.
   → Toute autre partie qui pourrait théoriquement créer la deuxième transaction avec des droits de création pourrait créer une transaction de "création" sur la chaîne de destination à tout moment sans avoir d'abord créé une transaction de "brûlure" ou de verrouillage sur la source, ce qui constitue une énorme vulnérabilité.

Nous pouvons voir que même si nous pouvions garantir l'exécution des lots inter-rollup, nous rencontrons des difficultés quant à la manière dont nous pourrions les construire en premier lieu pour transférer des actifs de valeur.

Cependant, il existe encore quelques cas d'utilisation pour une exécution atomique sans paquets inter-rollup dépendants. L'un d'entre eux est l'arbitrage inter-rollup :

Arbitrage DEX Cross-Rollup avec exécution atomique

Parce qu'il n'y a pas de dépendances strictes entre ces transactions, n'importe qui peut créer ce bundle atomique et le soumettre à un séquenceur partagé qui garantira une exécution atomique.

Cependant, pour garantir l'exécution atomique en premier lieu, les rollups doivent opter pour un séquenceur partagé et un superconstructeur qui exécutera des nœuds complets de tous les rollups connectés, de sorte que le passage de l'exécution atomique à la composabilité au niveau des blocs est assez petit et toutes les solutions de séquençage partagé le feront. La seule modification requise est que le constructeur de blocs ou un autre tiers doit être capable de créer des transactions au nom de l'utilisateur pour compléter les faisceaux dépendants entre rollups.

Il est peu probable que l'infrastructure soit construite de manière à permettre uniquement une exécution atomique sans aller plus loin pour avoir de la composabilité. Le gain relatif de passer à une composabilité totale au niveau du bloc l'emporte largement sur la difficulté à le réaliser compte tenu de l'infrastructure ayant déjà une exécution atomique.

Implications pour les parties prenantes :

1. Utilisateurs:
   Probablement pas de changement, bien qu'il soit possible que des solutions facilitant les tiers comme les intentions puissent être atomiques, mais comment spécifiquement n'est pas clair
2. Développeurs:
   Probablement aucun changement
3. Chercheurs de MEV :
   L'arbitrage inter-rollup est bien plus sûr en raison de l'exécution atomique
4. Rollups:
   Les rollups doivent opter pour l'utilisation d'un séquenceur partagé/superconstructeurs soumettant des blocs avec des transactions de chaque rollup souhaitant interopérer, ce qui peut changer la structure des revenus du rollup. Il n'est pas encore clair comment cela va changer. \

• Les places de marché de séquençage peuvent augmenter les revenus des rollups en permettant aux espaces ToB d'être achetés par des constructeurs sophistiqués

Point important : Bien que les bundles inter-rollup soient garantis d'être exécutés de manière atomique, il n'est pas clair comment ces bundles seront construits s'il n'y a pas de superconstructeur qui crée une partie du bundle, il est donc peu probable que l'exécution atomique à elle seule ait un impact sur l'interopérabilité. Les séquenceurs/superconstructeurs partagés devraient par défaut construire plutôt pour la composabilité au niveau du bloc.

5. Composabilité au niveau des blocs

Infrastructure requise :

Séquenceur partagé // Superbuilder // Couche d'agrégation de preuves// Contrat de pont partagé

(* = facultatif)

Dans une grande partie des discussions autour des séquenceurs partagés et des couches de règlement partagées, le terme souvent utilisé pour décrire ce niveau d'interopérabilité est la "composabilité synchrone".

Nous avons légèrement modifié ce terme pour le rendre plus descriptif. La mise à jour de la nomenclature en Composabilité au niveau du bloc implique qu'il est possible de composer entre deux rollups dans un ensemble de transactions inter-rollup qui seront incluses et exécutées avec succès dans le prochain bloc. La composabilité synchrone pourrait être confondue avec la composabilité au niveau de la transaction, que nous explorons dans la prochaine section. Il est important de noter que cela nécessite une partie intermédiaire (l'infrastructure de séquençage partagée) qui peut être le chef d'orchestre et le créateur de bundles de transactions dépendantes.

À ce niveau, nous commençons à voir une véritable composabilité entre les rollups au-delà du simple envoi à soi-même pour participer à une dapp sur un autre rollup.

Avec l'ajout d'un séquenceur partagé capable de créer des transactions, nous sommes désormais en mesure de créer des ensembles inter-rollup que les développeurs peuvent exploiter de manière programmable.

Il y a deux cas à considérer :

1. Composabilité au niveau des blocs
2. Composabilité au niveau du bloc + couche de règlement partagée

Dans les deux cas, nous pouvons créer des bundles cross-rollup pour des activités plus complexes, mais dans le deuxième cas avec un règlement partagé, nous pouvons utiliser des actifs natifs, ce qui pourrait avoir de meilleures implications de prix pour l'activité DEX cross-rollup, par exemple.

Avec la composabilité au niveau des blocs, nous avons à la fois les avantages de l’exécution atomique et la possibilité supplémentaire de créer des faisceaux de transactions dépendants. Examinons nos deux exemples illustratifs.

Transfert du même jeton via xERC-20 (pas de règlement partagé) :

1. L'utilisateur a ERC-20
2. L'utilisateur crée tx via dapp:
   → Déposez des ERC-20 dans la boîte de verrouillage xERC-20 pour recevoir la version enveloppée xERC-20
   → Brûler xERC-20
   → Émettre un message indiquant à l'infrastructure de séquençage partagée qu'un transfert inter-rollup a été initié avec les données pertinentes pour faciliter l'échange
3. Superbuilder récupère la transaction et crée un ensemble cross-rollup
   → Tx 1: La transaction de wrap and burn mentionnée ci-dessus
   → Tx 2: Créer xERC-20 sur rollup B
4. Superconstructeur soumet ce cross-rollup au séquenceur partagé
   → Parce que le superconstructeur exécute un noeud complet des deux rollups connectés, ils simulent les transactions pour garantir l'exécution réussie du bundle. Si l'une des transactions devait être annulée, l'ensemble du bundle serait annulé.
5. Le séquenceur partagé soumet le bloc contenant les deux transactions à la couche DA ainsi qu’aux nœuds qui exécutent le changement d’état
6. xERC-20 est émis à l'utilisateur sur Rollup B

Avec une couche de règlement partagée, le flux est encore plus simplifié car il ne serait pas nécessaire d'abord d'envelopper l'ERC-20 en tant qu'xERC-20 pour l'échanger.

Examinons maintenant l'ordre limite de transfert inter-rollup pour acheter un ERC-20 sur Rollup B avec un ERC-20 initial (différent) de Rollup A et faire en sorte que l'ERC-20 résultant soit renvoyé à Rollup A. Dans ce cas, nous ne supposons pas avoir une couche de règlement partagée, bien qu'un flux similaire existe dans le cas où il y en a une. La seule différence est de ne pas avoir à envelopper les actifs de manière externe en plus.

Voici les transactions requises dans ce cas :

1. Wrap and Burn ERC-20 on A
2. Mint xERC-20 sur B
3. Échangez initialement xERC-20 avec ERC-20 cible sur B
4. Envelopper et Brûler la cible ERC-20 sur B
5. Mint xERC-20 sur A

Voici un flux potentiel pour expliquer comment cela pourrait fonctionner:

Ordre limite Cross-Rollup dans un environnement composable au niveau du bloc

Flow :

1. L'utilisateur initie la première transaction:
   → Envelopper et Brûler xERC-20 avec un message émis pour spécifier les paramètres d'échange (chaîne de destination, adresse DEX, ERC-20 à échanger, prix de l'ordre limite, booléen pour renvoyer ou non)
2. Superbuilder voit la transaction et crée l’offre groupée :
   → Tx 1: L'utilisateur crée une tx décrite ci-dessus
   → Tx 2 : Créer xERC-20 sur la destination (le superconstructeur doit avoir des privilèges de création)
   → Tx 3: Ordre limité en utilisant les données de la tx 1
   → Tx 4 : Envelopper et Brûler ERC-20 sur B en supposant un remplissage complet de l'ordre limite avec un message à créer sur la chaîne source
   → Tx 5: Créer xERC-20 cible à partir de la sortie de l'échange sur la chaîne source

Parce que le superconstructeur crée le bloc et ordonne les transactions, il peut simuler chaque transaction et omettre le bundle si l'une des transactions devait être annulée. Par exemple, s'il est constaté que l'utilisateur ne recevrait pas un accomplissement complet de son ordre limite, le bundle serait omis avant l'exécution du bloc.

Dans ce cas d'infrastructure de séquençage partagée sans couche de règlement partagée, une version enveloppée externe d'Eth et xERC-20 devrait être utilisée, ce qui pourrait entraîner de pires conditions de marché sur le DEX en raison de pools de liquidité plus minces pour les actifs enveloppés. Dans ce cas, un utilisateur peut avoir à utiliser une limite plus souple avec plus de glissement toléré et pourrait recevoir des prix sous-optimaux. Une exception à cela est si l'USDC est impliqué. Il est possible qu'un séquenceur partagé sans règlement partagé puisse travailler avec Circle pour obtenir des droits exclusifs sur les contrats USDC à travers les rollups afin de faciliter les transferts et échanges natifs USDC entre les rollups.

Avec une couche de règlement partagée, cet emballage externe n'est pas nécessaire et offrirait probablement de meilleurs prix en raison de la profondeur des pools de liquidités pour les échanges d'actifs natifs, mais le flux est essentiellement le même.

Séquenceur de confiance optimiste

Les Rollups devraient avoir une confiance optimiste dans le séquenceur/superconstructeur partagé pour créer des lots cross-rollup valides. Cela est principalement dû au fait que ce lot cross-rollup contient des transactions dépendantes que les rollups individuels ne peuvent pas vérifier avant que le bloc ne soit ajouté à la chaîne de chaque rollup et agrégé à une couche de règlement sur L1. Un exemple est la combustion initiale et le minage d'Eth de la source à la destination. Il est crucial que l'Eth soit effectivement brûlé sur la chaîne source avant d'être miné sur la chaîne de destination, sinon des doubles dépenses sont possibles.

Cependant, pour que ce bundle complet soit exécuté en un seul bloc, toutes les transactions doivent être présentes dans ce bloc, même si la transaction représente un état qui est invalide avant le bloc lui-même (comme avoir de l'Eth sur la chaîne de destination pour l'échange si l'utilisateur n'en a pas avant le bloc). Pour cette raison, nous devons faire confiance au séquenceur qu'il a effectivement inclus les dépendances valides dans le bundle cross-rollup. On pourrait soumettre des preuves après coup pour prouver la validité de chaque transaction.

Cela est légèrement moins important lors de l'utilisation d'actifs enveloppés, car ils n'ont aucun impact sur la liquidité native stockée dans la L1, mais des mécanismes de secours doivent toujours être en place pour contrer le risque d'un séquenceur malveillant ou d'un bug dans le code qui a permis à un ensemble de transactions d'être exécuté avec une transaction dépendante qui a été annulée.

Implications pour les parties prenantes :

1. Utilisateurs
   Mises à niveau massives de l'UX permettant des ordres limités inter-rollups dans un seul bloc
2. Développeurs
   Il faudrait être conscient de l'interopérabilité entre rollups pour l'activité inter-rollup, en tirant probablement parti des précompilations personnalisées. Au lieu de simplement des transactions, les développeurs doivent penser en termes de bundles, mais il est probable que les superconstructeurs et l'infrastructure rollup personnalisée pourraient abstraire la plupart de la complexité pour les développeurs.
3. Chercheurs de MEV
   Les chercheurs de MEV ont essentiellement la même opportunité d'utiliser des stratégies L1 sur des ensembles cross-rollup, mais cela dépend de la manière dont le PBS (Proposer-Builder Separation) est mis en œuvre.
   → Les bundles cross-rollup sont essentiellement considérés comme une seule transaction, donc les MEV pourraient être trouvés en opérant en priorité ou en sandwichant ces bundles tant qu'ils ne déplacent pas les prix en dehors des montants de glissement tolérés (car alors l'ensemble du bundle serait annulé et les tentatives de MEV échoueraient)
4. Rollups
   Devrait opter pour l'infrastructure de séquençage partagée (y compris les superconstructeurs) et permettre l'accès à la gravure/création d'Eth au séquenceur partagé en cas de couche de règlement partagée.
   → Pourrait internaliser le MEV en vendant de l'espace de bloc aux constructeurs

6. Composabilité au niveau des transactions

Infrastructure requise:

Changements au niveau de la machine virtuelle // Règlement partagé // Superconstructeurs

La composabilité au niveau des transactions fait référence au même niveau de fonctionnalité que partagent les contrats intelligents sur une chaîne EVM. Dans ce cas, une seule transaction pourrait mettre à jour l'état à travers de multiples rollups simultanément, et garantir que tout changement d'état avant un appel peut être annulé si l'appel ne réussit pas. En effet, un ensemble atomique de transactions dans un environnement composable au niveau des blocs peut être réalisé dans une seule transaction croisée entre rollups et VM. Cela nécessite des modifications au niveau du VM pour tous les rollups connectés en plus d'une couche de règlement partagée et d'un superconstructeur.

Nous décrivons ici un mécanisme possible à un niveau élevé. (Cette construction est due à l'équipe Espresso selon nos connaissances). Tout d'abord, un utilisateur soumet une transaction de cross-rollup à tous les rollups dont l'état est modifié par la transaction ou à un superconstructeur qui peut construire des blocs à travers tous les rollups impliqués. Un superconstructeur simule la transaction et forme des listes de paires d'entrées-sorties, une pour chaque rollup impliqué, qui spécifient les messages de cross-rollup nécessaires et attendus au sein de la transaction. (Notez que le superconstructeur ne peut le faire que s'il a des droits de séquençage sécurisés sur tous les rollups impliqués pour une période de temps). Le superconstructeur envoie ensuite le bloc simulé au proposant de chaque rollup, ainsi que les listes de paires d'entrées-sorties attendues pour chaque transaction de cross-rollup. Pendant l'exécution, chaque rollup exécute sa propre fonction de transition d'état normalement en supposant que les entrées de la liste des transactions de cross-rollup sont correctes. Pendant le règlement, les listes d'entrées-sorties peuvent alors être comparées et prouvées sûres lors de la phase d'agrégation de preuves dans la couche de règlement partagée. Plus précisément, si une entrée attendue pour une transaction de cross-rollup ne correspond pas à ce qu'un autre rollup a spécifié comme sortie, le processus de règlement rejettera l'ensemble de la transaction de cross-rollup.

Bien que les prêts flash ne débloquent qu'une fonctionnalité limitée au niveau de la transaction, l'expérience des développeurs pour créer des applications inter-rollups peut être grandement améliorée. La capacité de créer des dapps qui interagissent avec toutes les chaînes connectées sans avoir à raisonner sur les bundles inter-rollups rendra beaucoup plus facile l'innovation dans un paysage multi-rollups. De plus, il est possible que de nouveaux cas d'utilisation et comportements émergent en conséquence.

Il existe de nombreuses questions de conception ouvertes pour la composabilité au niveau des transactions. Par exemple, comment les développeurs peuvent choisir de participer ou non aux appels cross-rollup pour leurs besoins en contrats intelligents doit être soigneusement considéré. Permettre une composabilité arbitraire sans restriction signifie que nous régressons vers un rollup monolithique. Nous pensons que la réponse ici est que les développeurs indiquent explicitement où la composabilité cross-rollup est nécessaire dans leurs contrats, par exemple via un modificateur Solidity comme composablequi marque certains points d'entrée du contrat comme appelables cross rollup.

Implications pour les parties prenantes

1. Utilisateurs:
   Les mêmes implications que la compossibilité au niveau des blocs avec des capacités avancées supplémentaires comme les flashloans
   → L'UX est pratiquement identique à l'utilisation d'une chaîne pour les dapps qui optent pour la
2. Devs :
   L'expérience des développeurs s'améliore considérablement car les développeurs d'applications peuvent appeler nativement des contrats inter-rollup et utiliser les sorties de ces appels comme des appels de rollup simples
   → L'infrastructure Superbuilder/Sequencer devra toujours placer la transaction dans des blocs pour les rollups affectés par l'appel cross-rollup, mais n'aura pas à construire les mêmes bundles que dans le cas de la composabilité au niveau des blocs.
3. Chercheurs MEV:
   Un potentiel MEV élevé alors que les paquets inter-rollup sont désormais essentiellement équivalents aux transactions uniques sur une seule chaîne
4. Rollups:
   Nécessiterait des modifications au niveau de la machine virtuelle, ainsi que l'adhésion à un séquenceur partagé et une couche de règlement partagée
   → Des hypothèses de confiance supplémentaires impliquent de devoir faire confiance aux entrées et sorties pour d'autres rollups avant de pouvoir vérifier l'état via des preuves, mais les mécanismes de réduction pourraient réduire le fardeau de confiance

Résumé et Carte de l'écosystème

Après avoir parcouru les détails techniques de chaque niveau d'interopérabilité défini ici, nous pouvons résumer :

1. Le règlement partagé permet des échanges croisés entre les rollups sans envelopper les actifs de manière externe et crée des voies de messagerie en protocole entre tous les rollups connectés
2. Les séquenceurs partagés / Superconstructeurs permettent des garanties d'exécution de bloc suivant sur les paquets de cross-rollup
3. La compossibilité au niveau des blocs permet de créer des ensembles complexes, rapides et dépendants entre les rollups croisés, atteignant ainsi un écosystème composable presque au niveau des contrats intelligents.
   Avec l'ajout de règlements partagés, ces ensembles de cross-rollup peuvent être créés sans utiliser d'actifs enveloppés extérieurement
4. La composabilité au niveau des transactions est possible, et bien que les nouveaux cas d'utilisation ouverts puissent être destinés à des utilisateurs plus sophistiqués, cela a le potentiel d'améliorer massivement l'expérience de développement inter-rollup.

À l'heure actuelle, de nombreux projets émergent pour créer ces écosystèmes nativement interopérables. Voici un aperçu général du paysage :

Carte de l'écosystème

Carte de l'écosystème

Pensées de clôture

Il reste encore des questions ouvertes concernant les subtilités techniques dans les cadres énoncés dans cet article. Par exemple, la construction de bundles dans un écosystème composable au niveau du bloc pour les ordres limites inter-rollup peut avoir des conceptions plus détaillées pour gérer le cas de l'exécution partielle et la tolérance au glissement pour les ordres du marché. Nous avons proposé une solution potentielle ici pour annuler un bundle d'ordres limites inter-rollup si l'ordre n'est pas complètement rempli, mais l'espace de conception est ouvert.

De plus, il vaut la peine de faire le lien avec l’état d’esprit actuel qui se développe dans l’espace des chaînes d’applications. Les chaînes d’applications sont des L2 à longue traîne qui sont soit généralisées, soit autorisées dans le but de cloisonner des protocoles connexes spécifiques sur une L2. Il est probable que lorsque nous atteindrons la composabilité au niveau des blocs, nous commencerons également à voir les environnements appchain gagner en popularité en raison de la composabilité native entre tous les réseaux connectés.

En ce moment, il est encore difficile de démarrer la liquidité pour ces appchains, mais une fois qu'une chaîne plus importante se connecte en tant que rampe d'accès à l'environnement interopérable, il est probable que nous verrons des écosystèmes de jardins clos autour de l'infrastructure partagée.

Une autre question ouverte importante est de savoir comment l'espace de conception autour des superconstructeurs se stabilisera. Le développement sur ce front est encore assez naissant, et il n'est pas encore clair quelle sera la manière la plus efficiente et efficace de créer un réseau de constructeurs sophistiqués capables de créer des ensembles de rollup croisés. L'endroit optimal où ces ensembles de rollup croisés seront inclus dans un bloc, et l'impact sur les revenus du rollup, est une question ouverte avec différentes stratégies explorées par de nombreuses équipes.

En fin de compte, l'avenir impliquera probablement une combinaison de solutions de pontage en protocole et hors protocole et elles fonctionneront de concert pour offrir un processus d'interopérabilité bien meilleur pour tous. Nous pensons que la progression définie dans cet article peut servir de guide aux développeurs et aux constructeurs qui se concentrent sur la rendant l'interopérabilité entre les rollups croisés plus fluide pour les utilisateurs finaux.

Il est également probable qu'il y aura des paradigmes complètement nouveaux pour l'interaction entre les rollups qui restent à découvrir. Si vous êtes un constructeur travaillant sur des approches qui développent les sujets abordés ici ou qui ne sont pas couverts ci-dessus, veuillezcontacter(les DM sont ouverts). La technologie a enfin suffisamment mûri pour mettre une pression réelle sur la recherche de solutions pour la fragmentation de la liquidité/de l'écosystème, et nous cherchons toujours à nous connecter avec des fondateurs qui prennent des risques pour construire des solutions créatives.

Remerciements

Cet article est issu d'une discussion très instructive sur l'interopérabilité des Rollup organisée par 1kx lors de l'EthCC. Un grand merci àNoah Pravecek, Ellie DavidsonetTerrypour avoir lu les premières versions de cet article et fourni des commentaires, ainsi qu'à Marti, mteam, et Bo Dupour des conversations ultérieures sur le sujet.

Avertissement：

1. Cet article est repris de [miroir], Transférez le titre original 'Trustless Interoperability entre Rollups: Paysage, Constructions et Défis', Tous les droits d'auteur appartiennent à l'auteur original [Marshall Vyletel Jr.]. En cas d'objections à cette réimpression, veuillez contacter Porte Apprendreéquipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.