Wann kann man sich sicher sein, dass eine L2 (Layer 2) Transaktion in einen Block aufgenommen wird? Wann kann man sicher sein, dass Einnahmen aus einer L2-Transaktion aufgrund eines Re-Org nicht verworfen werden?

Dieser Artikel wird den gesamten Ablauf der L2-Transaktionsimplementierung vorstellen und die Sicherheitsleistung in jedem Stadium des Transaktionsprozesses analysieren.

Grundkenntnisse:

• Der gesamte Prozess von L1 (Layer 1) Transaktionen
• Gründe und Auswirkungen von Re-Org-Vorkommnissen
• Verständnis der Rollen und Betriebsmethoden in der aktuellen Ethereum PBS-Architektur
• Unterschiede zwischen Optimistic Rollup und Validitäts (ZK) Rollup

Verständnis von L1-Transaktionen

Transaktionsprozess

Nachdem ein Benutzer eine Transaktion ausgestellt und unterzeichnet hat, wird sie an das P2P-Netzwerk gesendet und wartet darauf, in einen Block durch einen Miner unter dem Proof-of-Work (PoW)-Konsensmechanismus oder einen Vorschlagenden unter dem Proof-of-Stake (PoS)-Konsensmechanismus aufgenommen zu werden. Wenn ein Benutzer feststellt, dass seine Transaktion im neuesten Block enthalten ist, ist es noch nicht sicher, dass die Transaktion dauerhaft in der Blockchain-Geschichte aufgezeichnet wird. Diese Unsicherheit ergibt sich aus der Möglichkeit einer „Re-Org“ (Reorganisation) auf der Blockchain. Benutzer müssen warten, bis die Wahrscheinlichkeit eines Re-Orgs ausreichend gering ist, um sicher zu sein, dass ihre Transaktion dauerhaft in der Blockchain-Geschichte aufgezeichnet wird.

L1 Transaktionsprozess illustriert

Auch nachdem eine Transaktion in einen Block aufgenommen wurde, kann immer noch ein Re-Org auftreten, was bedeutet, dass eine Bestätigung erst dann gewährleistet ist, wenn die Wahrscheinlichkeit eines Re-Orgs unwahrscheinlich wird.

Die Wahrscheinlichkeit und die Kosten für einen Re-org variieren je nach Konsensalgorithmus der Blockchain und dem Marktwert ihrer Vermögenswerte. In diesem Dokument wird nicht auf die Berechnungsmethoden für Re-org-Kosten eingegangen.

Verständnis von L2-Transaktionen

Transaktionsprozess

L2-Benutzer generieren und signieren Transaktionen, die sie normalerweise direkt an einen Sequenzer senden, der diese Transaktionen dann in einem L2-Block einschließt. Anschließend, wenn der Sequenzer die L2-Blockdaten über eine L1-Transaktion zurück an L1 sendet, können Benutzer ihre Transaktionen im neuesten L2-Block sehen.

Es ist jedoch wichtig zu beachten, dass da die L2-Blockdaten über eine L1-Transaktion an L1 übermittelt werden, es immer noch möglich ist, dass ein L1-Re-org auftritt, was möglicherweise dazu führt, dass der L2-Block nicht dauerhaft in der Blockchain-Geschichte aufgezeichnet wird. Dieses Szenario ähnelt einem L2-Re-org, daher müssen Benutzer warten, bis die Wahrscheinlichkeit eines L1-Re-orgs ausreichend gering ist, um sicher zu sein, dass ihre Transaktion dauerhaft in der Blockchain-Geschichte aufgezeichnet wird.

L2 Transaktionsprozess illustriert

Benutzer müssen zunächst auf ihre Transaktion warten, um in einem L2-Block aufgenommen zu werden, dann darauf, dass der L2-Block über eine L1-Transaktion an L1 übermittelt wird, und schließlich darauf, dass die L1-Transaktion abgeschlossen wird.

Obwohl L2-Transaktionen im Vergleich zu L1-Transaktionen eine zusätzliche Wartezeit für die Aufnahme in einen L2-Block durch den Sequenzer mit sich bringen, ist diese Wartezeit im Allgemeinen kurz, wenn die Kapazität des L2-Blocks groß ist und die Blockgenerierung schnell erfolgt, da die Hauptwarteperiode für die Bestätigung der L1-Transaktion ist. Somit ist das Gesamterlebnis für Benutzer von L1- und L2-Transaktionen ähnlich.

Vorbestätigung/Schnellbestätigung/Soft-Bestätigung

Benutzer sollten persönlich überprüfen, ob ihre L2-Transaktionen zusammen mit dem L2-Block in einem L1-Block enthalten sind und sogar warten, bis die Wahrscheinlichkeit eines Re-Orgs ausreichend niedrig ist, um darauf zu vertrauen, dass ihre L2-Transaktion enthalten ist.

Aber was ist, wenn Benutzer dem Sequencer vertrauen wollen? Der Sequencer könnte vom L2-Entwicklungsteam oder einer seriösen Institution betrieben werden. Wenn der Sequencer den Benutzern sofort versichert, dass ihre Transaktionen nach Erhalt unmittelbar in einen bestimmten Block aufgenommen werden, könnte diese Garantie für diejenigen ausreichen, die dem Sequencer vertrauen möchten. Es ähnelt einem Benutzer, der seiner Wallet-Anwendung vertraut und nicht obsessiv Etherscan überprüft, um nach dem Erhalt einer Transaktionsbenachrichtigung eine Bestätigung zu erhalten.

Solche Garantien, die vom Sequenzer bereitgestellt werden, werden als Vorbestätigung, Schnellbestätigung oder Soft-Bestätigung bezeichnet. Diese gelten als "vorläufige" oder "weiche" Zusicherungen für die Transaktionseinschluss, die nicht erfordern, dass die L2-Transaktion in einem L1-Block enthalten ist. Es handelt sich jedoch lediglich um mündliche Verpflichtungen des Sequenzers, die aufgrund eines Fehlers vergessen oder bewusst von einem bösartigen Sequenzer gebrochen werden können, was im schlimmsten Fall zu einem Doppelverbrauch führt.

Anschließend werden wir verschiedene Möglichkeiten vorstellen, wie L2-Transaktionsinklusivitätsstatus präsentiert werden.

Arbitrum/Optimism Transaktionsinklusionsstatus

Derzeit können Benutzer auf Arbitrum oder Optimismus fast unmittelbar nach dem Senden einer Transaktion eine Transaktionsquittung erhalten, die das Ergebnis der Transaktionsausführung anzeigt. Dies zeigt an, dass der Sequenzer die Transaktion bereits lokal sequenziert und simuliert hat und den Benutzern eine Vorbestätigung bereitstellt.

Mehr erfahren

Für weitere Informationen zum Arbitrum-Transaktionslebenszyklus siehe die offizielle Dokumentation:https://docs.arbitrum.io/tx-lifecycle

Für weitere ausführliche Informationen zum Optimism-Transaktionslebenszyklus siehe die offizielle Dokumentation:https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Handels- Einkommensstatus für Arbitrum/Optimismus

Derzeit können Benutzer nach dem Senden einer Transaktion auf Arbitrum oder Optimismus fast sofort eine Transaktionsquittung (Transaktionsquittung) erhalten, die die Ergebnisse der Transaktionsausführung enthält. Dies bedeutet, dass der Sequenzer die Transaktion lokal sequenziert und einmal simuliert hat. Diese Transaktionsquittung ist die Vorbestätigung, die dem Benutzer gegeben wird.

mehr erfahren

Für eine ausführlichere Einführung in den Transaktionslebenszyklus von Arbitrum können Sie den unten stehenden Link kopieren und im Browser auf das offizielle Dokument verweisen:

https://docs.arbitrum.io/tx-lifecycle

Für eine ausführlichere Einführung in den Transaktionslebenszyklus von Optimism können Sie den Link unten in den Browser kopieren und das offizielle Dokument konsultieren:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Überprüfen Sie den Transaktionseingangsstatus auf Arbitrum

Die auf dem Arbitrum Explorer angezeigten Transaktionen umfassen Pre-Confirmation-Transaktionen, d.h. Transaktionen, die noch nicht auf L1 hochgeladen wurden. Bei dieser Transaktion, wie im untenstehenden Bild gezeigt, sehen Sie eine Bestätigung durch den Sequenzer neben der Blocknummer 145353000:

Das obige Bild zeigt Transaktionen, die nur vom Sequenzer bestätigt, aber noch nicht auf L1 hochgeladen wurden.

Wenn es sich um eine Transaktion handelt, die gemäß der untenstehenden Abbildung auf L1 hochgeladen wurde, hat sich ihr Status auf 69 L1-Blockbestätigungen geändert, was bedeutet, dass sie auf L1 hochgeladen wurde und der Layer1-Block, der die Transaktionsdaten enthält, 69 Blöcke hinter sich hat.

Der L1-Block, der diese Transaktionsdaten enthält, hat bereits 69 nachfolgende Blöcke. Je mehr Blöcke folgen, desto sicherer ist es.

Oder für diese Transaktion, wie im untenstehenden Screenshot gezeigt, der L1-Block, der bereits 6174 Blöcke enthält, die ihm folgen, was bereits sehr sicher ist.

Aber tatsächlich, was hier besser gemacht werden kann, ist es, es in Kombination mit den Finalitätsinformationen von L1 zu präsentieren.

Dem Benutzer einfach mitzuteilen, wie viele L1-Blockbestätigungen es gibt, ist für den Benutzer nur begrenzt hilfreich, da der Benutzer verstehen und den Sicherheitsgrad berechnen muss, der durch eine solche Anzahl von Blockbestätigungen dargestellt wird. Da Layer1 (d. h. Ethereum) bereits einen Finalitätsmechanismus wie Casper FFG hat, kann der Explorer tatsächlich direkt anzeigen, ob der Layer1-Block in Layer1 finalisiert wurde. Der Explorer von Optimism hat derzeit eine solche Funktion implementiert.

Überprüfen des Transaktionsbelegstatus auf Optimismus

Transaktionen, die im Optimism Explorer angezeigt werden, können solche enthalten, die als Vorbestätigung markiert sind, was darauf hinweist, dass sie noch nicht auf Layer 1 (L1) veröffentlicht wurden. Wie unten dargestellt, ist die Transaktion mit der Blocknummer 111526300 als "Bestätigt durch Sequencer" markiert:

Transaktionen werden nur vom Sequenzer bestätigt, aber noch nicht auf L1 veröffentlicht

Der Explorer scheint derzeit keine klare Definition für "Bestätigt vom Sequenzer" zu haben, was darauf hindeutet, dass "Sequenzer-Bestätigungen den Bestätigungen von einigen Blöcken auf L1 entsprechen". Dies impliziert, dass "Bestätigt vom Sequenzer" bedeutet, dass die Transaktion auf L1 veröffentlicht wurde und mehrere Blöcke darauf folgen:

Allerdings werden neu auftretende Transaktionen auch als „Vom Sequencer bestätigt“ angezeigt, und selbst Transaktionen von vor vielen Tagen, die die Herausforderungsfrist bereits überschritten haben, bleiben im Status „Vom Sequencer bestätigt“.

Transaktionen von vor Tagen sind immer noch im Status “Bestätigt vom Sequencer

Lesehinweis: Diese Situation könnte auch darauf zurückzuführen sein, dass der Explorer an verschiedenen Stellen unterschiedliche Statusindikatoren anzeigt: „Bestätigt durch Sequenzer“ neben der Blocknummer informiert die Benutzer darüber, dass der Block vom Sequenzer bestätigt wurde. Um den Post-L1-Status zu überprüfen, müssen die Benutzer auf andere Informationen verweisen, wie z.B. auf die unten diskutierten „L1 State Batch“-Details.

Darüber hinaus enthält eine Transaktion, die auf L1 veröffentlicht wurde, wie im untenstehenden Screenshot gezeigt, zwei zusätzliche Informationen: "L1 State Batch Index" und "L1 State Root Submission Tx Hash." Diese Details geben an, in welchem State Batch die L2-Transaktion enthalten ist und über welche L1-Transaktion dieser State Batch auf L1 veröffentlicht wurde:

Durch Klicken auf den „Status Batch 3480“ wird sein Status als Abgeschlossen angezeigt, was dem Abgeschlossen-Status auf L1 (d. h. dem Ethereum-Hauptnetz) entspricht, der nach Ansammlung von Stimmen von Validatoren über zwei Epochen erreicht wird und einen hohen Sicherheitsstatus darstellt.

△ State Batch 3480 ist in L1-Block 18457449 enthalten, und Block 18457449 wurde finalisiert.

Quelle: https://etherscan.io/block/18457449

Wenn eine Charge veröffentlicht, aber noch nicht auf L1 finalisiert wurde, wird sie als Unfinalisiert angezeigt:

Staatlicher Batch 3494, obwohl er auf L1 gepostet wurde, ist in einem L1-Block enthalten, der nicht finalisiert wurde:

Im Vergleich zum Arbitrum Explorer bietet der Optimism Explorer detailliertere Informationen (State Batch) und verknüpft L1 Finalitätsinformationen direkt mit dem L2 Explorer, sodass Benutzer wissen können, ob ein L1-Block finalisiert wurde, anstatt ihre eigene Beurteilung auf der Anzahl der Blockbestätigungen für den Sicherheitslevel zu basieren.

StarkNet Transaktionseinnahmenstatus

Derzeit können Benutzer, wenn sie Transaktionen auf StarkNet senden, den Transaktionsbeleg schnell abfragen. Der Beleg zeigt jedoch oft den Transaktionsstatus als EMPFANGEN an. Dieser Status zeigt an, dass der Knoten die Transaktion empfangen und nach Überprüfung keine Probleme festgestellt hat. Die Transaktion wartet darauf, in einen L2-Block vom Sequenzer aufgenommen und ausgeführt zu werden. Transaktionen im Status EMPFANGEN haben noch keine Ergebnisse aus der Ausführung. Benutzer können den Fortschritt ihrer Transaktionen überprüfen, indem sie den Transaktionsstatus im StarkNet Explorer anzeigen.

Lesetipp: Wenn der Sequenzer Transaktionen schnell genug verarbeitet, kann er den Status EMPFANGEN umgehen und direkt in den verarbeiteten Zustand übergehen. Für eine ausführlichere Einführung in den Transaktionsprozess auf StarkNet können Sie den unten stehenden Link in Ihren Browser kopieren, um die offiziellen Dokumente zu konsultieren.

Offizielle Dokumente:StarkNet Transaktionslebenszyklus

Transaktionen, die auf Starkscan, einem StarkNet Explorer, gesehen werden, beinhalten auch Vorbestätigungstransaktionen. Wie in der folgenden Transaktion gezeigt, ist der aktuelle Status "Akzeptiert auf L2", was darauf hinweist, dass sie vom Sequenzer in einen L2-Block eingereiht wurde:

"Accepted on L2” bedeutet, dass es von der Sequenzer in einen L2-Block eingereiht wurde, aber noch nicht auf L1 hochgeladen wurde.

Die beiden Status vor „Akzeptiert auf L2“ sind Empfangen und Ausstehend, die „die Transaktion wurde empfangen und überprüft“ und „die Transaktion wird vom Sequencer verarbeitet“ darstellen. Nach Abschluss der Transaktionsverarbeitung wechselt sie in den Status „Akzeptiert auf L2“:

Die Transaktion wurde empfangen und überprüft.

Die Transaktion wird vom Sequenzer verarbeitet.

Sobald die Transaktionsdaten auf L1 hochgeladen wurden, wird der Status auf "Akzeptiert auf L1" geändert, wie in der folgenden Transaktion gezeigt:

Die Transaktionsdaten wurden auf Gate 1 hochgeladen.

Obwohl StarkNet-Transaktionen über einen umfangreicheren Satz von Statusmeldungen verfügen, um Benutzer über den Verarbeitungsfortschritt zu informieren, kann das Hochladen von Transaktionen auf L1 immer noch eine Wartezeit von mehreren Stunden erfordern (möglicherweise, weil das Generieren von Zero-Knowledge-Beweisen länger dauert). Während dieser Zeit verlassen sich Benutzer auf die Vorbestätigung des Sequenzers.

Darüber hinaus zeigt der Explorer nur „Akzeptiert auf L1“ für Transaktionen, die auf L1 hochgeladen wurden, ohne begleitende Informationen zur L1-Endgültigkeit oder Blockbestätigung anzuzeigen. Dies bedeutet, dass Benutzer selbst überprüfen müssen, ob der L1-Block genügend nachfolgende Blöcke hat oder finalisiert wurde.

Insgesamt müssen Benutzer aufgrund der Leistungsengpässe von StarkNet über einen längeren Zeitraum auf die Vorbestätigung vertrauen, und der Explorer unterstützt keine L1-Endgültigkeitsinformationen, was zu einer weniger zufriedenstellenden Benutzererfahrung bei der Bestätigung von Transaktionseinnahmen führt. Dies ist ein Bereich, in dem StarkNet in Zukunft verbessern muss.

zkSync Transaktionsumsatzstatus

Ähnlich wie StakrNet hat auch zkSync einen PENDING-Zustand, was bedeutet, dass der Knoten die Transaktion erhalten hat und es nach der Überprüfung der Transaktion keine Probleme gibt. Es wird darauf gewartet, dass es in den L2-Block vom Sequenzer aufgenommen und ausgeführt wird. Es wird jedoch keine Transaktion im PENDING-Zustand ausgeführt. das Ergebnis von.

Benutzer können den Verarbeitungsfortschritt ihrer Transaktionen über den Transaktionsstatus im zkSync Explorer nachverfolgen.

Lektüretipps: Wenn der Sequenzer schnell genug verarbeitet wird, ist es möglicherweise möglich, den PENDING-Zustand direkt zu überspringen und in den Zustand zu gelangen, in dem die Transaktion verarbeitet wurde.

Für eine detailliertere Einführung in den Transaktionsprozess von zkSync können Sie den unten stehenden Link kopieren und in Ihrem Browser anzeigen:https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Die auf dem zkSync Explorer angezeigten Transaktionen werden auch Vorbestätigungstransaktionen umfassen, wie z.B. die Transaktion im untenstehenden Screenshot. Sie können sehen, dass der Status derzeit zkSync Era Processed ist, was darauf hindeutet, dass sie in den L2-Block durch den Sequenzer eingereiht wurde.

Diese Transaktion wurde von Sequencer in den L2-Block eingereiht und wartet derzeit darauf, auf L1 (Ethereum Senden) hochgeladen zu werden.

Nachdem der Sequenzer den L2-Block abgeschlossen hat, durchläuft der Block und die darin enthaltenen Transaktionen die drei Phasen Committed, Proven und Executed, was jeweils bedeutet "der Block wurde auf L1 hochgeladen" und "die Gültigkeit des Blocks wurde nachgewiesen". Und "der L2-Status wird auf L1 aktualisiert, nachdem die Transaktion im Block ausgeführt wurde." Im Folgenden sind drei Blöcke und Transaktionen in verschiedenen Phasen zu sehen:

Charge 292700 wurde auf L1 hochgeladen und hat die Stufe der Verpflichtung erreicht. Quelle: https://explorer.zksync.io/batch/292700

Der aktuelle Status der Transaktionen im Batch 292700 hat sich von Ethereum-Sendung in Ethereum-Validierung geändert, was darauf hinweist, dass sie auf die Überprüfung durch den Nullwissenbeweis wartet, um ihre Gültigkeit zu überprüfen.

Wenn Sie den Pfeil über das Ethereum-Validierungssymbol bewegen, werden auch die verschiedenen Phasen angezeigt, und der Transaktionslink für die vorherige Phase (Senden) wird ebenfalls angehängt:

Diese Transaktion hat die „Validierung“-Phase erreicht. Der Transaktionslink zum Hochladen des Batches auf L1 in der vorherigen Phase (Senden) kann auch direkt hier eingesehen werden.

Die Wirksamkeit von Batch 292000 wurde nachgewiesen, daher tritt es in die Bewährungsphase ein:

Nachdem die Charge bewiesen ist, gelangt sie in den bewiesenen Zustand, und es wird ein Transaktionslink zum Ausführen der Beweisaktion angehängt.

Die Transaktionen im Inneren werden auch vom Stadium der „Validierung“ in das Stadium der „Ausführung“ übergehen, wo sie darauf warten, ausgeführt zu werden.

Wenn die Batch-Prozedur abgeschlossen ist, wird sie dann eine Wartezeit (offizielle Dokumente besagen, dass es ungefähr 21 Stunden sind) durchlaufen, bevor sie die Transaktionen im Inneren ausführt und den auf L1 aufgezeichneten L2-Status aktualisiert. Dies liegt hauptsächlich an einer Schutzmaßnahme, die sich noch im Alpha-Stadium befindet, um sicherzustellen, dass ausreichend Zeit zum Reagieren vorhanden ist, wenn Fehler auftreten. Wenn die Batch-Prozedur ausgeführt wird, wird sie in die abschließende Ausführungsphase eintreten:

Nachdem die Batch ausgeführt wurde, gelangt sie in den endgültigen Zustand 'Ausgeführt', und es wird ein Transaktionslink zur Ausführung der Aktion 'Ausführen' angehängt.

Der Transaktionsstatus im Batch wird ebenfalls auf "Ausgeführt" aktualisiert. Im Gegensatz zu StarkNet-Transaktionen, die von Layer 2 (L2) nach Layer 1 (L1) in einem Schritt abgeschlossen werden, zerlegt zkSync den Prozess von Transaktionen von L2 nach L1 in drei detailliertere Phasen: Bestätigt -> Bewiesen -> Ausgeführt. Obwohl dies den gesamten Transaktionsprozess als Schutzmaßnahme auf etwa einen Tag verlängert, ermöglicht der Bestätigungsstatus den Benutzern schnell zu erfahren, ob ihre Transaktion enthalten ist (sobald eine Transaktion die Bestätigungsphase erreicht, handelt es sich nicht mehr nur um Vorbestätigung), ohne kontinuierlich auf das Vertrauen in den Sequenzer angewiesen zu sein. Darüber hinaus bietet der zkSync Explorer umfassende und vollständige Datenanzeigen für verschiedene Phasen, die es jedem ermöglichen, den aktuellen Status von Transaktionen zu erfassen und sogar die Ausführung von Transaktionen bei jedem Phasenübergang persönlich zu überprüfen (z. B. von Bestätigt zu Bewiesen, von Bewiesen zu Ausgeführt). Es ist jedoch wichtig zu beachten, dass der zkSync Sequenzer als Schutzmaßnahme in der Alphaphase historische Aufzeichnungen ändern kann. Dies bedeutet, dass, obwohl Transaktionen schnell über Vorbestätigung hinausgehen und die Bestätigungsphase erreichen können, der Sequenzer Benutzertransaktionen aus den historischen Aufzeichnungen entfernen kann, bis sie die Ausgeführt-Phase erreichen. Benutzer müssen daher weiterhin bis zu einem Tag dem Sequenzer vertrauen.

Layer 1 kann auch Pre-Bestätigung unterstützen

Wenn im Voraus bekannt ist, wer für die Produktion von Blöcken zuständig ist, kann L1 auch die Vorbestätigung unterstützen. Nehmen wir Ethereum als Beispiel: Der eigentliche Blockproduzent ist der Builder, der Pre-Confirmation-Dienste anbieten kann, die den Benutzern eine Garantie für die Einbeziehung von Transaktionen geben. Da der Bauherr jedoch nicht unbedingt das Recht hat, einen bestimmten Block zu erstellen, sondern für das Recht zur Herstellung jedes Blocks bieten muss, kann die Wirksamkeit der Vorabbestätigung schwächer sein. Darüber hinaus muss die Wettbewerbsfähigkeit des Bauherrn berücksichtigt werden. Wenn ein Bauherr nicht wettbewerbsfähig genug ist, wird es für ihn schwierig sein, sich das Recht zur Herstellung von Blöcken zu sichern, wodurch die Zuverlässigkeit seiner Vorabbestätigungsdienste erheblich verringert wird. Um diese Probleme zu vermeiden, wäre es besser, den Antragstellern die Bereitstellung von Vorabbestätigungsdiensten zu ermöglichen, da es in der Regel vorbestimmt und sicher ist, welcher Antragsteller welchen Block vorschlagen wird. In der aktuellen PBS-Architektur schlagen die Vorschlagenden jedoch nur Blöcke vor, und die eigentliche Blockproduktion und die inhaltliche Entscheidungsfindung werden von den Entwicklern durchgeführt, so dass die Vorschlagenden eine Transaktion nicht direkt in einen Block einfügen oder einen Ersteller auffordern können, dies zu tun. Wenn sich in Zukunft die PBS-Architektur ändert, z. B. durch Hinzufügen einer Aufnahmeliste oder durch die Teilnahme von Antragstellern an der Blockproduktion, haben die Antragsteller möglicherweise die Möglichkeit, Vorbestätigungsdienste anzubieten. Weitere Informationen zu PBS finden Sie unter dem angegebenen Link.

Verbesserung der Vorbestätigung:

Pre-Bestätigung ist lediglich ein mündliches Engagement von Erbauern oder L2-Sequenzern, ohne Verpflichtung, das Versprechen einzuhalten und ohne Strafmechanismus bei Nichterfüllung. Es ist jedoch möglich, dieses Engagement mithilfe von Smart Contracts zuverlässiger zu gestalten, um Erbauer oder Sequenzer zu standardisieren. Sie könnten Pre-Bestätigungsdienste anbieten und gleichzeitig eine Kaution im Smart Contract hinterlegen und den Inhalt bei Abgabe eines Transaktionseinbeziehungversprechens unterzeichnen. Wenn Benutzer feststellen, dass Erbauer oder Sequenzer ihre Versprechen nicht eingehalten haben, können sie den Versprecheninhalt und die Signatur dem Smart Contract vorlegen, der dann überprüfen kann, ob das Versprechen eingehalten wurde. Obwohl das Anwendungsszenario des oben genannten Vertrags noch im Proof-of-Concept-Stadium ist, zeigt der folgende Link ein Präsentationsvideo eines solchen Vertragsanwendungsbeispiels.

Zusammenfassung:

Nachdem L1-Transaktionen in L1-Blöcken enthalten sind, sinkt die Wahrscheinlichkeit einer Reorganisation, und das Vertrauen der Benutzer in die Einbeziehung von Transaktionen nimmt allmählich zu. L2-Transaktionen haben im Vergleich zu L1-Transaktionen einen zusätzlichen Workflow: "L2-Transaktionen sind in L2-Blöcken enthalten und warten auf das Hochladen in L1." Da die Daten in dieser Phase jedoch noch nicht in L1 hochgeladen wurden, besteht immer noch die Möglichkeit einer Abweichung, so dass die Zusicherung, die Benutzer in Bezug auf die Einbeziehung von Transaktionen in dieser Phase erhalten können, die mündliche Zusage des Sequencers ist, die als Vorbestätigung oder schnelle Bestätigung/weiche Bestätigung bezeichnet wird. Wenn der Sequencer bösartig ist oder einfach nur auf einen Fehler stößt, kann sein Versprechen gebrochen werden, was zu einer fehlenden Bestätigung für die L2-Transaktion des Benutzers führt. Derzeit zeigen die meisten L2s in ihren Explorern Transaktionsstatus an, die den Status "Pre-Confirmation" enthalten, wie z. B. "Arbitrum/Optimism" von "Confirmed by Sequencer" oder "Akzeptiert auf L2" von StarkNet. Wenn Sie solche Informationen sehen, ist es wichtig, auf die Zeiteffektivität der bereitgestellten Transaktionsinklusionsgarantie zu achten. Wenn Benutzer sich nicht auf die Vorabbestätigung des Sequencers verlassen möchten, müssen sie länger warten und die Informationen des L2-Explorers überprüfen, ob L2-Daten in L1 hochgeladen werden. Pre-Confirmation kann einen wirtschaftlichen Anreizmechanismus beinhalten, wie z. B. die Bestrafung von Sequencern durch Smart Contracts, wenn sie ihre Versprechen brechen, und den Nutzern einen klareren Schutz bieten. Die folgende Tabelle zeigt die Garantien für die Einbeziehung von Transaktionen und die entsprechenden Risikoszenarien, die von L1- und L2-Transaktionen in verschiedenen Phasen des Transaktionsprozesses bereitgestellt werden.

Haftungsausschluss：

1. Dieser Artikel wurde von [ wiedergegebenaicoin]. Alle Urheberrechte gehören dem Originalautor [.Foresight News]. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte den Gate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel geäußert werden, 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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.