• Originaltitel: Celestia-Forscher analysiert 6 Rollup-Varianten: Sequencer=Aggregator+Header-Generator

Hinweis: Um das Rollup-Modell leichter verständlich und analysieren zu können, hat der Celestia-Forscher NashQ den Rollup Sequencer in zwei logische Einheiten unterteilt - den Aggregator und den Header Producer. Gleichzeitig unterteilte er den Prozess der Transaktionsbestellung in drei logische Schritte: Inklusion, Bestellung und Ausführung.

Geleitet von diesem analytischen Denken sind die sechs Hauptvarianten von Sovereign Rollup klarer und leichter zu verstehen. NashQ diskutierte ausführlich die Zensurresistenz und Lebendigkeit der verschiedenen Rollup-Varianten sowie die Mindestkonfiguration jedes Rollup-Variantenknotens in der Minimierung des Vertrauenszustands (d. h. um einen vertrauenswürdigen Zustand zu erreichen, mindestens, welche Arten von Knoten Rollup-Benutzer ausführen müssen).

Obwohl dieser Artikel Rollup aus der Perspektive von Celestia analysiert, was sich von der Art und Weise unterscheidet, wie die Ethereum-Community das Rollup-Modell analysiert, ist dieser Artikel angesichts der vielen Verbindungen zwischen Ethereum Rollup und Celestia Sovereign Rollup sowie des zunehmenden Einflusses des letzteren auch für Ethereum-Enthusiasten äußerst lesenswert.

Was ist ein Rollup?

Rollups sind Blockchains, die ihre Transaktionsdaten auf eine andere Blockchain übertragen und deren Konsens und Datenverfügbarkeit erben.

Warum ändere ich hier "Block" in "Transaktionsdaten"? Lassen Sie mich Ihnen den Unterschied zwischen einem Rollup-Block und Rollup-Daten erklären und Ihnen zeigen, dass der minimale Rollup nur bei unserer ersten Variante Rollup-Daten benötigt.

Ein Rollup-Block ist eine Datenstruktur, die die Blockchain in einer bestimmten Höhe darstellt. Er besteht aus Rollup-Daten und Rollup-Header. Und Rollupdaten sind entweder ein Stapel von Transaktionen oder der Zustandsunterschied zwischen Transaktionsbatches.

Variante 1 : Basierend auf pessimistischem Rollup

Der einfachste Weg, ein Rollup zu erstellen, beginnt damit, dass ein Benutzer Transaktionen in einer anderen Blockchain bucht. Wir werden diese Blockchain als Konsens- und Datenverfügbarkeitsschicht bezeichnen, aber ich werde sie in allen folgenden Diagrammen auf DA-Layer verkürzen. (Hinweis: ähnlich wie Layer1, auf das in der Ethereum-Community oft Bezug genommen wird).

In unserer ersten Variante muss jeder Rollup-Knoten alle Transaktionen auf der Blockchain wiedergeben, um den neuesten Stand zu überprüfen. Wir haben gerade ein pessimistisches Rollup erstellt!

Ein pessimistischer Rollup ist ein Rollup, das nur vollständige Knoten unterstützt, die alle Transaktionen im Rollup wiedergeben, um seine Gültigkeit zu überprüfen.

Aber wer ist in diesem Fall der Sequenzer? Keine Entität führt die Transaktionen tatsächlich aus, abgesehen von den vollständigen Rollupknoten selbst. Normalerweise würde ein Sequenzer die Transaktionen aggregieren und einen Rollup-Header erzeugen, aber in diesem Fall gibt es keinen Header!

Um die Diskussion zu erleichtern, teilen wir den Sequenzer in zwei logische Einheiten auf: Der Aggregator und der Header-Produzent unterscheiden ihn. Eine Entität muss zustandsbewusst sein (d. h. den Zustand ausführen, um den Header zu berechnen), aber der Aggregator muss den Zustand nicht verstehen, um ihn aggregieren zu können.

Sequenzierung ist der Prozess der Aggregation und Header-Produktion.

Aggregation ist der Prozess der Batchverarbeitung von Transaktionen in einem Batch. Ein Stapel von Transaktionen besteht aus einer oder mehreren Transaktionen. (Hinweis: Batch ist der Teil der Daten im Rollup-Block mit Ausnahme des Headers).

Die Header-Produktion ist der Prozess der Erstellung des Rollup-Headers.

Rollup-Header sind Metadaten über den Block, die mindestens eine Verpflichtung zu den Transaktionen in diesem Block enthalten. (Hinweis: Das Commitment bezieht sich hier auf das Commitment zur Richtigkeit der Transaktionsverarbeitungsergebnisse).

Durch die obige Perspektive können wir sehen, wer die Rolle der einzelnen Komponenten des Rollups spielt. Schauen wir uns zunächst den Aggregator-Teil an. Der bereits erwähnte pessimistische Rollup hat keinen Header-Erstellungsprozess, und die Benutzer veröffentlichen Transaktionen direkt auf der DA-Schicht, was bedeutet, dass das DA-Layer-Netzwerk im Wesentlichen als Aggregator fungiert.

Ein Pessimistic Rollup ist eine Variante des Rollups, bei der der Aggregationsschritt an die DA-Schicht delegiert wird. Es hat keinen Sequenzer. Manchmal wird diese Art von Rollup auch als "basiertes Rollup" bezeichnet.

Das basierte Rollup hat die gleiche Zensurresistenz und Lebendigkeit wie der DA-Layer (Aktivität misst die Reaktionsgeschwindigkeit des Systems auf Benutzeranfragen). Wenn Benutzer dieses Rolluptyps einen Zustand mit minimaler Vertrauenswürdigkeit erreichen möchten (am ehesten vertrauenswürdig), müssen sie mindestens einen DA-Layer-Light-Knoten und einen Rollup-Vollknoten ausführen.

Variante 2: Pessimistisches Rollup mit einem Shared Aggregator

Lassen Sie uns die pessimistische Aggregation mit freigegebenen Aggregatoren besprechen. Diese Idee wurde von Evan Forbes in seinem Forenbeitrag über Shared Sequencer Design vorgeschlagen. DasDie wichtigste Annahme ist, dass ein gemeinsam genutzter Sequenzer die einzige formale Möglichkeit ist, Transaktionen zu sequenzieren. Evan erklärt die Vorteile von gemeinsam genutzten Sequenzern wie folgt:

"Um eine Web2-äquivalente UX freizuschalten, müssen die gemeinsam genutzten Sequenzer [...] kann schnelle weiche Zusagen machen (Hinweis: keine sehr zuverlässige Garantie). Diese weichen Verpflichtungen bieten ein willkürliches Versprechen für die endgültige Reihenfolge von Transaktionen (d. h., sie versprechen, dass sich die Transaktionsreihenfolge nicht ändert) und können verwendet werden, um vorzeitig aktualisierte Versionen des Zustands zu erstellen (die Finalisierung ist jedoch zu diesem Zeitpunkt noch nicht abgeschlossen).

Sobald bestätigt wurde, dass die Blockdaten auf dem Baselayer gepostet werden (s/b bezieht sich auf DAlayer), kann der Status als endgültig betrachtet werden."

Da wir immer noch ein pessimistisches Rollup sind, haben wir nur Rollup-Vollknoten und keine Light-Knoten. Jeder Knoten muss alle Transaktionen ausführen, um die Gültigkeit zu gewährleisten. In diesem System gibt es keine Lichtknoten, daher ist kein Rollup-Header erforderlich, auch bekannt als Header-Producer. (Hinweis: Im Allgemeinen muss ein Light Node einer Blockchain keine kompletten Blöcke synchronisieren, sondern empfängt nur Blockheader)

Da es keinen Rollup-Header-Produktionsschritt gibt, muss der oben erwähnte Rollup-Shared-Sequencer keine Transaktionen für Statusaktualisierungen ausführen (eine Voraussetzung für die Header-Produktion), sondern umfasst nur den Prozess der Aggregation von Bewegungsdaten. Daher ziehe ich es vor, es einen gemeinsamen Aggregator zu nennen.

In dieser Variante müssen Rollupbenutzer mindestens Folgendes in einem vertrauensminimierten Zustand ausführen:

DA-Layer-Lichtknoten + Lichtknoten des gemeinsam genutzten Aggregatornetzwerks + Rollup-Vollknoten.

Zu diesem Zeitpunkt ist es erforderlich, den veröffentlichten Aggregator-Header (der sich nicht auf den Rollup-Header bezieht) über den Light-Knoten des gemeinsam genutzten Aggregatornetzwerks zu überprüfen. Wie bereits erwähnt, übernimmt der gemeinsam genutzte Aggregator die Aufgabe der Transaktionssortierung. Im veröffentlichten Aggregator-Header enthält er eine kryptografische Zusage, die dem Batch entspricht, den er auf der DA-Schicht veröffentlicht hat.

Auf diese Weise kann der Betreiber des Rollup-Knotens bestätigen, dass der vom DA-Layer empfangene Batch vom freigegebenen Aggregator und nicht von anderen erstellt wurde.

(Da der oben enthaltene Inhalt relativ obskur ist, können Sie das Diagramm noch einmal lesen)

Inklusion ist der Prozess, durch den eine Transaktion in die Blockchain aufgenommen wird.

Ordering ist der Prozess der Anordnung von Transaktionen in einer bestimmten Reihenfolge in der Blockchain.

Die Ausführung ist der Prozess, durch den die Transaktionen in der Blockchain verarbeitet werden und ihre Auswirkungen auf den Zustand der Blockchain angewendet werden.

Da der gemeinsam genutzte Aggregator die Aufnahme und Reihenfolge steuert, erben wir seine Zensurresistenz.

Wenn wir annehmen, L_ss die Lebendigkeit des gemeinsamen Aggregators und L_da die Lebendigkeit der DA-Schicht ist, dann ist die Lebendigkeit dieses Schemas L = L_da & L_ss. Mit anderen Worten: Wenn eines der Systeme einen Verfügbarkeitsfehler aufweist, weist auch das Rollup einen Verfügbarkeitsfehler auf.

Der Einfachheit halber werde ich liveness als booleschen Wert verwenden. Wenn der freigegebene Aggregator ausfällt, können wir nicht mit dem Rollup fortfahren. Wenn der DA-Layer ausfällt, könnten wir mit den weichen Zusagen des gemeinsamen Aggregators fortfahren. Dennoch würden wir uns auf den Konsens und die Datenverfügbarkeit des gemeinsamen Aggregators verlassen, was schlechter wäre als der ursprüngliche DA-Layer.

Lassen Sie uns die Zensurresistenz der obigen Rollup-Lösung weiter untersuchen:

In diesem Schema kann der DA-Layer bestimmte Transaktionen nicht zensieren. (Hinweis: Die Transaktionsüberprüfung kann es oft verweigern, bestimmte Transaktionen in die Kette hochzuladen). Es können nur ganze Rollupbatches zensiert werden, die der freigegebene Aggregator bereits aggregiert hat. (Ablehnung eines Stapels, der in den DA-Layer aufgenommen werden soll).

Gemäß dem Workflow des Rollups hat der Freigabeaggregator jedoch, wenn er den Transaktionsstapel an den DA-Layer übermittelt, die Transaktionssequenzierung bereits abgeschlossen, und die Reihenfolge zwischen den verschiedenen Stapeln wurde ebenfalls bestimmt. Daher hat diese Art der Transaktionsüberprüfung durch die DA-Schicht keine andere Wirkung, als die Endgültigkeit des Rollup-Ledgers zu verzögern.

Zusammenfassend glaube ich, dass der Schwerpunkt des Zensurwiderstands darin besteht, sicherzustellen, dass keine einzelne Instanz den Informationsfluss innerhalb des Systems kontrollieren oder manipulieren kann, während Liveness die Aufrechterhaltung der Funktionalität und Verfügbarkeit des Systems beinhaltet, selbst bei Netzwerkausfällen und gegnerischen Aktionen. Obwohl dies im Widerspruch zur aktuellen akademischen Mainstream-Definition steht, werde ich dennoch die Definition des Konzepts verwenden, die ich angegeben habe.

Variante 3: Pessimistischer Rollup mit basierter und gemeinsamer Aggregation

Auch wenn die Community die Vorteile eines gemeinsamen Aggregators genießt, wollen wir nicht darauf angewiesen sein und einen Fallback auf den DA-Layer haben. Wir werden die Bestellung zusammenführen und es den Benutzern ermöglichen, Transaktionen direkt an den DA-Layer zu übermitteln. Es kombiniert basierte und gemeinsam genutzte Aggregation.

Wir gehen davon aus, dass die endgültige Reihenfolge als alle Transaktionen interpretiert wird, die vom gemeinsamen Aggregator geordnet wurden, und dann alle darauf basierenden Transaktionen pro DA-Layer-Block. Wir nennen dies die Rollups-Fork-Auswahlregel.

Die Aggregation ist hier ein zweistufiger Prozess. Zunächst übernimmt der gemeinsam genutzte Aggregator die Führung und aggregiert einige Transaktionen. Dann aggregiert der DA-Layer mit den bereits bestellten Batches und Transaktionen, die der Benutzer direkt übermittelt hat.

Die Analyse des Zensurwiderstands ist jetzt komplexer. Der DA-Layer-Netzwerkknoten kann den vom freigegebenen Aggregator übermittelten Batch überprüfen, bevor der nächste DA-Layer-Block erstellt wird. Nachdem der DA-Layer-Knoten die Transaktionsdaten im Batch kennt, kann er den MEV-Wert extrahieren, eine vorab ausgeführte Transaktion mit seinem Konto im Rollup-Netzwerk initiieren und in den DA-Layer-Block aufnehmen, bevor er den vom freigegebenen Rollup-Aggregator übermittelten Batch einschließt.

Anscheinend ist die Finalität der Transaktionsreihenfolge, die durch die weiche Verpflichtung der dritten Art von Rollup-Variante garantiert wird, anfälliger als die oben erwähnte zweite Art von Rollup-Variante. In diesem Fall übergibt der gemeinsam genutzte Aggregator den MEV-Wert an den DA-Layer-Knoten. In diesem Zusammenhang empfehle ich den Lesern, sich den Vortrag über die profitable Zensur von MEV anzusehen.

Gegenwärtig gibt es einige Designlösungen, die die Fähigkeit von DA-Layer-Netzwerkknoten zur Ausführung solcher MEV-Transaktionen verringern, wie z. B. die Funktion "Reorganisationsfenster-Periode", die die Transaktionen, die direkt von Rollup-Netzwerkbenutzern an die DA-Schicht gesendet werden, verzögert. Sovereign Labs hat dies in seinem Designvorschlag mit dem Namen Based Sequencing with Soft Confirmations detailliert beschrieben, in dem das Konzept des "bevorzugten Sequenzers" vorgeschlagen wird.

Da MEV von dem von Ihnen gewählten Aggregator-Schema und der Fork-Choice-Regel des Rollups abhängt, werden einige keine und einige einige oder alle MEV an die DA-Schicht abgeben, aber das ist ein Thema für einen anderen Tag.

Was die Lebendigkeit betrifft, so hat dieses Rollup-Design einen Vorteil gegenüber einem gemeinsamen Aggregator. Wenn der freigegebene Aggregator einen Live-Ausfall aufweist, kann der Benutzer weiterhin Transaktionen an den DA-Layer senden.

Lassen Sie uns abschließend über das kleinste vertrauensminimierte Setup sprechen: einen DA-Layer-Light-Node + einen gemeinsam genutzten Aggregator-Light-Node + einen Rollup-Full-Node.

Zu diesem Zeitpunkt müssen wir noch die Header des freigegebenen Aggregators für unseren vollständigen Rollupknoten validieren, um Transaktionsbatches für seine Fork-Auswahlregel unterscheiden zu können.

Variante 4: Basiertes optimistisches Rollup mit einem zentralen Header-Producer

Beginnen wir mit dem Kochen einiger leichter Knoten mit einer Variante, die als basiertes optimistisches Rollup mit einem zentralisierten Header-Producer bezeichnet wird. In diesem Design wird die DA-Schicht verwendet, um Transaktionen zu aggregieren, aber wir führen einen zentralisierten Header-Producer ein, um Rollup-Light-Knoten zu ermöglichen.

Rollup-Light-Knoten können die Gültigkeit von Rollup-Transaktionen indirekt durch eine einzige Runde des Betrugsnachweises überprüfen. Der Lichtknoten nimmt eine optimistische Haltung gegenüber dem Generator des Rollup-Headers ein und nimmt nach Ablauf des Zeitfensters für die Betrugssicherheit eine endgültige Bestätigung vor. Eine andere Möglichkeit ist, dass er einen Betrugsnachweis von einem ehrlichen Full Node erhält, wissend, dass der Header-Generator falsche Daten übermittelt hat.

Ich werde nicht im Detail darauf eingehen, wie Einzelrunden-Betrugsnachweise funktionieren, da dies den Rahmen dieses Artikels sprengen würde. Der Vorteil hierbei ist, dass Sie die Zeit für die Betrugssicherheit von 7 Tagen auf einen bestimmten Betrag reduzieren können, der noch festgelegt werden muss, aber um Größenordnungen kleiner ist. Light Nodes sind in der Lage, Betrugsnachweise über die P2P-Schicht zu erhalten, ohne auf einen Streitfall warten zu müssen, da alles in einem einzigen Beweis erfasst wird.

Wir verwenden den DA-Layer als Aggregator, der seine Zensurresistenz erbt. Es macht Inklusion und Ordnung. Der zentralisierte Header-Produzent liest die kanonische Reihenfolge aus der DA-Schicht und kann daraus einen gültigen Header erstellen. Der zentralisierte Header-Produzent sendet die Header- und State-Roots an die DA-Schicht. Diese staatlichen Wurzeln sind unerlässlich, um einen Betrugsschutz gegen diese Verpflichtung zu schaffen. Der Aggregator übernimmt die Aufnahme und Sortierung, während der Header-Produzent die Ausführung übernimmt.

Es wird davon ausgegangen, dass der DA-Layer (der derzeit auch als Aggregator von Rollup fungiert) ausreichend dezentralisiert ist und eine gute Zensurresistenz aufweist. Darüber hinaus kann der Header-Produzent die vom Aggregator veröffentlichte Rollup-Transaktionssequenz nicht ändern. Wenn der Header-Produzent dezentralisiert ist, besteht der einzige Vorteil in einer besseren Lebendigkeit, aber die anderen Eigenschaften von Rollup sind die gleichen wie bei der ersten Variante, dem basierten Rollup.

Wenn der Header-Produzent einen Verfügbarkeitsfehler aufweist, weist auch das Rollup einen Verfügbarkeitsfehler auf. Der leichte Knoten wird nicht in der Lage sein, der Kette zu folgen, während vollständige Knoten der Kette folgen können, wenn dies wünschenswert ist, und auf ein basiertes pessimistisches Rollup zurückgreifen können, wie in Variante 1 beschrieben. Die in Variante 4 beschriebene Mindestkonfiguration für die Vertrauensminimierung lautet natürlich:

DA-Layer-Lichtknoten + Rollup-Lichtknoten.

Variante 5 : Basiertes ZK-Rollup mit einem dezentralen Prover-Markt

Wir haben über Pessimistisches Rollup (Basiertes Rollup) und Optimistisches Rollup gesprochen, jetzt ist es an der Zeit, ZK-Rollup in Betracht zu ziehen. Kürzlich hielt Toghrul einen Vortrag über die Trennung von Aggregator (Sequencer) und Header-Produzent (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). In diesem Modell ist die Veröffentlichung von Transaktionen als Rollup-Daten und nicht als State Diff einfacher zu handhaben, daher werde ich mich auf Ersteres konzentrieren. Variante 5 ist ein basiertes zk-Rollup mit einem dezentralen Prover-Markt.

Inzwischen sollten Sie mit der Funktionsweise eines basierten Rollups vertraut sein. Variante 5 delegiert die Aggregatorrolle an die DA-Layer-Knoten, die die Arbeit der Inklusion und Sortierung übernehmen. Ich werde aus dem Dokument von Sovereign-Labs zitieren, das den Lebenszyklus ihres Designs auf erstaunliche Weise erklärt. Ich werde es leicht anpassen, damit es zur Variante 5 passt.

Benutzer posten einen neuen Datenblob in der L1-Kette. Sobald das Blob auf L1 abgeschlossen ist, ist es logisch endgültig. Unmittelbar nachdem der L1-Block fertiggestellt wurde, durchsuchen vollständige Knoten des Rollups ihn und verarbeiten alle relevanten Datenblobs in der Reihenfolge, in der sie angezeigt werden, wodurch ein neuer Rollupstatusstamm generiert wird. Zu diesem Zeitpunkt ist der Block subjektiv aus Sicht aller Full Nodes finalisiert.

Unser Header-Produzent in dieser Ausführung ist der dezentrale Prover-Markt.

Prover-Knoten (vollständige Knoten, die innerhalb einer ZKVM ausgeführt werden) führen in etwa den gleichen Prozess wie vollständige Knoten aus – sie scannen den DA-Block und verarbeiten alle Stapel in der richtigen Reihenfolge – sie produzieren Proofs und veröffentlichen sie in der Kette. (Proofs müssen in der Kette veröffentlicht werden, wenn das Rollup Anreize für Prüfer schaffen möchte – andernfalls ist es unmöglich zu sagen, welcher Prüfer einen bestimmten Stapel zuerst verarbeitet hat). Sobald ein Proof für einen bestimmten Stapel auf der Kette veröffentlicht wurde, ist der Stapel für alle Knoten, einschließlich der Lichtknoten, subjektiv endgültig.

(Da es viele Konzepte gibt, können Sie sich das schematische Diagramm noch einmal ansehen)

Variante 5 genießt die gleiche Zensurresistenz wie der DA-Layer. Der dezentrale Prover-Markt kann Transaktionen nicht zensieren, da die DA-Schicht die kanonische Reihenfolge bestimmt. Wir haben den Header-Producer nur für eine bessere Lebendigkeit und um einen Anreizmarkt zu schaffen, dezentralisiert. Die Lebendigkeit ist hier L = L_da & L_pm (Prüfmarkt). Wenn die Anreize des Prüfmarktes falsch ausgerichtet sind oder es zu einem Liveness-Ausfall kommt, können Light-Knoten der Kette nicht folgen, aber Rollup-Vollknoten könnten der Kette immer noch folgen, wenn dies wünschenswert ist, und auf ein basiertes pessimistisches Rollup zurückgreifen. Das kleinste vertrauensminimierte Setup ist hier, genau wie im optimistischen Fall mit einem DA-Layer-Lichtknoten + einem Rollup-Lichtknoten.

Variante 6 : Basiertes Hybrid-Rollup mit einem zentralen optimistischen Header-Producer und einem dezentralen Prover

Wir lassen die DA-Layer-Knoten weiterhin als Aggregatoren für das Rollup fungieren und delegieren sie, um die Aufnahme und Sortierung von Transaktionen zu übernehmen.

Wie Sie in der folgenden Abbildung sehen können, verwenden sowohl der ZK-Rollup als auch der optimistische Rollup die gleichen geordneten Transaktionsbatches auf dem DA-Layer als Quelle des Rollup-Ledgers. Aus diesem Grund können wir zwei Proof-Systeme gleichzeitig verwenden: Die bestellten Transaktions-Batches auf dem DA-Layer werden durch das Proof-System selbst nicht beeinflusst.

Lassen Sie uns über Endgültigkeit sprechen. Aus der Sicht eines Rollup-Vollknotens ist das Rollup endgültig, wenn der DA-Layer final ist, da er nur noch die Transaktionen für diese Variante ausführen muss. Aber wir kümmern uns mehr um die Endgültigkeit des Lichtknotens. Nehmen wir an, der zentralisierte Header-Produzent setzt einen Stake, signiert über einen Header und sendet die berechneten Zustandswurzeln an die DA-Schicht.

Wie bei der vorherigen Variante 4 vertrauen die Light-Nodes optimistisch auf die Ausführung und warten auf einen Betrugsnachweis von einem ehrlichen Full Node, der zeigt, dass der Header-Produzent Betrug begangen hat. Nachdem das Fenster für die Betrugssicherheit abgelaufen ist, ist der Rollup-Block aus der Perspektive eines Rollup-Light-Knotens endgültig.

Der entscheidende Punkt ist, dass wir, wenn wir einen ZK-Beweis erhalten können, nicht mehr warten müssen, bis das Fenster für die Betrugssicherheit endet. Zusätzlich zu den einrunden Betrugsbeweisen können wir Betrugsnachweise durch ZK-Beweise ersetzen und jeden bösartigen Header verwerfen, der vom optimistischen Header-Hersteller generiert wurde!

Wenn der Light-Knoten das ZK-Zertifikat empfängt, das einem bestimmten Rollup-Transaktionsbatch entspricht, wird der Batch abgeschlossen.

Jetzt haben wir ein schnelles, weiches Engagement und eine schnelle Endgültigkeit.

Variante 6 genießt nach wie vor die gleiche Zensurresistenz wie der DA-Layer, auf dem sie basiert. Für die Lebendigkeit haben wir L = L_da & (L_op || L_pm ), was bedeutet, dass wir unsere Liveness-Garantie erhöht haben. Wenn entweder der zentralisierte Header-Produzent oder der Proofer-Markt einen Live-Ausfall haben, können wir auf das andere Schema zurückgreifen.

Das kleinste vertrauensminimierte Setup ist ein DA-Layer-Lichtknoten + ein Rollup-Lichtknoten.

Zusammenfassung:

1. Wir teilen den Sequenzer in zwei logische Einheiten auf: den Aggregator und den Header-Producer

2. Wir unterteilen den Sequenzer in drei logische Prozesse: Inklusion, Reihenfolge und Ausführung.

3. Pessimistische Rollups und basierte Rollups sind eine Sache

4. Je nach Bedarf können Sie Plug-and-Play-Aggregatoren und Header-Produzenten einsetzen.

5. Jede Rollupvariante in diesem Artikel folgte diesem Entwurfsmuster:
   

Zum Schluss habe ich noch ein paar Gedanken. Bitte denken Sie darüber nach:

• Wie passen klassische Rollups dazu? (bezieht sich auf Ethereum Rollup)
• In allen Varianten haben wir nur den Aggregator dazu gebracht, die Aufnahme + Bestellung und die Ausführung des Header-Produzenten durchzuführen. Was ist, wenn der Aggregator nur die Aufnahme und der Header-Produzent die Bestellung und Ausführung übernimmt? Denken Sie an On-Chain-Auktionen. Könnten wir alle drei trennen?
• Was ist ein gemeinsamer Header-Producer-/Header-Producer-Markt?
• Wer bekommt die MEV? Und können wir es zurückbekommen?

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [Geek Web3], Forward the Original Title'Celestia researcher analyzes 6 Rollup variants: Sequencer = aggregator + Header generator',Alle Urheberrechte liegen beim ursprünglichen Autor [NashQ, Celestia Researcher]. 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.