Zum Hauptinhalt springen

Optimism-Architektur

· 5 Minuten Lesezeit
Tian Pan
Tian Pan
Community Hacker

Optimism ist ein EVM-äquivalentes, Optimistic-Rollup-Protokoll, das zur Skalierung von Ethereum entwickelt wurde. Die Skalierung von Ethereum bedeutet, die Anzahl der nützlichen Transaktionen zu erhöhen, die das Ethereum-Netzwerk verarbeiten kann. Optimistic Rollup ist eine Skalierungstechnik der Schicht 2 (Layer 2), die die Rechen- und Speicherkapazität von Ethereum erhöht, ohne dabei Sicherheit oder Dezentralisierung zu opfern. EVM-Äquivalenz bedeutet die vollständige Einhaltung der im Ethereum Yellow Paper beschriebenen Zustandsübergangsfunktion, der formalen Definition des Protokolls.

Optimistic Rollup funktioniert, indem mehrere Transaktionen zu einer einzigen Transaktion gebündelt werden, die dann von einem Smart Contract im Ethereum-Netzwerk verifiziert wird. Dieser Prozess wird als „Rolling Up“ bezeichnet, da die einzelnen Transaktionen zu einer größeren Transaktion zusammengefasst werden, die an das Ethereum-Netzwerk übermittelt wird. Der Begriff „optimistisch“ bezieht sich darauf, dass das System davon ausgeht, dass Transaktionen gültig sind, sofern nicht das Gegenteil bewiesen wird, was eine schnellere und effizientere Verarbeitung von Transaktionen ermöglicht.

Gesamtarchitektur​

Optimism-Architektur

op-node + op-geth​

Der Rollup-Knoten kann entweder im Validator- oder im Sequencer-Modus ausgeführt werden:

  1. Validator (auch Verifier genannt): Ähnlich wie beim Betrieb eines Ethereum-Knotens simuliert er L2-Transaktionen lokal, ohne Ratenbegrenzung. Er ermöglicht es dem Validator auch, die Arbeit des Sequencers zu überprüfen, indem er Output Roots neu ableitet und sie mit denen vergleicht, die vom Sequencer übermittelt wurden. Im Falle einer Diskrepanz kann der Validator einen Fault Proof durchführen.
  2. Sequencer: Der Sequencer ist ein privilegierter Akteur, der L2-Transaktionen von L2-Benutzern empfängt, entsprechende L2-Blöcke erstellt und diese dann an einen Data Availability Provider (über einen Batcher) übermittelt. Er übermittelt auch Output Roots an L1. Derzeit gibt es nur einen Sequencer im gesamten Stack, und hier kritisieren die Leute, dass der OP-Stack nicht dezentralisiert ist.

op-batcher​

Der Batch-Submitter, auch als Batcher bezeichnet, ist die Entität, die die L2-Sequencer-Daten an L1 übermittelt, um sie für Verifier verfügbar zu machen.

op-proposer​

Der Proposer generiert und übermittelt L2-Output-Checkpoints an den L2-Output-Oracle-Vertrag auf Ethereum. Nachdem die Finalisierungsperiode abgelaufen ist, ermöglichen diese Daten Abhebungen.

Sowohl Batcher als auch Proposer übermitteln Zustände an L1. Warum sind sie getrennt?

Der Batcher sammelt und übermittelt Transaktionsdaten in L1 in einem Batch, während der Proposer die Commitments (Output Roots) an den Zustand von L2 übermittelt, was die Ansicht der L2-Kontozustände finalisiert. Sie sind entkoppelt, damit sie parallel für mehr Effizienz arbeiten können.

contracts-bedrock​

Verschiedene Verträge für die Interaktion von L2 mit L1:

  • OptimismPortal: Ein Feed von L2-Transaktionen, die als Smart-Contract-Aufrufe im L1-Zustand entstanden sind.
  • Batch-Inbox: Eine L1-Adresse, an die der Batch-Submitter Transaktions-Batches übermittelt.
  • L2-Output-Oracle: Ein Smart Contract, der L2 Output Roots für Abhebungen und Fault Proofs speichert.

Optimism-Komponenten

Wie man einzahlt?​

Wie man abhebt?​

Feedback zur Optimism-Dokumentation​

Das Verständnis des OP-Stacks kann aufgrund einer Reihe von Faktoren herausfordernd sein. Ein solcher Faktor sind die zahlreichen Komponenten, die in Code und Dokumentation mehrfach mit leicht unterschiedlichen Namen bezeichnet werden. Zum Beispiel können die Begriffe „op-batcher“ und „batch-submitter“ / „verifiers“ und „validators“ austauschbar verwendet werden, was zu Verwirrung und Schwierigkeiten beim Verständnis der genauen Funktion jeder Komponente führt.

Eine weitere Herausforderung beim Verständnis des OP-Stacks ist die sich entwickelnde Architektur, die dazu führen kann, dass einige Designelemente im Laufe der Zeit veraltet sind. Leider wird die Dokumentation möglicherweise nicht immer aktualisiert, um diese Änderungen widerzuspiegeln. Dies kann zu weiterer Verwirrung und Schwierigkeiten beim Verständnis des Systems führen, da Benutzer möglicherweise mit veralteten oder ungenauen Informationen arbeiten.

Um diese Herausforderungen zu überwinden, ist es wichtig, alle verfügbaren Dokumentationen sorgfältig zu prüfen, Konzepte an allen Stellen konsistent zu halten und über alle Änderungen oder Aktualisierungen des OP-Stacks auf dem Laufenden zu bleiben. Dies kann zusätzliche Forschung und Zusammenarbeit mit anderen Benutzern oder Entwicklern erfordern, ist aber unerlässlich, um dieses komplexe System vollständig zu verstehen und effektiv zu nutzen.

Share on Twitter