Originaltitel: „Einführung in den Force-Inclusion-Mechanismus von Rollup“
Autor: NIC Lin, Leiter des Taipei Ethereum Meetup
Erst gestern geschah etwas, das unzählige Menschen schockierte: Linea, die zweite Schicht von Ethereum, die von der Metamask-Muttergesellschaft Consensys ins Leben gerufen wurde, wurde proaktiv geschlossen, der Zweck sei, die Auswirkungen des Velocore-Hacking-Vorfalls zu verringern. Und das erinnert die Menschen unweigerlich an die frühere Abschaltung der BSC Chain (BNB Chain) unter offizieller Koordination, um die Verluste durch Hackerangriffe zu reduzieren. Immer wenn Leute über solche Dinge sprechen, werden sie an dem dezentralen Wert zweifeln, den Web3 vertritt.
Der Hauptgrund für die oben genannten Vorfälle liegt natürlich eher in der Unvollkommenheit der Infrastruktur selbst, also unzureichender Dezentralisierung: Wenn eine Kette ausreichend dezentralisiert ist, dann sollte sie nicht bei einem Schlag aufhören. Aufgrund der einzigartigen Struktur der zweiten Schicht von Ethereum stützen sich die meisten Schichten 2 auf den zentralisierten Sequenzer. Obwohl es in den letzten Jahren immer mehr Argumente für dezentrale Sequenzer gab, sind wir angesichts des Zwecks der zweiten Schicht und ihrer Struktur wahrscheinlich davon überzeugt Es kann davon ausgegangen werden, dass der Layer-2-Sortierer höchstwahrscheinlich nicht sehr dezentralisiert sein wird und möglicherweise letztendlich nicht so dezentralisiert ist wie die BSC-Kette. Wenn dies tatsächlich der Fall ist, was sollten wir tun?
Tatsächlich liegt der unmittelbarste Schaden, der durch die Nichtdezentralisierung des Sortierers für die zweite Schicht verursacht wird, in seiner Zensurresistenz und -aktivität. Wenn es nur wenige Entitäten (Sequenzer) gibt, die Transaktionen verarbeiten, dann hat es die absolute Macht darüber, ob es Sie bedient: Es kann Sie ablehnen, wenn es möchte, und Sie haben möglicherweise keine andere Wahl. Wie das Anti-Zensur-Problem der Schicht 2 gelöst werden kann, ist offensichtlich ein wichtiges Thema.
In den letzten Jahren haben große Zweitschichten von Ethereum verschiedene Lösungen für Anti-Zensur-Probleme vorgeschlagen, wie z. B. Loopring und Degate, die erzwungenen Rückzugs- und Fluchtlukenfunktionen von StarkEx sowie die Force Inclusion-Funktion von Arbitrum und anderen OP Rollup. Diese Methoden können Überprüfungen durchführen und Guthaben auf dem Sequencer unter bestimmten Bedingungen, um zu verhindern, dass dieser die Transaktionsanfrage eines Benutzers ohne Angabe von Gründen ablehnt.
Im heutigen Artikel gibt NIC Lin von der Taipei Ethereum Association seinen eigenen Bericht, experimentiert persönlich mit den Anti-Zensur-Transaktionsfunktionen von vier Mainstream-Rollups und analysiert das Mechanismusdesign von Force Inclusion unter Aspekten wie Arbeitsablauf und Betriebsmethoden eingehend sehr wichtig für Ethereum Es ist besonders wertvoll für die Community und große Investoren mit riesigen Vermögenswerten.
Transaktionsüberprüfung und erzwungene Einbeziehung
Der Widerstand gegen Transaktionszensur (Censorship Resistance) ist für eine Blockchain sehr wichtig. Wenn die Blockchain von Benutzern initiierte Transaktionen willkürlich überprüfen und ablehnen kann, unterscheidet sie sich nicht von einem Web2-Server. Der derzeitige Widerstand von Ethereum gegen Zensur beruht auf der großen Anzahl von Validatoren. Wenn jemand Bobs Transaktionen überprüfen und verhindern möchte, dass seine Transaktionen in die Kette hochgeladen werden, muss er entweder versuchen, die meisten Validatoren im Netzwerk zu bestechen, oder das gesamte Netzwerk mit Spam versehen Netzwerk sendet kontinuierlich Junk-Transaktionen mit höheren Bearbeitungsgebühren als Bob, um Blockplatz zu belegen. In jedem Fall werden die Kosten sehr hoch sein.
Hinweis: In der aktuellen PBS-Struktur von Ethereum werden die Kosten für die Überprüfung von Transaktionen erheblich reduziert. Sie können sich auf den Anteil der Blöcke beziehen, die mit OFAC zusammenarbeiten, um Tornado Cash-Transaktionen zu überprüfen. Der derzeitige Widerstand gegen Zensur beruht auf unabhängigen Prüfern und Weiterleitungen außerhalb der Zuständigkeit des OFAC und der Regierung.
Aber was ist mit Rollup? Rollup erfordert keine große Anzahl von Validatoren, um die Sicherheit zu gewährleisten. Auch wenn Rollup nur eine zentrale Rolle (Sequenzer) zum Generieren von Blöcken hat, ist es genauso sicher wie L1. Aber Sicherheit und Zensurresistenz sind zwei verschiedene Dinge. Selbst wenn ein Rollup so sicher ist wie Ethereum, können mit nur einem zentralen Sequenzer die Transaktionen jedes Benutzers zensiert werden.
Sequencer kann sich weigern, die Transaktion des Benutzers zu verarbeiten, was dazu führt, dass das Geld des Benutzers einbehalten wird und er das Rollup nicht verlassen kann.
Force-Inclusion-Mechanismus
Anstatt von Rollup eine große Anzahl dezentraler Sequenzer zu verlangen, ist es besser, die Anti-Zensur-Funktionen von L1 direkt zu nutzen:
Ursprünglich dient Sequencer dazu, Transaktionsdaten zu packen und an den L1-Rollup-Vertrag zu senden. Es ist besser, dem Vertrag ein Design hinzuzufügen, damit Benutzer Transaktionen selbst in den Rollup-Vertrag einfügen können. Solange Sequencer Benutzer auf L1-Ebene nicht zensieren kann, kann er Benutzer nicht daran hindern, Transaktionen auf L1 zwangsweise einzufügen. Auf diese Weise kann Rollup die Zensurresistenz von L1 erben.
Sequencer kann die L1-Transaktionen des Benutzers nicht überprüfen, ohne hohe Kosten zu zahlen
Wie sollen Zwangstransaktionen wirksam werden?
Wenn Transaktionen durch Force Inclusion direkt in den Rollup-Vertrag geschrieben werden dürfen (d. h. mit sofortiger Wirkung), ändert sich der Status des Rollups sofort. Beispielsweise fügt Bob durch Force Inclusion eine Transaktion „1000 DAI an Carol übertragen“ ein Wenn die Transaktion sofort wirksam wird, beträgt Bobs Kontostand im letzten Status 1.000 DAI weniger und Carols Kontostand 1.000 DAI mehr.
Wenn Force Inclusion die Transaktion direkt in den Rollup-Vertrag schreiben und sofort wirksam werden kann, ändert sich der Status sofort.
Wenn der Sequencer zu diesem Zeitpunkt auch Transaktionen außerhalb der Kette sammelt und den nächsten Transaktionsstapel an den Rollup-Vertrag sendet, kann er von den Transaktionen, die Bob zwangsweise einfügt, betroffen sein und sofort wirksam werden. Diese Art von Problem muss so weit wie möglich vermieden werden, daher sorgt Rollup im Allgemeinen nicht dafür, dass die Force Inclusion-Transaktion sofort wirksam wird. Stattdessen kann der Benutzer die Transaktion zunächst in die Warteschlange auf L1 einfügen und in den Status „Vorbereiten“ wechseln .
Wenn Sequencer Off-Chain-Transaktionen verpackt und an den Rollup-Vertrag sendet, entscheidet er, ob die oben genannten Transaktionen in die Transaktionssequenz eingefügt werden sollen. Wenn Sequencer diese Transaktionen im „Vorbereitungs“-Status ignoriert hat, wird der Benutzer nach Ablauf des Fensterzeitraums entscheiden kann diese Transaktionen erzwingen.
Der Sequenzer kann entscheiden, wann in der Warteschlange wartende Transaktionen „nebenbei“ empfangen werden
Der Sequencer kann weiterhin die Verarbeitung von Transaktionen in der Warteschlange verweigern.
Wenn der Sequencer sich längere Zeit weigert, kann nach einer gewissen Zeit jeder die Transaktion über die Force Inclusion-Funktion in den Rollup-Vertrag einbinden.
Als nächstes werden wir der Reihe nach die Implementierung des Force-Inclusion-Mechanismus von vier bekannten Rollups vorstellen, darunter Optimism, Arbitrum, StarkNet und zkSync.
Der Force-Inclusion-Mechanismus des Optimismus
Zunächst stellen wir den Einzahlungsprozess von Optimism vor. Diese Einzahlung bezieht sich nicht nur auf die Einzahlung von Geld in Optimism, sondern umfasst auch das „Senden von von Benutzern an L2 gesendeten Informationen“ an L2. Nach dem Empfang der neu hinterlegten Nachricht wandelt der L2-Knoten die Nachricht zur Ausführung in eine L2-Transaktion um und sendet sie an den angegebenen Empfänger der Nachricht.
Benutzernachricht von L1-Einzahlung an L2
L1CrossDomainMessenger-Vertrag
Wenn ein Benutzer ETH- oder ERC-20-Token in Optimism einzahlen möchte, interagiert er über die Front-End-Webseite mit dem L1StandardBridge-Vertrag auf L1 und gibt an, wie viel eingezahlt werden soll und an welche L2-Adresse diese Vermögenswerte gesendet werden sollen.
Der L1StandardBridge-Vertrag leitet die Nachricht an den L1CrossDomainMessenger-Vertrag der nächsten Ebene weiter. Dieser Vertrag wird hauptsächlich als Komponente für die gegenseitige Kommunikation zwischen L1 und L2 verwendet. Über diese allgemeine Kommunikationskomponente kommuniziert L1StandardBridge in L2. Münzen, oder wer kann Token von L1 freischalten.
Wenn ein Entwickler einen Vertrag entwickeln muss, der den Status zwischen L1 und L2 kommuniziert und synchronisiert, kann er ihn auf dem L1CrossDomainMessenger-Vertrag aufbauen.
Die Nachricht des Benutzers wird über den CrossDomainMessenger-Vertrag von L1 an L2 weitergeleitet
Hinweis: In einigen Bildern in diesem Artikel wird CrossDomainMessager als CrossChainMessager geschrieben
OptimismPortal-Vertrag
Der L1CrossDomainMessenger-Vertrag sendet die Nachricht dann an den OptimismPortal-Vertrag der untersten Ebene. Nach der Verarbeitung löst der OptimismPortal-Vertrag ein Ereignis namens „TransactionDeposited“ aus. Zu den Parametern gehören „die Person, die die Nachricht gesendet hat“, „die Person, die die Nachricht erhalten hat“. und zugehörige Ausführungsparameter.
Dann hört der L2-Optimismus-Knoten das vom OptimismPortal-Vertrag ausgelöste „Transaction Deposited“-Ereignis ab und wandelt die Parameter im Ereignis in eine L2-Transaktion um. Der Initiator dieser Transaktion ist der im „Transaction Deposited“-Ereignisparameter angegebene „Nachrichtensender“. Der Transaktionsempfänger ist die „Person, die die Nachricht empfängt“ in den Ereignisparametern, und andere Transaktionsparameter werden ebenfalls von den Parametern in den oben genannten Ereignissen abgeleitet.
Der L2-Knoten wandelt den Ereignisparameter „Transaction Deposited“ von OptimismPortalemit in eine L2-Transaktion um
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 ist 0xbEb5...06Ed) und dann in einen L2 umgewandelt Transaktion ein paar Minuten später:
Der Initiator der Nachricht ist der L1CrossDomainMessenger-Vertrag; der Empfänger ist der L2CrossDomainMessenger-Vertrag auf L2; der Inhalt der Nachricht ist, dass L1StandardBridge die Einzahlung von BoB in Höhe von 0,01 ETH erhalten hat. Danach werden einige Prozesse ausgelöst, beispielsweise die Ausgabe zusätzlicher 0,01 ETH an L2StandardBridge, die dann an Bob übertragen werden.
Wie man es gezielt auslöst
Wenn Sie eine Transaktion in den Rollup-Vertrag von Optimism erzwingen möchten, besteht der gewünschte Effekt darin, dass eine „auf L2 von Ihrer L2-Adresse initiierte und ausgeführte Transaktion“ reibungslos ausgeführt werden kann. Zu diesem Zeitpunkt sollten Sie Ihre L2-Adresse verwenden sendet die Nachricht direkt an den OptimismPortal-Vertrag (beachten Sie, dass sich der OptimismPortal-Vertrag tatsächlich auf L1 befindet, das Adressformat des OP jedoch mit dem L1-Adressformat übereinstimmt. Sie können den obigen Vertrag direkt über das L1-Konto mit derselben Adresse wie aufrufen L2-Konto).
Der „Initiator“ der L2-Transaktion, die durch das vom Vertrag ausgelöste „Transaction Deposited“-Ereignis umgewandelt wird, ist Ihr L2-Konto. Zu diesem Zeitpunkt stimmt das Transaktionsformat mit der normalen L2-Transaktion überein.
Bei der vom Transaction Deposited-Ereignis umgewandelten 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.
Wenn Sie die Force Inclusion-Funktion von Optimism aufrufen möchten, müssen Sie direkt die DepositTransaction-Funktion des OptimismPortal-Vertrags aufrufen und die Parameter der Transaktion eingeben, die Sie in L2 ausführen möchten.
Ich habe ein einfaches Force-Inclusion-Experiment durchgeführt, um eines zu erreichen: meine Adresse für die Selbstübertragung auf L2 (0xeDc1...6909) zu verwenden, und habe eine Textnachricht mit dem Titel „Force Inclusion“ angehängt.
Dies ist die L1-Transaktion, in der ich die Funktion „depositTransaction“ über den OptimismPortal-Vertrag ausführe. Sie können sehen, dass sie im „Transaction Deposited“-Ereignis sowohl „von“ als auch „an“ auslöst.
Die Werte in der verbleibenden undurchsichtigen Datenspalte kodieren „wie viel ETH kommt mit der Person, die die Einzahlungstransaktionsfunktion aufruft“, „wie viel ETH möchte der L2-Transaktionsinitiator an den Empfänger senden“, „L2-Transaktion GasLimit“ und „ zu den Daten des L2-Empfängers" und anderen Informationen.
Nach der Dekodierung der obigen Informationen erhalten Sie:
„Wie viel ETH wurde von der Person angehängt, die die Einzahlungstransaktion aufgerufen hat“: 0, weil ich ETH nicht von L1 auf L2 eingezahlt habe;
„Wie viel ETH möchte der L2-Transaktionsinitiator an den Empfänger senden“: 5566 (wei)
„GasLimit für L2-Transaktionen“: 50000
„Daten für L2-Empfänger“: 0x666f72636520696e636c7573696f6e, was die hexadezimale Kodierung der Zeichenfolge „Force Inclusion“ ist.
Nicht lange danach erschien die konvertierte L2-Transaktion: eine L2-Transaktion, bei der ich Geld an mich selbst überwiesen habe, der Betrag war 5566 Wei und die Daten waren die Zeichenfolge „Einschluss erzwingen“. Und Sie können feststellen, dass der TxnType (Transaktionstyp) in „Andere Attribute“ in der vorletzten Zeile im Bild die Systemtransaktion 126 (System) zeigt, was bedeutet, dass diese Transaktion nicht von mir in L2 initiiert wurde, sondern von der L1-Transaktion hinterlegt wurde . Ereignisse werden transformiert.
Konvertierte L2-Transaktion
Wenn Sie den L2-Vertrag aufrufen und unterschiedliche Daten über Force Inclusion senden möchten, müssen Sie lediglich die Parameter einzeln in die vorherige Einzahlungstransaktionsfunktion eingeben. Denken Sie daran, zum Aufrufen dieselbe L1-Adresse wie Ihr L2-Konto zu verwenden Einzahlungstransaktionsfunktion, sodass der Initiator Ihr L2-Konto ist, wenn das hinterlegte Ereignis in eine L2-Transaktion umgewandelt wird.
Sequenzerfenster
Der zuvor erwähnte Optimism-L2-Knoten wandelt das Transaction Deposited-Ereignis in eine L2-Transaktion um. Tatsächlich bezieht sich dieser Optimism-Knoten auf den Sequencer. Dies hängt also mit der Transaktionssequenzierung zusammen, sodass nur der Sequencer entscheiden kann, wann das oben genannte Ereignis umgewandelt werden soll eine L2-Transaktion.
Beim Abhören des TransactionDeposited-Ereignisses wandelt der Sequencer das Ereignis nicht unbedingt sofort in eine L2-Transaktion um. Der maximale Wert dieses Zeitraums wird als SequencerWindow bezeichnet.
Das aktuelle Sequencer-Fenster im Optimism-Mainnet beträgt 24 Stunden. Das heißt, wenn ein Benutzer einen Geldbetrag von L1 einzahlt oder eine Transaktion erzwingt, besteht das schlimmste Szenario darin, dass er nach 24 Stunden in den L2-Transaktionsverlauf aufgenommen wird.
Der Force-Inclusion-Mechanismus von Arbitrum
In Optimism löst die Einzahlungsoperation von L1 ein Transaction Deposited-Ereignis aus, und der Rest besteht darin, darauf zu warten, dass der Sequencer die oben genannten Vorgänge erfasst. In Arbitrum werden jedoch die in L1 ausgeführten Vorgänge (Geld sparen oder Nachrichten an L2 senden usw.) ausgeführt .) wird in L1 in einer Warteschlange gespeichert, anstatt einfach ein Ereignis auszulösen.
Dem Sequencer wird eine Zeitspanne gegeben, um die Transaktionen in der oben genannten Warteschlange in den L2-Transaktionsverlauf aufzunehmen. Wenn der Sequencer nach Ablauf der Zeit nichts unternimmt, kann jeder die Transaktion für den Sequencer abschließen.
Arbitrum verwaltet eine Warteschlange im L1-Vertrag. Wenn der Sequencer die Transaktionen in der Warteschlange nicht aktiv verarbeitet, kann jeder erzwingen, dass die Transaktionen in der Warteschlange in den L2-Transaktionsverlauf aufgenommen werden.
Im Design von Arbitrum müssen Vorgänge wie Einzahlungen, die auf L1 erfolgen, über den Delayed-Inbox-Vertrag erfolgen. Wie der Name schon sagt, werden die Vorgänge hier verzögert wirksam. Der andere Vertrag ist der direkte Ort, an dem die Der Sequenzer lädt L2-Transaktionen auf L1 hoch. Jedes Mal, wenn der Sequencer eine L2-Transaktion hochlädt, kann er einige ausstehende Transaktionen aus dem verzögerten Posteingang entnehmen und in den Transaktionsverlauf schreiben.
Wenn Sequencer eine neue Transaktion schreibt, kann er die Transaktion aus DelayedInbox herausnehmen und zusammenschreiben.
Aufwendige Designs und hervorragende Referenzmaterialien
Wenn Leser direkt auf Arbitrums offizielles Kapitel über Sequencer und Force Inclusion verweisen, werden sie feststellen, dass dort erwähnt wird, wie Force Inclusion ungefähr funktioniert, sowie einige Parameternamen und Funktionsnamen:
Der Benutzer geht zunächst zum DelayedInbox-Vertrag, um die sendUnsignedTransaction-Funktion aufzurufen. Wenn der Sequencer nicht innerhalb von etwa 24 Stunden eingebunden wird, kann der Benutzer die forceInclusion-Funktion des SequencerInbox-Vertrags aufrufen. Dann hat der Arbitrum-Beamte den Link der Funktion nicht an das offizielle Website-Dokument angehängt, sodass Sie sich die entsprechende Funktion nur im Vertragscode selbst ansehen können.
Wenn Sie die Funktion sendUnsignedTransaction finden, müssen Sie den Nonce-Wert und den maxFeePerGas-Wert selbst eingeben. Welche Adresse ist die Nonce? In welchem Netzwerk ist maxFeePerGas? Wie füllt man es am besten aus? Es gibt keinen Dateiverweis, nicht einmal Natpsec. Dann finden Sie im Arbitrum-Vertrag auch eine Reihe ähnlich aussehender Funktionen:
SendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, es gibt kein Dokument, das Ihnen den Unterschied zwischen diesen Funktionen erklärt, wie Sie sie verwenden, wie Sie die Parameter ausfüllen, nicht einmal Natpsec.
Sie versuchen, die Parameter einzugeben und die Transaktion mit der Einstellung zu senden, es auszuprobieren. Sie möchten durch Ausprobieren herausfinden, ob Sie die richtige Verwendung finden können, stellen jedoch fest, dass alle diese Funktionen AddressAliasing für Ihre L1-Adresse durchführen , was zum endgültigen Fehler auf L2 führt. Der Absender beim Initiieren der Transaktion ist einfach eine andere Adresse, sodass Ihre L2-Adresse unverändert bleibt.
sendL2Message
Später habe ich versehentlich auf die Google-Suche geklickt und herausgefunden, dass Arbitrum über eine Tutorial-Bibliothek verfügt, die Skripte enthält, die demonstrieren, wie L2-Transaktionen von L1 gesendet werden (was Force Inclusion bedeutet), und dass die darin aufgeführten Funktionen keine dieser Funktionen sind oben erwähnt, aber eine Funktion namens sendL2Message, und der Nachrichtenparameter ist tatsächlich eine mit dem L2-Konto signierte Transaktion?
Wer hätte gedacht, dass die „durch Force Inclusion an L2 gesendete Nachricht“ tatsächlich eine „signierte L2-Transaktion“ sein würde? Und es gibt keine Dokumentation oder Natspec, die erklärt, wann und wie diese Funktion verwendet wird.
Fazit: Es ist mühsam, eine erzwungene Arbitrum-Transaktion 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 Codehinweise. 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 die Leute von Arbitrum auf dem Arbitrum Discord gefragt, aber keine zufriedenstellende Antwort erhalten.
Als ich auf Discord nachfragte, sagte mir die andere Partei nur, ich solle mir sendL2Message ansehen. Sie wollte nicht erklären, welche Funktionen andere Funktionen haben (sogar sendUnsignedTransaction, die im Force Inclusion-Dokument erwähnt werden), wofür sie verwendet werden und wie man sie verwendet und wann man sie verwendet.
Der ForceInclusion-Mechanismus von StarkNet
Leider verfügt StarkNet derzeit nicht über einen ForceInclusion-Mechanismus. Im offiziellen Forum gibt es nur zwei Artikel über Zensur und ForceInclusion.
Fehlgeschlagene Transaktion konnte nicht nachgewiesen werden
Der oben genannte Grund liegt tatsächlich darin, dass das Zero-Knowledge-Proof-System von StarkNet eine fehlgeschlagene Transaktion nicht nachweisen kann, sodass Force Inclusion nicht zugelassen werden kann. Denn wenn jemand böswillig (oder unbeabsichtigt) eine fehlgeschlagene Transaktion erzwingt, die nicht nachgewiesen werden kann, bleibt StarkNet direkt hängen: Denn nachdem die Transaktion gewaltsam eingeschlossen 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 Force-Inclusion-Mechanismus weiter zu implementieren.
ForceInclusion-Mechanismus von zkSync
Die L1->L2-Nachrichtenübertragung und der Force-Inclusion-Mechanismus von zkSync werden alle über die requestL2Transaction-Funktion des MailBox-Vertrags durchgeführt. Der Benutzer gibt die L2-Adresse, die Anrufdaten, den zusätzlichen ETH-Betrag, den L2GasLimit-Wert usw. an. requestL2Transaction kombiniert diese Parameter zu einem L2 Die Transaktion wird dann in die Prioritätswarteschlange (PriorityQueue) gestellt. Wenn die Transaktion verpackt und auf L1 hochgeladen wird (über die Funktion commitBatches), gibt der Sequenzer an, wie viele Transaktionen aus der Prioritätswarteschlange entnommen werden sollen, und fügt sie in den L2-Transaktionsdatensatz ein .
zkSync ist Optimism in Form von Force Inclusion sehr ähnlich. Es verwendet die L2-Adresse des Initiators (konsistent mit der L1-Adresse), um verwandte Funktionen aufzurufen und die Daten (Angerufener, Anrufdaten usw.) einzugeben In einer signierten L2-Transaktion ist das Design jedoch das gleiche wie bei Arbitrum. Beide unterhalten eine Warteschlange in L1, und der Sequenzer entnimmt die vom Benutzer direkt übermittelten ausstehenden Transaktionen aus der Warteschlange und schreibt sie in die Mitte des Transaktionsverlaufs.
Wenn Sie über die offizielle Brücke von zkSync zu Deposit ETH wechseln, ruft diese die requestL2Transaction-Funktion des MailBox-Vertrags auf. Dadurch wird die L2-Transaktion von Deposit ETH in die Prioritätswarteschlange gestellt und ein NewPriorityRequest-Ereignis ausgelöst. Da der Vertrag die L2-Transaktionsdaten in eine Bytefolge kodiert, ist es schwierig, sie zu lesen. Wenn Sie sich die Parameter dieser L1-Transaktion ansehen, werden Sie feststellen, dass der Empfänger von L2 in den Parametern auch der Initiator der Transaktion ist (. weil es bei Ihnen selbst hinterlegt ist), also wird diese L2-Transaktion nach einer Weile, wenn sie vom Sequencer aus der Prioritätswarteschlange genommen und in den Transaktionsverlauf aufgenommen wird, in eine Transaktion umgewandelt, die auf L2 an sich selbst übertragen wird, und der Betrag von Bei der Übertragung handelt es sich um die Einzahlung des Transaktionsinitiators in L1. Der in der ETH-Transaktion enthaltene ETH-Betrag.
In der L1Deposit-Transaktion 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.
Es findet eine Transaktion von 0xeDc1...6909 statt, bei der auf L2 Geld an Sie selbst überwiesen wird. Der Transaktionstyp (TxnType) ist 255, eine Systemtransaktion.
Dann habe ich direkt die requestL2Transaction-Funktion von zkSync aufgerufen und eine Selbstübertragung gesendet, genau wie ich es zuvor getan habe, als ich mit der erzwungenen Transaktionsfunktion des OP experimentiert habe: Ohne ETH brachten die Aufrufdaten die HEX-Kodierung der Zeichenfolge „Force Inclusion“ ein.
Dann wird es in die letzte Transaktion von L2 für sich selbst konvertiert. Die Aufrufdaten sind die hexadezimale Zeichenfolge von „Inklusion erzwingen“: 0x666f72636520696e636c7573696f6e.
Wenn der Sequencer die Transaktion aus der PriorityQueue nimmt und in den Transaktionsverlauf schreibt, wird sie auf L2 in die entsprechende L2-Transaktion umgewandelt.
Über die Funktion „requestL2Transaction“ können Benutzer das L1-Konto mit derselben L2-Adresse verwenden, um Informationen in L1 zu übermitteln und dabei den L2-Empfänger, den zugehörigen ETH-Betrag und Anrufdaten anzugeben. Wenn der Benutzer andere Verträge mit unterschiedlichen Daten aufrufen möchte, geschieht dies auch, indem er die Parameter nacheinander in die Funktion requestL2Transaction einträgt.
Es gibt keine Funktion, mit der Benutzer die Aufnahme erzwingen können
Nachdem die L2-Transaktion in die Prioritätswarteschlange gestellt wurde, wird zwar nebenbei die Wartezeit für die Aufnahme der L2-Transaktion in den Sequencer berechnet. Das aktuelle zkSync-Design verfügt jedoch nicht über eine Force-Inclusion-Funktion, die Benutzer erzwingen können entspricht nur einem halben Satz. Das heißt, obwohl es eine „Wartezeit für die Aufnahme“ gibt, geht es tatsächlich darum, „zu prüfen, ob der Sequenzierer Einnahmen erhalten möchte“: Der Sequenzierer kann bis zum Ablaufdatum warten, bevor er die Transaktion empfängt, oder er kann niemals Transaktionen empfangen in der Prioritätswarteschlange.
Zukünftig sollte zkSync entsprechende Funktionen hinzufügen, damit Benutzer die Aufnahme der Transaktion in den L2-Transaktionsverlauf erzwingen können, wenn der Einkommensgültigkeitszeitraum abgelaufen ist, aber nicht in den Sequencer aufgenommen wurde. Dies ist ein wirklich effektiver Force-Inclusion-Mechanismus.
Zusammenfassen
L1 ist auf eine große Anzahl von Validatoren angewiesen, um die „Sicherheit“ und „Zensurresistenz“ des Netzwerks zu gewährleisten. Rollup verwendet eine kleine Anzahl oder sogar einen einzigen Sequenzer zum Schreiben von Transaktionen, und seine Zensurresistenz ist noch schwächer. Daher benötigt Rollup einen Force-Inclusion-Mechanismus, der es Benutzern ermöglicht, den Sequencer zu umgehen und Transaktionen in den Verlauf zu schreiben, um eine Überprüfung durch den Sequencer zu vermeiden und es unmöglich zu machen, Gelder aus dem Rollup zu verwenden und abzuheben.
Mit Force Inclusion 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, wirkt sich dies negativ auf den Sequenzer aus, da Transaktionen, die auf L2 auf den Empfang warten, von Transaktionen beeinflusst werden können, die von L1 zwangsweise empfangen werden.
Daher versetzt der aktuelle Force-Inclusion-Mechanismus von Rollup zunächst die auf L1 eingefügten Transaktionen in einen Wartezustand und gibt dem Sequencer eine Zeitspanne, um zu reagieren und zu entscheiden, ob diese ausstehenden Transaktionen einbezogen werden sollen.
Sowohl zkSync als auch Arbitrum unterhalten eine Warteschlange in L1, um L2-Transaktionen zu verwalten, die von Benutzern von L1 oder Nachrichten an L2 gesendet werden. Arbitrum heißt DelayedInbox; zkSync heißt PriorityQueue
Die Art und Weise, wie zkSync L2-Transaktionen sendet, ähnelt der von Optimism. Es verwendet die L2-Adresse, um Nachrichten an L1 zu senden. Nach der Konvertierung in eine L2-Transaktion ist die L2-Adresse der Initiator. Die Funktion von Optimism zum Senden von L2-Transaktionen heißt DepositTransaction; zkSync heißt RequestL2Transaction. Arbitrum generiert und signiert eine vollständige L2-Transaktion und sendet sie dann über die sendL2Message-Funktion. Arbitrum stellt den Unterzeichner durch die Signatur auf L2 als Initiator der L2-Transaktion wieder her.
StarkNet verfügt derzeit nicht über einen Force-Inklusion-Mechanismus; zkSync ist wie ein halber Satz von Force-Inklusion – es gibt eine PriorityQueue und jede L2-Transaktion in der Warteschlange hat einen Inklusionsgültigkeitszeitraum, aber dieser Gültigkeitszeitraum dient derzeit nur der Dekoration. Der Sequenzer kann sich dafür entscheiden, überhaupt keine L2-Transaktionen in die PriorityQueue aufzunehmen
