PREDA — Asynchronous Decomposable Parallel EVMs

Stellen Sie sich vor: Sie sind in einer belebten Küche, in der die Köche warten müssen, bis einer mit dem Zerkleinern von Gemüse fertig ist, bevor der nächste mit dem Backen von Kartoffeln beginnen kann. Klingt frustrierend langsam und ineffizient, oder? Das ist das, was synchrones Ausführen in der Informatik und der Blockchain ist: Eine Aufgabe muss abgeschlossen sein, bevor die nächste gestartet werden kann. Stellen Sie sich nun eine gut koordinierte Küche vor, in der jeder Koch gleichzeitig an verschiedenen Teilen mehrerer Gerichte arbeitet, Zutaten vorbereitet, kocht und alles gleichzeitig anrichtet. Das ist asynchrones Ausführen - Aufgaben werden gleichzeitig ausgeführt, was einen effizienteren und schnelleren Arbeitsablauf ermöglicht.

Am Scheideweg der Blockchain-Entwicklung ist die synchrone Komponierbarkeit zu einem Schlagwort geworden, da sie eine Lösung zu bieten scheint, um die fragmentierten Rollup Layer 2s im Ethereum-Netzwerk zu vereinen. Dieser Ansatz behebt die katastrophale UX und DevEx, bei der selbst eine einfache Übertragung zwischen Layer 2s einen Dollar kosten und bis zu 7 Tage dauern könnte.Vitaliks BeteiligungIn diesen Debatten wird hervorgehoben, dass eine universelle Synchronizität nicht unbedingt erforderlich ist, um diese Probleme zu lösen. Wir stimmen überein, dass eine effektive Übersetzungsausführung nicht unbedingt Synchronizität beinhalten muss, und es echte Kosten für den Aufbau und die Aufrechterhaltung synchroner Infrastruktur gibt. Wir glauben, dass es keine binäre Wahl zwischen allem, was synchron oder asynchron ist, ist. Beides kann ad hoc nebeneinander existieren, mit einer wahrscheinlichen Verschiebung hin zur Letzteren.

1. Asynchron zerlegbar

Bei der Verfolgung von skalierte Leistung in der Blockchain-Technologie hat die parallele Ausführung einzelner Smart Contracts erhebliche Aufmerksamkeit erregt. Herkömmlicherweise war die Leistung jedes Smart Contracts durch die Fähigkeiten einer einzelnen virtuellen Maschine (EVM) eingeschränkt, auch mit dem Aufkommen von Multi-Chain- oder Layer-2-Systemen. Parallele virtuelle Maschinen bieten eine vielversprechende Lösung, die es ermöglicht, Transaktionen eines einzelnen Smart Contracts gleichzeitig auszuführen und somit mehr CPU-Kerne für verbesserte Leistung zu nutzen.

Parallel Relay-Execution Distributed Architecture (PREDA) ist ein verteiltes, funktionales, auf den Funktionsumfang ausgerichtetes und hochrangiges Programmiermodell, das für von Natur aus parallelisierte allgemeine Smart Contracts in verteilten Multi-EVM-Blockchain-Systemen entwickelt wurde. Aus systemischer Sicht macht PREDA parallele EVMs zerlegbar und asynchron, was die vollständige Parallelisierbarkeit einer Vertragsfunktion ermöglicht und die Parallelität einer Reihe von Transaktionen maximiert. Dies gewährleistet, dass alle Instanzen von EVMs weitgehend genutzt werden können, um optimale Leistung und Skalierbarkeit zu erreichen.

Bevor wir uns in die Details stürzen, klären wir zunächst, auf was sich einige wichtige Begriffe in diesem Artikel beziehen:

Tx1= Transaktion 1

Tx2= Transaktion 2

Wir nehmen an,,

Die Ausführung von Tx1 muss den Zustand A, Zustand B, Zustand C ändern

Die Ausführung von Tx2 muss den Zustand A, den Zustand D, den Zustand E ändern

State-of-the-art Parallelisierungsmethoden für EVMs¹, wie sie von Sei, Aptos und Sui implementiert wurden, versuchen, alle Schritte in jeder Transaktion synchron auszuführen. Stellen Sie sich vor, Sie zoomen in eine einzelne Transaktionsszene, in diesen Systemen wird eine Transaktion innerhalb einer Blockhöhe ausgeführt, unabhängig von der Art der verstreuten Datenabhängigkeiten (d.h. Zugriff auf verschiedene Teile von Vertragszuständen). Wenn also ein Schritt der aufgerufenen Vertragszustände zwischen zwei Transaktionen gemeinsam genutzt oder aktualisiert wird, werden sie als Lese-Schreib- oder Schreib-Schreib-Konflikte identifiziert und können nicht parallel ausgeführt werden, was die Gesamtdurchsatzleistung und Skalierbarkeit des Systems behindert. Diese Situation verschlechtert sich erheblich, wenn die On-Chain-Aktivität plötzlich in die Höhe schießt.

PREDA verfolgt einen neuen und anderen Ansatz im Vergleich zu den oben genannten Systemen. Es übernimmt ein Smart-Vertragsausführungsmodell, das eine asynchrone Zerlegbarkeit implementiert, bei der Schritte einer Transaktion gemäß ihren Datenzugriffsabhängigkeiten zerlegt werden, wodurch Schritte asynchron ausgeführt werden können. Das PREDA-Ausführungsmodell führt zu einer größeren Effizienz und theoretisch unendlicher Skalierbarkeit. Wir werden genauer darauf eingehen, wie PREDA dies erreicht, und experimentelle Ergebnisse vorlegen, um diese Behauptung zu unterstützen.

2. Leistungsbewertung

Historische ETH-Token-Überweisungstransaktionen werden zur Bewertung von Sei (V2), Aptos, Sui und PREDA anhand von Durchsatz und Skalierbarkeit wiederholt. Beachten Sie, dass unsere Bewertung echte historische ETH-Token-Überweisungstransaktionen verwendet, anstatt eine Reihe von Überweisungstransaktionen zwischen zufälligen Adresspaaren zu erstellen. Zufällige Transaktionen würden ein experimentelles Ergebnis erzeugen, das die Leistung in realen Fällen übermäßig übersteigt, da Transaktionen in der realen Welt Adressen beinhalten, die auf die eine oder andere Weise miteinander verbunden sind und eine große Menge an Datenabhängigkeiten einführen.

Experimental Setups sind wie folgt:

Der Vergleich in Abbildung 1 unterstreicht die Notwendigkeit, das PREDA-Programmiermodell zu übernehmen, um signifikante Verbesserungen in der Durchsatzrate zu erzielen. PREDA zeigt 3,3X bis 28,2X höhere TPS als Aptos für echte historische Übertragungstransaktionen im Ethereum-Netzwerk.

Da diese Systeme in verschiedenen Sprachen (einschließlich Go, Rust und C++) und verschiedenen virtuellen Maschinen implementiert sind, bewerten wir die Skalierbarkeit verschiedener Systeme anhand des relativen Speedups gegenüber dem Ausgangspunkt der Verwendung eines einzelnen EVM, um den Einfluss unterschiedlicher Systemimplementierungen auszuschließen.

Abbildung 1. Die absoluten Durchsatzwerte in TPS der entsprechenden Token-Transfer-Smart-Verträge, die auf Sei, Aptos, Sui und PREDA ausgeführt werden.

Abbildung 2. Relative Geschwindigkeitssteigerungen für Aptos, Sui, Sei und PREDA gegenüber ihren eigenen Ausgangswerten

3. Das Programmiermodell

Um das Verständnis von PREDA für jeden zu erleichtern, der mit der parallelen EVM vertraut ist, gibt es in den heutigen parallelen EVM-Blockchain-Systemen¹ zwei typische Arten von Parallelisierungsmechanismen.

• Optimistische Parallelisierung, einschließlich Aptos, Sei (V2) und Monad, ignorieren Zustandsabhängigkeiten zwischen Transaktionen, führen Transaktionen gleichzeitig aus und validieren sie und rollen eine Transaktion für die erneute Ausführung bei Konflikt zurück.
• Pessimistische Parallelisierung, einschließlich Solana (Sealevel), Sui und Sei (V1), überprüft vor der Ausführung die Zustandsabhängigkeiten für jede Transaktion, analysiert ihre Zustandsabhängigkeiten und führt gleichzeitig nur diejenigen Transaktionen ohne Konflikte aus.

Beide Methoden folgen der Shared-everything-Architektur und behandeln eine Transaktion als Ganzes in der Nebenläufigkeitskontrolle. Alle Schritte (z.B. Zugriff auf verschiedene Vertragszustände) sind nicht zerlegbar und müssen synchron ausgeführt werden. Das PREDA-Modell schlägt vor,@devteam_48518/crystality-the-parallel-evm-model-implementierung-einer-shared-nothing-architektur-8d82fc0a836a">Shared-Nothing-Architektur, um Zustandsabhängigkeiten zu unterbrechen und sicherzustellen, dass verschiedene EVM-Instanzen niemals auf denselben Vertragszustand zugreifen, um Konflikte beim Schreiben vollständig zu vermeiden.

Im Kern führt PREDA programmierbare Vertragsbereiche ein, um den Vertragszustand in nicht überlappende, parallelisierbare Stücke mit feiner Granularität zu zerlegen, und asynchrones funktionales Relais, um den Ausführungsflusswechsel zwischen verschiedenen EVMs zu beschreiben.

Um diese Konzepte weiter zu erläutern, wird in PREDA eine Vertragsfunktion in mehrere geordnete Schritte zerlegt. Jeder Schritt verlässt sich auf einen einzigen parallelisierbaren Zustandsteil ohne Konflikte. Eine vom Benutzer initiierte Transaktion wird zuerst an eine EVM geleitet, die die Zustände der Benutzeradresse auf deterministische Weise hält, zum Beispiel durch Verwendung einer Methode zur Zuordnung von Benutzeradresse zu EVM. Während der Transaktionsausführung kann der Ausführungsfluss durch Ausgabe einer Weiterleitungstransaktion von einer EVM zu einer anderen wechseln, die die gewünschten Vertragszustände enthält. Auf diese Weise hält PREDA die Daten stationär, während der Ausführungsfluss je nach Datenabhängigkeiten zwischen EVMs verschoben wird.

Bei jeder EVM werden benutzerinitiierte und Weiterleitungs-Transaktionen sequentiell geordnet und ausgeführt, während Transaktionen auf verschiedenen EVMs gleichzeitig ausgeführt werden, da keine Datenabhängigkeiten zwischen den EVMs bestehen. Dieser Mechanismus vermeidet Konflikt-bezogene Wiederholungen in optimistischen Parallelisierungs-Methoden und den Bedarf an Laufzeit-Abhängigkeitsanalyse und Sperren-/Entsperren-Overhead in pessimistischen Parallelisierungs-Ansätzen. Daher bietet PREDA eine parallele und shared-nothing Architektur für die Blockchain-Systeme, die sich von der sequentiellen und shared-everything Architektur in Solidity und Move unterscheidet, die signifikante Konkurrenz-Kontroll-Overhead verursachen kann.

4. Die Sprache

Wir haben das PREDA-Programmiermodell als Algo-ähnliche Sprache implementiert, ähnlich wie C/C++ und Javascript. Im Folgenden finden Sie eine vereinfachte Token-Transferfunktion sowohl in Solidity als auch in der PREDA-Sprache.

Der Solidity-Code in Abbildung (a) enthält einen Vertragszustand (Guthaben), der Adressguthaben darstellt, und eine Transferfunktion, um eine bestimmte Anzahl von Tokens vom Transaktionssender (msg.sender) an einen Empfänger (Zahlungsempfänger) zu übertragen.

In der in Abbildung (b) dargestellten PREDA-Implementierung wird das Schlüsselwort 'gate' verwendet.@addressdefiniert programmierbare Vertragsbereiche, in denen Vertragszustände, die zu einer Vertragsvariablen (Balance) gehören, nach Adresse partitioniert und von EVMs verteilt und verwaltet werden. Das Stichwort Relais identifiziert ein asynchrones funktionales Relais.

Es gibt drei Teile in der PREDA-Implementierung. Im Teil (1) das Stichwort @addressdefiniert die Kontostände der Benutzer und stellt eine feinkörnige, trennbare Zustandsbeschreibung bereit. Die Adressbereichsvariable balance hat eine eindeutige Instanz für jede Benutzeradresse. Die Instanzen verschiedener Benutzeradressen werden von verschiedenen, nicht überlappenden EVMs aufgerufen und verwaltet. Die Transferfunktion ist im selben Adressbereich in Teil (2) definiert und wird aufgerufen, indem die Adresse des Zahlers als Zielbereich bereitgestellt wird, wenn ein Benutzer eine Überweisungstransaktion initialisiert. In Teil (3) wird zur Durchführung der Einzahlung beim Zahlungsempfänger nach einem erfolgreichen Abzug ein Relay mit der Adresse des Zahlungsempfängers als Zielbereich initiiert, indem Gelder zum Kontostand des Zahlungsempfängers hinzugefügt und von einem EVM ausgeführt werden, das die Instanz des Kontostands der Zahlungsempfängeradresse hostet.

Der Ausführungsablauf einer Token-Transfer-Transaktion in PREDA

Die obige Abbildung zeigt den Ausführungsfluss einer Token-Transfer-Transaktion im parallelen EVM-System von PREDA. Bob startet eine Transaktion, um die Transfer-Funktion aufzurufen, die an das EVM weitergeleitet wird, das Bobs Guthaben enthält, und die Auszahlung wird dort ausgeführt. Danach wird eine Relay-Transaktion ausgegeben und an das EVM weitergeleitet, das Alice's Guthaben enthält, und die Einzahlung wird ausgeführt. Die Parallelisierung erfolgt auf zwei Arten:

1. Zwischen benutzerinitiierten Transaktionen: Da die durch Adresse partitionierten Zustände nicht überlappend sind, können benutzerinitiierte Transaktionen ohne Konflikte parallel ausgeführt werden. Zum Beispiel können in einem Token-Transfer-Vertrag, der den Zustand des Zahlenden pro Adresse aktualisiert, verschiedene benutzerinitiierte Transaktionen über EVMs parallelisiert werden.
2. Mit Relay-Transaktionen: In einem Szenario, in dem Bob Tokens an Alice und Carol überweist, kann die Relay-Transaktion für die Einzahlung an Alice (vom Bob-an-Alice-Transfer) gleichzeitig mit der benutzerinitiierten Transaktion für die Auszahlung von Bob (im Bob-an-Carol-Transfer) und der Einzahlung an Carol ausgeführt werden. Nur mit der Zerlegbarkeit des PREDA-Modells kann die inhärente Parallelisierung in einem Smart Contract dem zugrunde liegenden Blockchain-System zugänglich gemacht werden, was eine pipelinierte Verarbeitung von benutzerinitiierten und Relay-Transaktionen ermöglicht und parallele Ausführung erleichtert.

Nächstes und Darüber hinaus

PREDA markiert einen großen Fortschritt in der Leistung und vor allem in der Skalierbarkeit der Blockchain. Durch die Implementierung von asynchroner Zerlegbarkeit ermöglicht es eine effiziente Transaktionsverarbeitung ohne die Engpässe herkömmlicher synchroner Parallelisierungsmodelle. Dieser Ansatz zerlegt Transaktionen in Mikrotransaktionen entsprechend den Datenabhängigkeiten, ermöglicht gleichzeitige Zustandsänderungen und vermeidet vollständig Schreibkonflikte.

Die Allgemeinheit von PREDA geht über die Verwendung von @addressdie Vertragszustände nach Adresse aufteilen. Es ermöglicht benutzerdefinierte Aufteilungstypen mit Schlüsselwörtern wie @type, wobei der Typ jede Solidity-Elementartypbezeichnung wie @uint. Darüber hinaus unterstützt PREDA nicht partitionierte Vertragszustände mit@globalund stellt sicher, dass jede EVM konsistente Werte für solche Zustände aufrechterhält. Diese Flexibilität bei der Zustandsteilung verbessert die Anpassungsfähigkeit und Effektivität des Modells in verschiedenen Smart Contracts.

Unsere Experimente zeigen, dass PREDA signifikant besser abschneidet als andere Parallelisierungsmethoden und eine höhere Durchsatz- und Skalierbarkeit erreicht. Die kommenden Artikel des PREDA-Teams werden sich weiterhin mit unseren Ergebnissen befassen und umfassendere Vergleiche mit verschiedenen Arten von Smart Contracts sowie eine eingehende Analyse des PREDA-Programmiermodells und der Sprache bieten. Bleiben Sie gespannt auf diese detaillierten Erkundungen.

Haftungsausschluss:

1. Dieser Artikel ist eine Neuveröffentlichung von [Medium]. Das Urheberrecht liegt beim ursprünglichen Autor, [PREDA Parallel VMs]. Wenn Sie Einwände gegen diese Wiederveröffentlichung haben, kontaktieren Sie bitte denGate Learn TeamDas Team wird Ihre Anliegen umgehend gemäß den relevanten Verfahren bearbeiten.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Das Gate Learn-Team hat den Artikel in andere Sprachen übersetzt. Das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel ist untersagt, es sei denn, es ist erwähnt.