Kann MegaETH wirklich eine Echtzeit-Blockchain implementieren?

Autor: knower, crypto KOL; Übersetzung: Golden Finance xiaozou

1. Einführung in MegaETH

Der Hauptinhalt dieses Artikels werden einige meiner persönlichen Gedanken zum MegaETH-Whitepaper sein, und ich werde von hier aus möglicherweise noch weiter darauf eingehen, wenn ich kann. Unabhängig davon, wie dieser Beitrag aussehen wird, hoffe ich, dass Sie daraus etwas Neues gelernt haben.

Die Website von MegaETH ist cool, weil sie einen mechanischen Hasen mit einem sehr auffälligen Farbschema hat. Davor gab es nur einen Github – eine Website zu haben macht alles viel einfacher.

Ich habe einen Blick auf MegaETH Github geworfen und erfahren, dass dort eine Art Ausführungsschicht entwickelt wird, aber ich muss ehrlich sein, vielleicht habe ich mich da geirrt. Die Wahrheit ist, ich wusste nicht genug über MegaETH und jetzt sind sie ein heißes Thema auf EthCC.

Ich musste alles wissen und sicherstellen, dass ich die gleiche Technologie sah wie die coolen Jungs.

Das MegaETH-Whitepaper besagt, dass es sich um eine EVM-kompatible Echtzeit-Blockchain handelt, die entwickelt wurde, um Web2-ähnliche Leistung in die Kryptowelt zu bringen. Ihr Ziel ist es, das Erlebnis bei der Nutzung von Ethereum L2 zu verbessern, indem Attribute wie über 100.000 Transaktionen pro Sekunde, Blockzeiten von weniger als einer Millisekunde und Transaktionsgebühren von einem Cent bereitgestellt werden.

Ihr Whitepaper hebt die wachsende Zahl von L2s hervor (die in einem meiner vorherigen Beiträge besprochen wurde, obwohl die Zahl auf über 50 gestiegen ist und sich viele weitere L2s in der „aktiven Entwicklung“ befinden) und ihre Bemühungen im Bereich Krypto. Es gibt einen Mangel an PMF in der Welt. Ethereum und Solana sind die beliebtesten Blockchains, und Benutzer werden von einer von ihnen angezogen und werden sich nur dann für die andere L2 entscheiden, wenn es Token zum Schürfen gibt.

Ich denke nicht, dass zu viel L2 eine schlechte Sache ist, genauso wie ich nicht denke, dass es unbedingt eine gute Sache ist, aber ich stimme zu, dass wir einen Schritt zurücktreten und untersuchen müssen, warum unsere Branche so viele L2s hervorbringt.

Occams Rasierklinge würde sagen, dass VCs das Gefühl genießen, zu wissen, dass sie wirklich das Potenzial haben, den nächsten L2- (oder L1-)König aufzubauen, und die Befriedigung aus der Investition in diese Projekte ziehen, aber ich denke auch, dass viele Crypto-Entwickler vielleicht tatsächlich mehr L2 wollen . Beide Seiten mögen Recht haben, aber die Schlussfolgerung, welche Seite richtiger ist, ist unerheblich. Es ist besser, einen objektiven Blick auf das aktuelle Infrastruktur-Ökosystem zu werfen und das Beste aus dem zu machen, was wir haben.

Die Leistung des derzeit verfügbaren L2 ist hoch, aber nicht ausreichend. Im Whitepaper von MegaETH heißt es, dass selbst mit den (relativ) hohen 100 MGas/s von opBNB dies nur 650 Uniswap-Transaktionen pro Sekunde bedeuten würde – moderne oder Web2-Infrastruktur kann 1 Million Transaktionen pro Sekunde durchführen.

Wir wissen, dass Krypto trotz der Vorteile, die sich aus der dezentralen Natur ergeben und erlaubnislose Zahlungen ermöglichen, immer noch recht langsam ist. Wenn eine Spieleentwicklungsfirma wie Blizzard Overwatch in die Kette bringen möchte, kann sie das nicht – wir brauchen eine höhere Klickrate, um Echtzeit-PvP und andere Funktionen bereitzustellen, die Web2-Spiele natürlich bieten.

Eine der Lösungen von MegaETH für das L2-Dilemma besteht darin, Sicherheit und Zensurresistenz an Ethereum bzw. EigenDA zu delegieren und MegaETH ohne Kompromisse zum leistungsstärksten L2 der Welt zu machen.

L1 erfordert typischerweise homogene Knoten, die die gleichen Aufgaben ausführen, ohne Raum für Spezialisierung. In diesem Fall bezieht sich die Spezialisierung auf Arbeiten wie Sequenzierung oder Beweis. L2 umgeht dieses Problem, indem es die Verwendung heterogener Knoten ermöglicht und Aufgaben trennt, um die Skalierbarkeit zu verbessern oder einen Teil der Belastung zu verringern. Dies lässt sich an der wachsenden Beliebtheit gemeinsam genutzter Sequenzer (wie Astria oder Espresso) und dem Aufkommen spezialisierter ZK-Proof-Dienste (wie Succinct oder Axiom) erkennen.

„Die Erstellung einer Live-Blockchain erfordert mehr als nur die Verwendung eines handelsüblichen Ethereum-Ausführungsclients und das Hinzufügen von Sequenzer-Hardware. Unsere Leistungsexperimente zeigen beispielsweise, dass die Leistung von Reth bei aktuellen Ethereum-Blöcken erreicht werden kann.“ erreichen in der Echtzeit-Synchronisationseinstellung auch nur etwa 1000 TPS, was etwa 100 MGas/s entspricht.“

MegaETH erweitert diese Partitionierung, indem es die Transaktionsausführung von vollständigen Knoten abstrahiert und nur einen „aktiven“ Sequenzer verwendet, um den Konsens-Overhead bei der typischen Transaktionsausführung zu eliminieren. „Die meisten vollständigen Knoten erhalten Statusunterschiede von diesem Besteller über das P2P-Netzwerk und wenden die Unterschiede direkt an, um den lokalen Status zu aktualisieren. Stattdessen führen sie die von Prüfern bereitgestellten Beweise indirekt aus.“

Ich habe außer den Kommentaren zu „es ist schnell“ oder „es ist billig“ nicht viele Analysen darüber gelesen, wie gut MegaETH ist, daher werde ich versuchen, seine Architektur sorgfältig zu analysieren und sie mit anderen L2s zu vergleichen.

MegaETH verwendet EigenDA, um die Datenverfügbarkeit zu verwalten, was heutzutage eine ziemlich gängige Praxis ist. Auf Rollup-as-a-Service-Plattformen (RaaS: Rollup as a Service) wie Conduit können Sie Celestia, EigenDA oder sogar Ethereum (falls gewünscht) als Datenverfügbarkeitsanbieter für das Rollup wählen. Der Unterschied zwischen den beiden ist eher technischer Natur und nicht ganz relevant, und es scheint, als ob die Entscheidung, sich für das eine gegenüber dem anderen zu entscheiden, eher auf der Resonanz als auf irgendetwas anderem beruht.

Der Sequenzer ordnet Transaktionen an und führt sie letztendlich aus, ist aber auch für die Ausgabe von Blöcken, Zeugen und Zustandsunterschieden verantwortlich. In einem L2-Kontext handelt es sich bei einem Zeugen um zusätzliche Daten, die vom Prüfer zur Überprüfung des Sequenzerblocks verwendet werden.

Zustandsunterschiede sind Änderungen am Zustand der Blockchain und können im Grunde alles sein, was in der Kette passiert – die Funktion der Blockchain besteht darin, ständig neue Informationen an ihren Zustand anzuhängen und zu überprüfen, und die Funktion dieser Zustandsunterschiede besteht darin, dies vollständig zu ermöglichen Knoten Bestätigen Sie die Transaktion, ohne sie erneut auszuführen.

Prover besteht aus spezieller Hardware, die zur Berechnung kryptografischer Beweise zur Überprüfung von Blockinhalten verwendet wird. Sie ermöglichen es Knoten auch, doppelte Ausführungen zu vermeiden. Es gibt wissensfreie Beweise und Betrugsbeweise (oder optimistische Beweise?), aber der Unterschied zwischen ihnen ist im Moment nicht wichtig.

All dies zusammenzuführen, ist die Aufgabe des vollständigen Knotennetzwerks, das als eine Art Aggregator zwischen Prüfern, Bestellern und EigenDA fungiert, um (hoffentlich) die MegaETH-Magie Wirklichkeit werden zu lassen.

Das Design von MegaETH basiert auf einem grundlegenden Missverständnis von EVM. Obwohl L2 EVM häufig für seine schlechte Leistung (Durchsatz) verantwortlich macht, wurde festgestellt, dass revm 14.000 TPS erreichen kann. Wenn es nicht EVM ist, was ist der Grund?

2. Aktuelle Skalierbarkeitsprobleme

Die drei wichtigsten EVM-Ineffizienzen, die zu Leistungsengpässen führen, sind fehlende parallele Ausführung, Interpreter-Overhead und hohe Latenz beim Statuszugriff.

MegaETH ist aufgrund seines großen Arbeitsspeichers in der Lage, den Zustand der gesamten Blockchain zu speichern, der genaue Arbeitsspeicher von Ethereum beträgt 100 GB. Dieses Setup beschleunigt den Statuszugriff erheblich, indem es die SSD-Leselatenz eliminiert.

Ich weiß nicht viel über die SSD-Leselatenz, aber vermutlich sind einige Opcodes intensiver als andere, und wenn Sie mehr RAM für das Problem einsetzen, können Sie es abstrahieren. Funktioniert das noch im großen Maßstab? Ich bin mir nicht sicher, aber für diesen Artikel gehe ich davon als Tatsache aus. Ich bin immer noch skeptisch, ob Ketten gleichzeitig Durchsatz, Transaktionskosten und Latenz bestimmen können, aber ich versuche, aktiv zu lernen.

Eine weitere Sache, die ich erwähnen sollte, ist, dass ich nicht zu wählerisch sein möchte. Meine Idee ist es, niemals ein Protokoll gegenüber einem anderen zu unterstützen oder sie überhaupt gleich zu bewerten – ich tue dies nur zum besseren Verständnis und um jedem, der dies liest, zu helfen, gleichzeitig das gleiche Verständnis zu erlangen.

Sie kennen vielleicht den Trend zum parallelen EVM, aber es soll ein Problem geben. Obwohl bei der Portierung des Block-STM-Algorithmus auf die EVM Fortschritte erzielt wurden, heißt es, dass „die tatsächlich erreichbare Beschleunigung in der Produktion von Natur aus durch die in der Arbeitslast verfügbare Parallelität begrenzt ist.“ Die Technologie wird schließlich in der EVM-Kette im Mainnet eingesetzt, ist aber auch durch die grundlegende Realität eingeschränkt, dass die meisten Transaktionen möglicherweise nicht parallel ausgeführt werden müssen.

Wenn Transaktion B vom Ergebnis von Transaktion A abhängt, können Sie nicht beide Transaktionen gleichzeitig ausführen. Wenn wie in diesem Fall 50 % der Transaktionen eines Blocks voneinander abhängig sind, stellt die parallele Ausführung keine so große Verbesserung dar wie behauptet. Das ist zwar etwas zu stark vereinfacht (und vielleicht sogar ein wenig falsch), aber ich denke, es trifft ins Schwarze.

Die Lücke zwischen Revm und der nativen Ausführung ist sehr auffällig, insbesondere Revm, das immer noch 1-2 OOMs langsamer ist und als eigenständige VM-Umgebung nicht geeignet ist. Es wurde außerdem festgestellt, dass es derzeit nicht genügend rechenintensive Verträge gibt, um den Einsatz von revm zu rechtfertigen. „Wir haben zum Beispiel die pro Opcode während der historischen Synchronisierung aufgewendete Zeit analysiert und festgestellt, dass etwa 50 % der Zeit im Revm für die Opcodes ‚Host‘ und ‚System‘ aufgewendet wurden.“

In Bezug auf die Zustandssynchronisierung stellte MegaETH weitere Probleme fest. Die Zustandssynchronisierung wird einfach als ein Prozess der Synchronisierung vollständiger Knoten mit der Aktivität des Bestellers beschrieben, eine Aufgabe, die schnell die Bandbreite eines Projekts wie MegaETH verbrauchen kann. Hier ein Beispiel zur Veranschaulichung: Wenn das Ziel darin besteht, 100.000 ERC20-Übertragungen pro Sekunde zu synchronisieren, dann verbraucht dies etwa 152,6 Mbit/s Bandbreite. Diese 152,6 Mbit/s sollen die Schätzungen (oder die Leistung) von MegaETH übertreffen und stellen im Grunde eine unmögliche Aufgabe dar.

Dabei werden nur einfache Token-Transfers berücksichtigt und die Möglichkeit höherer Kosten bei komplexeren Transaktionen außer Acht gelassen. Angesichts der Vielfalt der On-Chain-Aktivitäten in der realen Welt ist dies ein mögliches Szenario. MegaETH schrieb, dass die Uniswap-Transaktion 8 Speicherplätze veränderte (während die ERC20-Übertragung nur 3 Speicherplätze veränderte), wodurch sich unser gesamter Bandbreitenverbrauch auf 476,1 Mbit/s erhöhte, was ein noch weniger erreichbares Ziel ist.

Ein weiteres Problem bei der Implementierung einer 100.000 TPS-Hochleistungsblockchain besteht in der Lösung von Aktualisierungen des Chain-State-Roots, einer Aufgabe, die das Senden von Speichernachweisen an Light-Clients verwaltet. Selbst bei professionellen Knoten müssen vollständige Knoten weiterhin den Sequenzerknoten des Netzwerks verwenden, um den Statusstamm aufrechtzuerhalten. Nehmen wir als Beispiel das obige Problem der Synchronisierung von 100.000 ERC20-Übertragungen pro Sekunde. Dies führt zu Kosten für die Aktualisierung von 300.000 Schlüsseln pro Sekunde.

Ethereum verwendet die Datenstruktur MPT (Merkle Patricia Trie: Merkle Prefix Tree), um den Zustand nach jedem Block zu berechnen. Um 300.000 Schlüssel pro Sekunde zu aktualisieren, müsste Ethereum „6 Millionen nicht zwischengespeicherte Datenbanklesevorgänge konvertieren“, was deutlich mehr ist, als jede SSD der Verbraucherklasse heute leisten kann. MegaETH schreibt, dass diese Schätzung nicht einmal Schreibvorgänge (oder Schätzungen für On-Chain-Transaktionen wie Uniswap-Transaktionen) einschließt, was die Herausforderung eher zu einem Sisyphus-ähnlichen Unterfangen macht, als die meisten von uns vielleicht bevorzugen.

Es gibt noch ein weiteres Problem: Wir haben die Grenze des Blockgases erreicht. Die Geschwindigkeit der Blockchain wird tatsächlich durch das Blockgaslimit begrenzt, eine selbst auferlegte Barriere, die die Sicherheit und Zuverlässigkeit der Blockchain erhöhen soll. „Die Faustregel für die Festlegung von Blockgasgrenzen besteht darin, sicherzustellen, dass jeder Block innerhalb dieser Grenze innerhalb der Blockzeit sicher verarbeitet werden kann.“ Das Whitepaper beschreibt die Blockgasgrenze als „Drosselungsmechanismus“, der sicherstellt, dass der Knoten mithalten kann zuverlässig, sofern die Mindestanforderungen an die Hardware erfüllt sind.

Andere sagen, dass die Blockgasbegrenzung eine konservative Wahl sei, um das Worst-Case-Szenario zu verhindern, was ein weiteres Beispiel für eine moderne Blockchain-Architektur ist, die sich auf Sicherheit statt Skalierbarkeit konzentriert. Die Idee, dass Skalierbarkeit wichtiger ist als Sicherheit, zerfällt, wenn man bedenkt, wie viel Geld täglich zwischen Blockchains transferiert wird und wie viel dieses Geld verloren gehen würde, um die Skalierbarkeit leicht zu verbessern, was zu einem nuklearen Winter führen würde.

Blockchains sind vielleicht nicht besonders gut darin, hochwertige Verbraucheranwendungen anzuziehen, aber sie sind außergewöhnlich gut bei erlaubnisfreien Peer-to-Peer-Zahlungen. Niemand will das vermasseln.

Anschließend wird erwähnt, dass die Geschwindigkeit paralleler EVM von der Arbeitslast abhängt und ihre Leistung durch die „lange Abhängigkeitskette“, die eine übermäßige „Beschleunigung“ von Blockchain-Funktionen minimiert, eingeschränkt wird. Die einzige Möglichkeit, dieses Problem zu lösen, ist die Einführung einer mehrdimensionalen Gaspreisgestaltung (MegaETH bezieht sich auf den nativen Gebührenmarkt von Solana), die immer noch schwer umzusetzen ist. Ich bin nicht sicher, ob es eine dedizierte EIP gibt oder wie eine solche EIP auf der EVM funktionieren würde, aber ich denke, technisch gesehen ist dies eine Lösung.

Schließlich interagieren Benutzer nicht direkt mit dem Sequenzerknoten, und die meisten Benutzer werden zu Hause keinen vollständigen Knoten ausführen. Daher hängt die tatsächliche Benutzererfahrung einer Blockchain stark von der zugrunde liegenden Infrastruktur wie RPC-Knoten und Indexern ab. Egal wie schnell eine Live-Blockchain läuft, wenn die RPC-Knoten die große Anzahl von Leseanforderungen in Spitzenzeiten nicht effizient verarbeiten, Transaktionen nicht schnell an die Sequenzerknoten weitergeben können oder der Indexer die Anwendungsansicht nicht schnell genug aktualisieren kann, um mit der Kette Schritt zu halten Geschwindigkeit, dann spielt es keine Rolle, wie schnell die Echtzeit-Blockchain läuft. "

Vielleicht zu viel zu sagen, aber sehr wichtig. Wir alle verlassen uns auf Infura, Alchemy, QuickNode usw. und die Infrastruktur, auf der sie laufen, unterstützt wahrscheinlich alle unsere Transaktionen. Die einfachste Erklärung für diese Abhängigkeit ergibt sich aus der Erfahrung. Wenn Sie jemals versucht haben, innerhalb der ersten 2-3 Stunden nach einem L2-Airdrop einen Airdrop zu beanspruchen, werden Sie verstehen, wie schwierig es für RPC ist, diese Art von Überlastung zu bewältigen.

3. Fazit

Nach alledem möchte ich nur zum Ausdruck bringen, dass ein Projekt wie MegaETH viele Hürden überwinden muss, um die gewünschten Höhen zu erreichen. In einem Beitrag hieß es, dass es ihnen gelungen sei, durch den Einsatz einer heterogenen Blockchain-Architektur und einer superoptimierten EVM-Ausführungsumgebung eine Hochleistungsentwicklung zu erreichen. „Heute verfügt MegaETH über ein leistungsstarkes Live-Entwicklungsnetzwerk und macht stetige Fortschritte auf dem Weg zur schnellsten Blockchain, die nur durch Hardware-Einschränkungen begrenzt ist.“

Github von MegaETH listet einige wichtige Verbesserungen auf, darunter unter anderem: EVM-Bytecode → nativer Code-Compiler, dedizierte Ausführungs-Engine für große Speichersortierknoten und effizientes Parallelitätskontrollprotokoll für paralleles EVM. Mittlerweile ist ein EVM-Bytecode/Native-Code-Compiler namens evmone verfügbar, und obwohl ich mich nicht gut genug mit dem Codieren auskenne, um die Kernfunktionen zu kennen, habe ich mein Bestes getan, um es herauszufinden.

evmone ist eine C++-Bereitstellung von EVM, die die EVMC-API übernimmt und sie in ein Ausführungsmodul für den Ethereum-Client umwandelt. Es erwähnt einige andere Funktionen, die ich nicht verstehe, wie den dualen Interpreter-Ansatz (Basis und erweitert) und die intx- und ethash-Bibliotheken. Zusammenfassend bietet evmone eine schnellere Transaktionsverarbeitung (durch schnellere Ausführung intelligenter Verträge), eine größere Entwicklungsflexibilität und eine höhere Skalierbarkeit (vorausgesetzt, dass verschiedene EVM-Bereitstellungen mehr Transaktionen pro Block verarbeiten können).

Es gibt noch ein paar andere Codebasen, aber die meisten davon sind ziemlich standardisiert und nicht speziell mit MegaETH (reth, geth) verbunden. Ich glaube, ich bin mit dem Whitepaper so gut wie fertig, daher überlasse ich die Frage jetzt jedem, der dies liest: Was kommt als nächstes für MegaETH? Ist es wirklich möglich, effiziente Spreading-Codes zu implementieren? Wie lange wird es dauern, bis dies geschieht?

Als Blockchain-Benutzer bin ich gespannt, ob dies möglich ist. Ich habe zu viel Geld für Mainnet-Transaktionsgebühren ausgegeben und es ist Zeit für eine Veränderung, aber diese Veränderung scheint immer noch schwieriger zu erreichen und wird in absehbarer Zeit wahrscheinlich nicht passieren.

Obwohl sich der Inhalt dieses Artikels hauptsächlich auf Architekturverbesserungen und Skalierbarkeit konzentriert, müssen interne Rollups dennoch Liquidität und kettenübergreifende Tools gemeinsam nutzen, um die Erfahrung von Rollup A mit Rollup B konsistent zu machen. Wir sind noch nicht so weit, aber vielleicht werden sich bis 2037 alle zurücklehnen und sich daran erinnern, wie besessen wir davon waren, Skalierbarkeitsprobleme zu „beheben“.