*Den Originaltitel weiterleiten:Erkundung der kanonischen Ethereum-Bridge und des Beweissystems von Eclipse

Unsere Canonical Bridge im Überblick

Eclipse besteht aus drei Schichten:

1. Ausführung: Ein Fork des Solana Labs-Clients (v1.17) für die Ausführung von SVM-Transaktionen
2. Abwicklung: Unsere kanonische Brücke, die die Fork-Choice-Regel von Eclipse definiert, existiert auf Ethereum, wo auch Betrugsnachweise eingereicht werden
3. Datenverfügbarkeit: Eclipse veröffentlicht die Daten, die für die Erstellung von Betrugsbeweisen erforderlich sind, als Datenblobs auf Celestia

Das folgende Diagramm veranschaulicht, wie diese Module interagieren:

Der Rest dieses Artikels konzentriert sich auf die Ethereum-Bridge von Eclipse, wie im Diagramm gezeigt. Blobstream wird Bescheinigungen weiterleiten, die von Celestias Validator signiert wurden, um Ethereum zu bescheinigen, dass die Daten für eine Charge von Eclipse-Slots korrekt veröffentlicht wurden. Auf diese Weise kann die Bridge von Eclipse die für Betrugsbeweise bereitgestellten Daten mit den signierten Datenstämmen von Celestia abgleichen. Im weiteren Verlauf dieses Abschnitts werden wir die Prozesse skizzieren, durch die:

1. Gelder werden über unsere Brücke eingezahlt,
2. Daten-Blobs von Batches von Eclipse-Blöcken werden auf Celestia gepostet,
3. Abhebungen über die Bridge abgewickelt werden und
4. Betrugsnachweise werden in Worst-Case-Szenarien generiert.

Einzahlung über die native Ethereum Bridge von Eclipse

Der Ablauf, wenn ein Benutzer über die native Ethereum-Bridge auf Eclipse einzahlt, wird wie folgt zusammengefasst:

1. Ein Benutzer ruft den Deposit-Bridge-Vertrag von Eclipse auf Ethereum auf
2. Innerhalb des SVM-Executors von Eclipse [1] beobachtet der Relayer [2] die Hinterlegungs- und Zieladresse des Benutzers
3. Als nächstes ruft der Relayer das SVM-Bridge-Programm auf, das für die Überweisung der Einzahlung eines Benutzers an die entsprechende Zieladresse verantwortlich ist
4. Der relayer verifiziert die Einzahlungstransaktion über einen zk-light-Client (noch zu implementieren)
5. Schließlich wird der Block, der die anschließende Überweisungstransaktion nach der Einzahlung enthält, fertiggestellt und über ein Solana Geyser Pluginveröffentlicht

Das folgende Diagramm zeigt die Interaktionen zwischen Ethereum, Celestia und dem SVM Executor während des oben beschriebenen Einzahlungsflusses:

Veröffentlichung der Eclipse-Slots auf Celestia als Daten-Blobs

Der Ablauf für die Veröffentlichung von Batches von Eclipse-Slots in Celestia als Daten-Blobs ist unten zusammengefasst:

1. Der SVM-Executor veröffentlicht jeden Eclipse-Slot über Geyser in der Nachrichtenwarteschlange
2. Der SVM-Executor sendet Batches der Eclipse-Slots als Daten-Blobsan Celestia
3. Das Celestia-Validierungsset erzeugt Commits für die übermittelten Datenblobs, die verwendet werden können, um die Aufnahme einer Transaktion in die Eclipse-Kette gegen den Datenstamm zu beweisen
4. Die Datenwurzeln, die in jedem einzelnen Celestia-Block-Header enthalten sind, werden über Blobstream an den Bridge-Vertrag von Eclipse auf Ethereum weitergeleitet

Das folgende Diagramm von Celestia erklärt, wie die Zuschreibung der Daten innerhalb eines bestimmten Celestia-Blocks im Block-Header gespeichert wird:

Abheben und Einreichen von Betrugsnachweisen an die Ethereum Bridge von Eclipse

Ähnlich wie bei anderen L2s, die Betrugsnachweise verwenden (Arbitrum, Fuel und viele andere), erfordern Auszahlungen von Eclipse eine Anfechtungsphase, in der Verifizierer Betrugsnachweise im Falle eines ungültigen Zustandsübergangs einreichen können:

1. In regelmäßigen Abständen gibt der SVM-Executor eine Verpflichtung zu einer Epoche (eine vorbestimmte Anzahl von Batches) der Eclipse-Slots an Ethereum ab, zusammen mit Sicherheiten
2. Der Bridge-Vertrag von Eclipse führt einige grundlegende Überprüfungen durch, um sicherzustellen, dass die veröffentlichten Daten wohlgeformt sind (beschrieben im Abschnitt Fraud Proof Design)
3. Wenn die eingereichte Charge diese grundlegenden Prüfungen besteht, gibt es ein vordefiniertes Zeitfenster, in dem die Prüfer Betrugsnachweise veröffentlichen können, falls die Chargenverpflichtung einen ungültigen Zustandsübergang impliziert
4. Wenn ein Verifier einen erfolgreichen Betrugsnachweis veröffentlicht, erhält er die Sicherheiten des Testamentsvollstreckers, der gebuchte Batch wird abgelehnt und der kanonische Status von Eclipse L2 wird auf die letzte gültige Batch-Verpflichtung zurückgesetzt. Hier hätte die Governance von Eclipse die Möglichkeit, einen neuen Testamentsvollstrecker zu wählen
5. Wenn die Anfechtungsfrist ohne erfolgreichen Betrugsnachweis verstrichen ist, erhält der Testamentsvollstrecker seine Sicherheiten zusammen mit einer Belohnung zurück
6. Folglich schließt der Eclipse-Bridge-Vertrag nun alle Auszahlungstransaktionen ab, die im finalisierten Batch enthalten waren

Betrugssicheres Design

In diesem letzten Abschnitt werden wir das Design des betrugssicheren Systems von Eclipse detailliert beschreiben, das von Anatoly Yakovenko und John Adler inspiriert wurde. Im Allgemeinen muss eine Prüfstelle für jeden Betrugsnachweis:

1. Identifizieren einer Transaktion mit einem ungültigen Zustandsübergang
2. Geben Sie die Eingaben für die Transaktion mit dem ungültigen Zustandsübergang an.
3. Demonstrieren Sie, dass die erneute Ausführung der Transaktion mit den angegebenen Eingaben zu einer Ausgabe führt, die nicht dem entspricht, was auf der Kette festgeschrieben wurde

Im Fall von Eclipse (1) mergelt Celestia Blobs von Stapeln von Blöcken, die der SVM-Executor von Eclipse veröffentlicht, und ermöglicht so den Nachweis der Transaktionseinbindung über Merkle-Zeugen. Für (2) gilt: Im Gegensatz zu EVM-basierten L2s, die eine Merkle-Wurzel an den globalen Zustandsbaum senden, aktualisiert Eclipse aus Performance-Gründen einen globalen Zustandsbaum nicht auf Transaktionsbasis, aber wir werden im Folgenden genauer erklären, wie wir die Korrektheit der Eingaben sicherstellen. Schließlich generiert der Verifier von Eclipse im Fall von (3) einen zk-Beweis der Ausgabe(n) für eine bestimmte Transaktion, im Gegensatz zu dem interaktiven Verifikationsspielansatz , der bei EVM-basierten L2s üblich ist.

Alle Eclipse-Transaktionen können so dargestellt werden, dass sie eine Liste von Eingabekonten erstellen, eine Transaktion ausführen und eine Liste der resultierenden Ausgabekonten erstellen:

Die entscheidende Beobachtung für unser betrugssicheres Design ist, dass es für die Ausführung von Transaktionen immer der Fall ist, dass jeder S_InputAccount der S_OutputAccount einer früheren Transaktion gewesen sein muss. Auf diese Weise können wir auf die letzte Transaktion in der Kette verweisen, die ein bestimmtes Eingabekonto erzeugt hat, anstatt einen Merkle-Zeugen für einen globalen Zustandsbaum bereitzustellen. Als Ergebnis unseres Designs führen wir zusätzliche Arten von Betrugsvorwürfen ein, wie z. B. einen Verweis darauf, dass die vorherige Transaktion ungültig ist oder das Eingabekonto bereits durch eine spätere Transaktion "ausgegeben" wurde. Im Folgenden beschreiben wir diesen Prozess genauer:

An Celestia gebuchte Transaktionseingaben

1. Bewegungsdaten (vom Sequencer gebucht)
2. Transaktionsdaten (gebucht vom SVM-Executor), die Folgendes enthalten:
   1. Anzahl der Transaktionen [3]
   2. Celestia-Namespace-Speicherort der Transaktionsdaten
   3. Konto-Hash [4] für jede Eingabe, wobei die Anzahl der Transaktionen zu jedem
   4. Liste der verwendeten Sysvars und deren Wert, wobei die Anzahl der Transaktionen zu jedem Ergebnis führt (falls zutreffend) [5]
   5. Transaktionsausgabe, wenn die Transaktion erfolgreich war; Andernfalls ein Indikator, dass die Transaktion fehlgeschlagen ist (entweder weil sie nicht analysiert werden konnte oder weil sie nicht ausgeführt werden konnte)

Batch-Verpflichtungen, die auf der Ethereum Bridge veröffentlicht wurden

Darüber hinaus werden die Verpflichtungen der an Celestia gesendeten Transaktionsdaten an den Ethereum-Vertrag weitergeleitet. Die Verpflichtungen bestehen aus:

1. Der Celestia-Namespace-Speicherort der Transaktionsdaten der letzten Transaktion, die im Batch enthalten ist
2. Der Celestia-Namensraum, an dem sich die Ausführungsdaten [6] aller eingeschlossenen Transaktionen befinden
3. Eine Liste von Einzahlungen, Abhebungen und Außerkraftsetzungen, die jeweils mit der Transaktionsanzahl der zugehörigen Eclipse-Transaktion geliefert werden

Kriterien für einen ungültigen Stapel

Wie oben erläutert, gibt es mehrere Möglichkeiten, wie ein Stapel als falsch eingestuft werden kann:

1. Einer der verknüpften Celestia-Namespace-Speicherorte ist falsch formatiert oder verweist nicht auf Daten des erforderlichen Typs
2. Es gibt eine Transaktion auf Celestia ohne zugeordnete Ausführungsdaten, was zwei Gründe haben kann:
   1. Der Transaktion, bei der es sich um die neueste im Batch handeln sollte, sind keine Ausführungsdaten zugeordnet.
      1. In einem solchen Fall überprüft ein Verifizierer, ob dies der Fall ist, und der Ethereum-Bridge-Vertrag prüft, ob der letzte Eintrag in der Ausführungsdatenliste nicht den korrekten Transaktionsdaten entspricht
   2. Die Ausführungsdaten einer anderen Transaktion fehlen
      1. Ein Verifizierer veröffentlicht den Celestia-Namespace-Speicherort der Transaktionsdaten der fehlerhaften Transaktion und der vorherigen und folgenden Transaktionen in der Reihenfolge, die erfolgreich ausgeführt wurde. Anschließend prüft der Bridge-Vertrag, ob diese Transaktion übersprungen wurde
3. Es gibt eine Transaktion, deren Ausführungsdaten falsch sind, was folgende Ursachen haben kann:
   1. Die Transaktionsanzahl, die einem Kontohash oder sysvar zugeordnet ist, erzeugt nicht die beanspruchte Ausgabe.
      1. In diesem Fall postet ein Verifizierer den Celestia-Namespace-Speicherort der Ausführungsdaten für die angegebene Transaktion mit der entsprechenden Anzahl, und der Bridge-Vertrag prüft, ob der angegebene Wert falsch ist.
   2. Die Anzahl der Transaktionen, die einem Kontohash oder einer Sysvar zugeordnet sind, ist veraltet
      1. Ein Verifizierer postet den Celestia-Namespace-Speicherort der Ausführungsdaten für eine neuere Transaktion und ändert den fraglichen Wert, und der Bridge-Vertrag prüft, ob dieser tatsächlich neuer ist.
   3. Die Transaktionsausgabe ist falsch, oder die Transaktion verwendet eine Eingabe, die nicht aufgeführt ist:
      1. In diesem Fall wird ein zk-Beweis für die korrekte Ausführung der Transaktion oder ein zk-Beweis benötigt, dass die Transaktion eine Eingabe verwendet, die nicht aufgeführt ist. Dies kann auf zwei Arten erreicht werden:
         1. eine Prüfstelle den Beweis veröffentlicht, oder
         2. Ein Verifizierer veröffentlicht den Index der Transaktion, von der behauptet wird, dass sie betrügerisch ist, und der Eclipse-Bridge-Vertrag verwendet diesen, um einen zk-Beweis von RISC Zeros Bonsaianzufordern
   4. Vor mehr als N Batches gab es eine Einzahlung von Ethereum, aber es gibt keine entsprechende Einzahlung in der Transaktionsliste (enthalten in der Batch-Verpflichtung, die im Bridge-Vertrag verbucht wurde) für die N vergangenen Batches. Alternativ gibt es eine Einzahlung in der Transaktionsliste ohne zugehörige Ethereum-Einzahlungstransaktion, oder die Transaktion existiert, wurde aber bereits in einem anderen Eclipse-Batch enthalten
      1. Der Brückenvertrag kann in all diesen Fällen feststellen, dass dies geschehen ist, und eine solche Charge als ungültig betrachten
   5. Es wird eine Ein- oder Auszahlung ohne entsprechenden Eintrag in der Transaktionsliste ausgeführt
      1. In einem solchen Fall postet ein Verifizierer den Celestia-Namespace-Speicherort der angegebenen Ausführungsdaten, und der Bridge-Vertrag überprüft diese Tatsache, um die Transaktion als ungültig zu beurteilen
   6. Es gibt eine Ein- oder Auszahlung in der Transaktionsliste, deren zugeordnete Eclipse-Transaktion nicht die erwartete Aktion ausführt oder deren Transaktionsanzahl nicht innerhalb des erwarteten Transaktionsanzahlbereichs liegt. In einem solchen Fall würde eine der folgenden Situationen eintreten:
      1. Die Brücke würde automatisch feststellen, dass dies der Fall ist, und die entsprechende Charge ablehnen
      2. Ein Verifizierer bemerkt den ungültigen Zustandsübergang und stellt einen Nachweis für die fehlerhafte Transaktion bereit, der dann durch den Brückenvertrag verifiziert wird

Wenn sich herausstellt, dass ein Commitment-Batch falsch ist, setzt der Eclipse-Bridge-Vertrag die Bridge auf den des letzten nachweislich korrekten Batch-Commitments zurück. Beachten Sie, dass Transaktionen niemals aus der Kette entfernt werden, auch nicht im Falle von Betrug, sodass nur die Verpflichtung neu berechnet werden muss.

Abschiedsgedanken

Dieser Artikel zielte darauf ab, einen allgemeinen Leitfaden für die vertrauensminimierte Bridge von Eclipse auf Ethereum zu geben und einige Details zu unserem betrugssicheren Design zu erläutern. Angesichts des modularen Charakters unseres L2 und der Entstehung unseres Technologie-Stacks werden wir in den kommenden Wochen weiterhin Artikel und Dokumentationen zu verschiedenen Aspekten von Eclipse veröffentlichen.

Um sich am Eclipse Testnet zu beteiligen, folgen Sie bitte unseren Anweisungen hier. Sie können uns auf Twitter oder Discord kontaktieren, wenn Sie spezifische Fragen zu unserem Testnet, Bridge oder technischen Fragen haben.

Fußnoten

[1]: Der Knoten, der die Ergebnisse von SVM-Transaktionen berechnet und die letztendliche Ausgabe auf den neuen Zustand von Eclipse anwendet

[2]: Ein Operator, der On-Chain-Ereignisse zwischen Ethereum und Eclipse übergibt

[3]: Beachten Sie, dass der Executor, nicht der Sequenzer, dies postet. Wenn es in den vom Sequenzer gesendeten Daten enthalten wäre, würde es die Komplikation hinzufügen, dass der Sequenzer eine Zählung überspringen könnte, was es dem Executor unmöglich machen würde, seine Arbeit korrekt auszuführen. Dies könnte durch das betrugssichere Design kompensiert werden, würde aber die Komplexität erhöhen. Ein zweiter Vorteil, wenn nur der Testamentsvollstrecker die Zählung postet, besteht darin, dass es einfach ist, Transaktionsüberschreibungen an Celestia zu senden, falls gewünscht.

[4]: SVM-Konten können mit einem eindeutigen Hash dargestellt werden. Die einzige Möglichkeit, diesen Hash zu ändern, ist über eine Transaktion.

[5]: Um dies ohne übermäßiges Hashing zu tun, führen wir für jedes ausgeführte Programm einen Trace durch, um zu sehen, auf welche Teile jedes verwendeten Sysvars tatsächlich zugegriffen wird. Dies ist möglich, erfordert jedoch eine Modifikation des BPF-Interpreters von Solana.

[6]: Dazu gehören Daten für versuchte Transaktionen, die nicht ausgeführt werden konnten.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [[mirror], Alle Urheberrechte liegen beim ursprünglichen Autor [Eclipse]. 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.