Dies ist die erste Version der persönlichen Studiennotizen des Whitepapers von @megaeth_labs. Wenn Sie interessiert sind, können Sie einen Blick darauf werfen. Als De-facto-Grenze der Blockchain-Innovation verdient Ethereum sehr viel Aufmerksamkeit. Wenn es Fehler oder Auslassungen gibt, weisen Sie mich bitte darauf hin und danken Ihnen.

1. Drei Merkmale und aktuelle eingeschränkte Fälle:

hoher Transaktionsdurchsatz, hoher Durchsatz

Der beste opBNB zeichnet sich durch seine extrem hohe Gasrate von 100 MGas/s aus, ist aber im Vergleich zu den Fähigkeiten von Web2-Servern immer noch sehr niedrig. 100 MGas/s entsprechen 650 Uniswap-Swaps oder 3700 ERC20-Transfers pro Sekunde, während moderne Server pro 2. Mehr als 1 Million Transaktionen können ausgeführt werden.

reichlich Rechenkapazität, reichlich Rechenleistung

Komplexe Anwendungen können nicht in die Kette hochgeladen werden und sind hauptsächlich durch die Rechenleistung begrenzt. Wenn der EVM-Vertrag zur Berechnung von n-Fibonacci-Zahlen verwendet wird, sind 5,5 Milliarden Gas erforderlich, was eine Berechnungsgeschwindigkeit von 100 MGas/s erfordert, die 55 Sekunden dauert der gesamten Opbnb-Kette. Traditionell dauert ein in C-Sprache geschriebenes Programm nur 30 ms. Die Single-Core-CPU-Geschwindigkeit wurde um das 1833-fache erhöht

und das Einzigartigste: Reaktionszeiten im Millisekundenbereich selbst unter hoher Last. Reaktionszeiten im Millisekundenbereich unter hoher Last.

Mit Ausnahme von Arb benötigen andere Mainstream-Blockchains der zweiten Ebene mehr als 1 Sekunde Blockgenerierungszeit, um den Status der Kette zu aktualisieren. Dies ist für Anwendungen, die hohe Aktualisierungsraten und schnelle Rückkopplungsschleifen erfordern, nicht möglich. Selbst erstellte Welten und Spiele in der Kette erfordern beispielsweise eine Reaktionszeit von 100 ms, während der Hochfrequenzhandel eine Reaktionszeit von 10 ms für die Platzierung oder Stornierung von Aufträgen erfordert, andernfalls kann keines davon erreicht werden.

2. Wie man die Leistungsgrenzen überschreitet

Aktuelle Blockchain-Architektur (L1)

Jede Blockchain besteht aus zwei Grundkomponenten, einschließlich Konsens und Ausführung.

Der Konsens bestimmt die Reihenfolge der Benutzertransaktionen und die Ausführung verarbeitet diese Transaktionen in einer festgelegten Reihenfolge, um den Blockchain-Status zu aktualisieren. In den meisten L1-Blockchains führt jeder Knoten die gleiche Aufgabe ohne Spezialisierung aus. Jeder Knoten nimmt am verteilten Protokoll teil, erreicht einen Konsens und führt dann Transaktionen lokal aus. Jede L1 muss entscheiden, inwieweit sie die Hardwareanforderungen für normale Benutzer zum Betrieb von Knoten erhöhen kann, ohne die grundlegenden Eigenschaften der Blockchain, wie Sicherheit und Zensurresistenz, zu beeinträchtigen.

Daher sind die Betriebsanforderungen vollständiger Knoten im Hinblick auf Sicherheit und Zensurresistenz sehr wichtig.

Das neue Paradigma der Schicht 2

Die Natur der L2-Blockchain ist heterogen und von Natur aus unterschiedlich. Verschiedene L2-Knoten sind darauf spezialisiert, bestimmte Aufgaben effizienter auszuführen.

megaETH geht noch einen Schritt weiter und entkoppelt (trennt) Transaktionsausführungsaufgaben von vollständigen Knoten. Insbesondere hat MegaETH drei Rollen: Sequenzer (Sequenzer), Prüfer (Zertifizierer) und vollständige Knoten (vollständige Knoten).

Der erste Schlüssel ist ein leistungsstarker zentraler Sortierer

Sequenzer: Verantwortlich für die Bestellung und Ausführung von Transaktionen. Megaeth unterscheidet sich jedoch darin, dass es zu jedem Zeitpunkt nur einen aktiven Sequenzer gibt, wodurch der Konsensaufwand während der normalen Ausführung entfällt. Die meisten vollständigen Knoten empfangen Statusunterschiede von diesem Besteller über das P2P-Netzwerk und wenden die Unterschiede dann direkt an, um ihren lokalen Status zu aktualisieren. Sie führen jedoch keine Transaktionen erneut aus, sondern überprüfen Blöcke indirekt durch vom Prüfer bereitgestellte Beweise. Fortgeschrittene Benutzer (Brückenbetreiber und Market Maker) können weiterhin jede Transaktion so schnell wie möglich ausführen, um die Endgültigkeit zu erreichen. Dies erfordert jedoch höhere Hardwareanforderungen, um mit dem Sequenzer Schritt zu halten. Schließlich verwenden Prüfer das zustandslose Validierungsschema, um Blöcke asynchron und außerhalb der Reihenfolge zu überprüfen.

 

Die Knotenspezialisierung ist sehr wichtig. Obwohl die Blockgenerierung stärker zentralisiert ist, ist die Blockchain stärker dezentralisiert. Beispielsweise erfordert der Sequenzer einen High-End-Server, während der für den vollständigen Knoten erforderliche Server sehr kostengünstig ist.

Neben leistungsstarken zentralen Servern gibt es komplexere technische Implementierungen

Wenn Sie sich nur auf leistungsstarke Server verlassen, kann Reth im Experiment nur 1000 TPS erreichen, was etwa 100 MGas/s entspricht. Dies ist hauptsächlich auf die begrenzte Aktualisierung der MPT (von Ethereum verwendete Datenstruktur) in jedem Block zurückzuführen, die schneller ist Die Berechnung der Ausführung der Transaktion selbst ist zehnmal höher.

Wir stehen also immer noch vor vielen komplexen Situationen.

3. Design von megaETH

Messen, dann bauen, zuerst messen, um die tatsächlichen Probleme und Leistungsbeschränkungen zu finden, und dann das neue System entwerfen, um alle Probleme gleichzeitig zu lösen.

Strebt danach, Systeme so zu entwerfen, dass sie die Grenzen der Hardware erreichen, mag kein inkrementelles Design und bevorzugt neue Designs nahe an theoretischen Grenzen.

Im Folgenden sind einige Herausforderungen und Lösungen aufgeführt, die während des Designprozesses auftreten

Transaktionsausführung. Transaktionsausführung

 

Beginnen wir mit dem Sequenzer. Viele Leute sagen, dass EVM der Grund für die schlechte Leistung und die niedrigen TPS von L2s ist, aber das ist falsch. Laut Megaeths Test kann EVM 14.000 TPS erreichen, was bereits sehr hoch ist.

Für die Echtzeit-Blockchain reicht dies jedoch nicht aus. Die herkömmliche EVM-Implementierung weist drei Ineffizienzprobleme auf:

Hohe Statuszugriffslatenz: Der Zugriff auf und das Lesen des Blockchain-Status ist langsam, da er auf der Festplatte gespeichert ist und mehrere Lesevorgänge erfordert.

Lösung: Der Bestellknoten ist mit ausreichend RAM ausgestattet, um den gesamten Blockchain-Status zu speichern. Derzeit beträgt der RAM von Ethereum etwa 100 GB. Diese Methode beschleunigt den Statuszugriff erheblich, indem die SSD-Leselatenz eliminiert wird.

Mangel an paralleler Ausführung: Da Transaktionen sequentiell ausgeführt werden, um Zustandskonsistenz und doppelte Ausgaben sicherzustellen, ist eine parallele Ausführung schwierig

Lösung: Für dieses Szenario gibt es bereits Workarounds, aber selbst wenn sie gelöst werden, ist die tatsächlich erreichbare Beschleunigung in der tatsächlichen Produktion von Natur aus durch die im Workload verfügbare Parallelität begrenzt. Tests zufolge beträgt die tatsächliche mittlere Parallelität von Ethereum in letzter Zeit weniger als 2, was auf eine begrenzte Parallelität hinweist. Tatsächlich besteht der Kern darin, dass verschiedene Transaktionen in Ethereum eine große Anzahl von Abhängigkeiten und sogar das Lesen und Schreiben von Objekten im selben Zustand aufweisen, was zu Konflikten in der Parallelität führt. Dieses Problem muss gelöst werden.

Interpreter-Overhead: Der zusätzliche Overhead, der durch die virtuelle Maschine oder den Interpreter bei der Ausführung intelligenter Verträge verursacht wird.

Lösung: Ein relativ hoher Anteil der Opcodes ist bereits in Rust enthalten, daher ist es schwierig, von der Kompilierung zu profitieren. Die maximale Beschleunigung beträgt möglicherweise nur das Zweifache.

Zusätzlich zu den Problemen, mit denen diese drei allgemeinen Hochleistungs-Blockchains konfrontiert sind, gibt es noch zwei Herausforderungen, um eine Echtzeit-Blockchain auf 10-ms-Ebene zu erreichen. Die erste ist die hochfrequente konsistente Produktion von Blöcken, beispielsweise wird ein Block generiert alle 10 ms. Zweitens muss die parallele Ausführungs-Engine die Transaktionspriorisierung unterstützen, damit kritische Transaktionen auch in Spitzenlastzeiten ohne Warteschlangenverzögerungen verarbeitet werden können.

Zustandssynchronisation

Bei der Zustandssynchronisierung geht es darum, vollständige Knoten mit dem Sequenzer auf den neuesten Stand zu bringen. Dies ist einer der anspruchsvollsten Aspekte des Hochleistungs-Blockchain-Designs.

Wenn Übertragungen und Uniswap-Transaktionen 100.000 Mal pro Sekunde übertragen werden, benötigen sie eine Bandbreite von 152,6 Mbit/s bzw. 476,1 Mbit/s, was weit mehr ist als die 100 Mbit/s-Bandbreite des gesamten Knotens. Darüber hinaus werden diese 100 Mbit/s wahrscheinlich nur zu einem Drittel genutzt. Die tatsächlich für die Synchronisierung verwendete Bandbreite beträgt möglicherweise nur 25 Mbit/s, was einen großen Unterschied zu den tatsächlichen Anforderungen darstellt.

Statusstamm aktualisieren

Das Konzept ist sehr kompliziert. Um die Statuswurzel zu aktualisieren, müssen 100.000 Übertragungen vorgenommen werden. Für Datenbank-Lesevorgänge sind zwischengespeicherte Zeiten erforderlich. Selbst wenn wir davon ausgehen, dass jeder Datenbank-Lesevorgang von einer einzelnen Festplatten-E/A verarbeitet werden kann, liegen 6 Millionen IOPS weit über den Möglichkeiten einer Consumer-SSD, und diese Berechnung berücksichtigt nicht einmal Schreibvorgänge Operationen berücksichtigen.

Eine gängige Optimierungsstrategie zur Reduzierung von Festplatten-E/A besteht darin, mehrere Trie-Knoten in einem Unterbaum zu gruppieren und sie auf einer 4-KB-Festplattenseite zu speichern. Aber es ist immer noch sechsmal niedriger als wir verlangt haben.

Gasbegrenzung blockieren

Für die Sicherheit und Zuverlässigkeit der Blockchain müssen wir angemessene Gasgrenzwerte festlegen.

Infrastruktur

Schließlich interagieren Benutzer nicht direkt mit Sequenzerknoten, und die meisten Leute führen zu Hause keine vollständigen Knoten aus. Stattdessen übermitteln Benutzer Transaktionen an einen RPC-Knoten eines Drittanbieters und verlassen sich auf einen dApp- oder Blockchain-Explorer wie das Web-Frontend von http://etherscan.io/, um die Transaktionsergebnisse zu bestätigen.

Daher hängt die tatsächliche Benutzererfahrung einer Blockchain stark von der unterstützenden Infrastruktur wie RPC-Knoten und Indexern ab. Unabhängig davon, wie schnell eine Echtzeit-Blockchain läuft, wenn die RPC-Knoten die große Anzahl von Leseanforderungen während der Spitzenzeiten nicht effizient verarbeiten, Transaktionen nicht schnell an die Sortierknoten weiterleiten können oder die Indexer die Anwendungsansichten nicht schnell genug aktualisieren können, um mitzuhalten, dann Es spielt keine Rolle.

Skalierung der Blockchain mit einem prinzipiellen Ansatz

Engagiert für einen ganzheitlichen und prinzipiellen Ansatz in Forschung und Entwicklung. Indem wir frühzeitig eine detaillierte Leistungsanalyse durchführen, stellen wir sicher, dass wir uns weiterhin auf die Lösung von Problemen konzentrieren, die unseren Benutzern echte Vorteile bringen. Tatsächlich liegt der Schlüssel in der Gesamt-, Tiefen- und Benutzerperspektive.

4. Erwartete Anwendungstypen

• Spiel

• Dezentrale physische Infrastruktur (dePin), die Echtzeit-Computing erfordert

• Autonome Weltmaschine

• Dezentrales VPN-Netzwerk

• Grenzüberschreitende Zahlungen

• Nutzen Sie den Hochfrequenzhandel mit extrem geringer Latenz (On-Chain-Binance?)

Tatsächlich sollte der Anwendungsteil viel Raum für Fantasie bieten. Ich habe mir viele verwandte Bereiche angehört und habe das Gefühl, dass die Denkweise immer noch nicht gut genug ist.