Ein Artikel, der erklärt, wie Ethereum Reth 1 GB Gas pro Sekunde erreicht

Wie erreicht Ethereum Reth 1 GB Gas pro Sekunde? Wir haben 2022 mit dem Aufbau von Reth begonnen, um Ethereum L1 Elastizität zu verleihen und gleichzeitig das Skalierungsproblem der Ausführungsschicht auf L2 zu lösen. Heute freuen wir uns, Ihnen mitzuteilen, wie Reth plant, im Jahr 2024 einen L2-Durchsatz von 1 GB Gas pro Sekunde zu erreichen, und unseren langfristigen Fahrplan, wie dieses Ziel übertroffen werden kann. Wir laden das gesamte Ökosystem ein, sich uns anzuschließen, um die Leistungsgrenze und das strenge Benchmarking im Kryptobereich zu erweitern. Heute gibt Ihnen der Herausgeber dieser Website eine detaillierte Einführung, wie Reth 1 GB Gas pro Sekunde erreicht. Freunde, die Ethereum Reth mögen, sollten es sich nicht entgehen lassen!

Wir legen Wert auf Gas pro Sekunde und verwenden es, um die EVM-Netzwerkleistung umfassend zu bewerten und gleichzeitig die Rechen- und Speicherkosten zu erfassen. Netzwerke wie Solana, Sui oder Aptos sind aufgrund ihrer einzigartigen Kostenmodelle nicht enthalten. Wir unterstützen Bemühungen, die Kostenmodelle in allen Blockchain-Netzwerken zu harmonisieren, um umfassende und faire Vergleiche zu ermöglichen.

Wir entwickeln eine Reihe von Non-Stop-Benchmarking-Tools für Reth, um reale Arbeitslasten nachzubilden. Unsere Anforderung an Knoten ist die Einhaltung des TPC-Benchmarks.

2. Wie erreicht Reth 1GB Gas pro Sekunde? Oder noch höher?

Ein Teil unserer Motivation für die Gründung von Reth im Jahr 2022 war, dass wir dringend einen Client brauchten, der speziell für Web-Rollups entwickelt wurde. Wir glauben, dass unser Weg nach vorne vielversprechend ist.

Reth ​​​​erreicht während der Live-Synchronisierung bereits 100–200 MB Gas pro Sekunde (einschließlich Absenderwiederherstellung, Ausführung von Transaktionen und Berechnung von Versuchen für jeden Block). Um unser kurzfristiges Ziel von 1 GB Gas pro Sekunde zu erreichen, müssen wir also skalieren weitere 10 Mal.

Da Reth wächst, müssen unsere Expansionspläne ein Gleichgewicht zwischen Skalierbarkeit und Effizienz finden:

• Vertikale Expansion: Unser Ziel ist es, die Nutzung jeder „Box“ optimal zu nutzen. Durch die Optimierung der Art und Weise, wie jedes einzelne System Transaktionen und Daten verarbeitet, können wir die Gesamtleistung erheblich verbessern und gleichzeitig die Effizienz einzelner Knotenbetreiber steigern.

• Horizontale Skalierung: Trotz Optimierungen übersteigt das reine Transaktionsvolumen im Web-Maßstab die Verarbeitungskapazität eines einzelnen Servers. Um mit dieser Situation umzugehen, haben wir über den Einsatz einer horizontalen Skalierungsarchitektur nachgedacht, die dem Kubernetes-Modell der Blockchain-Knoten ähnelt. Das bedeutet, die Arbeitslast auf mehrere Systeme zu verteilen, um sicherzustellen, dass kein einzelner Knoten zum Engpass werden kann.

Die Optimierung, die wir hier besprechen, wird keine staatlichen Wachstumslösungen beinhalten, diesen Teil werden wir separat in anderen Artikeln besprechen. Hier ist ein Überblick über unsere Pläne, dies zu erreichen:

Im gesamten Technologie-Stack haben wir außerdem E/A und CPU mithilfe des Akteurmodells optimiert, sodass jeder Teil des Stacks als Dienst und feinkörnig bereitgestellt werden kann Kontrolle über seine Verwendung. Schließlich evaluieren wir aktiv alternative Datenbanken, haben jedoch noch keine endgültige Version erstellt.

Vertikale Skalierungs-Roadmap für 2.1 Reth

Unser Ziel für die vertikale Skalierung ist die Maximierung der Leistung und Effizienz des Servers oder Laptops, auf dem Reth ausgeführt wird.

(1) Even (Just-In-Time) EVM und Ahead-of-Time (Ahead-of-Time) EVM

In einer Blockchain-Umgebung wie der Ethereum Virtual Machine (EVM) erfolgt die Ausführung von Bytecode durch Interpretation Dolmetscher (Dolmetscher), der Dolmetscher verarbeitet Anweisungen der Reihe nach. Diese Methode bringt einen gewissen Mehraufwand mit sich, da die nativen Assembleranweisungen nicht direkt ausgeführt werden, sondern der Vorgang über die VM-Ebene ausgeführt wird.

Just-in-Time (JIT)-Kompilierung löst dieses Problem, indem Bytecode vor der Ausführung in nativen Maschinencode konvertiert wird, wodurch die Leistung verbessert wird, indem der Interpretationsprozess der VM umgangen wird. Diese Technologie kann Verträge im Voraus in optimierten Maschinencode kompilieren und wurde bereits in anderen virtuellen Maschinen wie Java und WebAssembly gut eingesetzt.

JIT kann jedoch anfällig für bösartigen Code sein, der Schwachstellen im JIT-Prozess ausnutzt, oder zu langsam sein, um während der Ausführung in Echtzeit ausgeführt zu werden. Reth kompiliert die anspruchsvollsten Verträge im Voraus (AOT) und speichert sie auf der Festplatte. So wird verhindert, dass nicht vertrauenswürdiger Bytecode versucht, unseren nativen Code-Kompilierungsprozess während der Live-Ausführung zu missbrauchen.

Wir haben einen JIT/AOT-Compiler für Revm entwickelt und integrieren ihn derzeit in Reth. Wir werden es als Open Source veröffentlichen, sobald wir die Benchmarks in den kommenden Wochen abgeschlossen haben. Im Durchschnitt werden etwa 50 % der Ausführungszeit im EVM-Interpreter verbracht, sodass eine etwa zweifache Verbesserung der EVM-Ausführung erforderlich sein sollte. In einigen Fällen kann die Auswirkung jedoch bei höherem Rechenaufwand größer sein. In den nächsten Wochen werden wir unsere Benchmarks teilen und unser eigenes JIT EVM in Reth integrieren.

(2) Parallel EVM

Das Konzept der Parallel Ethereum Virtual Machine (Parallel EVM) unterstützt die gleichzeitige Verarbeitung mehrerer Transaktionen, was sich vom herkömmlichen seriellen EVM-Ausführungsmodell unterscheidet. Wir haben folgende zwei Wege:

• Historische Synchronisierung: Die historische Synchronisierung ermöglicht es uns, den bestmöglichen parallelen Zeitplan zu berechnen, indem wir historische Transaktionen analysieren und alle historischen Zustandskonflikte identifizieren.

• Echtzeitsynchronisierung: Für die Echtzeitsynchronisierung können wir Technologien wie Block STM verwenden, um eine spekulative Ausführung ohne zusätzliche Informationen (z. B. Zugriffslisten) durchzuführen. Die Leistung des Algorithmus ist in Zeiten starker Zustandskonflikte schlecht. Daher möchten wir den Wechsel zwischen serieller und paralleler Ausführung basierend auf den Arbeitslastbedingungen untersuchen und statisch vorhersagen, auf welche Speichersteckplätze zugegriffen wird, um die Qualität der Parallelität zu verbessern.

Laut unserer historischen Analyse sind etwa 80 % der Ethereum-Speicherplätze unabhängig voneinander zugänglich, was bedeutet, dass Parallelität die EVM-Ausführungseffizienz um das Fünffache steigern kann.

(3) Optimierung des State Commitment

Im Reth-Modell ist die Berechnung der State Root ein von der Ausführung von Transaktionen unabhängiger Prozess, der die Verwendung von Standard-KV-Speicher ohne den Erhalt von Trie-Informationen ermöglicht. Derzeit dauert die Versiegelung eines Blocks >75 % der End-to-End-Zeit, was einen sehr spannenden Optimierungsbereich darstellt.

Wir haben die folgenden zwei „einfachen Erfolge“ identifiziert, um die Leistung des Statusstamms ohne Protokolländerungen um das Zwei- bis Dreifache zu verbessern:

• Statusstamm vollständig parallelisieren: Jetzt parallelisieren wir ihn einfach neu. Berechnen Sie den Speicherbaum für geänderte Konten, aber Wir können noch einen Schritt weiter gehen und den Kontobaum parallel berechnen, während der Speicher-Root-Job im Hintergrund ausgeführt wird.

• Pipelined State Root: Während der Ausführung werden Zwischen-Trie-Knoten vorab von der Festplatte abgerufen, indem der State Root-Dienst über die beteiligten Speicherplätze und Konten informiert wird.

Darüber hinaus können wir auch einige Wege nach vorne erkunden, indem wir von der Ethereum L1-Zustandswurzelaktivität abweichen:

• Häufigere Zustandswurzelberechnung: Die Zustandswurzel wird nicht für jeden Block berechnet, sondern für alle T-Blöcke einmal berechnet. Dies reduziert den gesamten Zeitaufwand für Investitionen in die staatliche Wurzel des gesamten Systems, was wahrscheinlich die einfachste und effektivste Lösung ist.

• Verfolgen Sie die Zustandswurzel: Anstatt die Zustandswurzel auf demselben Block zu berechnen, lassen Sie sie ein paar Blöcke dahinter liegen. Dadurch kann die Ausführung fortgesetzt werden, ohne dass die Berechnung des Zustandsstamms blockiert wird.

• Ersetzen Sie den RLP-Encoder und Keccak256: Es kann günstiger sein, Bytes direkt zusammenzuführen und eine schnellere Hash-Funktion wie Blake3 zu verwenden, als die RLP-Codierung zu verwenden.

• Weiterer Versuch: Erhöhen Sie die N-Arität der untergeordneten Knoten des Baums, um den IO-Anstieg aufgrund der logN-Tiefe des Versuchs zu reduzieren.

Ein paar Fragen hier:

• Welche sekundären Auswirkungen haben die oben genannten Änderungen auf Light Clients, L2, Bridges, Coprozessoren und andere Protokolle, die auf häufige Konten und Speichernachweise angewiesen sind?

• Können wir staatliche Verpflichtungen für SNARK-Proofs und die native Ausführungsgeschwindigkeit gleichzeitig optimieren?

• Was ist das umfassendste staatliche Engagement, das wir mit unseren vorhandenen Instrumenten erreichen können? Was sind die sekundären Auswirkungen auf die Zeugengröße?

Scale-out-Roadmap für Reth 2.2

Wir werden im Laufe des Jahres 2024 viele der oben genannten Maßnahmen umsetzen, um das Ziel von 1 GB Gas pro Sekunde zu erreichen.

Allerdings stößt die vertikale Skalierung irgendwann auf physikalische und praktische Grenzen. Keine einzelne Maschine kann den Rechenbedarf der Welt decken. Wir glauben, dass es hier zwei Wege gibt, die uns bei der Erweiterung durch die Einführung weiterer Boxen nach steigender Last unterstützen können:

(1) Multiple Rollup Reth

Der heutige L2-Stack muss mehrere Dienste ausführen, um die Kette zu verfolgen: L1 CL, L1 EL , L1 -> L2 abgeleitete Funktionen (möglicherweise gebündelt mit L2 EL) und L2 EL. Während dies der Modularität zugute kommt, werden die Dinge komplizierter, wenn mehrere Knotenstapel ausgeführt werden. Stellen Sie sich vor, Sie müssten 100 Rollups ausführen!

Wir möchten die gleichzeitige Veröffentlichung von Rollups ermöglichen, während sich Reth weiterentwickelt, und die Betriebskosten für die Ausführung Tausender Rollups auf nahezu Null reduzieren.

Daran arbeiten wir bereits in unserem Execution Scaling-Projekt, weitere werden in den kommenden Wochen folgen.

(2) Cloud-natives Reth

Hochleistungssortierer können viele Anforderungen an eine einzelne Kette stellen, sie müssen skaliert werden und eine Maschine kann ihre Anforderungen nicht erfüllen. Dies ist mit den heutigen Einzelknotenbereitstellungen nicht möglich.

Wir hoffen, die Ausführung cloudnativer Reth-Knoten zu unterstützen, sie als Service-Stack bereitzustellen, der je nach Rechenbedarf automatisch skaliert werden kann, und scheinbar unbegrenzten Cloud-Objektspeicher für persistenten Speicher zu nutzen. Dies ist eine gängige Architektur in serverlosen Datenbankprojekten wie NeonDB, CockroachDB oder Amazon Aurora.

3. Zukunftsaussichten

Wir hoffen, diese Roadmap schrittweise für alle Reth-Nutzer ausrollen zu können. Unsere Mission ist es, 1 GB Gas pro Sekunde und mehr für jedermann zugänglich zu machen. Wir werden die Optimierung auf Reth AlphaNet testen und hoffen, dass die Leute Reth als SDK verwenden, um optimierte Hochleistungsknoten zu erstellen.

Es gibt einige Fragen, auf die wir noch keine Antworten gefunden haben.

• Wie trägt Reth dazu bei, die Leistung des gesamten L2-Ökosystems zu verbessern?

• Wie messen wir die Worst-Case-Szenarien, die bei einigen unserer Optimierungen im Allgemeinen auftreten können, richtig?

• Wie gehen wir mit möglichen Meinungsverschiedenheiten zwischen L1 und L2 um?

Auf viele dieser Fragen haben wir noch keine Antworten, aber wir haben viele vielversprechende erste Ideen, die uns noch eine Weile beschäftigen werden, und wir hoffen, dass diese Bemühungen in den kommenden Monaten Früchte tragen.

Das obige ist der detaillierte Inhalt vonEin Artikel, der erklärt, wie Ethereum Reth 1 GB Gas pro Sekunde erreicht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!