Aggregierte Blockchains

Ich möchte zwei Behauptungen aufstellen:

1. Keine einzelne Kette, ob L1 oder L2, kann den Durchsatz unterstützen, der erforderlich ist, um die Internetskala zu erreichen.
2. Die Skalierung von Blockchains bedeutet die Skalierung des Zugangs zu Liquidität und Shared State. Das Hinzufügen von Blockspace über mehrere Chains funktioniert nicht, wenn es die Liquidität fragmentiert.

Dies stellt eine Herausforderung sowohl für die modulare als auch für die monolithische Sichtweise der Blockchain-Skalierbarkeit dar. (1) ist eine Herausforderung für die monolithische Sichtweise, die besagt, dass eine einzelne Kette mit hohem Durchsatz der beste Weg zur Skalierung ist. (2) ist eine Herausforderung für die modulare Sichtweise, denn es bedeutet, dass ein Multi-Chain- oder Multi-Rollup-Ökosystem nicht ausreicht, um in einem sinnvollen Sinne zu skalieren: Verbesserung des Zugangs zu gemeinsamem Zustand und Liquidität.

Wenn (1) und (2) wahr sind, erfordert die Lösung des Skalierbarkeitsproblems die Skalierung des Zugriffs auf den gemeinsamen Zustand und die Liquidität über viele Chains hinweg. Die Lösung von Polygon ist der Aggregations-Layer oder "AggLayer". Der AggLayer bietet Sicherheit für nahezu sofortige Cross-Chain-Transaktionen und ermöglicht einen einheitlichen Zustand und eine einheitliche Liquidität über Chains hinweg.

In diesem Beitrag erfahren Sie, was der AggLayer ist, wie er funktioniert und wie er sich von einem gemeinsam genutzten Sequenzer oder Proof unterscheidet.

Das Problem

Es gibt ein Problem mit L2s: Liquidität und Status sind über Rollups und L1 hinweg fragmentiert.

Das ist aus Sicht der Benutzerfreundlichkeit schlecht, weil es Komplexität mit sich bringt, aber es ist auch teuer. Fragmentierte Liquidität bedeutet höhere Slippage und schlechtere Ausführung. Bei optimistischen Rollups (ORs) müssen Benutzer teure Bridges von Drittanbietern bezahlen, um die siebentägige Auszahlungsverzögerung zu vermeiden. Sogar ZK-Rollups (ZKRs) verlangen von den Nutzern, dass sie für vertrauenslose Cross-Chain-Transaktionen zu Ethereum wechseln.

Endgültigkeit und Gültigkeit

Hier erfahren Sie, warum vertrauenslose Cross-Chain-Transaktionen mit geringer Latenz derzeit nicht möglich sind.

Angenommen, es gibt zwei Rollups, Kette A und Kette B, die sich eine Brücke zu L1 teilen. Alice auf Kette A möchte Bob auf Kette B bezahlen, also sperrt oder verbrennt Alice Token auf Kette A, um auf Kette B zu übertragen.

Zwei Dinge sind erforderlich, damit Chain B diese Token sicher an Bob gutschreiben kann.

1. Der Stapel, der Alices Transaktion enthält, muss auf Ethereum L1 abgeschlossen werden.
2. Kette B muss in der Lage sein, zu überprüfen, ob der resultierende Status von Kette A nach Alices Transaktion gültig ist.

Wenn der Stapel mit Alices Transaktionen auf Ethereum nicht abgeschlossen ist, könnte Kette A mit Kette B gleichbedeutend sein und doppelt ausgeben, indem sie Alices Gelder auf Kette A behält und Bobs Gelder auf Kette B prägt. Wenn Kette B keinen Gültigkeitsnachweis für A prüft, könnte Kette A eine ungültige Transaktion enthalten und Gelder von B stehlen.

(1) und (2) bedeuten, dass vertrauenslose Cross-Chain-Transaktionen keine geringe Latenz aufweisen können. (1) erfordert derzeit 12 Minuten, während (2) eine Wartezeit für die Dauer des Challenge-Zeitraums in OPs und einige Minuten für die Proof-Generierung in ZKRs erfordert.

Eine gute UX ist mit einer Latenz von 20 Minuten nicht vereinbar. Die Aggregationsschicht wurde entwickelt, um dieses Problem zu lösen.

Die Aggregationsschicht

Polygon ist ein Ökosystem von ZK-betriebenen L2s, die sich auf Ethereum niederlassen. Die Aggregationsschicht ist ein dezentrales Protokoll, das von gestakten Knoten betrieben wird und Sicherheit für kettenübergreifende Transaktionen mit geringer Latenz und eine einheitliche Bridge gewährleistet [1].

"Sicherheit" bedeutet in diesem Zusammenhang:

Es ist unmöglich, dass der Status eines Rollups auf Ethereum finalisiert/abgerechnet wird, wenn dieser Chain-Status auf einem ungültigen oder nicht finalisierten Zustand einer anderen Chain beruht oder wenn er eine Transaktion aus einem atomaren [2]-Bundle enthält, das nicht erfolgreich auf allen anderen Chains ausgeführt wurde.

Mit anderen Worten, ein Zustand von Chain B kann nicht auf Ethereum finalisiert werden, wenn er von einem ungültigen oder nicht finalisierten Zustand von Chain A abhängt.

Diese Garantie ist wichtig. Es ermöglicht Chain B, sicher mit Chain A mit extrem niedriger Latenz zu interagieren, bevor der Status von Chain A auf Ethereum abgeschlossen ist oder ein Beweis generiert wurde.

Funktionsweise des Aggregations-Layers

Die Aggregationsschicht funktioniert in drei Phasen. Angenommen, Chain A ist eine ZK-betriebene Chain, die im Polygon-Ökosystem ausgeführt wird.

1. Vorbestätigung: Kette A sendet einen Header für einen neuen Block/Batch A1 an die
2. AggLayer zusammen mit einem leichten Client-Proof. Die Kopfzeile enthält Obligos für alle
3. andere Blöcke und Bündel, von denen Ar abhängt (B1, C1 usw.). Wenn der neue Stapel
4. ohne Gültigkeitsnachweis akzeptiert werden, wird es vom AggLayer als "vorbestätigt" betrachtet.
5. Bestätigung: Kette A oder ein beliebiger vollständiger Knoten von A erzeugt einen Beweis für A1 und übermittelt ihn an den AggLayer. Sobald der Proof durch den AggLayer verifiziert wurde, wird A1 bestätigt, wenn alle Chargen, von denen es abhängt, ebenfalls bestätigt werden.
6. Finalisierung: Nachdem A1 bestätigt wurde, wird der Nachweis zusammen mit Stapeln aus anderen Rollups zu einem einzigen Nachweis zusammengefasst, der auf Ethereum veröffentlicht wird. Der aggregierte Beweis erzwingt, dass abhängige Kettenzustände und Bündel konsistent sind.

Ketten können den Kompromiss zwischen Latenz und Live-Garantien für sich selbst navigieren. Eine Chain kann sich nach dem Vorbestätigungsschritt für Cross-Chain-Transaktionen mit sehr niedriger Latenz für die Interoperabilität mit einer anderen Chain entscheiden, aber grundsätzlich ist dieses Modell mit Chains kompatibel, die auf die Bestätigung oder sogar auf den Abschluss warten.

Die Sicherheitsgarantie für Cross-Chain-Transaktionen wird im dritten Schritt durchgesetzt. Schauen wir uns genauer an, wie dieses Design eine sichere Cross-Chain-Interaktion ermöglicht.

Asynchrone Interoperabilität

Nehmen wir das erste Beispiel eines Cross-Chain-Transfers. Alice auf Kette A möchte einige Token in Block A1 sperren oder verbrennen, um Token zu prägen und an Bob auf Chain B zu übertragen. Wenn Chain B nicht wartet, bis A1 auf Ethereum mit einem gültigen Beweis abgeschlossen ist, könnte Chain A Chain B einen ungültigen Zustand geben.

Der Aggregation Layer löst dieses Problem auf einfache Weise. Chain B kann vorübergehend davon ausgehen, dass A1 gültig ist und auf Ethereum finalisiert wird, ohne auch nur auf einen Beweis warten zu müssen. Der Sequenzer für Kette B verpflichtet sich zur beanspruchten Kette A-Zustandswurzel A1 als Abhängigkeit im Header für B1 (als B1A1), bevor er an die Aggregationsschicht übermittelt wird. Die Latenz, die erforderlich ist, damit Kette B B1 erstellt, verringert sich von 20 Minuten auf höchstens einige Sekunden.

Im Schritt Bestätigung erstellt die Aggregationsschicht ein Abhängigkeitsdiagramm für jeden übermittelten Block/Batch. Wenn z.B. A1 von B1 abhängt, das wiederum von B1 abhängt, wird C1 bestätigt, sobald ein Beweis πC1 vorgelegt wird. Aber selbst wenn πA1 empfangen wird, wird πA1 nur mit πC1 und πB1 bestätigt.Der entscheidende Aspekt dieses Designs besteht darin, dass die Beweisaggregationsschaltung die Konsistenz über Abhängigkeiten hinweg erzwingt. Wenn B1A1 nicht mit dem Block A1 übereinstimmt, den Kette A einreicht, oder ein Beweis für A1′ fehlt, kann B1 nicht in den aggregierten Stapel aufgenommen werden, der auf Ethereum abgeschlossen wurde.

Dieser Mechanismus garantiert, dass, wenn Kette A einen ungültigen Block gleichzusetzen oder übermittelt, z. B. A1′, jeder Batch, der von einer ungültigen oder zweideutigen Zustandswurzel für Kette A abhängt, nicht auf Ethereum abgeschlossen/abgerechnet werden kann. Selbst wenn der AggLayer selbst zweideutig ist, haben Ketten eine kryptographische Garantie, dass jeder Block, der von einem ungültigen oder mehrdeutigen Block abhängt, nicht abgeschlossen werden kann, da zwei Beweise für Kettenzustände, die inkonsistent oder ungültig sind, nicht in der Beweisaggregationsschaltung aggregiert werden können. Dadurch wird sichergestellt, dass die oben beschriebene Sicherheitseigenschaft erhalten bleibt.

Atomare Interoperabilität

Der Sicherheitsmechanismus kann auf das Atomgehäuse ausgeweitet werden. Angenommen, ein Benutzer übermittelt ein atomares Bündel von Transaktionen an mehrere Chains. Dieses Bundle ist so geordnet, dass das Ergebnis der Ausführung der Transaktion auf Chain A an Chain B übergeben wird, und ebenso wird der aktualisierte Status von Chain B an Chain C übergeben usw. Wenn alle Transaktionen über alle Chains hinweg erfolgreich ausgeführt werden, ist das Bundle enthalten. Andernfalls wird es abgelehnt.

Es wäre ideal, die Möglichkeit zu bieten, atomare Transaktionen einzuschließen, ohne:

1. Der Betreiber von Kette B muss einen vollständigen Knoten für alle anderen Ketten betreiben, die in einem Bundle enthalten sind. oder
2. Akzeptieren Sie das Risiko, dass das Bundle teilweise auf Ethereum enthalten sein könnte (was den teilnehmenden Chains schadet).

Dies wirft ein ähnliches Sicherheitsproblem auf wie im asynchronen Fall: Kette A kann einen Batch mehrdeutig machen und senden, der das atomare Bündel nicht enthält, oder ein ungültiges Ergebnis an Kette B senden.

Glücklicherweise kann derselbe Mechanismus aus dem asynchronen Fall für den atomaren Fall wiederverwendet werden. Chain B verpflichtet sich zu Bundles und erhält Transaktionsergebnisse von anderen Chains. Die Aggregationsschicht (und die Proof-Aggregationsschaltung) prüft, ob die Bündel über die Ketten hinweg konsistent sind. Ein Batch, der ein Bundle aus Chain B enthält, kann nur dann auf Ethereum finalisiert/abgerechnet werden, wenn alle Transaktionen im Bundle erfolgreich ausgeführt werden.

Cross-Chain-Composability

Die Aggregationsschicht ermöglicht eine Cross-Chain-Composability mit extrem niedriger Latenz durch asynchrone Cross-Chain-Aufrufe. Dies ist ein unglaublich mächtiges Primitiv: Verträge können Kontrakte auf anderen Chains mit sehr niedriger Latenz sicher aufrufen, ohne auf die Endgültigkeit von Ethereum zu warten. Ein Benutzer könnte über die OKX-Chain auf Polygon einsteigen und mit einem Klick sofort in einen hochliquiden Kreditmarkt auf Aave auf einer anderen Chain einzahlen, ohne aus einem verpackten synthetischen Vermögenswert aussteigen zu müssen.

Emergente Koordinationsinfrastruktur

Der AggregationLayer garantiert, dass Cross-Chain-Interaktionen nahezu sofort sicher sind [3]. Aber das ist nur die halbe Miete. Wie teilen und vertrauen Chain-Betreiber die Chain-Zustände der anderen? Wie koordinieren sie die Herstellung von Atombündeln?

Ein Designziel für den AggLayer ist, dass er minimal sein sollte. Sein Zweck ist es, die Sicherheit zu gewährleisten und eine Grundlage zu schaffen, die es jedem ermöglicht, eine Koordinationsinfrastruktur aufzubauen, die in einer Vielzahl von verschiedenen Umgebungen Leben bietet.

Die Betreiber von Ketten können je nach ihren Vertrauensannahmen frei zwischen emergenten Koordinationsmechanismen wählen - dazu gehören Relays, Shared Prover-Infrastruktur oder Shared Validity Sequencer [4]-Cluster. Diese schützen Ketten vor Lebendigkeitsproblemen, wenn sie von anderen Kettenzuständen oder Bündeln abhängig sind.

Das Polygon-Ökosystem priorisiert Auswahl und Souveränität für Chains. Chains können ihre eigenen modifizierten Ausführungsumgebungen betreiben, ihre eigenen Token für Staking- und Gasgebühren verwenden, ihre eigenen Datenverfügbarkeitsmechanismen wählen usw. In ähnlicher Weise sollten Ketten entscheiden, wie sie mit Kompromissen zwischen Interoperabilität und dem Risiko von Live-Fehlern umgehen. Es gibt mehrere Möglichkeiten:

1. Kette B kann sich vollständig gegen die schnelle Interoperabilität und die Aggregatorschicht entscheiden. Es kann einfach Chargen und Proofs direkt an Ethereum übermitteln und die Fertigstellung wird nie verzögert.
2. Kette B kann den Zustand von Kette A nur akzeptieren, wenn der Zustand von Kette A vom AggLayer bestätigt wird. Kette B wird nur verzögert, wenn der AggLayer gleichbedeutend ist.
3. Kette B kann den Zustand von Kette A übernehmen, wenn Kette A vom AggLayer vorab bestätigt wurde. Kette B verzögert sich, wenn der AggLayer gleichbedeutend ist oder Kette A keinen Beweis erbringt.
4. Kette B kann den Zustand von Kette A in einer Peer-to-Peer-Umgebung akzeptieren, ohne zu überprüfen, ob Kette A auf dem AggLayer vorab bestätigt ist. Kette B verzögert sich, wenn Kette A einen zweideutigen Beweis erbringt oder nicht erbringt.

Es ist wichtig zu beachten, dass Benutzer keine Liveness-Fehler verursachen können, sondern nur Ketten mit schlechtem Verhalten oder Fehlfunktionen. Mehrdeutigkeiten und das Einreichen eines ungültigen Blocks können stark bestraft werden, entweder durch Slashing oder durch das Auswerfen von Ketten aus dem AggLayer und den Ausschluss ihrer Fähigkeit zur nahtlosen Interoperabilität. Daher sollte ein Lebendfehler äußerst selten sein.

Chains können zusätzliche Vorkehrungen treffen, um das Risiko von Liveness-Problemen zu minimieren, indem sie White- oder Blacklists anderer Chains führen, mit denen sie zusammenarbeiten, und die Anzahl der Chains begrenzen, die gemeinsam an einer Charge beteiligt sein können. Sie könnten sich darauf verlassen, dass Drittanbieter vollständige Knoten betreiben, um sicherzustellen, dass es einen Backup-Beweis gibt, wenn eine Kette offline geht, bevor sie einen Beweis erbringen kann.

Der Mechanismus, mit dem sich Ketten koordinieren, um Atombündel aufzunehmen, ist ebenfalls flexibel. Beispielsweise könnte eine Teilmenge von Ketten in einem Cluster für die Sequenzierung der gemeinsamen Gültigkeit zusammenarbeiten, um eine extrem niedrige Latenz zu erzielen, oder sie könnten sich auf Relays verlassen.

Ein kryptoökonomisch gesicherter Relayer könnte die Interoperabilität zwischen den Ketten A und B ermöglichen, indem er einen vollständigen Knoten für beide Ketten betreibt und bestätigt, dass die Zustände jeder Kette gültig sind. Selbst wenn Kette A oder B eine neue Charge vorab bestätigt und dann offline geht, kann die gemeinsam genutzte Prüfinfrastruktur eingreifen, um einen Nachweis zu generieren.

Sie können sich vorstellen, dass auf der Grundlage der Sicherheit durch den AggLayer eine neuartige Koordinationsinfrastruktur entsteht, die neue und bessere Formen der Interoperabilität und der gemeinsamen Liquidität ermöglicht. Entscheidend ist, dass das gesamte Polygon-Ökosystem nicht die gleiche Infrastruktur teilen oder den Annahmen vertrauen muss. Es muss nicht unter einem einzigen Shared-Validity-Sequenzer oder -Proof betrieben werden. Dies ist ein äußerst wichtiger Vorteil gegenüber OPs.

Schließen

Die Aggregationsschicht ermöglicht es uns im Grunde, ein Multi-Chain-Ökosystem zu schaffen, das sich anfühlt, als würde man eine einzige Chain verwenden. Es ist die Synthese der monolithischen und modularen Thesen: einheitlicher Zustand, Liquidität und Composability mit der unbegrenzten Skalierbarkeit eines Multi-Chain-Ökosystems.

Aggregation in ZK vs. optimistischen Systemen

Eine Vision, die grundsätzlich nur ZK-basierten Systemen zur Verfügung steht. Ich werde diesen Punkt in einem zukünftigen Beitrag weiter ausführen, aber optimistische Ökosysteme, die eine schnelle Interoperabilität ermöglichen wollen, müssen sich auf Shared-Validity-Sequenzer verlassen. Dies ist ein schlechter Deal für Ketten: Es schränkt sie ein, Sequenzergebühren und MEV neu zu verteilen, Shared-Validity-Sequenzer zwingen Ketten, möglicherweise Einschränkungen ihrer Ausführungsumgebungen zu akzeptieren, und Interoperabilität in OR-basierten Systemen zwingt Ketten, zusätzliche Vertrauensannahmen im Austausch für geringe Latenz zu akzeptieren.

Darüber hinaus bricht die Cross-Chain-Interoperabilität eine wichtige Eigenschaft für OPs. Mit Single-Chain-OPs kann jeder einen vollständigen Knoten für einen OR ausführen und sofort bestätigen, dass Transaktionen gültig und abgeschlossen sind, sobald sie in L1s gebucht werden. Dies ist im Multi-Chain-Fall nicht mehr der Fall - jetzt ist es notwendig, für jede Kette, mit der der OR interoperiert, einen vollständigen Knoten zu betreiben.

Im Gegensatz dazu ist die Vision von Polygon eine, in der Ketten souverän sind. Sie können jede beliebige Ausführungsumgebung verwenden, sich auf alle zentralen oder dezentralen Sequenzer verlassen und Kompromisse zwischen Cross-Chain-Latenz und Liveness für sich selbst bewältigen.

Dies ist eine Vision, die das bestehende Internet widerspiegelt. Das Internet ist eine elastisch skalierbare, erlaubnisfreie und einheitliche Umgebung. Ebenso ist der AggLayer skalierbar und erlaubnisfrei - er erlegt den teilnehmenden Ketten keine Einschränkungen auf - und ermöglicht es den Benutzern, Assets und Zustände nahtlos über das Ökosystem hinweg zu verschieben und eine einheitliche Schnittstelle für die Wertschöpfungsschicht des Internets zu präsentieren.

Das ist die Zukunft von Polygon: nicht monolithisch, nicht vollständig modular, sondern aggregiert.

[1] Ein Teil der Gewährleistung einer einheitlichen Liquidität besteht darin, die schreckliche UX von verpackten synthetischen Token auf Brücken loszuwerden. Benutzer der LxLy-Bridge von Polygon können Assets nahtlos über Chains hinweg übertragen und dabei die Fungibilität beibehalten. Um dies jedoch sicher zu tun, müssen wir uns vor der Sicherheit des schwächsten Glieds schützen - oder vor einem Angreifer, der eine einzelne Kette beschädigt und alle Gelder über alle Chains in der Bridge abzieht. Wie das geht, werde ich in einem zukünftigen Beitrag besprechen, aber der AggLayer kann den Schritt der Proof-Aggregation nutzen, um die Buchhaltung auf Chain-Ebene durchzusetzen und die Sicherheit der schwächsten Glieder zu vermeiden.

[2] Wenn ich mich auf atomare Cross-Chain-Transaktionen beziehe, meine ich die Möglichkeit für einen Benutzer, ein "Bündel" oder eine Reihe von Transaktionen über mehrere Chains hinweg einzureichen. Das Atomic Bundle hat die Eigenschaft, dass seine Transaktionen nur dann in jede relevante Kette aufgenommen werden, wenn alle Transaktionen erfolgreich ausgeführt werden. Wenn eine einzelne Transaktion fehlschlägt, kann das Bundle nicht in eine Kette aufgenommen werden.

Das einfachste Beispiel ist wieder unser Cross-Chain-Transfer. Nehmen wir an, Alice möchte 1 ETH an Bob senden, aber Alice ist auf Kette A und Bob auf Kette B. Unter der Annahme einer gemeinsamen nativen Bridge für beide Rollups kann Alice ihre ETH auf Kette A verbrennen und ETH auf Kette B prägen, die an Bob übertragen wird. Aber es ist wichtig zu garantieren, dass sie ETH nicht prägen kann, ohne sie zu verbrennen oder umgekehrt - entweder könnte sie ihre ETH verlieren oder die Brücke untersichern.

Aus diesem Grund sind atomare Transaktionen so wichtig. Um Interaktionen zwischen Chains mit geringer Latenz zu ermöglichen und die Nutzung des Polygon-Ökosystems wie die Verwendung einer einzigen Chain wirken zu lassen, sind atomare Garantien erforderlich.

[3] Dies ist ein subtiler Punkt, aber aus der Perspektive des Ökosystems - der AggLayer bietet Sicherheit, aber aus der Perspektive einer einzelnen Kette priorisiert dieses Design die Lebendigkeit über die Sicherheit, da Kette B von einem ungültigen Kettenzustand von Kette A abhängen kann. In diesem Fall wird Kette B vom AggLayer nicht akzeptiert (erzwungen durch die Proof-Aggregationsschaltung) und muss einen neuen Block ohne die Abhängigkeit von A erstellen.

[4] Unser Ansatz als Ganzes verdankt viel dem Shared Validity Sequencing Design von Umbra Research.

09.02.24 - Dieser Entwurf wurde aktualisiert, um einige Vergleiche zwischen Aggregation und gemeinsamer Sequenzierung zu verdeutlichen. Die aggregierte These beruht auf Mechanismen wie gemeinsam genutzten Sequenzern, Relays und Buildern, um die Koordination zwischen den Ketten zu erleichtern. Die agg-Schicht wiederum garantiert Sicherheit.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [[Brendan Farmer], Alle Urheberrechte liegen beim ursprünglichen Autor [Brendan Farmer]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten 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, Verbreiten oder Plagiieren der übersetzten Artikel verboten.