Introduction

Fin 2020, Ethereum a adopté une approche centrée sur le rolluppour fournir des transactions rapides et bon marché. Cependant, cela se fait au prix d'une fragmentation accrue, les utilisateurs et la liquidité se dispersant à travers plusieurs rollups. Cette fragmentation est un défi à l'échelle de l'écosystème qui empêche une expérience Ethereum unifiée.

Dans cet article, nous examinerons les racines de cette fragmentation, examinerons l'un des défis principaux de l'interopérabilité des rollups, l'équivoque, et catégoriserons les solutions existantes pour aborder cette question. En décrivant les différentes solutions proposées concernant l'interopérabilité des rollups et en mettant en évidence les compromis impliqués, nous espérons donner un aperçu de l'avenir de l'interopérabilité des rollups et de la manière de construire un avenir rollup mieux connecté.

Le problème de la fragmentation

La fragmentation de l’état entre différents cumuls entraîne une mauvaise expérience utilisateur, une réduction de l’efficacité du capital et un manque de composabilité native :

Expérience utilisateur : la fragmentation oblige les utilisateurs à changer fréquemment de réseau, à gérer plusieurs copies du même jeton et à jongler avec différents portefeuilles. Cela ajoute de la friction et de la complexité, ce qui rend plus difficile pour les utilisateurs de profiter d’une expérience Ethereum transparente et « qui fonctionne tout simplement ». Par exemple, supposons qu’Alice ait ses fonds sur le rollup A mais qu’elle souhaite acheter un jeton disponible uniquement sur le rollup B. Au lieu de simplement cliquer sur « Acheter », elle doit d’abord changer de réseau, transférer ses fonds d’un point A à un point B, attendre les confirmations de niveau 1, puis exécuter la transaction.

Liquidité : Avec une liquidité dispersée sur de nombreux rollups, les paires de trading manquent de profondeur et d'efficacité. Cela conduit à des prix moins favorables, des rendements réduits pour les protocoles de prêt et une exécution de transaction sous-optimale.

Composabilité : Sur une seule chaîne, un protocole de prêt peut liquider instantanément une position en appelant un contrat DEX dans la même transaction—tout se passe en une seule opération atomique, synchroneDans un monde fragmenté et multi-rollup, ce processus devient asynchrone. Le protocole pourrait déclencher une liquidation sur un rollup, puis attendre un message pour finaliser sur un autre DEX du rollup. Si quelque chose se passe mal, inverser le processus n'est pas simple. Il n'existe également aucun outil fourni nativement par Ethereum pour effectuer des appels de contrat entre rollups ou garantir une exécution rapide de ces appels. Cette perte d'interactions immédiates et atomiques compromet la composabilité qui rend l'écosystème d'Ethereum si puissant.

Interopérabilité

À la base, l’interopérabilité consiste à permettre une transaction qui commence sur un rollup et met à jour l’état sur un autre, comme l’envoi de tokens du rollup A au rollup B. Idéalement, cette action est aussi simple que de faire baisser votre solde sur A et votre solde sur B augmenter, tout à la fois. En pratique, il est difficile d’obtenir un tel comportement « tout ou rien » entre différents cumuls.

Idéalement, les interactions entre les rollups fonctionneraient comme sur Ethereum L1 - de manière synchrone. Dans un environnement synchrone, plusieurs appels à différents contrats dans différents rollups peuvent être regroupés dans une seule transaction qui réussit entièrement ou échoue entièrement, offrant des résultats immédiats et atomiques.

En revanche, la compossibilité asynchrone implique plusieurs étapes réparties dans le temps sur différents rollups. Au lieu d'une transaction atomique unique, une action pourrait déclencher un événement sur un rollup, puis attendre une confirmation avant de terminer l'interaction sur un autre. La compossibilité asynchrone doit gérer les avortements : seul l'un des rollups peut effectuer l'action en temps opportun, puis il peut être nécessaire d'annuler cette transition d'état partielle (car l'autre rollup n'a pas fait sa part). La compossibilité synchrone et asynchrone partagent de nombreux défis communs que nous discutons ici.

Cet article se concentre sur les solutions d'interopérabilité de rollup natif qui nécessitent une intégration au niveau du protocole. Nous excluons les solutions de pont externe qui reposent sur les fournisseurs de liquidité et ne prennent en charge que les transferts de jetons fongibles.

Les défis de l'interop

Parvenir à une véritable interopérabilité entre les rollups ne consiste pas seulement à envoyer des messages de va-et-vient ; il s'agit de garantir que les transactions se finalisent de manière sécurisée et rapide. S'appuyer uniquement sur Ethereum L1 peut entraîner de longs retards et des coûts élevés. Alice a ses fonds sur le rollup A mais souhaite acheter un jeton disponible uniquement sur le Rollup B. Deux options sont possibles :

• Rollup B n’accepte les fonds d’Alice que s’ils sont pontés par Ethereum. Dans ce cas, Alice doit retirer ses fonds sur L1, puis les déposer dans le rollup B, et enfin acheter le jeton dans le rollup B, ce qui entraîne des retards et des coûts élevés.
• Le Rollup B offre un chemin plus rapide et moins cher en traitant le transfert directement au lieu de régler d'abord sur la couche 1 d'Ethereum. Cependant, comme nous l'expliquons ci-dessous, cela expose le Rollup B à des risques potentiels de réorganisation si le Rollup A équivaut, ne se règle pas ou soumet une transition d'état invalide.

Lorsque deux L2 interagissent à une latence plus rapide que celle d'Ethereum (c'est-à-dire avant même qu'ils ne valident ou ne règlent leurs transitions d'état vers L1), il y a trois problèmes fondamentaux auxquels les rollups doivent faire face : l'équivoque, l'invalidité et la non-règlement.

• Équivoque : Un rollup diffuse des états conflictuels à différentes chaînes, promettant efficacement les mêmes actifs plusieurs fois.
• Invalidité : Une transition d'état pourrait ne jamais être prouvée correcte sur L1.
• Non-règlement : Le processus de génération de preuve ou de règlement pourrait rester indéfiniment en suspens.

Rappelons ici que tous ces problèmes peuvent être résolus de manière triviale en attendant la finalité L1 - lorsque les transitions d'état sont entièrement réglées sur Ethereum. Cependant, nous sommes intéressés à permettre des interactions sécurisées entre les rollups à une latence plus rapide que sur Ethereum. Nous explorons des solutions qui maintiennent la sécurité tout en opérant dans cette fenêtre de sous-finalité.

Illustrons ces défis avec un exemple : supposons qu'Alice possède 10 ETH sur le mainnet de Scroll et souhaite les transférer à Bob sur Arbitrum. Idéalement, Alice pourrait déplacer la liquidité entre ces deux chaînes de manière native à des latences plus rapides que celles d'Ethereum. Supposons qu'une telle solution existe, et qu'Arbitrum crédite Alice de 10 ETH sur Arbitrum avant que Scroll ne soumette quoi que ce soit à la couche L1, quels problèmes peuvent survenir pour Arbitrum ?

• Équivoque : Scroll équivoque en s'engageant sur L1 dans une transition d'état différente dans laquelle la transaction d'Alice n'est pas incluse, volant effectivement 10 ETH à Arbitrum (qui doit se réorganiser pour pouvoir régler).
• Invalidité : Scroll n’est pas équivoque, mais la transition d’état qui contenait la transaction est invalide, et donc Scroll ne peut jamais la régler (c’est-à-dire le prouver) sur L1 et donner les fonds à Arbitrum. Encore une fois, Arbitrum a besoin d’être réorganisé pour pouvoir s’installer.
• Non-règlement : Scroll n'équivoque pas et la transition d'état est valide, mais les prouveurs désignés de Scroll se déconnectent et donc le règlement n'a jamais lieu. Arbitrum doit revoir sa copie.

En intégrant les 10 ETH envoyés par Alice dans Scroll avant que Scroll ne s'engage sur L1 (en cas d'équivoque) et avant que Scroll ne se règle (en cas d'invalidité et de non-règlement), Arbitrum prend un risque dans sa chaîne dépendant des considérations de sécurité de Scroll.

Un aspect critique de l'interopérabilité des rollups est la façon dont les systèmes gèrent l'équivoque. Différentes architectures adoptent des approches différentes. Dans certains systèmes comme l'OP Superchain, les rollups sont conçus pour se réorganiser ensemble - si un rollup équivoque, tous les rollups connectés doivent réorganiser leur état pour maintenir la cohérence dans l'ensemble du système, une propriété appelée blocs contingents inter-chaînes. D'autres architectures se concentrent sur la prévention de l'équivoque entièrement grâce à divers mécanismes que nous explorerons ci-dessous.

Le non-règlement et l’invalidité seront résolus de manière triviale une fois que la génération en temps réel de la preuve zk deviendra pratique (c’est-à-dire la preuve en temps réel). Le problème de l’équivoque est cependant fondamentalement différent. Une preuve zk peut prouver qu’Alice a envoyé 10 ETH à Bob sur Arbitrum, mais elle ne garantit pas que Scroll validera cette transition sur L1. Les preuves Zk seules ne résolvent pas et ne résoudront jamais l’équivoque. Là encore, attendre le règlement L1 résout l’équivoque, mais au prix de l’avantage de vitesse du rollup. Ainsi, nous nous concentrons sur l’équivoque pré-règlement, c’est-à-dire les garanties d’équivoque-prévention avant le règlement à Ethereum. Comme nous le verrons, chaque approche implique des arbitrages différents, notamment en termes d’hypothèses de confiance que nous abordons ci-dessous.

Architecture d'interopérabilité

Nous présentons deux approches différentes qui ont été explorées pour l'interopérabilité à une latence plus rapide que celle d'Ethereum, que nous appelons le maillage et le concentrateur.

En bref, le modèle maillé est celui où les rollups sont directement interconnectés les uns avec les autres dans une clique où ils se font mutuellement confiance pour ne pas équivoquer afin d'atteindre une finalité pré-règlement.

Le modèle de hub introduit une couche partagée, sur laquelle les rollups s'appuient pour gérer la prévention de l'équivoque des interactions inter-chaînes à une latence plus rapide que celle d'Ethereum. Explorons ce que cette différence signifie en pratique.

Maillage

Le modèle mesh fonctionne comme on pourrait s'y attendre, avec des rollups communiquant directement les uns avec les autres tout en restant responsables de régler eux-mêmes sur Ethereum L1 :

À mesure que de plus en plus de rollups deviennent interconnectés dans ce grand maillage, la transitivité de la confiance et des dépendances devient un problème d’évolutivité. Si Arbitrum fait confiance à Scroll mais pas à zkSync, alors Scroll ne peut pas faire confiance à zkSync tout en conservant la confiance d’Arbitrum. Seuls les « groupes de confiance » disjoints, c’est-à-dire les cliques de rollups, peuvent interagir les uns avec les autres dans un maillage. Ce problème de dépendance est amplifié par le fait que de plus en plus de rollups sont impliqués dans des cas d’interopérabilité complexes, où la sécurité de l’ensemble est limitée à la sécurité du rollup le plus faible.

Alors que les systèmes maillés reposent sur la confiance pour la sécurité avant le règlement, ils peuvent détecter l'équivoque lors du règlement, déclenchant des réorganisations à travers tous les rollups connectés.

Par conséquent, bien que ce modèle d'interop ait quelques lacunes, il est parfaitement adapté aux cas où les opérations de chaîne croisée souhaitées se limitent aux principaux rollups qui se sont révélés être sécurisés et/ou fiables, et qui sont prêts à créer cette dépendance de confiance dans leurs systèmes. Cependant, il devient rapidement évident que ce modèle ne s'adapte pas bien si nous voulons ajouter de plus en plus de rollups, d'autres L2, et même des appchain L3 dans le maillage.

Hub

Dans le modèle de concentrateur, les lacunes du modèle maillé sont traitées en introduisant une couche partagée. Chaque rollup doit faire confiance à cette couche, qui sert de source de vérité pour les interactions, donc lier un autre rollup à la couche est beaucoup plus facile. Naturellement, nous avons besoin que cette couche soit aussi sécurisée que possible pour offrir les meilleures garanties de non-équivoque avec une latence plus rapide que celle d'Ethereum.

L'avantage de cette solution est que l'ajout de rollups supplémentaires dans le mix ne crée pas plus de problèmes de dépendance, car la couche d'interopération agit comme un « bouclier » entre chaque rollup. Cela peut inclure n'importe quelle chaîne L2 arbitraire, ainsi que des L3s et des rollups d'applications - tout ce qu'ils ont à faire est de s'intégrer dans le hub et de profiter des avantages.

Le principal compromis de cette approche est que tous les rollups ont une dépendance partagée commune dans le hub, qui acquiert un pouvoir significatif.

Plus précisément, pour prévenir l'équivoque avant le règlement, nous devons nous assurer que le concentrateur ne collabore pas avec un rollup équivoque. Ainsi, les systèmes de concentrateurs remplacent la confiance mutuelle entre les rollups dans la conception en maillage, par la confiance en une couche partagée unique qui ne doit pas collaborer avec d'autres rollups pour équivocuer.

Il n'est donc pas surprenant que le hub doit être construit en tenant compte de la sécurité et de la décentralisation. Il existe quelques options différentes pour construire un tel hub :

• En utilisant un rollup existant : Cette option présente l'avantage d'être la plus simple, car le rollup existe déjà et a probablement été testé en conditions réelles, il suffirait alors de déployer des contrats intelligents dessus.
• Création d'un composant dédié : Au lieu de demander aux rollups de compter sur toutes les propriétés de sécurité d'un rollup existant, nous créons plutôt un nouveau composant dédié pour agir comme le hub. L'avantage ici est que ce nouveau composant aurait une surface de bug/exploit minimisée en étant spécifiquement adapté aux besoins inter-chaînes (et pourrait même être formellement vérifié !).
• Utiliser Ethereum L1 lui-même: Cette option consiste à utiliserpréconfirmations baséesdirectement sur la couche 1 pour profiter du meilleur des deux mondes : utilisez la couche maximale décentralisée pour une vivacité et une sécurité maximales tout en bénéficiant de confirmations quasi-instantanées, de temps de retrait minimisés, etc.

En supposant que des preuves zk sont utilisées, ces trois options peuvent toutes tirer parti du concept d'agrégation de preuves pour réduire encore plus les coûts impliqués, en faisant en sorte que le L1 vérifie une seule preuve regroupant de nombreuses preuves individuelles provenant de tous les rollups pris en charge par le concentrateur.

Systèmes existants

De nombreux projets ont proposé diverses solutions d’interopérabilité, qui peuvent être classées comme suit.

Systèmes mesh. OPSuperchaîne et celle d’Arbitrum Clusters-chaînes sont des systèmes maillés, où les chaînes doivent se croiser - si une chaîne équivoque, toutes les chaînes connectées doivent se réorganiser. Les chaînes doivent se faire confiance pour les confirmations préalables au règlement.

Ces solutions pourraient évoluer vers l'utilisation d'un type de concentrateur car les groupes de confiance ne peuvent pas s'étendre au-delà de quelques grands rollups pour atteindre une finalité de règlement prédéfinie.

Systèmes de hub.Expresso et le Chaîne élastique sont des systèmes de hub. Chez Scroll, nous avons exploré une conception de hub qui pourrait permettre des solutions d’interopérabilité plus évolutives et sans confiance. Notre présentationLors du Columbia CryptoEconomics Workshop 2024, une présentation générale du design sera proposée, avec plus de détails à suivre dans un prochain article.

D'autres systèmes. Les rollups basés ont le potentiel de permettre une composabilité synchrone non seulement entre eux, mais même avec Ethereum L1, et peuvent à leur tour utiliser Ethereum L1 pour la prévention de l'équivoque.

AggLayer de Polygon est un autre type de système de hub qui fournit une couche partagée avec laquelle tous les rollups communiquent. Cependant, il se distingue en évitant des hypothèses de confiance supplémentaires dans cette couche partagée. Au lieu de cela, ils attendent le règlement et utilisentpreuves pessimistes pour assurer la sécurité. L’équivoque n’est donc évitée qu’au moment du règlement. Les pré-confirmations pourraient éventuellement être utilisées pour offrir des garanties de finalité plus rapides. L’AggLayer a récemment annoncé un partenariat avec les systèmes Espresso, qui fournit un mécanisme de séquençage partagé.

Conclusion

Le développement d'un mécanisme de prévention de l'équivoque pour une interopérabilité plus rapide que celle d'Ethereum comporte toutes sortes de compromis qui doivent être soigneusement considérés pour des raisons de sécurité, de décentralisation et de neutralité crédible. Bien que ce post se soit concentré sur la prévention de l'équivoque, il existe plusieurs autres défis critiques en matière d'interopérabilité que nous n'avons pas discutés en profondeur ici, tels que la disponibilité des données, la conception de la couche de règlement (par exemple, la mise en œuvre de contrats de pont partagés et de rollup entre différents rollups), les protocoles de passage de messages et les incitations économiques nécessaires pour faire fonctionner le système. Mais comme l'a dit Vitalik dans un tweet récentNous sommes plus proches de résoudre ces problèmes d'interopérabilité que la plupart des gens ne le pensent. Dans cette phase finale d'interop, nous croyons que les utilisateurs auront vraiment l'impression de "utiliser un seul Ethereum", par opposition aux rollups individuels d'aujourd'hui.

Avertissement :

1. Cet article est repris de [Gate.io]Recherche sur le défilement]. Tous les droits d'auteur appartiennent à l'auteur original [Alejandro Ranchal-Pedrosa]. Si des objections sont formulées à cette réimpression, veuillez contacter le 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 pas des conseils en matière d'investissement.
3. L'équipe Gate Learn traduit l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.