Was ist nach dem Cancun-Upgrade der Leistungsengpass bei Rollups?

Zusammengestellt von: Azuma, Odaily Planet Daily

Am Mittag des 26. März, Pekinger Zeit, veröffentlichte Monad-Mitbegründer Keone Hon einen ausführlichen Artikel über den Leistungsstatus von Rollup. In dem Artikel erläuterte Keone, wie das theoretische TPS-Limit von Rollup nach dem Blockanzeige-Upgrade berechnet werden sollte, und erklärte, dass die Einzeltransaktionsgebühr einiger Layer 2 (Basis) nach dem Upgrade immer noch mehrere Dollar beträgt. Darüber hinaus erläuterte Keone auch einige der Engpässe, mit denen Rollup konfrontiert ist, und mögliche Verbesserungen.

Das Folgende ist der Originalinhalt von Keone, zusammengestellt von Odaily Planet Daily. Zur Vereinfachung der Leser hat der Übersetzer bestimmte Ergänzungen zum Originaltext vorgenommen.

In letzter Zeit gab es auf dem Markt einige Diskussionen über Rollup-Ausführungsengpässe und Gasbeschränkungen, die nicht nur Layer1, sondern auch Layer2 betreffen. Auf diese Engpässe gehe ich weiter unten ein.

Datenverfügbarkeit (DA)

Gemäß dem EIP-4844-Standard wurde die Datenverfügbarkeit (DA) von Ethereum erheblich verbessert. Die Datensynchronisierungstransaktionen von Layer2 müssen nicht mehr mit Ordinary interagieren Layer-1-Transaktionen werden im selben Gebührenmarkt angeboten.

Derzeit beträgt der Gesamtkapazitätsstatus von Blobs 3 125-KB-Blobs pro Block (12 Sekunden), was 31,25 KB pro Block entspricht. Wenn man davon ausgeht, dass die Größe einer Transaktion etwa 100 Byte beträgt, bedeutet dies, dass alle Rollups ein gemeinsames TPS haben etwa 300.

Natürlich gibt es einige Informationen, die besondere Anmerkungen erfordern.

• Erstens: Wenn Rollup eine bessere Technologie zur Transaktionsdatenkomprimierung einsetzt, um die Größe einer einzelnen Transaktion zu reduzieren, kann TPS wachsen.
• Zweitens kann Rollup theoretisch zusätzlich zur Verwendung von Blob zum Synchronisieren von Daten auch weiterhin Calldata zum Synchronisieren von Daten verwenden (dh die alte Lösung vor dem Cancun-Upgrade), obwohl dies zusätzliche Komplexität mit sich bringt.
• Drittens gibt es Unterschiede in der Art und Weise, wie verschiedene ZK-Rollups den Status veröffentlichen (insbesondere zkSync Era und Starknet), sodass für diese Rollups auch die Berechnungsmethoden und Ergebnisse unterschiedlich sind.

Rollup-Gaslimit

In letzter Zeit hat Base+ aufgrund des Anstiegs der Gasgebühren große Aufmerksamkeit erregt. Die Kosten für einige normale Transaktionen im Netzwerk sind auf mehrere Dollar gestiegen.

Warum hat sich das Basisnetz nach dem Upgrade in Cancun nur für einen bestimmten Zeitraum verringert und ist nun auf das Niveau vor dem Upgrade zurückgekehrt oder hat es sogar überschritten? Dies liegt daran, dass es auf Base ein Gesamtgaslimit für Blöcke gibt, das durch einen Parameter in seinem Code durchgesetzt wird.

Die derzeit von Base verwendeten Gasparameter sind die gleichen wie bei Optimism, d. h. es gibt ein Gesamtlimit von 5 Millionen Gas pro Layer2-Block (2 Sekunden), wenn die Nachfrage (Gesamtzahl der Transaktionen) im Netzwerk das Angebot übersteigt (Blockraum) Zu diesem Zeitpunkt wird die Preisabrechnung einen On-Demand-Ausführungsmechanismus übernehmen, was zu einem Anstieg des Gasvolumens im Netzwerk führt.

Warum erhöht Base dieses Gesamtgaslimit nicht? Oder mit anderen Worten: Warum muss Rollup ein Gesamtgaslimit festlegen?

Neben der oben erwähnten TPS-Obergrenze für die Datenverfügbarkeit gibt es tatsächlich zwei weitere Hauptgründe, nämlich den Engpass beim Ausführungsdurchsatz und die versteckte Gefahr des Zustandswachstums.

Problem 1: Engpass beim Ausführungsdurchsatz

Im Allgemeinen führt EVM Rollup eine von Geth gespaltene EVM aus, was bedeutet, dass sie ähnliche Leistungsmerkmale wie der Geth-Client aufweisen.

Geths Client ist Single-Threaded (d. h. er kann jeweils nur eine Aufgabe verarbeiten), verwendet LevelDB/PebbleDB-Codierung und speichert seinen Status in einem Merkle Patricia Trie (MPT). Hierbei handelt es sich um eine Allzweckdatenbank, die eine andere Baumstruktur (LSM-Baum) als zugrunde liegende Ebene zum Speichern von Daten auf einem Solid-State-Laufwerk (SSD) verwendet.

Für Rollup sind „Statuszugriff“ (Lesen von Werten aus dem Merkle-Trie) und „Statusaktualisierung“ (Aktualisierung des Merkle-Tries am Ende jedes Blocks) die teuersten Links im Ausführungsprozess. Dies liegt daran, dass die Kosten für einen einzelnen Lesevorgang von der SSD 40–100 Mikrosekunden betragen und da die Merkle-Trie-Datenstruktur in eine andere Datenstruktur (LSM-Baum) eingebettet ist, ist eine Menge unnötiger zusätzlicher Suchvorgänge erforderlich.

Diesen Link kann man sich als den Prozess vorstellen, eine bestimmte Datei in einem komplexen Dateisystem zu finden. Sie müssen vom Stammverzeichnis (Trie-Stammknoten) bis zur Zieldatei (Blattknoten) gehen. Bei der Suche nach jeder Datei müssen Sie einen bestimmten Schlüssel in der Datenbank LevelDB finden und innerhalb von LevelDB den eigentlichen Datenspeichervorgang über eine andere Datenstruktur namens LSM-Baum durchführen. Diese zusätzlichen Schritte machen das Lesen und Aktualisieren der Daten insgesamt recht langsam und ineffizient.

Beim Design von Monad haben wir dieses Problem durch MonadDb gelöst. MonadDb ist eine benutzerdefinierte Datenbank, die das Speichern von Merkle Trie direkt auf der Festplatte unterstützt und so den Overhead von LevelDb vermeidet. Sie unterstützt asynchrone E/A und ermöglicht die parallele Verarbeitung mehrerer Lesevorgänge unter Umgehung des Dateisystems.

Darüber hinaus ermöglicht der von Monad übernommene Mechanismus der „optimistischen parallelen Ausführung“ die parallele Verarbeitung mehrerer Transaktionen und das parallele Extrahieren ihres Status aus MonadDb.

Allerdings verfügt Rollup nicht über diese Optimierungen und weist daher einen Engpass beim Ausführungsdurchsatz auf.

Es ist zu beachten, dass der Erigon/Reth-Client bestimmte Optimierungen für die Datenbankeffizienz aufweist und einige Rollup-Clients auch auf diesen Clients basieren (z. B. OP-Reth). Erigon/Reth verwendet eine flache Datenstruktur, die den Abfrageaufwand beim Lesen bis zu einem gewissen Grad reduziert. Sie unterstützen jedoch weder asynchrones Lesen noch Multithread-Verarbeitung. Darüber hinaus muss die Merkle-Wurzel nach jedem Block neu berechnet werden, was ebenfalls ein ziemlich langsamer Prozess ist.

Frage 2: Verborgene Gefahren des Zustandswachstums

Wie andere Blockchains wird auch Rollup ihren Durchsatz begrenzen, um zu verhindern, dass sein aktiver Zustand zu schnell wächst.

Ein häufiges Argument auf dem Markt ist, dass die Wachstumsraten der Bundesstaaten deshalb besorgniserregend sind, weil bei einem deutlichen Anstieg der Bundesstaatendaten auch die Gerätenachfrage nach Solid-State-Drives (SSDs) nach oben angepasst werden muss. Allerdings halte ich das für etwas ungenau, SSDs sind relativ günstig (eine hochwertige 2-TB-SSD kostet etwa 200 US-Dollar) und der Gesamtumfang von Ethereum betrug in seiner fast 10-jährigen Geschichte „nur“ etwa 200 GB. Aus reiner Speichersicht gibt es noch viel Raum für Wachstum.

Die größere versteckte Gefahr besteht tatsächlich darin, dass mit zunehmendem Status die Zeit für die Abfrage des angegebenen Statusfragments länger wird. Dies liegt daran, dass der aktuelle Merkle-Patricia-Versuch die „Verknüpfung“ verwendet, wenn die Bedingung „Knoten hat nur einen untergeordneten Knoten“ erfüllt ist, was die effektive Tiefe des Versuchs verringern und dadurch den Abfrageprozess beschleunigen kann Der Status des Merkle Trie wird immer voller, es werden immer weniger „Verknüpfungen“ verfügbar sein.

Zusammenfassend lässt sich sagen, dass die verborgene Gefahr des Staatswachstums letztendlich eine Frage der Effizienz des Staatszugangs ist. Daher ist die Beschleunigung des Staatszugangs der Schlüssel, um das Staatswachstum nachhaltiger zu gestalten.

Warum funktioniert es nicht, nur die Hardware zu optimieren?

Layer2 befindet sich derzeit noch in einem relativ zentralisierten Zustand, das heißt, das Netzwerk ist immer noch auf einen einzigen Sequenzer angewiesen, um den Zustand aufrechtzuerhalten und Blöcke zu produzieren. Man könnte sich fragen, warum man den Sequenzer nicht auf Hardware mit sehr großem RAM (Random Access Memory) laufen lässt, damit der gesamte Status im Speicher gespeichert werden kann?

Dafür gibt es zwei Gründe.

Erstens wird dies das Problem der Datenverfügbarkeit des Ethereum-Hauptnetzwerks nicht lösen. Basierend auf der aktuellen Situation von Base wird der Anstieg des Netzwerkgases jedoch nicht durch unzureichende Datenverfügbarkeitsfähigkeiten des Hauptnetzwerks verursacht Auf lange Sicht scheint dies letztendlich ein großer Engpass zu sein, der Rollup einschränkt.

Das zweite Problem ist die Dezentralisierung. Obwohl der Sequenzer immer noch stark zentralisiert ist, sind auch andere am Netzwerkbetrieb beteiligte Rollen wichtig. Sie müssen in der Lage sein, Knoten unabhängig auszuführen, denselben Transaktionsverlauf wiederzugeben und denselben Status beizubehalten.

Die rohen Transaktionsdaten und die Statusübermittlung auf Layer1 reichen nicht aus, um den vollständigen Status freizuschalten. Jeder Akteur, der Zugriff auf den vollständigen Status benötigt (z. B. ein Händler, eine Börse oder ein automatisierter Händler), sollte einen vollständigen Layer2-Knoten betreiben, um Transaktionen zu verarbeiten und über eine aktuelle Kopie des Status zu verfügen.

Rollups sind immer noch Blockchains, und Blockchains sind aufgrund ihrer Fähigkeit interessant, durch einen gemeinsamen globalen Zustand eine globale Koordination zu erreichen. Für alle Blockchains ist leistungsstarke Software notwendig, und die Optimierung der Hardware allein reicht nicht aus, um das Problem zu lösen.

Community-Interaktion

Nachdem Keone diesen Artikel veröffentlicht hatte, interagierten Schlüsselpersonen mehrerer leitender Layer2-Projekte im Rahmen des Updates.

zkSync-Mitbegründer Alex Gluchowski fragte, was der Unterschied zwischen Monad in dieser Hinsicht ist, als Antwort auf den Artikel „Die Merkle-Wurzel muss nach jedem Block neu berechnet werden“?

Keones Antwort ist, dass es nach jedem Block einen Optimierungsalgorithmus zur Berechnung der Merkle-Wurzel geben wird.

Jesse Pollak, der Verantwortliche von Base, erklärte damit auch, warum die Gaskosten nach dem Base-Upgrade in Cancun gestiegen statt gesunken seien. Er sagte, dass EIP-4844 die DA-Kosten auf Layer 1 deutlich gesenkt habe Da die Nachfrage nach Netztransaktionen jedoch um mehr als das Fünffache gestiegen ist und die Blöcke im Basisnetz eine Grenze von 250 Gas/s haben, übersteigt die Nachfrage das Angebot, was zu einem Anstieg der Gasgebühren führt.

Das obige ist der detaillierte Inhalt vonWas ist nach dem Cancun-Upgrade der Leistungsengpass bei Rollups?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!