Monad-Erste-Schritte-Leitfaden: Paralleles EVM und Leistungsverbesserung schnell verstehen

Transaktionsskalierbarkeit war schon immer ein heißes Thema. In den letzten Wochen haben wir untersucht, wie Monaden zur Skalierung von TPS beitragen können.

Hier finden Sie eine ausführliche Erklärung zur Funktionsweise von Monaden, verfasst von Saurabh Deshpande.

Detaillierte Erklärung der Funktionsweise von Monad

TPS ist ein Indikator, dem wir große Aufmerksamkeit schenken. Wir möchten, dass unsere Ketten höhere TPS unterstützen können, weil sie mehr Benutzer und Anwendungen unterstützen können. Die folgende Grafik zeigt die TPS-Zahlen für Ethereum und L2. Keine Kette hat jemals die 100-TPS-Marke überschritten. Beachten Sie, dass TPS ein allgemeiner Begriff zur Messung der Skalierung ist. TPS ist ungenau, da nicht alle Transaktionen gleich sind und sich in ihrer Komplexität unterscheiden. Der Einfachheit halber verwenden wir jedoch TPS als Maß für die Skalierung.

Was sollten wir tun, wenn wir den TPS erhöhen wollen?

• Der erste Weg besteht darin, ein völlig neues System aufzubauen, wie es Solana getan hat. Im Vergleich zur Geschwindigkeit geht die EVM-Kompatibilität verloren. Es verwendet Multithread-Ausführung anstelle von Single-Thread-Ausführung (denken Sie an Multi-Core-CPU vs. Single-Core-CPU), parallelisiert Transaktionen und verwendet einen anderen Konsensmechanismus.

• Der zweite Ansatz besteht darin, die Off-Chain-Ausführung zu nutzen und Ethereum mit einem zentralisierten Sequenzer zu skalieren.

• Der dritte Ansatz besteht darin, die EVM in separate Komponenten zu zerlegen und diese zu optimieren, um die Skalierbarkeit zu verbessern.

Monad ist ein neues EVM-kompatibles L1, das kürzlich 225 Millionen US-Dollar gesammelt hat und EVM von Grund auf aufbaut, anstatt es direkt zu nutzen. Um die Skalierbarkeit zu erhöhen, wurde dieser dritte Ansatz gewählt.

Wir haben mehrere wichtige Änderungen besprochen, die Monaden mit sich gebracht hat.

Parallele Ausführung

Die Ethereum Virtual Machine (EVM) führt Transaktionen nacheinander aus. Bevor eine Transaktion ausgeführt wird, muss die nächste Transaktion warten. Denk darüber so. Stellen Sie sich eine Plattform in einer Motorradmontagewerkstatt vor. Mehrere LKWs liefern Motorradteile (jeder LKW verfügt über alle Teile, die zum Zusammenbau von 50 Motorrädern benötigt werden). Die Montagehalle erfüllt vier verschiedene Funktionen: Entladen, Sortieren, Montieren und Beladen.

Im aktuellen EVM-Setup gibt es nur eine Plattform und derselbe Standort wird zum Be- und Entladen verwendet. Während der LKW geparkt ist, werden die Motorradteile entladen, sortiert, zusammengebaut und auf denselben LKW geladen. Während das Klassifizierungsteam arbeitet, warten andere Teams. Wenn man sich ihre Arbeit also als separate Zeitfenster vorstellt, arbeitet jedes Team nur einmal in vier Zeitfenstern. Dies führt zu erheblichen Ineffizienzen und unterstreicht die Notwendigkeit eines effizienteren Ansatzes.

Stellen Sie sich nun eine Plattform mit vier verschiedenen Be- und Entladebereichen vor. Auch wenn das Entladeteam jeweils nur mit einem LKW arbeiten kann, muss es nicht auf die nächsten drei Slots warten. Sie können direkt auf den nächsten LKW umgeladen werden.

Das Gleiche gilt für die Sortier-, Montage- und Verladeteams. Sobald die Entladung abgeschlossen ist, fährt der LKW zur Verladerampe und wartet darauf, dass das Verladeteam die montierten Motorräder verlädt. Daher führt ein Lager mit nur einer Plattform und Be-/Entladebereichen alle Vorgänge nacheinander aus, während ein Lager mit 4 Plattformen und verschiedenen Be-/Entladebereichen eine Parallelisierung durchführt.

Stellen Sie sich Monads als Infrastruktur vor, gleichbedeutend mit einem Lagerhaus mit mehreren LKW-Plattformen. Aber es ist nicht einfach. Die Komplexität steigt, wenn man sich auf Lkw verlässt. Was passiert zum Beispiel, wenn ein LKW nicht über alle Teile verfügt, um 50 Motorräder zusammenzubauen? Transaktionen sind möglicherweise nicht immer unabhängig. Daher muss die Monade voneinander abhängige Transaktionen verarbeiten, wenn sie diese parallel ausführt.

Wie gehe ich damit um? Es implementiert eine Methode namens optimistische parallele Ausführung. Das Protokoll kann nur unabhängige Transaktionen parallel ausführen. Betrachten Sie zum Beispiel 4 Transaktionen, bei denen Joels Guthaben 1 ETH beträgt:

• Joel sendet 0,2 Ether an Saurabh

• Sid prägt einen NFT

• Joel sendet 0,1 Ether an Sid

Kaufen Sie PEPE
Alle diese Transaktionen werden parallel ausgeführt und ausstehende Ergebnisse werden einzeln übermittelt. Wenn die Ausgabe des ausstehenden Ergebnisses mit der ursprünglichen Eingabe einer Transaktion in Konflikt steht, wird die Transaktion erneut ausgeführt. Die Transaktionen 2 und 4 haben keine ausstehenden Ergebnisse, die mit den Eingaben anderer Transaktionen in Konflikt stehen, da sie unabhängig voneinander sind. Die Transaktionen 1 und 4 sind jedoch nicht unabhängig.

Bitte beachten Sie, dass der Fokus auf Joels Saldo von 1 ETH liegt, da alle 4 Transaktionen im selben Zustand beginnen. Nachdem Joel 0,2 ETH gesendet hatte, betrug der Restbetrag 0,8 ETH. Nachdem Joel 0,1 ETH an Sid gesendet hat, beträgt sein Guthaben 0,9 ETH. Die Ergebnisse werden einzeln übermittelt, um sicherzustellen, dass die Ausgabe nicht mit Eingaben in Konflikt steht. Nach Übermittlung des ausstehenden Ergebnisses von 1 beträgt Joels neuer Kontostand 0,8 ETH.

Diese Ausgabe steht im Konflikt mit der Eingabe der dritten Transaktion. Jetzt wird 3 mit einer Eingabe von 0,8 ETH erneut ausgeführt. Nach der Ausführung von 3 beträgt Joels Guthaben 0,7 ETH.

MonadDb

An diesem Punkt stellt sich natürlich die Frage, woher wir wissen, dass wir die meisten Transaktionen nicht erneut ausführen müssen. Die Antwort ist, dass die erneute Ausführung nicht der Engpass ist. Der Engpass ist der Zugriff auf den Speicher von Ethereum. Es stellt sich heraus, dass die Art und Weise, wie Ethereum den Status in einer Datenbank speichert, den Zugriff auf den Status schwierig macht (zeitaufwändig und daher teuer). Dies ist eine weitere Verbesserung von Monad: MonadDb. Die Art und Weise, wie Monads Datenbanken strukturieren, reduziert den mit Lesevorgängen verbundenen Overhead.

Wenn die Transaktion erneut ausgeführt werden muss, befinden sich alle Eingaben bereits im Cache-Speicher, der im Vergleich zum Gesamtzustand einfacher zugänglich ist.

Solana hatte 50.000 TPS in seinem Testnetz, hat aber jetzt nur noch etwa 1.000 TPS im Hauptnetz. Monad behauptet, in seinem internen Testnetz 10.000 reale TPS erreicht zu haben. Auch wenn dies nicht immer die tatsächliche Leistung widerspiegelt, können wir es kaum erwarten, zu sehen, wie Monad in realen Anwendungen abschneidet.

Das obige ist der detaillierte Inhalt vonMonad-Erste-Schritte-Leitfaden: Paralleles EVM und Leistungsverbesserung schnell verstehen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!