Vertrauenslose Interoperabilität zwischen Rollups: Landschaft, Konstruktionen und Herausforderungen

Einführung

Es hat eine kambrische Explosion von Rollups auf Ethereum gegeben. Zum Zeitpunkt des Schreibens gibt es laut L2Beat 91 Live-L2 & L3s und 82 bevorstehende. Als Folge gibt es auch eine signifikante Fragmentierung in Bezug auf Liquidität, Benutzererfahrung und Entwicklertools. Aktuelle Lösungen zur Interoperabilität lassen viel zu wünschen übrig, da sie auf einer Kombination von Drittanbieterbrücken, extern gewickelten Vermögenswerten und Absichtsrahmen beruhen, von denen jede ihre eigenen Probleme mit sich bringt.

1. Liquiditätsbrücken sind oft das Ziel der größten Kryptohacks (z. B. der $321m Wurmlochbrücken-Hack)
2. Extern gewickelte Vermögenswerte sind unerwünscht, und Daten haben gezeigt, dass die Menschen Vermögenswerte möglichst in natürlicher Form halten möchten (z. B. gibt es 22 Mrd. US-Dollar an kanonisch überbrückten Vermögenswerten und nur 3 Mrd. US-Dollar an extern gewickelten Vermögenswerten, gemäß L2Beat)
3. Intent-Frameworks verlassen sich auf Dritte, die ein gewisses nicht zu vernachlässigendes Vertrauen erfordern und zusätzliche Gebühren verlangen, um die Cross-Rollup-Aktivität zu erleichtern (z.B. Degen Chain-Benutzer Verlieren von >80% der Tokenaufgrund des nicht-kanonischen offiziellen Brücken(auch: Zentralisierte Absichtsrahmen bedeuten auch weniger Wettbewerb und dies könnte zu suboptimaler Preisgestaltung und Leistung führen

In diesem Artikel untersuchen wir die vertrauenslose Interoperabilitätslandschaft, indem wir sechs Ebenen von Interoperabilitätslösungen zwischen fragmentierten Rollup-Ökosystemen definieren und diskutieren.

Wir beginnen mit dem Standardfall des asynchronen Abhebens vom Quell-Rollup auf L1 und dem manuellen Brücken zum Ziel-Rollup, und enden mit einer hypothetischen Architektur für die Komponierbarkeit zwischen Rollups in einer einzigen Transaktion. Wir werden untersuchen, wie jede Ebene der Interoperabilität die Benutzererfahrung, die Entwicklererfahrung, das MEV-Potenzial und die Rollups selbst (speziell im Zusammenhang mit Infrastrukturänderungen) beeinflussen wird.

Wir bleiben in diesem Artikel hauptsächlich im Rahmen von Ethereum und seinen L2s und konzentrieren uns ausschließlich auf die vertrauenslose Interoperabilität. In diesem Fall bezieht sich „vertrauenslose Interoperabilität“ auf in-Protokoll-Kanäle, die keine Drittanbieter benötigen, um Transfers außerhalb der notwendigen Infrastruktur zu erleichtern, die die meisten Rollups bereits erfordern.

Vorbemerkungen

Definitionen

Grundsätzlich erfordert die vertrauenslose Interoperabilität eine gemeinsame Ressource, auf die alle zwei Protokolle, die miteinander interagieren möchten, zugreifen müssen. Im Fall von Ethereum L1 existieren alle Smart Contracts in der gleichen Umgebung und teilen sich den gesamten Zustand von Ethereum, sodass sie immer das höchste Maß an Interoperabilität haben werden. Allerdings teilen L2s nur eine Abwicklungsschicht über separate Brückenverträge, und die Interoperabilität ist daher weitaus eingeschränkter.

Die entscheidenden gemeinsamen Infrastrukturkomponenten, die uns entlang der Vertrauenslosen Interoperabilitätsleiter voranbringen können, sind gemeinsame Sequenzer, Superbauer und gemeinsame Abrechnung. Die Garantien und die neuen Funktionalitäten, die durch diese gemeinsamen Schichten eröffnet werden, sind zwar verwandt, aber im Wesentlichen orthogonal in der Natur.

1. Geteilte Sequenzer/Superbauer: Hauptsächlich Geschwindigkeits- und Benutzererfahrungs-Upgrades.
2. Gemeinsame Abrechnung: Vermögenswerte tauschen ohne externe Verpackung sowie in-Protokoll-Nachrichten.

Um zu beginnen, werden wir zunächst die sechs Ebenen der vertrauenslosen Interoperabilität definieren, auf die in der Einleitung angespielt wird:

1. L1 Async:
   → Interoperabilität über manuelle Vermögensübertragung durch das L1, zu dem Rollups abgerechnet werden.
2. Atomare Aufnahme:
   → Eine Garantie, dass entweder alle Transaktionen in einem Cross-Rollup-Bundle im nächsten Block für jeden Rollup, der am Bundle beteiligt ist, enthalten sein werden, oder keine.
3. Gemeinsame Abrechnung:
   → Mehrere Rollups, die über denselben Brückenvertrag mit der L1 verbunden sind.
4. Atomare Ausführung:
   Eine Garantie, dass entweder alle Transaktionen in einem Cross-Rollup-Bundle im nächsten Block für jeden Rollup, der am Bundle beteiligt ist, enthalten und erfolgreich ausgeführt werden oder keine ausgeführt werden. Erfolgreiche Ausführung bezieht sich darauf, dass jede Transaktion ohne Rückgängigmachung ausgeführt wird und im aktualisierten Zustand für jeden Rollup im Bundle reflektiert wird.
5. Block-Level Komponierbarkeit:
   → Nächster Block garantiert auf Cross-Rollup-Bundles, die abhängige Transaktionen enthalten können (tx B auf Rollup B ist abhängig vom Ergebnis von tx A auf Rollup A)
6. Tx-Level Komponierbarkeit:
   → Smart Contract-Ebene Interoperabilität, die nur eine Transaktion erfordert, die gleichzeitig Zustandsänderungen in vielen Rollups verursachen kann (keine Bündel). Die Verwendung eines beliebigen Protokolls in jedem Rollup ist logisch äquivalent zur Verwendung verschiedener Smart Contracts auf einer Chain. Wichtig ist, dass dadurch Zustandsänderungen vor jedem Aufruf rückgängig gemacht werden können, wenn dieser zurückkehrt.

Um jedes Level genauer zu verstehen, werden wir die folgenden Schlüsselanwendungsfälle durchgehen, um die Leistung jedes Levels sowie die Auswirkungen auf Benutzer, Entwickler, Rollups und MEV-Sucher zu demonstrieren.

Illustrative Beispiele:

1. Gleiche Token-Übertragung
   → Send-to-self: Austausch von Eth gegen Eth oder ERC-20 gegen ERC-20 über zwei Rollups
2. Tokenkauf
   → Cross-Rollup Limit Order: Verwenden Sie Eth/ERC-20 von Rollup A, um einen anderen ERC-20 von einem DEX auf Rollup B zu kaufen und (optional) zurück zu Rollup A zu senden

Auswirkungen:

Die folgenden Fragen werden ebenfalls beantwortet, um das Verständnis für die Auswirkungen auf wichtige Aktionäre in jedem Rollup-Ökosystem zu vertiefen.

1. Benutzererfahrung
   Wie verändert sich die Benutzererfahrung durch das Erreichen dieses Maßes an Interoperabilität?
2. Entwicklererfahrung
   Wie verändert sich die Entwicklererfahrung durch das Erreichen dieses Maßes an Interoperabilität?
3. MEV Potenzial
   Gibt es Potenzial für neue MEV-Möglichkeiten, wenn wir dieses Maß an Interoperabilität erreichen?
4. Rollup Auswirkungen
   Muss das Rollup in neue Infrastruktur optieren, um dies zu erreichen? Welche Änderungen gibt es in den Gebührenstrukturen für das Rollup? Welche potenziellen Vorteile könnte es für Rollups geben, an dieser Infrastruktur teilzunehmen?

Übersicht auf hoher Ebene

Überblick über die Änderungen für wichtige Interessengruppen

Die sechsstufige Entwicklung hin zur Vertrauenslosen Interoperabilität

1. L1 Asynchron

Erforderliche Infrastruktur:

N/A

Wie definiert, bezieht sich dies auf den aktuellen Standardmodus der vertrauenslosen Interoperabilität. Alle Rollups werden als solche definiert, weil sie auf einer L1 als Abwicklungsebene aufgebaut sind und nur über die Brückenverträge Zugang zu dieser L1 haben, wo sie in regelmäßigen Abständen Statusaktualisierungen veröffentlichen, um das Netzwerk zu sichern.

Der einzige kanonische Weg, um in diesem Fall eine vertrauenslose Cross-Rollup-Aktivität durchzuführen, besteht darin, Vermögenswerte aus dem Quell-Rollup über die kanonische Brücke abzuheben und sie manuell in das Ziel-Rollup einzuzahlen, sobald sie auf dem L1 verfügbar sind.

Bei optimistischen Rollups beträgt die Auszahlungsverzögerung etwa 7 Tage, um das fehlersichere Fenster zu berücksichtigen. Bei einem ZK-Rollup ist die Auszahlungsverzögerung weniger sicher, könnte aber zwischen 15 Minuten und einem ganzen Tag liegen, wie es bei ZkSync der Fall ist.

Zusätzlich sind Peer-to-Peer-Atomswaps mit Smart Contracts möglich, aber dies ist ein kleinerer Anwendungsfall und skaliert nicht effektiv.

Es ist erwähnenswert, dass derzeit Drittanbieterlösungen existieren:

1. Liquiditätsbrücken
2. Absichtsrahmen

Beide unserer anschaulichen Beispiele erfordern Drittanbieterlösungen zur Erleichterung.

Send-To-Self:

1. Kanonisch:
   → Assets von Rollup A abheben
   → Manuell in Rollup B einzahlen
2. Dritter:
   → Liquiditätsbrücke / Solver-Netzwerke

Cross-Rollup Limit Order

1. Kanonisch:
   Assets aus Rollup A abheben
   → Manuell in Rollup B einzahlen
   → Führen Sie eine Limitorder aus
   Um es zurückzusenden, müsste man das Ziel-ERC-20 extern einwickeln
2. Dritter
   → Aufstrebender Lösungsraum für Cross-Rollup-Limitaufträge
   Es gibt offene Designs, die die Verwendung von Absichten zur Erleichterung dessen umgeben.

Da es sich um den Standardfall handelt, ist es nicht notwendig, Änderungen an UX, DevEx, MEV und Rollups zu diskutieren.

2. Atomare Eingliederung

Erforderliche Infrastruktur

Gemeinsamer Sequenzer *

Atomare Einschluss garantiert nur, dass ein Cross-Rollup-Bundle im nächsten Block enthalten sein wird.

Dies erfordert einen gemeinsamen Sequenzer, kann aber theoretisch auch ohne diesen manuell erreicht werden, wenn die Sequenzer auf zwei bestimmten Rollups nicht die maximale Durchsatzrate erreichen (man könnte einfach zwei Transaktionen an jedes Rollup einzeln senden). Deshalb haben wir einen Stern in die erforderliche Infrastruktur aufgenommen.

Allerdings gehen wir nicht davon aus, dass der gemeinsame Sequenzer einen vollständigen Knoten jeder der verbundenen Rollups ausführt und daher keine erfolgreiche Ausführung für ein Bündel von Transaktionen garantieren kann. Der gemeinsame Sequenzer kann in diesem Fall nur garantieren, dass die Transaktionen wohlgeformt sind und dass sie im nächsten Block enthalten sein werden, aber nicht unbedingt, dass sie erfolgreich ausgeführt werden.

Da es keine Ausführungsgarantien gibt, ist es unmöglich, atomare Einschlüsse in irgendeiner sinnvollen Weise programmgesteuert zu nutzen, ohne das Risiko einer Rückgängigmachung einer der Transaktionen einzugehen. Als Ergebnis befinden wir uns im Wesentlichen im genau gleichen Fall wie bei der Interoperabilität von L1 Async.

Erwägen Sie die Initiierung eines einfachen Cross-Rollup-Swaps mit nur atomaren Einschlussgarantien:

1. Cross-Rollup Swap Bundle
   → Tx 1: Sperren/Verbrennen von Token auf der Quell-Rollup
   → Tx 2: Token an die Benutzeradresse auf dem Ziel-Rollup prägen

Wir können atomare Einschlussgarantien haben, dass beide Transaktionen tatsächlich in den nächsten Blöcken für jede Rollup enthalten sind, aber wenn die erste Transaktion rückgängig gemacht wird und die zweite nicht, würden dem Benutzer auf der Zielkette fälschlicherweise Mittel zugewiesen, ohne dass sie auf der Quellkette gesperrt oder verbrannt wurden, und wir würden auf ein doppeltes Ausgabenproblem stoßen.

Jede Interoperabilitätslösung, sei es eine Liquiditätsbrücke, ein Absichtsrahmen oder ein xERC-20-Swap, wäre anfällig für dieses Risiko, und es ist unmöglich, es zu mildern. Aufgrund dieses Risikos erfordern aktuelle Lösungen, dass die initiierende Transaktion erfolgreich ausgeführt wurde und in einem Block auf der Quellkette enthalten ist, bevor Relayer verwendet werden, um eine emittierte Nachricht zu übergeben und die zweite Transaktion auf der Ziellinie auszuführen.

Wichtige Erkenntnis: Atomare Inklusion hat keinen wesentlichen Einfluss auf das Potenzial der Interoperabilität

3. Gemeinsame Abwicklung

Erforderliche Infrastruktur:

Nachweis-Aggregationslayer // Gemeinsamer Brückenvertrag

Hier beginnt es interessanter zu werden. Aufgrund des gemeinsamen Brückenvertrags können alle Liquiditäten, die aus dem L1 in das Rollup-Ökosystem eingezahlt werden, frei zwischen allen verbundenen Rollups bewegt werden. Bis zu diesem Zeitpunkt konnten wir keine Swaps zwischen Rollups durchführen, ohne durch kanonische Kanäle zu gehen, Vermögenswerte extern zu wickeln oder eine Lösung eines Drittanbieters zu verwenden.

Warum einen gemeinsamen Brückenvertrag erstellen? Um zu verstehen, warum es uns ermöglicht, Vermögenswerte vertrauenslos über Rollups zu bewegen, betrachten Sie zunächst, was passieren würde, wenn es möglich wäre, Eth in Rollup A zu haben, es zu verbrennen und es nativ auf Rollup B zu prägen, ohne einen gemeinsamen Brückenvertrag auf L1 zu haben.

Wir sehen, dass jeder Rollup mit seinem Brückenvertrag auf dem Mainnet nicht synchron wäre. Der Brückenvertrag des Rollup B hat immer noch 50 Eth, daher könnte der Benutzer ihre 1 Eth nicht auf L1 abheben.

Um dies zu lösen, werden externe Asset-Wrapping-Protokolle entwickelt, die eine extern gewrappte Version von Tokens über Rollups ausgeben, die eine native Version an anderer Stelle im Netzwerk symbolisieren.

Mit einer gemeinsamen Abrechnungsschicht sieht die Situation anders aus. Da alle Liquidität für jeden verbundenen Rollup im selben Brückenvertrag gesperrt ist, kann man sich frei zwischen den Rollups bewegen, da der Gesamtwert im Brückenvertrag gleich bleibt und immer abgehoben werden kann.

Es muss eine Aktualisierung auf der Ebene des L1-Vertrags über wo Die Liquidität ermöglicht es den Benutzern, von überall abzuheben, aber das ist trivial, weil alle verbundenen Rollups auf den gemeinsamen Vertrag lesen/schreiben können.

Mit einer gemeinsamen Abrechnungsschicht könnte der Ablauf in einem einfachen Send-an-Sich-selbst-Fall wie folgt aussehen.

Send-to-Self:

1. Benutzer erstellt die erste Transaktion:
   → Tx 1: Eth auf Rollup A abheben (mit Nachricht, um es auf Rollup B zu prägen)
   → Transaktion wird gebündelt und an den L1-Vertrag übermittelt
   → Es wird in den Transaktions-Root aggregiert, der alle gemeinsamen Abrechnungs-Rollups gruppiert
2. Rollup B importiert diesen Transaktions-Root
3. Der Relayer reicht die Transaktion zur Prägung zusammen mit dem Merkle-Beweis zur Rollup B ein
4. Rollup B überprüft die Brenntransaktion mithilfe des Merkle-Beweises und des Transaktions-Roots
5. Benutzer wird auf Rollup B Eth geprägt
6. Rollup B reicht den Nachweis bei L1 ein

Wir können diesen Ablauf auf jedes ERC-20 ausweiten, das Verträge in allen Rollups im gemeinsamen Abrechnungssystem hat.

Man kann einen gemeinsamen Brückenvertrag als eine in-Protokoll-Messaging-Schicht zwischen allen verbundenen Rollups betrachten, sodass dieser Fluss theoretisch tatsächlich auf jeden beliebigen Messaging-Standard erweitert werden kann.

Dies bringt uns näher an die Komponierbarkeit, aber aufgrund der notwendigen Schritte zur Aggregation von Beweisen und Weiterleitung von Nachrichten erst nachdem die Zustandsänderungen auf L1 reflektiert sind, gibt es hohe Latenzen (obwohl bemerkenswert niedriger als im Fall von L1 async). Darüber hinaus wäre jede komplexe Cross-Rollup-Aktivität wie die Verwendung eines DEX auf Rollup B, die mit Vermögenswerten auf Rollup A für eine Cross-Rollup-Limitorder beginnt, immer noch ein mühsamer Prozess für den Benutzer, da sie immer noch Vermögenswerte an sich selbst senden und manuell Vermögenswerte auf dem Ziel-Rollup tauschen müssten. In diesem Fall können keine atomaren Cross-Rollup-Bündel erstellt werden.

Ein weiterer wichtiger Vorteil beim gemeinsamen Abwicklung ist, dass es weniger Reibung für Liquiditätsanbieter oder Solver gibt, die Aufträge in mehreren Umgebungen ausführen. Da ihre Liquidität über alle verbundenen Rollups hinweg im selben Brückenvertrag widergespiegelt wird, müssen sie nicht auf das volle Abhebungsfenster warten, um ihre Cross-Rollup-Liquidität zu verwalten.

Auswirkungen auf Interessengruppen:

1. Benutzer:
   Kann jetzt Vermögenswerte in nativer Form ohne L1 Abhebungszeit übertragen
2. Entwickler:
   Änderungen sind auf Token-Aussteller beschränkt, die jetzt in-Protokoll-Nachrichten verwenden können, um native Versionen von ERC-20s über alle verbundenen Rollups auszugeben
3. MEV-Sucher:
   Da dies über mehrere Blöcke für jeden Rollup geschieht, gibt es kein neues MEV-Potenzial
4. Rollups:
   Rollups müssen sich dafür entscheiden, einen gemeinsamen Bridge-Vertrag zu verwenden und wahrscheinlich Precompiles hinzufügen, um Cross-Rollup-Nachrichten zu verarbeiten

Wichtiger Hinweis: Gemeinsame Abrechnung ermöglicht nicht extern verpackte Vermögensübertragungen und beliebige Nachrichtenübermittlung über alle Rollups, die den Brückenvertrag und die Nachweiskonsolidierungsschicht teilen, aber es wird immer noch nicht zu vernachlässigende Latenzen geben (obwohl weit kürzer als L1 Async), und man kann keine Cross-Rollup-atomaren Bündel erstellen.

4. Atomare Ausführung

Erforderliche Infrastruktur:

Gemeinsame Sequenzer // Superbauer

Atomare Ausführung ermöglicht es uns, die erfolgreiche Ausführung von Cross-Rollup-Bundles zu garantieren, aber wie wir sehen werden, ist die Anzahl der Anwendungsfälle für Cross-Rollup-Bundles ohne abhängige Transaktionen kleiner als man zunächst erwarten könnte.

Wenn eine einzelne Transaktion in einem Bündel von abhängigen Transaktionen rückgängig gemacht wird, werden auch alle anderen Transaktionen ungültig und müssen ebenfalls rückgängig gemacht werden, wie dies beim Verbrennen und Prägen von Token über Rollups der Fall ist. Das Prägen von Token auf einem Ziellayer ist abhängig davon, dass sie auf dem Quellayer verbrannt oder gesperrt wurden. Daher würden wir sagen, dass ein Bündel von Verbrennungs- und Präge-Transaktionen ein Bündel von abhängigen Transaktionen ist.

Die Erstellung dieses Bundles ist ohne eine Zwischenpartei wie einen Superbuilder, der die Zieltransaktion erstellen kann, unmöglich.

Denken Sie darüber nach, was wahr sein müsste, damit Cross-Rollup-Swap-Bundles erstellt werden könnten, ohne dass eine andere Partei als der Benutzer erforderlich ist. Ein Bundle müsste erstellt werden, um das Vermögenswert auf dem Ursprungs-Rollup zu sperren/verbrennen und das Vermögenswert auf dem Ziel-Rollup zu prägen, aber wir stoßen auf Probleme:

1. Verträge auf dem Ursprungs-Rollup können nur eine Nachricht abgeben, wenn sie das ursprüngliche Quellen-Asset sperren/verbrennen. Sie können keine Transaktion auf dem Ziels-Rollup aufrufen und erstellen.
   Deshalb gibt es Nachrichtenprotokolle und Relaisnetzwerke.
   → Die Nachricht kann verwendet werden, um zu strukturieren, wie der Aufruf am Ziel aussehen soll, aber sie kann die Transaktion selbst nicht tatsächlich erstellen.
2. Erstellen der zweiten Transaktion auf dem Ziel-Rollup zum Prägen:
   → Der Benutzer selbst kann diese Transaktion nicht erstellen, da er keine Prägerechte für das Token auf Rollup B hat.
   → D. h.) Die Zielkette benötigt einen Nachweis dafür, dass Token auf der Quellkette verbrannt/gesperrt wurden, aber dieser Nachweis steht erst nach Ausführung der ersten Transaktion zur Verfügung, was unsere Anforderung an die Atomarität beeinträchtigen würde.
   Jede andere Partei, die theoretisch die Minting-Rechte für die zweite Transaktion erstellen könnte, könnte jederzeit eine "Mint"-Transaktion auf der Zielkette erstellen, ohne zuvor einen "Burn" oder eine Sperrung auf der Quellkette erstellt zu haben, was eine massive Schwachstelle darstellt.

Wir sehen, dass wir selbst wenn wir die Ausführung von Cross-Rollup-Bundles garantieren könnten, auf Schwierigkeiten stoßen, wie wir sie überhaupt erst bauen könnten, um Werte zu übertragen.

Jedoch gibt es immer noch einige Anwendungsfälle für atomare Ausführung ohne abhängige Cross-Rollup-Bundles. Einer davon ist Cross-Rollup-Arbitrage:

Cross-Rollup DEX Arbitrage mit atomarer Ausführung

Da es keine strengen Abhängigkeiten zwischen diesen Transaktionen gibt, kann jeder dieses atomare Bündel erstellen und an einen gemeinsamen Sequenzer senden, der eine atomare Ausführung garantiert.

Um jedoch atomare Ausführungsgarantien von vornherein zu haben, müssen Rollups sich für einen gemeinsamen Sequenzer und Superbuilder entscheiden, der vollständige Knoten aller verbundenen Rollups ausführen würde, sodass der Schritt von atomarer Ausführung zur Blockebene-Zusammensetzbarkeit recht klein ist und alle gemeinsamen Sequenzierungslösungen dies tun werden. Die einzige erforderliche Änderung besteht darin, dass der Blockbuilder oder ein anderer Drittanbieter in der Lage sein muss, Transaktionen im Namen des Benutzers zu erstellen, um abhängige Cross-Rollup-Bundles abzuschließen.

Es ist unwahrscheinlich, dass Infrastruktur aufgebaut wird, die nur die atomare Ausführung ermöglicht, ohne einen Schritt weiterzugehen, um Komponierbarkeit zu haben. Der relative Gewinn, den Sprung zur vollständigen Blockebene-Komponierbarkeit zu machen, überwiegt bei weitem die Schwierigkeit, dies zu erreichen, da die Infrastruktur bereits eine atomare Ausführung hat.

Auswirkungen auf Interessengruppen:

1. Benutzer:
   Voraussichtlich keine Änderung, obwohl es möglich ist, dass Drittanbieterlösungen wie Absichten atomar sein könnten, aber wie genau, ist nicht klar
2. Entwickler:
   Vermutlich keine Änderung
3. MEV-Sucher:
   Cross-Rollup-Arbitrage ist viel sicherer, da die Ausführung atomar erfolgt
4. Rollups:
   Rollups müssen sich dafür entscheiden, einen gemeinsamen Sequenzer/Superbuilder zu verwenden, der Blöcke mit Transaktionen von jedem Rollup einreicht, das interoperieren möchte, was die Umsatzstruktur des Rollups möglicherweise verändern wird. Es ist noch nicht klar, wie sich dies ändern wird. \

• Das Sequenzieren von Marktplätzen kann die Einnahmen für Rollups erhöhen, indem es fortgeschrittenen Bauherren ermöglicht, ToB-Raum zu kaufen.

Wichtige Erkenntnis: Während Cross-Rollup-Bundles garantiert atomar ausgeführt werden, ist nicht klar, wie diese Bundles erstellt werden, wenn es keinen Superbuilder gibt, der einen Teil des Bundles erstellt. Daher ist es unwahrscheinlich, dass die atomare Ausführung an sich die Interoperabilität beeinträchtigt. Geteilte Sequenzer/Superbuilder sollten standardmäßig stattdessen für die Blockebene-Komponierbarkeit erstellen.

5. Block-Level Composability

Erforderliche Infrastruktur:

Gemeinsamer Sequenzer // Superbuilder // Nachweissammelschicht// Gemeinsamer Brückenvertrag

(* = optional)

In vielen Diskussionen über gemeinsame Sequenzer und gemeinsame Abrechnungsebenen wird der Begriff, der oft zur Beschreibung dieses Grades der Interoperabilität verwendet wird, als "synchrone Komponierbarkeit" bezeichnet.

Wir haben diesen Begriff geringfügig modifiziert, um ihn genauer zu beschreiben. Ein Update der Nomenklatur auf Block-Level-Komponierbarkeit impliziert, dass es möglich ist, zwischen zwei Rollups in einem Bündel von Cross-Rollup-Transaktionen zu komponieren, die im nächsten Block enthalten und erfolgreich ausgeführt werden. Synchrone Komponierbarkeit könnte mit Transaktions-Ebene-Komponierbarkeit verwechselt werden, die wir im nächsten Abschnitt behandeln. Wichtig ist, dass dies eine Mittelperson (die gemeinsame Sequenzinfrastruktur) erfordert, die der Dirigent und Schöpfer abhängiger Transaktionsbündel sein kann.

Auf diesem Niveau beginnen wir, eine echte Komponierbarkeit zwischen Rollups zu sehen, die über das bloße Senden an sich selbst hinausgeht, um an einer Dapp auf einem anderen Rollup teilzunehmen.

Mit dem Hinzufügen eines freigegebenen Sequenzers, der Transaktionen erstellen kann, sind wir jetzt in der Lage, Cross-Rollup-Bundles zu erstellen, die Entwickler programmgesteuert nutzen können.

Es gibt zwei Fälle zu beachten:

1. Block-Ebene Komponierbarkeit
2. Block-Level Composability + gemeinsame Abwicklungsschicht

In beiden Fällen können wir jedoch platzübergreifende Bündel für komplexere Aktivitäten erstellen, aber im zweiten Fall mit gemeinsamer Abwicklung können wir native Vermögenswerte verwenden, die bessere Preisauswirkungen für platzübergreifende DEX-Aktivitäten haben könnten, zum Beispiel.

Mit Block-Level-Komponierbarkeit haben wir sowohl die Vorteile einer atomaren Ausführung als auch die Möglichkeit, abhängige Transaktionsbündel zu erstellen. Lassen Sie uns unsere beiden illustrativen Beispiele untersuchen.

Gleicher Token-Transfer über xERC-20 (Keine gemeinsame Abwicklung):

1. Benutzer hat ERC-20
2. Benutzer erstellt Transaktion über Dapp:
   → Einzahlung von ERC-20 in den xERC-20-Schließfach, um die xERC-20-Version zu erhalten
   → Burn xERC-20
   → Senden Sie eine Nachricht an die gemeinsame Sequenzinfrastruktur, die darauf hinweist, dass ein Cross-Rollup-Transfer eingeleitet wurde, zusammen mit relevanten Daten, um den Austausch zu erleichtern
3. Superbuilder übernimmt die Transaktion und erstellt ein Cross-Rollup-Bundle
   → Tx 1: Die oben genannte Wrap- und Burn-Transaktion
   → Tx 2: Mint xERC-20 auf Rollup B
4. Superbuilder reicht diesen Cross-Rollup beim gemeinsamen Sequenzer ein
   Da der Superbuilder einen vollständigen Knoten der beiden verbundenen Rollups betreibt, simulieren sie die Transaktionen, um die erfolgreiche Ausführung des Bündels zu garantieren. Wenn eine der Transaktionen rückgängig gemacht würde, wird das gesamte Bündel rückgängig gemacht.
5. Der Shared Sequencer sendet den Block, der beide Transaktionen enthält, an die DA-Schicht sowie an die Knoten, die die Zustandsänderung ausführen
6. xERC-20 wird dem Benutzer auf Rollup B geprägt

Mit einer gemeinsamen Abwicklungsschicht wird der Ablauf noch weiter vereinfacht, da es nicht erforderlich wäre, zuerst den ERC-20 als xERC-20 zu umwickeln, um ihn zu tauschen.

Lassen Sie uns jetzt den Cross-Rollup-Limitauftrag untersuchen, um einen ERC-20 auf Rollup B mit einem anfänglichen (unterschiedlichen) ERC-20 von Rollup A zu kaufen und den resultierenden ERC-20 zurück an Rollup A zu senden. In diesem Fall gehen wir nicht davon aus, dass wir eine gemeinsame Abwicklungsschicht haben, obwohl ein ähnlicher Ablauf auch im Fall mit einer existiert. Der einzige Unterschied besteht darin, dass Assets nicht zusätzlich extern verpackt werden müssen.

Hier sind die erforderlichen Transaktionen in diesem Fall:

1. Wrap und Burn ERC-20 auf A
2. xERC-20 auf B prägen
3. Tauschen Sie anfängliche xERC-20 mit Ziel-ERC-20 auf B
4. Einwickeln und Verbrennen Ziel-ERC-20 auf B
5. Mint xERC-20 auf A

Hier ist ein potenzieller Ablauf, wie dies funktionieren könnte:

Cross-Rollup Limit Order in Block-Level Composable Environment

Fluss:

1. Benutzer initiiert die erste Transaktion:
   → Wrap and Burn xERC-20 mit einer ausgestrahlten Nachricht, um die Tauschparameter (Zielkette, DEX-Adresse, ERC-20 zum Tausch, Limitorderpreis, Boolescher Wert zum Zurückschicken oder nicht) anzugeben
2. Superbuilder sieht die Transaktion und erstellt das Bündel:
   → Tx 1: Benutzer erstellt die oben beschriebene Transaktion
   → Tx 2: Mint xERC-20 am Zielort (Superbuilder muss Ausgabeberechtigungen haben)
   → Tx 3: Limit order mit Daten aus Tx 1
   → Tx 4: Wrap and Burn ERC-20 on B assuming full fulfillment on limit order with message to mint on source chain
   → Tx 5: Erstelle das Ziel-xERC-20 aus der Ausgabe des Swaps auf der Quellkette

Da der Superbuilder den Block erstellt und Transaktionen anordnet, kann er jede Transaktion simulieren und das Bündel auslassen, wenn eine der Transaktionen rückgängig gemacht würde. Wenn beispielsweise festgestellt wird, dass der Benutzer keine vollständige Erfüllung ihres Limitauftrags erhalten würde, würde das Bündel vor der Ausführung des Blocks ausgelassen.

In diesem Fall einer gemeinsam genutzten Sequenzinfrastruktur ohne gemeinsame Abwicklungsschicht müsste eine extern verpackte Version von Eth und xERC-20 verwendet werden, was zu schlechteren Marktbedingungen auf der DEX aufgrund dünnerer Liquiditätspools für verpackte Vermögenswerte führen könnte. In diesem Fall könnte ein Benutzer eine weichere Grenze mit mehr toleriertem Schlupf verwenden und suboptimale Preise erhalten. Eine Ausnahme hiervon ist, wenn USDC beteiligt ist. Es ist möglich, dass ein gemeinsamer Sequenzer ohne gemeinsame Abwicklung mit Circle zusammenarbeiten könnte, um exklusive Rechte an den USDC-Verträgen über Rollups hinweg zu erlangen, um native USDC-Transfers und Swaps über Rollups hinweg zu erleichtern.

Mit einer gemeinsamen Abwicklungsschicht ist diese externe Verpackung nicht erforderlich und würde wahrscheinlich aufgrund tieferer Liquiditätspools für native Asset-Swaps bessere Preise bieten, aber der Ablauf ist im Wesentlichen derselbe.

Optimistisch Vertrauensloser Sequenzer

Rollups müssten dem gemeinsamen Sequenzer/Superbuilder optimistisch vertrauen, um gültige Cross-Rollup-Bundles zu erstellen. Dies liegt hauptsächlich daran, dass dieses Cross-Rollup-Bundle abhängige Transaktionen enthält, die individuelle Rollups erst nach Hinzufügen des Blocks zu jeder Rollup-Kette und Aggregation auf einer Abrechnungsschicht auf L1 überprüfen können. Ein Beispiel ist die anfängliche Verbrennung und Prägung von Eth von der Quelle zum Ziel. Es ist entscheidend, dass Eth tatsächlich auf der Quellkette verbrannt wird, bevor es auf der Zielkette geprägt wird, da sonst doppelte Ausgaben möglich sind.

Allerdings müssen alle Transaktionen in einem Block vorhanden sein, auch wenn die Transaktion einen Zustand darstellt, der vor dem Block selbst ungültig ist (zum Beispiel, wenn Eth auf der Zielkette für den Austausch vorhanden ist, obwohl der Benutzer vor dem Block keines hat), um dieses vollständige Bündel in einem Block auszuführen. Aus diesem Grund müssen wir dem Sequenzer vertrauen, dass er die gültigen Abhängigkeiten tatsächlich in das Cross-Rollup-Bündel aufgenommen hat. Man könnte nachträglich Beweise einreichen, um die Gültigkeit jeder Transaktion zu beweisen.

Dies ist etwas weniger wichtig, wenn Wrapped-Assets verwendet werden, da sie keinen Einfluss auf die native Liquidität haben, die in der L1 gespeichert ist, aber dennoch müssen Ausfallmechanismen vorhanden sein, um das Risiko eines bösartigen Sequenzers oder eines Fehlers im Code auszugleichen, der es ermöglichte, dass ein Transaktionspaket mit einer abhängigen Transaktion ausgeführt wurde, die rückgängig gemacht wurde.

Auswirkungen für Interessengruppen:

1. Benutzer
   Massive Upgrades im UX, die das Platzieren von Cross-Rollup-Limit-Orders in einem einzigen Block ermöglichen
2. Entwickler
   Müsste für die Aktivitäten zwischen Rollups rollup-übergreifend bewusst sein, wobei wahrscheinlich spezielle Precompiles genutzt werden. Anstatt nur Transaktionen müssen Entwickler in Bündeln denken, aber es ist wahrscheinlich, dass Superbuilder und maßgeschneiderte Rollup-Infrastruktur die meisten Entwicklerkomplexitäten abstrahieren könnten.
3. MEV-Sucher
   MEV-Sucher haben im Wesentlichen die gleiche Möglichkeit, L1-Strategien bei Cross-Rollup-Bundles einzusetzen, aber es hängt davon ab, wie die PBS (Proposer-Builder Separation) implementiert ist.
   → Cross-rollup-Bundles werden im Wesentlichen als einzelne Transaktion betrachtet, sodass MEV durch Front-Running oder Sandwiching dieser Bundles gefunden werden könnte, solange sie die Preise nicht außerhalb der tolerierten Schlupfbeträge bewegen (denn dann würde sich das gesamte Bundle zurückverwandeln und MEV-Versuche würden scheitern)
4. Rollups
   Müsste sich für die gemeinsame Sequenzinfrastruktur (einschließlich Superbuilder) entscheiden und auch den Zugriff auf das Brennen/Prägen von Eth für den gemeinsamen Sequenzer im Falle einer gemeinsamen Abrechnungsebene ermöglichen.
   Könnte MEV internalisieren, indem man Blockraum an Bauherren verkauft

6. Transaktionsniveau-Komponierbarkeit

Erforderliche Infrastruktur:

VM-Level-Änderungen // Gemeinsame Abwicklung // Superbuilders

Transaktionsbasierte Zusammensetzbarkeit bezieht sich auf das gleiche Maß an Funktionalität, das Smart Contracts auf einer EVM-Kette teilen. In diesem Fall könnte eine einzige Transaktion den Status über mehrere Rollups hinweg gleichzeitig aktualisieren und sicherstellen, dass alle Statusänderungen vor einem Aufruf rückgängig gemacht werden können, wenn der Aufruf nicht erfolgreich zurückkehrt. Im Wesentlichen kann ein atomares Bündel von Transaktionen in einer blockbasierten zusammensetzbaren Umgebung innerhalb einer einzigen Cross-Rollup- und Cross-VM-Transaktion durchgeführt werden. Dies erfordert VM-spezifische Änderungen für alle verbundenen Rollups sowie eine gemeinsame Abwicklungsschicht und einen Superbuilder.

Wir beschreiben hier auf hoher Ebene einen möglichen Mechanismus. (Dieser Aufbau geht nach unserem Wissen auf das Espresso-Team zurück). Zunächst reicht ein Benutzer eine Cross-Rollup-Transaktion bei allen Rollups ein, deren Zustand durch die Transaktion geändert wird oder bei einem Superbuilder, der Blöcke über alle beteiligten Rollups hinweg erstellen kann. Ein Superbuilder simuliert die Transaktion und bildet Listen von Ein- und Ausgabepaaren, eine für jedes beteiligte Rollup, die die erforderlichen und erwarteten Cross-Rollup-Nachrichten innerhalb der Transaktion spezifizieren. (Zu beachten ist, dass der Superbuilder dies nur tun kann, wenn er für einen bestimmten Zeitraum sichere Sequenzierungsrechte für alle beteiligten Rollups hat). Der Superbuilder sendet dann den simulierten Block an den Vorschlagenden jedes Rollups, zusammen mit den Listen der erwarteten Ein- und Ausgabepaare für jede Cross-Rollup-Transaktion. Während der Ausführung führt jedes Rollup seine eigene Zustandsübergangsfunktion wie gewohnt aus, vorausgesetzt, dass die Eingaben aus der Liste der Cross-Rollup-Transaktionen korrekt sind. Während der Abwicklung können die Ein-Ausgabe-Listen dann im Proof-Aggregationsphasen im gemeinsamen Abwicklungsschicht überprüft und als sicher nachgewiesen werden. Insbesondere, wenn eine erwartete Eingabe für eine Cross-Rollup-Transaktion nicht mit dem übereinstimmt, was ein anderes Rollup als Ausgabe angegeben hat, wird der Abwicklungsprozess die gesamte Cross-Rollup-Transaktion ablehnen.

Obwohl mit der Transaktionskomponierbarkeit auf Transaktionsebene nur begrenzte neue Funktionen freigeschaltet werden, kann die Entwicklererfahrung bei der Erstellung von Anwendungen für Cross-Rollup erheblich verbessert werden. Die Möglichkeit, dApps zu erstellen, die mit allen verbundenen Chains interagieren, ohne sich um Cross-Rollup-Bundles kümmern zu müssen, wird es weitaus einfacher machen, in einer Multi-Rollup-Landschaft zu innovieren. Darüber hinaus ist es möglich, dass sich neue Anwendungsfälle und Verhaltensweisen ergeben.

Es gibt viele offene Designfragen zur Transaktions-Level-Komponierbarkeit. Zum einen muss sorgfältig überlegt werden, wie Entwickler sich in oder aus Cross-Rollup-Aufrufen für ihre Smart Contracts ein- oder ausschalten können. Die Erlaubnis zur beliebigen Komponierbarkeit ohne Einschränkung bedeutet, dass wir zu einem monolithischen Rollup zurückkehren. Wir glauben, dass die Antwort hier darin besteht, dass Entwickler explizit angeben, wo die Cross-Rollup-Komponierbarkeit in ihren Verträgen erforderlich ist, zum Beispiel über einen Solidity-Modifier wie zusammensetzbardie bestimmte Einstiegspunkte des Vertrags als aufrufbarer Cross-Rollup markiert.

Auswirkungen für Interessengruppen

1. Benutzer:
   Die gleichen Auswirkungen wie die Block-Level-Komponierbarkeit mit zusätzlichen erweiterten Fähigkeiten wie Flash-Darlehen \
   → Die Benutzeroberfläche ist nahezu identisch mit der Verwendung einer Kette für DApps, die sich dafür entscheiden
2. Entwickler:
   Die Entwicklererfahrung verbessert sich massiv, da Dapp-Entwickler Verträge plattformübergreifend nativ aufrufen und Ausgaben aus diesen Aufrufen wie einzelne Rollup-Aufrufe verwenden können.
   → Superbuilder/Sequencer Infrastruktur muss immer noch die Transaktionen in Blöcken für die Rollups platzieren, die vom Cross-Rollup-Aufruf betroffen sind, muss jedoch nicht dieselben Bündel wie im Fall der Blockebene-Komponierbarkeit erstellen.
3. MEV-Sucher:
   Hohe MEV-Potenzial, da Cross-Rollup-Bundles jetzt im Wesentlichen äquivalent zu einzelnen Transaktionen auf einer Kette sind
4. Rollups:
   Würde VM-Ebene Änderungen erfordern, sowie die Teilnahme an einem gemeinsamen Sequenzer und einer gemeinsamen Abrechnungsschicht \
   Zusätzliche Vertrauensannahmen sind erforderlich, um den Zustand über Beweise zu überprüfen, aber Slashing-Mechanismen könnten die Last des Vertrauens verringern, indem sie dazu führen, dass man den Inputs und Outputs anderer Rollups vertrauen muss, bevor man den Zustand überprüfen kann.

Zusammenfassung und Ökosystemkarte

Nachdem wir die technischen Details jeder Ebene der hier definierten Interoperabilität durchlaufen haben, können wir zusammenfassen:

1. Shared Settlement ermöglicht plattformübergreifende Swaps ohne externe Verpackung von Vermögenswerten und schafft in-Protokoll-Kommunikationswege zwischen allen verbundenen Rollups
2. Geteilte Sequenzierung/Superbuilders ermöglichen Garantien für die Ausführung des nächsten Blocks in Cross-Rollup-Bundles
3. Block-Level Composability ermöglicht die Erstellung komplexer, schneller, abhängiger Cross-Rollup-Bundles, wodurch ein nahezu komponierbares Ökosystem auf Smart-Contract-Ebene entsteht.
   → Mit der Hinzufügung eines gemeinsamen Abrechnungssystems können diese Cross-Rollup-Bundles erstellt werden, ohne externe Wrapped-Assets zu verwenden
4. Transaktionsübergreifende Komponierbarkeit ist möglich, und obwohl die neuen Anwendungsfälle, die sich eröffnen, möglicherweise für anspruchsvollere Benutzer sind, hat sie das Potenzial, das Entwicklungserlebnis für Cross-Rollup massiv zu verbessern.

Zum gegenwärtigen Zeitpunkt gibt es viele Projekte, die entstehen, um diese nativ interoperablen Ökosysteme zu schaffen. Hier ist eine Übersicht auf hohem Niveau der Landschaft:

Ökosystemkarte

Ökosystemkarte

Abschließende Gedanken

Es gibt immer noch offene Fragen zu den technischen Feinheiten innerhalb der in diesem Artikel dargelegten Rahmenbedingungen. Zum Beispiel kann der Aufbau von Bündeln in einem blockweisen zusammensetzbaren Ökosystem für Cross-Rollup-Limit-Orders detailliertere Designs zur Behandlung des Falls von teilweiser Erfüllung und Schlupftoleranz für Marktaufträge haben. Wir haben hier eine potenzielle Lösung angeboten, um ein Cross-Rollup-Limit-Order-Bundle rückgängig zu machen, wenn der Auftrag nicht vollständig ausgeführt ist, aber der Gestaltungsraum ist offen.

Darüber hinaus ist es sinnvoll, dies in Bezug zu setzen auf den gegenwärtigen Geist, der im Raum der Appchains wächst. Appchains sind Long-Tail-L2s, die entweder generalisiert oder permissioniert sind mit dem Ziel, spezifische verwandte Protokolle auf einer L2 zu isolieren. Es ist wahrscheinlich, dass wir, wenn wir die Block-Level-Komponierbarkeit erreichen, auch sehen werden, dass Appchain-Umgebungen aufgrund der nativen Komponierbarkeit zwischen allen verbundenen Netzwerken erheblichen Auftrieb erhalten.

Zum jetzigen Zeitpunkt ist es immer noch schwierig, Liquidität für diese Appchains bereitzustellen, aber sobald eine größere Kette als Einfahrt in die interoperable Umgebung verbunden ist, ist es wahrscheinlich, dass wir geschlossene Ökosysteme um gemeinsame Infrastrukturen herum sehen werden.

Eine weitere wichtige offene Frage ist, wie sich der Designraum um Superbuilder entwickeln wird. Die Entwicklung auf diesem Gebiet ist noch recht jung, und es ist noch nicht klar, was der effizienteste und effektivste Weg sein wird, ein Netzwerk von anspruchsvollen Buildern zu schaffen, die Cross-Rollup-Bundles erstellen können. Wo diese Cross-Rollup-Bundles optimal in einen Block aufgenommen werden sollen, und der Einfluss auf die Rollup-Einnahmen ist eine offene Frage, zu der verschiedene Strategien von vielen Teams erforscht werden.

Letztendlich wird die Zukunft wahrscheinlich eine Kombination aus in-Protokoll- und außerhalb-Protokoll-Brückenschlaglösungen beinhalten, die zusammenarbeiten, um einen weitaus besseren Interoperabilitätsprozess für alle bereitzustellen. Wir glauben, dass die in diesem Artikel definierte Entwicklung als Leitfaden für Entwickler und Bauherren dienen kann, die sich darauf konzentrieren, die Cross-Rollup-Interoperabilität für Endbenutzer nahtloser zu gestalten.

Es ist auch wahrscheinlich, dass es völlig neue Paradigmen für die Interaktion zwischen Rollups geben wird, die noch entdeckt werden müssen. Wenn Sie ein Entwickler sind, der an Ansätzen arbeitet, die sich auf die hier behandelten Themen ausdehnen oder nicht oben abgedeckt sind, bitte Kontakt aufnehmen(DMS sind geöffnet). Die Technologie hat endlich genug Reife erlangt, um echten Druck auf die Suche nach Lösungen für Liquiditäts-/Ökosystemfragmentierung auszuüben, und wir sind immer auf der Suche nach Gründern, die Risiken eingehen, um kreative Lösungen zu entwickeln.

Danksagungen

Dieser Artikel entstand aus einer unglaublich aufschlussreichen Rollup-Interoperabilitätsrunde, die von 1kx auf EthCC abgehalten wurde. Ein besonderer Dank geht anNoah Pravecek, Ellie Davidson, und Terryfür das Lesen früherer Versionen dieses Artikels und das Bereitstellen von Feedback sowieMarti, mteam, und Bo Dufür weitere Gespräche zum Thema.

Haftungsausschluss：

1. Dieser Artikel wird aus [nachgedrucktSpiegel] Weiterleiten des Originaltitels 'Vertrauenslose Interoperabilität zwischen Rollups: Landschaft, Konstruktionen und Herausforderungen', Alle Urheberrechte gehören dem Originalautor [Marshall Vyletel Jr.]. Bei Einwänden gegen diesen Nachdruck kontaktieren Sie bitte den Gate LearnTeam, und sie werden es umgehend bearbeiten.

2. Haftungsausschluss: Die in diesem Artikel zum Ausdruck gebrachten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.

3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel verboten.