• Den Originaltitel weiterleiten:Decentralizing Rollup: Analyzing Aztec's Decentralized Sequencer Solution

Einleitung: Seit Rollup an Bedeutung gewonnen hat, war die Dezentralisierung des Sequencers immer ein Schwerpunkt der Ethereum/Celestia-Community, und es ist auch ein schwieriger Berg, den es bei der Layer2-Entwicklungsarbeit zu überwinden gilt. In diesem Zusammenhang haben verschiedene Rollup-Pläne Ideen für die Dezentralisierung von Knoten vorgeschlagen, die ein extrem breites Spektrum an Vorstellungskraft für dieses Thema bieten.

Der Autor dieses Artikels nimmt das bekannte ZKRollup-Projekt Aztec als Beispiel und verwendet die beiden Vorschläge namens B52 und Fernet, die kürzlich von Aztec Labs vorgeschlagen wurden, als Einstiegspunkt, um für die Leser zu analysieren, wie ZKR die Dezentralisierung der Sequenzerknoten realisiert.

Vorschlag B52: Permissionless Sequencer Scheme

Mit dem Vorschlag B52 sollen (im Idealfall) folgende Ziele erreicht werden:

1. Dezentrales Sequenzer-Netzwerk mit L2-Knoten, die für jede Runde Vorschlagende auswählen.

2. Dezentrales Prover-Netzwerk mit geringen Hardwareanforderungen für Prover-Nodes.

3. Rollup besitzt insgesamt eine hervorragende Zensurresistenz.

4. Der auf L2 generierte MEV-Wert wird von L2-Knoten abgerufen.

5. Wenn L2-Blöcke an die DA-Schicht übergeben werden, kann eine relativ effektive Finalität erreicht werden. Die irreversible Endgültigkeit erfordert den Abschluss der Einreichung des Gültigkeitsnachweises.

6. L2-Token können ein anständiges Tokenomic-Modell haben.

7. Sowohl L2-Block- als auch Transaktionsdaten werden im P2P-Netzwerk des L2 weitergegeben.

8. L2 erbt die Sicherheit von L1.

(B52-Vorschlag geht von der Rollup-Struktur aus, der Vorschlagende ist im Wesentlichen der Sequenzer)

Dieser Plan unterteilt den gesamten Produktionsprozess von L2-Blöcken in drei Zeitphasen:

Block Proposal Window (BPW) Block Acceptance Window (BAW) Statusfortschritte

Unter ihnen ist die BPW-Phase (Block Proposal) der Prozess, bei dem mehrere Sequenzer verschiedene Blöcke vorschlagen und gegeneinander antreten, und Prover wählt einen Kandidatenblock zur Abstimmung aus. BAW (Block Acceptance) ist der Prozess, bei dem Prover einen Gültigkeitsnachweis für den Block erstellt und einreicht. Block Proposal Window (Block Proposal Phase): BPW lässt sich weiter in drei Stufen unterteilen – Block Proposal, Block Voting, Aggregation.

(Prozessdiagramm des Blockvorschlagsfensters)

Block Proposal (BP)-Phase: Jeder in der Phase kann Transaktionen sammeln und seine eigenen BP-Inhalte übertragen. Der BP-Inhalt besteht aus drei Teilen: txs-Order-Hash, Prover-Belohnungsprozentsatz, Burn-Token-Betrag.

txs-Order-Hash: Der Vorschlagende wählt den wertvollsten Stapel von Transaktionen aus dem L2-Transaktionspool (mempool) aus, sortiert sie und platziert dann den Hashwert dieser Transaktionen in dem Block, den sie erstellen. Prover-Belohnungsprozentsatz: Der Prozentsatz der Block-Belohnungen, die der Sequencer mit dem Geprüften teilt. Burn-Token-Betrag: Die Menge an nativen L2-Token, die der Antragsteller zu verbrennen vorschlägt, dann sendet er seine BP an das L2-P2P-Netzwerk.

Block-Abstimmungsphase:

Nachdem der Prover BPs erhalten hat, die von verschiedenen Antragstellern im P2P-Netzwerk vorgeschlagen wurden, stimmt er für den BP, der es ihm ermöglicht, die meisten Belohnungen zu erhalten. Die Zusammensetzung der Abstimmung ist jedoch speziell:

Abstimmen ={BlockHash, Index of Proof Tree}

BlockHash ist der Hash des Vorschlags, für den Prover stimmen möchte, und Index of Proof Tree ist der Blattindexwert des Proof Tree, an dessen Erstellung Prover teilnehmen möchte (wird später erklärt)

Aggregation: Der Antragsteller sammelt Stimmen von Prüfern auf dem BP im L2-P2P-Netzwerk, aggregiert sie, legt sie in den BP ein und übermittelt sie an L1 (jeder BP enthält in der Regel nur Abstimmungsdatensätze, die sich auf ihn selbst beziehen).

Hier ist die Voraussetzung für die Selektion und Aufnahme des GP in das Rollp-Ledger hervorzuheben:

Mit der höchsten Punktzahl:

SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2'

NUM_PROVERS (x) ist die Anzahl der Prover-Stimmen, die dieser BP erhalten hat, und BURN_BID ist die Anzahl der L2-Token, die von diesem BP verbrannt werden sollen. Denn je höher der BURN_BID, desto weniger Belohnungen erhält der BP-Vorschlagende am Ende, daher sollte dieser Wert entsprechend festgelegt werden.

Gleichzeitig muss dieser BP vor dem Ende des Blockvorschlagsfensters bei L1 eingereicht werden, und der entsprechende Gültigkeitsnachweis muss vor dem Ende des Blockannahmefensters in L1 hochgeladen werden.

Hinweis: Im Scoring von BP nimmt die Anzahl der Stimmen das größte Gewicht ein, gefolgt von der Anzahl der Burn-Token. Gleichzeitig erlaubt das B52-Schema mehreren Antragstellern (eigentlich Sequenzierern), um eine gültige BP-Quote zu konkurrieren.

Das B52-Schema verlangt lediglich, dass der Proposer (Sequenzer) die Anzahl der Burn-Token in seinem eigenen BP angibt (ähnlich wie bei der EIP1559-Methode), ohne dass er im Voraus Token einsetzen muss, was das Netzwerk erlaubnisfreier machen kann (keine Zulassungserlaubnis) und auch der nativen Token-Deflation von L2 förderlich ist.

Darüber hinaus enthält der BP keine vollständigen Transaktionsdaten, sondern nur den Hash der Transaktionssequenz, der dem PBS-Schema von Ethereum ähnelt und darauf abzielt, zu vermeiden, dass MEV von anderen Antragstellern gepiept und vorweggenommen wird.

Detaillierte Erläuterung des Fensters "Blockannahme":

(Schematische Darstellung des Blockabnahmefensters, im Bild als Proof Acceptance geschrieben)

Nach dem Ende des Blockvorschlagsfensters muss der Prover seine vollständigen Transaktionsdaten offenlegen, die seinem GP entsprechen. Wenn der BP ausgewählt wird, für den der Prover stimmt (mit der höchsten Punktzahl, die über den L1-Vertrag abgefragt werden kann), muss er den Sub-Proof-Baum erstellen, der dem Index des Proof-Baums entspricht, der bei der Abstimmung angegeben wurde.

Angenommen, ein aztekischer Block enthält 2^13=16384 Transaktionsmengen und es gibt 2048 Beweise, dann konstruiert jeder Prüfer einen Unterbeweisbaum, der aus 2^3=8 Transaktionen besteht. Dann sendet der Prüfer seinen konstruierten Sub-Proof-Baum an das L2-P2P-Netzwerk. Nach Erhalt des Nachweises aggregiert der Antragsteller alle Unternachweisbäume zu einem Blockbeweis.

Als Nächstes reicht Propsoer den aggregierten Nachweis beim L1-Rollup-Vertrag ein, der die Richtigkeit dieses Nachweises und die entsprechenden Zustandsübergangsergebnisse überprüft. Es ist hier zu beachten, dass, wenn Prover den Nachweis absichtlich nicht vorlegt, es nicht nur die vom Antragsteller versprochenen Blockbelohnungsdividenden nicht erhält, sondern auch gekürzt wird, da ein Prover zu werden, erfordert das Staking von Token im Voraus. Daher ist der Prover im Gegensatz zum Proposer (Sequencer) nicht erlaubnisfrei.

Detaillierte Erläuterung der staatlichen Vorschüsse:

Nach Ablauf des Blockannahmefensters wählt der Rollup-Vertrag den Block mit der höchsten Punktzahl aus, der in das Rollup-Ledger aufgenommen werden soll, und die Blockbelohnung wird an den Vorschlagenden (Sequencer) und den Prover in dem vom Vorschlagenden zuvor deklarierten Verhältnis gesendet.

Das obige ist das B52-Schema von Aztec. Der Autor dieses Artikels ist jedoch der Meinung, dass der B52-Vorschlag einige potenzielle Probleme mit sich bringt:

Problem eins: Angenommen, der Gültigkeitsnachweis eines Blocks mit der höchsten Punktzahl ist unvollständig. Die im Vorschlag angegebene Lösung besteht darin, dass, wenn der Antragsteller nur 50 % des Beweises liefert, er nur 50 % der Blockbelohnung erhalten kann, wodurch sichergestellt wird, dass der Antragsteller keinen Anreiz hat, absichtlich keinen vollständigen Beweis vorzulegen. Gleichzeitig kann der Prover den Nachweis auch direkt beim Vertrag einreichen.

Gemäß der Beschreibung des Vorschlags ist es akzeptabel, dass ein Block keinen vollständigen Transaktionsgültigkeitsnachweis hat. Das ist eigentlich unzumutbar, denn: zkrollup erklärt den neuen Zustand, der diesem Block entspricht, erst dann für gültig, wenn der Gültigkeitsnachweis erbracht ist.

Wenn der aggregierte Nachweis, den der Vorschlagende schließlich an L1 übermittelt, den Beweis für eine bestimmte Transaktion fehlt, ist es offensichtlich, dass der Zustandsübergangsnachweis aller Transaktionen, die nach dieser Transaktion auftreten, ungültig ist (da Transaktionen nacheinander ausgeführt werden und Zustandsabhängigkeiten aufweisen), und wir können nicht bestätigen, dass der neue Zustand, der diesem Block entspricht, gültig ist.

Daher sollte es zu diesem Zeitpunkt sinnvoll sein, in das unendliche Wartefenster für die Blockannahme zu gelangen, bis alle Transaktionsnachweise eingereicht wurden.

Problem 2: Angenommen, der Block mit der höchsten Punktzahl ist ein illegaler Block (dieser Punkt wird im B52-Plan nicht erklärt). Der BP enthält nur den Hash der Transaktionssequenz, sodass ein böswilliger Vorschlager absichtlich problematische Transaktionen erstellen kann, z. B. Double-Spending-Transaktionen. Zu diesem Zeitpunkt ist es tatsächlich notwendig, dem L1-Vertrag eine Funktion hinzuzufügen, die es jedem ermöglicht, einen illegalen Nachweis einzureichen. Dieser illegale Beweis wird verwendet, um zu beweisen, dass der BP mit der höchsten Punktzahl ein illegaler Block ist.

Auch diese Art von Bericht sollte belohnt werden. Wir können alle Burn-Token, die vom Antragsteller an den Vertrag gesendet wurden, als Belohnung an den Knoten geben, der den illegalen Nachweis eingereicht hat.

Interessanter Gedanke: Über Onkel-Blöcke und redundante Prover-Arbeit: Der B52-Plan wird tatsächlich, nachdem jede Runde des höchsten und gültigen BP erscheint, andere BPs (die vollständige Beweise eingereicht haben) in dieser Runde als Onkel-Blöcke behandeln und eine bestimmte Anzahl von Onkel-Block-Belohnungen verteilen.

Dies folgt eigentlich der Praxis des ETH-POW-Konsensmechanismus. Um eine übermäßige Konzentration der Rechenleistung zu vermeiden, ist es notwendig, einen Teil der Blockbelohnung den Antragstellern der nicht angenommenen Blöcke (Miner) zuzuweisen, um die Interessen kleiner Mining-Pools/einzelner Miner zu schützen und um zu verhindern, dass die Mining-Leistung von großen Mining-Pools monopolisiert wird. Daher ist es auch eine sehr kluge Wahl, den gut funktionierenden Onkel-Block-Mechanismus von Ethereum zu übernehmen.

Die Bedeutung des B52-Vorschlags in Bezug auf die Rollup-Dezentralisierung: Der Proposer ist dezentralisiert und benötigt keine Zusage, und die Eintrittsbarriere ist niedrig. Da es jedoch erfordert, den wertvollsten Block selbst zu erstellen, sowie Stimmen von anderen Prüfern zu sammeln und alle Beweise zu aggregieren, ist die Hardware-Schwelle des Antragstellers nicht so niedrig wie im Vorschlag beschrieben (z. B. ist die Bandbreite möglicherweise nicht sehr niedrig).

Daher wird es schließlich zu einem zentralisierteren Netzwerk, ähnlich wie bei Mev-Boost Builder, da der Vorschlag, der den Block schließlich erstellen kann, oft der Block Builder ist, der MEV am besten erfassen kann.

Gleichzeitig muss der Prover im B52-Schema Vermögenswerte verpfänden, aber da er nur einen Teilbaumbeweis generieren muss, ist der Dezentralisierungsgrad des Prover im Vergleich zu den Lösungen, die den gesamten Blockbeweis vollständig generieren müssen, besser (die Hardwareanforderungen können gesenkt werden).

Liveness: Die gesamte Netzwerk-Liveness ist gut, weil L2 über ein eigenes P2P-Netzwerk verfügt, um Transaktionen und Abstimmungen/BP zu übertragen, und sowohl Sequencer als auch Prover sind relativ dezentralisiert. Aber wir müssen die beiden oben genannten Probleme lösen, eines ist, dass der Block mit der höchsten Punktzahl ein legaler Block sein muss, und das zweite ist, dass wir warten müssen, bis der vollständige Blockbeweis an L1 übermittelt wurde, bevor wir in einen neuen Zustand eintreten. Daher ist ein effektiverer Anreizmechanismus erforderlich, um zu verhindern, dass das gesamte Rollup-Netzwerk aufgrund des Fehlens eines tx-Beweises nicht normal funktioniert (stoppt).

Zensurresistenz: Wenn wir sicherstellen können, dass jeder Blockvorschläge BP veröffentlichen kann, und sicherstellen können, dass nicht nur der Antragsteller Blockbeweise einreichen kann, dann wird das Netzwerk eine gute Zensurresistenz haben.

Finalität: Die Endgültigkeit von L2 hängt eng mit der Lebendigkeit des Netzwerks zusammen, da die endgültige verifizierte Endgültigkeit noch auf die Einreichung des Blockproofs warten muss, aber tatsächlich können Sie auch dem Blockinhalt vertrauen, der dem BP mit der höchsten Punktzahl entspricht (solange er keine bösartigen Transaktionen enthält).

Dieser Block wird zu Beginn des Blockannahmefensters angezeigt, was bedeutet, dass Sie als Benutzer nur auf eine Blockvorschlagszeit warten müssen, und der Block, in dem sich Ihre Transaktion befindet, kann übernommen werden.

L1-Sicherheit erben: Als L2, das den Status durch Einreichen eines Gültigkeitsnachweises aktualisiert, kann es die Sicherheit von L1 erben.

Fernet-Vorschlag: Einführung von VDF für die Auswahl von Antragstellern

Überblick über das Fernet-Schema: Durch die Verwendung von VDF innerhalb jedes Blockgenerierungszyklus wird eine projizierte Punktzahl verschiedenen Knoten innerhalb des Komitees zugewiesen (die Sammlung von Sequenzer-Knoten), und der vom Sequencer vorgeschlagene Block mit der höchsten Endpunktzahl wird zum gültigen Block.

Erstens: Wie tritt man dem Komitee bei? Im Wesentlichen müssen 16 ETH auf L1 gestakt werden und dann, nachdem der Staking-Prozess abgeschlossen ist, 4 L1-Blöcke warten, bevor man dem Sequencer-Komitee beitritt. Um das Sequencer-Komitee zu verlassen, muss man die Unsstake-Funktion im L1-Vertrag aufrufen, wonach es 3 Tage dauert, bis der verbleibende eingesetzte Betrag abgerufen wird.

Als nächstes: Was ist VDF? Die überprüfbare Verzögerungsfunktion ist eine mathematische Funktion, die sich an strenge serielle Ausführungsmerkmale hält. Es führt bestimmte Rechenschritte aus und verbraucht eine vorhersehbare Menge an Zeit. Wir bezeichnen den von VDF berechneten Wert als Score, der einer gleichmäßigen Normalverteilung folgt. Sobald der Sequenzer den VDF-Score berechnet hat, kann er die Wahrscheinlichkeit bestimmen, als legitimer Vorschlagender ausgewählt zu werden.

Die VDF-Berechnung für Sequencer sieht wie folgt aus:

Punktzahl = VDF( privater Schlüssel , öffentliche Eingänge )

Öffentliche Eingaben = { current block number , randao }

Randao ist eine Zufallszahl, die verwendet wird, um zu verhindern, dass Sequencer ihren VDF-Score für alle zukünftigen Blockhöhen vorzeitig berechnen

Der gesamte Prozess von Fernet ist hauptsächlich in drei Phasen unterteilt:

1. Vorschlagsphase 2. Erprobungsphase 3. Fertigstellung

Vorschlagsphase: PROPOSAL_PHASE_L1_BLOCKS = 2 Ethereum-Blöcke (Diese Phase dauert 2 L1-Blöcke)

Zu Beginn dieser Phase berechnet jeder Sequencer seinen eigenen VDF-Score bei der aktuellen Blockhöhe. Wenn der Sequenzer der Meinung ist, dass sein VDF-Score wahrscheinlich das Blockproduktionsrecht für diesen Block gewinnen wird (vorausgesetzt, der Score erfüllt die Normalverteilung), wird er ein Angebot für den L1-Rollup-Vertrag einreichen. Der Vorschlag enthält: den Hash der Transaktionssequenz, der auf einen vorherigen L2-Block zeigt.

unbewiesener Block: Der Block, der nur den Vorschlag an den Inhalt des Rollup-Vertragsblocks übermittelt hat. Dann muss der Sequencer den Blockinhalt entsprechend dem unbewiesenen Block und den VDF-Nachweis an das L2-P2p-Netzwerk senden.

Gärphase: PROVING_PHASE_L1_BLOCKS= 50 L1-Blöcke (Diese Phase dauert 50 L1-Blöcke, ca. 10 min)

Der Prover empfängt alle Transaktionen, die dem Blockinhalt entsprechen, aus dem L2-P2P-Netzwerk und erstellt einen Proof für den Block mit einem höheren VDF-Score. Die Konstruktion des Beweises verwendet auch eine Methode, bei der mehrere Prüfer parallel zusammenarbeiten (ähnlich dem B52-Schema).

Daher muss der Sequencer schließlich die Proofs mehrerer verschiedener Transaktionen in einem Blockproof (einschließlich VDF-Proof) aggregieren und an den L1-Rollup-Vertrag übermitteln. Jeder kann die Blockinhalte, die den Blocknachweis bereits an den Rollup-Vertrag übermittelt haben, übermitteln.

Finalisierung: Es muss eine L1-Transaktion eingereicht werden, um den Block abzuschließen, ein Block, der endgültig finalisiert werden kann, muss Folgendes erfüllen: eingereichte Blockinhalte und Block Proof, der vorherige Block, auf den er verweist, muss finalisiert werden. Auf dieser Grundlage muss es auch die höchste Punktzahl haben.

(Der Blockout-Prozess im Pipeline-Stil: Sobald die Vorschlagsphase des vorherigen Blocks endet, beginnt die Vorschlagsphase des nächsten Blocks, ohne auf das Ende der Testphase des vorherigen Blocks zu warten.)

Mechanismus zur Generierung von Pipeline-Blöcken: Es ist erwähnenswert, dass Fernet einen Mechanismus zur Generierung von Pipeline-Blöcken anwendet. Wenn die Vorschlagsphase von Block N endet, beginnt der Vorschlag für Block N+1 (ähnlich wie Aptos und andere öffentliche Chains). Für Block N+1 muss jedoch gewartet werden, bis Block N abgeschlossen ist, bevor er die Transaktion des letzten Blocks von L1 übermitteln und validiert werden kann, um der letzte Block zu werden.

Potentielle Angriffsvektoren: Wenn der Sequencer mit dem höchsten VDF-Score absichtlich keine Blockinhalte im L2-P2P ausstrahlt, kann dies zu einer Blockreorganisation (Reorg) führen.

Berechnung der L2-Blockmenge für Reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 Blöcke

Lösung: Führen Sie einen Onkel-Block-Mechanismus ein, um zu vermeiden, dass nur ein vollständiger Kandidatenblock für jeden L2-Steckplatz (Zeitschlitz für die Blockgenerierung) vorhanden ist.

Die Bedeutung der Dezentralisierung in Fernet: Sequencer treten dem Sequencer-Komitee bei, indem sie 16 ETH einsetzen, und die Eintrittsschwelle ist nicht hoch (aber auch nicht niedrig). Provers benötigen kein Staking, aber wenn Provers keine Beweise generieren, gibt es keine Strafe. Dies ist im Grunde das Gegenteil des B52-Schemas.

Liveness: Die Liveness des gesamten Netzwerks kann garantiert werden, da der VDF + Onkel-Block-Mechanismus sicherstellen kann, dass es in jeder Runde mehr als einen Blockproduzenten gibt.

MEV: Die Berücksichtigung von MEV ist besonders einzigartig. Dieses Schema sieht die Einführung von PBS vor, so dass ein Sequencer, nachdem er einen VDF-Score mit hoher Punktzahl berechnet hat, sich direkt an den Block Builder wenden kann, um einen wertvolleren Block zu erstellen.

Zensurwiderstand: Fernet wird auch einen PBS-Mechanismus einführen, der mit Ethereum konsistent ist, so dass Fernets Problem mit der Zensurresistenz im Wesentlichen mit dem Problem der PBS-Zensurresistenz von Ethereum gleichzusetzen ist.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [Geek Web3], Forward the Original Title'ollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution',Alle Urheberrechte gehören dem ursprünglichen Autor [xhhh,EthStorage]. 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.