Ursprünglicher Autor: NIC Lin

Originalquelle: mittel

Möge die Macht mit dir sein. In diesem Artikel wird der Transaktions-Anti-Zensur-Mechanismus von Rollup – Force Inclusion – vorgestellt und das Design und die Praxis mehrerer berühmter Rollups als Beispiele verwendet.

Foto von Artur Tumasjan auf Unsplash

Vorkenntnisse:

• Erfahren Sie, wie Rollup funktioniert und warum Rollup Transaktionen auf L1 hochladen muss

Widerstand gegen Transaktionszensur

Die Fähigkeit von Transaktionen, zensurresistent zu sein (zensurresistent), ist für eine Blockchain sehr wichtig. Wenn eine Blockchain Transaktionen für jeden Zensurbenutzer durchführen kann, dann unterscheidet sich diese Blockchain nicht von einem Web2-Server. Der aktuelle Transaktionswiderstand von Ethereum gegenüber der Zensur beruht auf der großen Anzahl von Validatoren. Wenn Alice Bobs Transaktionen überprüfen und verhindern möchte, dass seine Transaktionen in die Kette hochgeladen werden, muss Alice versuchen, jeden Validator im Netzwerk zu bestechen, oder sie wird es tun Quatsch. Das gesamte E-Mail-Netzwerk sendet weiterhin Spam-Transaktionen, die höher sind als Bobs Transaktionen, um die Blöcke aufzufüllen. In jedem Fall werden ihre Kosten sehr hoch sein.

Hinweis: In der aktuellen PBS-Architektur von Ethereum wurden die Kosten für die Überprüfung tatsächlich erheblich reduziert. Sie können sich auf die Überprüfung des Anteils der Blöcke bei Tornado Cash-Transaktionen durch OFAC beziehen. Der derzeitige Zensurwiderstand beruht auf unabhängigen Prüfern und Weiterleitungen außerhalb der Zuständigkeit des OFAC und der Regierung.

Aber was ist mit Rollups? Rollup erfordert keine große Anzahl von Validatoren, um seine Sicherheit zu gewährleisten. Darüber hinaus verfügt Rollup nur über eine zentrale Rolle (Sequenzer, Sequenzer oder Sequenzer genannt) für die Stapelverarbeitung von Blöcken und ist genauso sicher wie L1. Aber Sicherheit und Zensurresistenz sind zwei verschiedene Dinge. Der Aufbau eines Rollups ist genauso sicher wie Ethereum, verfügt aber nur über einen zentralen Sequenzer. Dann kann der Sequenzer die Transaktionen jedes Benutzers überprüfen.

Sequencer kann den Empfang von Benutzertransaktionen verweigern, was dazu führt, dass Benutzer Rollup nicht verwenden oder verlassen können.

Zwangseinschlussmechanismus

Gleichzeitig muss Rollup über so viele Validatoren wie L1 verfügen, um die Zensurresistenz zu gewährleisten. Es ist besser, die Zensurresistenz von L1 direkt zu nutzen: Der Sequenzer komprimiert auch Transaktionsdaten in den Rollup-Vertrag von L1 eine Funktion im Rollup-Vertrag zur Überwachung von Benutzern. Sie können auch Transaktionen in die Sortierung einfügen. Solange Sequencer die „L1-Transaktionen“ des Überwachungsbenutzers nicht überprüfen kann, kann er Benutzer nicht daran hindern, Rollup-Transaktionen gewaltsam über L1 einzufügen, und der Betrieb und die Sicherheit von Rollup basieren auf den Anti-Zensur-Funktionen von L1.

Der Sequenzer kann die L1-Transaktionen des Benutzers nicht überprüfen, es sei denn, es fallen sehr komplexe Kosten an

Hinweis: Eine erzwungene Einbeziehung ist nur möglich, wenn das Rollup so konzipiert ist, dass Benutzer L1 definitiv durchbrechen und Rollup-Transaktionen erzwingen können. Wenn Rollup keinen erzwungenen Einschlussmechanismus bietet, können Benutzer nur beten, dass die Sequencer-Überprüfung nicht von selbst erfolgt.

Die Transaktion wird sofort wirksam, im Gegensatz zur verzögerten Wirkung

Wenn wir zulassen, dass über Force Inclusion eingefügte Transaktionen direkt in den Transaktionsverlauf von Rollup geschrieben werden (mit sofortiger Wirkung), dann wird der Status von Rollup sofort geändert. Beispielsweise führt Bob einen Stift über den Force Inclusion-Mechanismus ein: „Er hat 1000 übertragen.“ DAI zu „Carol“-Transaktion: Wenn die Transaktion sofort wirksam wird, beträgt Bobs Kontostand im letzten Status 1000 DAI weniger und Carol 1000 DAI mehr (die Voraussetzung ist natürlich, dass Bobs Kontostand 1000 DAI übersteigt).

Wenn Bobs Transaktion direkt in den Transaktionsverlauf geschrieben werden kann und sofort wirksam wird, ändert sich der Status des Rollups sofort.

Wenn der Sequencer zu diesem Zeitpunkt Transaktionen außerhalb der Kette sammelt und wartet, bis die nächste Transaktion an den Rollup-Vertrag gesendet wird, kann er von der Transaktion betroffen sein, die Bob zwangsweise einfügt und sofort wirksam wird. Beispielsweise muss Bob im Voraus nur eine Zahlungstransaktion von „Er überweist 1000 DAI an Alice“ an den Sequencer senden. Dies entspricht der Überprüfung, dass kein Problem vorliegt, und dem Versprechen, Einnahmen zu erhalten Sequencer, ob die Transaktion empfangen wird und berechnet den neuesten Status (Alice hat 1000 DAI mehr und Bob hat 1000 DAI weniger). Als der Sequencer jedoch feststellte, dass Bob sich beeilt hatte, die Transaktion gewaltsam einzufügen, hatte sich der Ausführungsstatus der Transaktionen in seinen Händen geändert. Er wusste, dass die Transaktion „Bob hat 1000 DAI an Alice übertragen“ zu einem Ausführungsfehler geworden war und Alice dies nicht konnte Holen Sie es sich auf 1000 DAI.

Sequencer erhält Bobs Transaktion, also geht Alice davon aus, dass sie 1000 DAI erhalten wird

Infolgedessen zwang Bob direkt den Empfang einer weiteren widersprüchlichen Transaktion auf L1, was dazu führte, dass die Transaktion in der Hand des Sequenzers nicht empfangen wurde und Alice kein DAI erhalten konnte.

Dies ist möglicherweise keine gute Benutzererfahrung, daher sorgt Rollup im Allgemeinen dafür, dass die erzwungene Einschlusstransaktion sofort wirksam wird, versetzt die Transaktion jedoch in den Status „Vorbereitung“. Der Sequencer kann wählen, ob die Transaktionen, die in den Status „Vorbereitung“ wechseln, am Ende des Stapels hinzugefügt werden sollen, wenn die Budgettransaktion gesendet wird. Wenn der Sequencer diese Status „Vorbereitung“ nie verarbeiten möchte, werden diese Transaktionen nach einem verarbeitet Nach einer bestimmten Zeit kann es zwangsweise in den Transaktionsverlauf eingefügt werden.

Bob möchte Alice austricksen, indem er die Umsatztransaktion erzwingt, aber tatsächlich wird die Transaktion zuerst in die Warteschlange gestellt

Der Sequenzer kann selbst entscheiden, wann die wartenden Transaktionen in die Warteschlange „aufgenommen“ werden, sodass die Transaktion von Bob zu Alice DAI zuerst ausgeführt wird.

Wenn der Sequencer nicht auf Transaktionen in der Warteschlange wartet, kann der Benutzer (oder jeder andere) nach einer bestimmten Zeit den Umsatz selbst erzwingen.

Der Sequenzer weigert sich, Bobs Transaktion zu empfangen, daher stellt Bob die Transaktion von L1 in die Warteschlange

Der Sequenzer kann noch einige Zeit lang weiterhin Transaktionen in der Warteschlange ablehnen

Allerdings kann Sequencer in der Warteschlange wartende Transaktionen nicht für immer ablehnen. Nach einer gewissen Zeit kann jeder ein erzwungenes Einkommen auslösen. Als nächstes werden wir die Implementierung des Force-Containment-Mechanismus der bekannteren Rollups wie Optimism, Arbitrum, StarkNet und zkSync vorstellen .

Optimistischer Power-Inclusive-Mechanismus

Lassen Sie uns zunächst den Einzahlungsprozess von Optimism vorstellen. Diese Einzahlung bezieht sich nicht nur auf die Einzahlung von Geld in Optimism, sondern entspricht der allgemeineren „Einzahlung von Nachrichten für L2“ in L2. Nach dem Empfang der neu hinterlegten Nachricht überträgt der L2-Knoten die Nachricht, wandelt sie zur Ausführung in eine Port-L2-Transaktion um und überträgt die Nachricht an den angegebenen Empfänger.

Nachricht des Benutzers, der Geld von L1 nach L2 einzahlt

L1CrossDomainMessenger-Vertrag

Wenn ein Benutzer beschließt, ETH- oder ERC-20-Token in Optimism einzuzahlen, interagiert er (webübergreifend) mit dem L1StandardBridge-Vertrag auf L1 und gibt an, wie viel eingezahlt werden soll und von welcher Adresse er es erhalten möchte usw. Anschließend wird die L1StandardBridge-Verbindungsnachricht an den L1CrossDomainMessenger-Vertrag der nächsten Schicht übergeben. Dieser Vertrag wird hauptsächlich als allgemeiner Kommunikationsvertrag zwischen L1 und L2 verwendet, um mit L2StandardBridge auf L2 zu kommunizieren Token von L2 abheben oder Token von L1 abheben. Wenn ein Entwickler einen Vertrag für die Interoperabilität und den Synchronisierungsstatus zwischen L1 und L2 entwickeln muss, kann er ihn auf L1CrossDomainMessenger aufbauen.

Der CrossChainMessenger-Messaging-Vertrag des Benutzers wird von L1 an L2 übergeben

OptimismPortal-Vertrag

Der L1CrossDomainMessenger-Vertrag sendet die Nachricht dann an den OptimismPortal-Vertrag auf der untersten Ebene. Nachdem der OptimismPortal-Vertrag verarbeitet wurde, wird ein TransactionDeposited-Ereignis ausgegeben. Zu den Ereignisparametern gehören „die Person, die die Nachricht gesendet hat“. " und zugehörige Ausführungsparameter.

Dann hört der Optimism-Knoten von L2 das von der OptimismPortal-Vereinbarung ausgegebene TransactionDeposited-Ereignis ab und wandelt die Parameter im Ereignis in eine Transaktion um, die L2 aufzeichnet. Der Initiator dieser L2-Transaktion kann der „Nachrichtensender“ im TransactionDeposited-Ereignis sein. Die Person, die die Transaktion gesendet hat. Der Empfänger ist die „Person, die die Nachricht empfängt“ im Ereignis, und andere Ausführungsparameter werden ebenfalls von den Ereignisparametern übergeben.

Der L2-Knoten fügt das vom OptimismPortal ausgegebene TransactionDeposited-Ereignis in kommentierte L2-Transaktionen ein

Dies ist beispielsweise eine Transaktion, bei der ein Benutzer 0,01 ETH über den L1StandardBridge-Vertrag einzahlt. Diese Nachricht und die ETH werden bis zum OptimismPortal-Vertrag übertragen (die Adresse lautet 0xbEb5...06Ed). in eine L2-Transaktion und der Nachrichteninitiator ist der L1CrossDomainMessenger-Vertrag. Der Empfänger ist der L2CrossDomainMessenger-Vertrag mit 0,01 ETH.

erzwungene Inklusion

Wenn der Benutzer eine optimistische Ausführung seiner Transaktion erzwingen möchte, muss er keine Nachricht von L1 an L2 senden und wird daher den L1CrossDomainMessenger-Vertrag nicht verwenden. Der Effekt, den er erreichen möchte, besteht darin, die Rechnung so zu gestalten, dass „die Transaktion, die er von seiner L2-Adresse auf L2 sendet und ausführt“, reibungslos ausgeführt wird, sodass er direkt mit dem OptimismPortal-Vertrag interagiert und seine L2-Adresse den OptimismPortal-Vertrag aufrufen lässt dass, wenn das TransactionDeposited-Ereignis in eine L2-Transaktion umgewandelt wird, der „Transaktionsinitiator“ seine L2-Adresse ist, sodass die Transaktion wieder sichtbar ist.

Bei der aus dem TransactionDeposited-Ereignis konvertierten L2-Transaktion ist Bob selbst der Initiator; der Empfänger ist der Uniswap-Vertrag, der von der angegebenen ETH begleitet wird, genau wie Bob selbst die L2-Transaktion initiiert hat

Verwenden Sie die L2-Adresse, um die von OptimismPortal signierte DepositTransaction-Funktion aufzurufen, und denken Sie daran, die Parameter der L2-Transaktion einzeln einzugeben.

Ich habe eine einfache Transaktion zur erzwungenen Einbeziehung durchgeführt: Ich habe mir Geld an meine L2-Adresse (0xeDc1...6909) überwiesen und eine Textnachricht mit der Aufschrift „erzwungene Einbeziehung“ angehängt. Dies ist die L1 -Transaktion, bei der ich die Einzahlungsfunktion durch den Optimismus -Portal -Vertrag ausführte. 5BE000000000000C35000666F72636520696E636C7573696F6E) Wie viel ist codiert? „Wie viel ETH fügt die Person hinzu“, „Der L2-Transaktionsinitiator muss ETH an den L2-Empfänger anhängen“, „Gaslimit der L2-Transaktion“ und „Daten an den L2-Empfänger“ und andere Informationen.

Von der L1-Transaktion ausgegebenes TransactionDeposited-Ereignis

Nachdem Sie die numerischen Werte mehrerer Informationen in diesen undurchsichtigen Daten interpretiert haben, erhalten Sie:

• „Wie viel ETH ist an die Person gebunden, die DepositTransaction aufgerufen hat“: 0, weil ich ETH nicht von L1 auf L2 aufladen möchte

• „Wie viel ETH muss der L2-Transaktionsinitiator an den L2-Empfänger senden“: 5566 (wei), weil ich Geld an mich selbst überweisen möchte

• „L2-Transaktionsgaslimit“: 50.000

• „Daten für L2-Empfänger“: 0x666f72636520696e636c7573696f6e, „erzwungene Einbeziehung“ der Hexadezimalkodierung dieser Zeichenfolge löschen

Nicht lange danach erschien die konvertierte L2-Transaktion: Zeichnen Sie die L2-Transaktion auf, bei der ich Geld an mich selbst überwiesen habe, der Betrag ist 5566 und die Daten sind die Zeichenfolge „obligatorische Einbeziehung“. Und Sie können erkennen, dass der Txn-Typ (Transaktionstyp) in den anderen Attributen in der vorletzten Zeile der Abbildung die Systemtransaktion 126 (System) ist, was bedeutet, dass die Transaktion nicht von mir in L2 initiiert wurde, sondern von dort konvertiert wurde das L1TransactionDeposited-Ereignis.

Konvertierung abgeschlossen L2-Transaktion

Wenn der Benutzer andere Verträge mit anderen Daten aufrufen möchte, muss er die Parameter einzeln in den DepositTransaction-Brief eingeben. Denken Sie jedoch daran, die L2-Adresse für die Ausführung auf L1 zu verwenden, damit der Initiator der L2-Transaktion wird die L2-Adresse sein.

Sequenzer-Fenster

Der zuvor erwähnte Optimism-L2-Knoten wandelt das TransactionDeposited-Ereignis in eine L2-Transaktion um. Tatsächlich handelt es sich bei diesem Optimism-Knoten um die Transaktionssequenzierung, sodass nur der Sequencer entscheiden kann, wann er in eine L2-Transaktion umgewandelt wird . Beim Abhören des TransactionDeposited-Ereignisses konvertiert der Sequencer das Ereignis möglicherweise nicht sofort in eine L2-Transaktion, kann aber entscheiden, es für einen bestimmten Zeitraum umzuwandeln. Dieser Zeitraum wird im Optimism als Sequencer-Fenster bezeichnet Mainnet beträgt derzeit 24 Stunden. Wenn der Benutzer dann mit der Einzahlung von Geld von L1 beginnt oder eine Aufforderung erhält oder eine Aufladetransaktion zwangsweise einschließt, wird es im schlimmsten Fall 24 Stunden später offiziell in den L2-Transaktionsverlauf aufgenommen. Aber das ist immerhin besser, als dass die Transaktion niemals etwas bewirken kann.

Arbitrums erzwungener Inklusionsmechanismus

Optimistisch gesehen sendet die Einzahlungsoperation von L1 ein TransactionDeposited-Ereignis, und der Rest besteht darin, darauf zu warten, dass der Sequenzer die Einzahlungsoperation empfängt (Geld einzahlen oder Nachrichten an L2 senden usw.). in einer von L1 vereinbarten Warteschlange gespeichert, anstatt nur Ereignisse auszugeben. Dem Sequenzer wird eine Zeitspanne gegeben, um die L1-Operationen in dieser Warteschlange zum Transaktionsverlauf hinzuzufügen. Wenn die Zeit abgelaufen ist und der Sequenzer verwendet wird, kann er abgeschlossen werden, ohne dass jemand den Sequenzer ersetzen muss.

Durch die Schlichtung wird eine Warteschlange im L1-Vertrag verwaltet. Wenn der Sequencer nach Ablauf der Zeit keine Transaktionen in der Warteschlange empfängt, kann jeder erzwingen, dass die Transaktionen in der Warteschlange in den Transaktionsverlauf eingetragen werden.

Alle L1-Vorgänge sind verzögerte Inbox-Verträge. Wie der Name schon sagt, werden die Vorgänge hier verzögert und laufen ab. Der andere Vertrag ist Sequencer Inbox, eine Schnittstelle zum Hochladen von L2-Transaktionen in Sequencer. Die von Sequencer hochgeladenen Transaktionen werden direkt in den Transaktionsverlauf geschrieben. Darüber hinaus können Sie beim Hochladen von Sequencer auswählen, wie viele L1-Vorgänge aus dem verzögerten Posteingang übernommen werden sollen, und sie zusammen in den Transaktionsverlauf schreiben, damit diese L1-Vorgänge ausgeführt werden können Wirkung.

SequencerInbox enthält den Transaktionsverlauf. Im Allgemeinen kann nur Sequencer neue Transaktionen direkt schreiben.

Wenn Sequencer eine neue Transaktion schreibt, kann er eine Transaktion von DelayedInbox aus initiieren und diese zusammen schreiben.

Komplexe Designs und beeindruckende Dokumentation

Wenn Leser sich direkt auf Arbitrums offizielles Kapitel über Sequencer und Force Inclusion beziehen, werden sie sehen, wie die dort erwähnte Force Inclusion kompatibel ist, sowie einige Parameternamen und Funktionsnamen: Der Benutzer geht zuerst zum Posteingang, um einen Termin zum Aufrufen der sendUnsignedTransaction-Funktion zu vereinbaren Wenn der Sequencer nicht innerhalb von 24 Stunden im Termineingang ist, kann der Benutzer die von Sequencer Inbox signierte ForceInclusion-Funktion aufrufen. Auf diese Weise ist nicht einmal der Link enthalten, und Sie können sich nur selbst auf die entsprechende Funktion im Programmcode einigen.

Wenn Sie die Funktion sendUnsignedTransaction finden, stellen Sie fest, dass Sie den Nonce-Wert und den maxFeePerGas-Wert tatsächlich selbst eingeben müssen. Welche Adresse ist die Nonce? Welches Netzwerk ist der maxFeePerGas-Wert? Wie füllt man es am besten aus? Es gibt keine Dokumentation, nicht einmal von Natpsec. Dann finden Sie auch eine Funktion, die Skins sammelt: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. Es gibt auch kein Dokument, das Ihnen den Unterschied zwischen diesen Funktionen, ihre Verwendung und das Ausfüllen der Parameter erklärt, nicht einmal Natpsec.

Sie überlegen alles und probieren es aus, bevor Sie die Parameter eingeben und die Transaktion senden. Sie möchten mithilfe von Versuch und Irrtum herausfinden, ob Sie die richtige Methode finden, stellen jedoch fest, dass diese Funktionen alle Ihre L1-Adresse als verwenden Adressalias, was dazu führt, dass der Transaktionsinitiator auf L2 im Grunde eine andere Adresse ist, sodass Ihre L2-Adresse überhaupt nicht verschoben wird.

L2-Nachricht senden

Später klickte ich versehentlich auf einen Link auf der Google-Suchseite und entdeckte, dass Arbitrum über eine Tutorial-Bibliothek verfügte. Darin befand sich ein Skript, das zeigte, wie L2-Transaktionen von L1 gesendet (oder erzwungen) werden, und dessen Funktion war überhaupt nicht vorhanden Dasselbe wie oben erwähnt. Ist eine davon nur eine Funktion namens sendL2Message, und der Nachrichtenparameter ist tatsächlich eine signierte Arbitrum L2-Transaktion? ? ? Wer hätte gedacht, dass „Senden von L2-Nachrichten“ tatsächlich „signierte L2-Transaktion“ bedeuten würde? ? Und wieder einmal gibt es keine Dokumentation oder Natspec, die erklärt, wann und wie diese Funktion verwendet wird.

Fazit: Es ist mühsam, eine Zwangseinkommenstransaktion von Arbitrum manuell zu generieren. Es wird empfohlen, dem offiziellen Tutorial zu folgen und das Arbitrum SDK auszuführen. Im Gegensatz zu anderen Rollups verfügt Arbitrum über eine klare Entwicklerdokumentation und Hinweise zum Projektcode. Der Zweck und die Parameter vieler Funktionen sind nicht erklärt, was dazu führt, dass Entwickler mehr Zeit als erwartet für den Zugriff und die Verwendung aufwenden. Ich habe auch Leute bei Arbitrum auf dem Arbitrum Discord gefragt, aber keine zufriedenstellende Antwort erhalten.

Hinweis: Als ich auf Discord fragte, bat mich die andere Partei lediglich, sendL2Message anzuhören. Es war nicht nötig zu erklären, wofür andere Funktionen (auch sendUnsignedTransaction, die in der obligatorischen Einschlussdatei erwähnt werden) verwendet werden, wie und wann sie verwendet werden Benutze sie.

Leider erzwingt StarkNet derzeit keine Aufnahme. Im offiziellen Forum gibt es nur zwei Artikel, die sich mit Zensur und obligatorischen Inklusionsmechanismen befassen.

Das Scheitern der Transaktion konnte nicht nachgewiesen werden

Der Grund dafür ist, dass das Zero-Knowledge-Proof-System von StarkNet keine Transaktionen nachweisen kann, die nicht erfasst wurden, sodass eine erzwungene Gutschrift nicht zugelassen werden kann. Denn wenn jemand böswillig (oder unbeabsichtigt) die Eingabe einer fehlgeschlagenen und nicht beweisbaren Transaktion erzwingt, bleibt StarkNet direkt hängen: Denn nachdem die Transaktion gewaltsam eingegeben wurde, muss der Prover die fehlgeschlagene Transaktion beweisen, hat aber keine Möglichkeit, dies zu beweisen . .

StarkNet erwartet, die Funktion zum Nachweis fehlgeschlagener Transaktionen in Version v0.15.0 einzuführen, und dann sollte es möglich sein, den obligatorischen Einschlussmechanismus weiter zu implementieren.

Der obligatorische Einschlussmechanismus von zkSync

Die L1->L2-Nachrichtenübermittlung und der erzwungene Einschlussmechanismus von zkSync werden alle über die requestL2Transaction-Funktion des MailBox-Vertrags durchgeführt. Der Benutzer gibt die anzurufende L2-Adresse, die Anrufdaten, die übertragene ETH-Menge, den L2-Gasgrenzwert usw. an. und teilt die Parameter von requestL2Transaction auf. In einer L2-Transaktion zusammengefasst und dann in der Prioritätswarteschlange simuliert, gibt der Sequenzer an, wie viele Transaktionen aus der Prioritätswarteschlange entnommen und zusammen empfangen werden sollen, wenn die Transaktionssicherung auf L1 hochgeladen wird (commitBatches-Funktion). .

zkSync ist Optimistic in Bezug auf die erzwungene Inklusionsschnittstelle sehr ähnlich. Beide verwenden die L2-Adresse des Benutzers, um relevante Daten (Angerufener, Anrufdaten usw.) auszufüllen, anstatt eine signierte L2-Transaktion wie Arbitrum einzugeben. Vom Design her unterhalten Transaktionen und Arbitrum jedoch eine Entitätswarteschlange in L1, und der Sequencer entnimmt Transaktionen aus der Warteschlange und schreibt sie in den Transaktionsverlauf.

Der Benutzer fügt über requestL2Transaction L2-Transaktionen in die Prioritätswarteschlange ein, und der Sequenzer kann beim Festschreiben von Batches mit der Transaktion aus der Prioritätswarteschlange kommunizieren.

Wenn Sie die ETH über die offizielle Brücke von zkSync aufladen, was der Transaktion zu diesem Zeitpunkt entspricht, ruft sie die requestL2Transaction-Funktion des MailBox-Vertrags auf. Dadurch bleibt die aufgeladene ETH in der L2-Transaktionsprioritätswarteschlange und gibt ein NewPriorityRequest-Ereignis aus. Da der Vertrag die L2-Transaktionsdaten in eine Bytefolge kodiert, ist es nicht einfach, sie zu lesen. Wenn Sie sich stattdessen die Parameter der L1-Transaktion ansehen, werden Sie feststellen, dass der Empfänger von L2 in den Parametern auch der Initiator der ist Transaktion, weil (es handelt sich um eine Einzahlung auf sich selbst). Wenn die L2-Transaktion der Börse nach einer Weile aus der Prioritätswarteschlange genommen und vom Sequenzer in den Transaktionsverlauf aufgenommen wird, wird sie auf L2 in eine Transaktion umgewandelt, die die Übertragung aufzeichnet an sich selbst, und der Betrag der Überweisung ist der Betrag, den der Transaktionsinitiator in L1 an die Einzahlungs-ETH-Börse gebracht hat.

Bei der L1-Aufladetransaktion sind sowohl der Initiator als auch der Empfänger der Transaktion 0xeDc1…6909, der Betrag beträgt 0,03 ETH und die Anrufdaten sind leer.

Auf L2 erscheint die Buchhaltung 0xeDc1…6909, eine Transaktion, die Sie an sich selbst übertragen. Der Transaktionstyp (Txn-Typ) ist 255, eine Systemtransaktion.

Als nächstes rief ich den requestL2Transaction-Brief direkt gemäß dem Skript auf und schickte die Transaktion, die den Anruf aufzeichnete, an mich selbst: Ohne ETH enthielten die Anrufdaten die hexadezimale Kodierung der Zeichenfolge „erzwungene Einbeziehung“. Die nachfolgende Formel wird in eine Transaktion auf L2 umgewandelt, die ihren eigenen Anruf aufzeichnet. Die Anrufdaten enthalten die Zeichenfolge „erzwungene Aufnahme“: 0x666f72636520696e636c7573696f6e.

Wenn der Sequenzer die Transaktion aus der Prioritätswarteschlange nimmt und in den Transaktionsverlauf schreibt, kann sie auf L2 in die entsprechende L2-Transaktion umgewandelt werden

Über die Funktion „requestL2Transaction“ können Benutzer eine L2-Transaktion auf L1 mit der L2-Adresse anfordern und dabei den L2-Empfänger, den mitgebrachten ETH-Betrag und die Anrufdaten angeben. Wenn der Benutzer andere Verträge mit anderen Daten aufrufen möchte, muss er die Parameter auch einzeln in die Funktion „requestL2Transaction“ eingeben. Denken Sie jedoch daran, die L2-Adresse für die Ausführung auf L1 zu verwenden, damit der L2-Transaktionsinitiator der L2 ist Adresse. .

Es gibt keine Funktion, mit der Benutzer Einnahmen erzwingen können

Obwohl durch das Platzieren von L2-Transaktionen in der Prioritätswarteschlange automatisch der Zeitraum berechnet wird, in dem L2-Transaktionen vom Sequenzer erfasst werden, enthält das aktuelle zkSync-Design keine obligatorischen zugehörigen Funktionen, die Benutzer selbst ausführen können, was einem halben Satz entspricht. Obwohl es also einen „Umsatzgültigkeitszeitraum“ gibt, hängt dieser tatsächlich immer noch davon ab, ob der Sequencer Einnahmen erhalten möchte: Der Sequencer kann bis zum Übergang warten, um Einnahmen zu erhalten, oder er kann niemals Transaktionen in der Prioritätswarteschlange empfangen. Zukünftig sollte zkSync relevante Funktionen hinzufügen, damit Benutzer Einnahmen erzwingen können, wenn die Einnahmen verstrichen sind, aber noch nicht vom Sequenzer empfangen wurden. Dies ist ein wirklich wirksamer Mechanismus zur erzwungenen Einbeziehung.

Zusammenfassen

• L1 verlässt sich auf eine große Gruppe von Menschen, um die „Sicherheit“ und „Zensurresistenz“ des Internets zu gewährleisten, während Rollup auf „die Zensurresistenz von L1“ angewiesen ist, um „die gleiche Sicherheit wie L1“ zu erreichen, die Zensurresistenz von Rollup jedoch nicht einbezieht. Fähigkeit

• Im Gegenteil, da Rollup eine kleine Anzahl oder sogar einen einzigen Sequenzer zum Schreiben von Transaktionen verwendet, ist seine Anti-Zensur-Fähigkeit noch schwächer. Daher benötigt Rollup einen Force-Inclusion-Mechanismus, der es Benutzern ermöglicht, Sequencer zu umgehen und Transaktionen in den Verlauf zu schreiben, um zu vermeiden, dass sie vom Sequencer überprüft werden und Rollup nicht verwenden oder verlassen können.

• Durch die erzwungene Einbeziehung können Benutzer das Schreiben von Transaktionen in den Verlauf erzwingen. Beim Entwurf müssen sie jedoch auswählen, ob die Transaktion sofort in den Verlauf eingefügt werden kann und sofort wirksam wird. Wenn Transaktionen sofort wirksam werden dürfen, führt dies zu Problemen für den Sequenzer und zu Schwierigkeiten bei der Benutzererfahrung, da Transaktionen, die auf L2 auf den Empfang warten, durch Transaktionen beeinträchtigt werden können, die von L1 zwangsweise empfangen werden

• Daher versetzt der aktuelle Rollup-Mechanismus zur erzwungenen Einbeziehung zunächst die auf L1 eingefügten Transaktionen in einen Wartezustand und gibt dem Sequenzer eine Zeitspanne, um zu reagieren und zu entscheiden, ob diese wartenden Transaktionen einbezogen werden sollen.

• Sowohl zkSync als auch Arbitrum unterhalten eine Entitätswarteschlange in L1, um L2-Transaktionen zu verwalten, die von Benutzern von L1 oder Nachrichten an L2 gesendet werden. Arbitrum nennt es verzögerten Posteingang; zkSync nennt es Prioritätswarteschlange

• Die Art und Weise, wie zkSync L2-Transaktionen sendet, ähnelt jedoch der von Optimism. Beide werden unter Verwendung der L2-Adresse an L1 gesendet, sodass der Initiator der L2-Transaktion die L2-Adresse ist. Die Funktion von Optimism zum Senden von L2-Transaktionen heißt DepositTransaction; zkSync heißt RequestL2Transaction. Arbitrum erstellt eine abgeschlossene L2-Transaktion, signiert sie und sendet sie dann über den sendL2Message-Brief. Arbitrum stellt den Unterzeichner durch die Signatur auf L2 als Initiator der L2-Transaktion wieder her.

• StarkNet verfügt derzeit nicht über einen erzwungenen Einschlussmechanismus; zkSync hat einen halben Satz obligatorischer Einschlüsse implementiert – es gibt eine Prioritätswarteschlange und die L2-Transaktionen in jeder Warteschlange haben eine Einkommensgültigkeitsdauer, aber diese Gültigkeitsdauer dient derzeit eigentlich nur der Dekoration , kann der Sequenzer wählen, überhaupt keine L2-Transaktionen mehr in der Prioritätswarteschlange zu empfangen