Web3 Parallel Computing Track Panorama: Die beste Lösung für native Skalierung?

Autor: 0xjacobzhao und ChatGPT 4oDas

"Blockchain-Trilemma" von "Sicherheit", "Dezentralisierung" und "Skalierbarkeit" der Blockchain zeigt den wesentlichen Kompromiss beim Design von Blockchain-Systemen, das heißt, es ist für Blockchain-Projekte schwierig, gleichzeitig "extreme Sicherheit, jeder kann teilnehmen und eine Hochgeschwindigkeitsverarbeitung" zu erreichen. Als Reaktion auf das ewige Thema "Skalierbarkeit" sind die Mainstream-Blockchain-Skalierungslösungen auf dem Markt nach Paradigmen unterteilt, darunter:

• Ausführungsgestützte Skalierung: Verbessert die Ausführungsmöglichkeiten vor Ort, wie z. B. Parallelität, GPU und Multi-Core
• State-isolierte Skalierung: Horizontal geteilter Zustand/Shard, z. B. Shards, UTXO und Multi-Subnetze
• Off-Chain-ausgelagerte Skalierung: Ausführung außerhalb der Kette platzieren, z. B. Rollups,
• Skalierung der Coprozessor- und DA-Strukturentkopplung: Modulare Architektur und kollaborativer Betrieb, z. B. Modulkette, gemeinsam genutzter Sequenzer, Rollup-Mesh
• Asynchrone gleichzeitige Skalierung: Akteurmodell, Prozessisolation, nachrichtengesteuert, z. B. Agent, asynchrone Multithread-Kette

  Die Blockchain-Skalierungslösung umfasst: paralleles On-Chain-Computing, Rollup, Sharding, DA-Modul, modulare Struktur, Akteursystem, zk-Proof-Komprimierung, zustandslose Architektur usw., die mehrere Ausführungsebenen, Status, Daten und Struktur abdeckt und ein vollständiges Skalierungssystem für "mehrschichtige Zusammenarbeit und Modulkombination" ist. Dieser Artikel konzentriert sich auf Skalierungsmethoden, die paralleles Computing zum Mainstream machen.

  Intra-Chain-Parallelität, die sich auf die parallele Ausführung von Intra-Block-Transaktionen/-Anweisungen konzentriert. Gemäß dem parallelen Mechanismus können seine Skalierungsmethoden in fünf Kategorien unterteilt werden, von denen jede ein anderes Leistungsstreben, Entwicklungsmodell und Architekturphilosophie darstellt, und die parallele Granularität wird immer feiner, die Parallelitätsintensität wird immer höher, die Scheduling-Komplexität wird immer höher und die Programmierkomplexität und die Implementierungsschwierigkeit werden ebenfalls immer höher.

  • Kontoebene: Stellt das Projekt
  dar
  • Objektebene: Stellt das Projekt Sui
  • Transaction-Ebene: Stellt das Projekt Monad, Aptos
  • Call-Ebene / MicroVM dar : MegaETH auf Unterrichtsebene
  :
  • GatlingX

  Das Off-Chain-Modell der asynchronen Parallelität, dargestellt durch das Actor/Actor-Modell, gehört zu einem anderen parallelen Computing-Paradigma, als Cross-Chain/asynchrones Nachrichtensystem (Non-Block-Synchronisationsmodell), jeder Agent läuft unabhängig als "Agentenprozess", asynchrone Nachrichten im parallelen Modus, ereignisgesteuert, keine synchrone Zeitplanung, repräsentative Projekte wie AO, ICP, Cartesi, etc.

  Das bekannte Rollup- oder Shard-Skalierungsschema gehört zum Parallelitätsmechanismus auf Systemebene, nicht zum parallelen Computing innerhalb der Kette. Sie erreichen eine Skalierung, indem sie "mehrere Ketten/Ausführungsdomänen parallel ausführen", anstatt die Parallelität innerhalb eines einzelnen Blocks/virtuellen Computers zu erhöhen. Diese Art der Skalierungslösung steht nicht im Mittelpunkt dieses Artikels, aber wir werden sie dennoch verwenden, um die Ähnlichkeiten und Unterschiede in den Architekturkonzepten zu vergleichen.

  

  2. EVM Parallel Enhancement Chain: Die Leistungsgrenze in der Kompatibilität

  durchbrechen Seit der Entwicklung der seriellen Verarbeitungsarchitektur von Ethereum hat sie mehrere Runden von Skalierungsversuchen wie Sharding, Rollup und modulare Architektur durchlaufen, aber der Durchsatzengpass der Ausführungsschicht wurde immer noch nicht grundlegend durchbrochen. Aber gleichzeitig sind EVM und Solidity immer noch die Smart-Contract-Plattformen mit der größten Entwicklerbasis und dem größten ökologischen Potenzial. Daher wird die parallele EVM-Verbesserungskette zu einer wichtigen Richtung für eine neue Runde der Skalierung und Evolution als Schlüsselpfad, der die ökologische Kompatibilität und die Verbesserung der Ausführungsleistung berücksichtigt. Monad und MegaETH sind die repräsentativsten Projekte in dieser Richtung, beginnend mit der verzögerten Ausführung bzw. der Zustandszerlegung, um eine EVM-Parallelverarbeitungsarchitektur für Szenarien mit hoher Parallelität und hohem Durchsatz aufzubauen.

  Die parallele Computing-Analyse von MonadMonad

  ist eine Hochleistungs-Layer1-Blockchain, die für die Ethereum Virtual Machine (EVM) neu gestaltet wurde und auf dem grundlegenden parallelen Konzept des Pipelinings basiert, mit asynchroner Ausführung auf der Konsensschicht und optimistischer Parallelität auf der Ausführungsschicht Parallele Ausführung) 。 Darüber hinaus hat Monad auf der Konsens- und Speicherebene das Hochleistungs-BFT-Protokoll (MonadBFT) bzw. ein dediziertes Datenbanksystem (MonadDB) eingeführt, um eine End-to-End-Optimierung zu erreichen.

  Pipelining: Mehrstufiger Pipeline-Mechanismus für parallele Ausführung

  Pipelining ist das Grundkonzept der parallelen Ausführung von Monad, und seine Kernidee besteht darin, den Ausführungsprozess der Blockchain in mehrere unabhängige Phasen aufzuteilen und diese Phasen parallel zu verarbeiten, um eine dreidimensionale Pipeline-Architektur zu bilden, wobei jede Phase auf unabhängigen Threads oder Kernen ausgeführt wird, um eine blockübergreifende gleichzeitige Verarbeitung zu erreichen. Das Ergebnis ist ein erhöhter Durchsatz und eine geringere Latenz. Zu diesen Phasen gehören: Vorschlagen, Konsens, Ausführung und Commit.

  Asynchrone Ausführung: Konsens - Die Ausführung ist asynchron entkoppeltIn

  herkömmlichen Chains sind Transaktionskonsens und -ausführung oft synchrone Prozesse, und dieses serielle Modell schränkt die Leistungsskalierung stark ein. Monad implementiert die asynchrone Konsensschicht, die asynchrone Ausführungsschicht und die asynchrone Speicherebene durch "asynchrone Ausführung". Reduzieren Sie die Blockzeit und die Bestätigungslatenz erheblich, wodurch das System widerstandsfähiger wird, die Verarbeitung segmentierter wird und die Ressourcenauslastung steigt.

  Core-Design:

  Der
  • Konsensprozess (Konsensschicht) ist nur für die Sortierung von Transaktionen zuständig und führt keine Vertragslogik aus.
  • Der Ausführungsprozess (Ausführungsschicht) wird asynchron angestoßen, nachdem der Konsens abgeschlossen ist.
  • Nachdem der Konsens abgeschlossen ist, tritt er sofort in den Konsensprozess des nächsten Blocks ein, ohne auf den Abschluss der Ausführung zu warten.

  Optimistische parallele Ausführung: Optimistische parallele AusführungTraditionelles

  Ethereum verwendet ein streng serielles Modell für die Transaktionsausführung, um Zustandskonflikte zu vermeiden. Monad hingegen verfolgt eine Strategie der "optimistischen parallelen Ausführung", um die Geschwindigkeit der Transaktionsverarbeitung deutlich zu erhöhen.

  Ausführungsmechanismus:

  • Monad führt optimistisch alle Transaktionen parallel aus, wobei davon ausgegangen wird, dass die meisten Transaktionen zustandslos und konfliktfrei sind.
  • Führen Sie auch einen "Konfliktdetektor" aus, um zu überwachen, ob zwischen Transaktionen auf denselben Zustand (z. B. Lese-/Schreibkonflikte) zugegriffen wird.
  • Wenn ein Konflikt erkannt wird, wird die in Konflikt stehende Transaktion serialisiert und erneut ausgeführt, um sicherzustellen, dass der Status korrekt ist.

  Monad hat einen kompatiblen Weg gewählt: so wenige EVM-Regeln wie möglich zu verschieben, Parallelität zu erreichen, indem der Schreibzustand verzögert und Konflikte während der Ausführung dynamisch erkannt werden, was eher einer Performance-Version von Ethereum ähnelt, mit einem Reifegrad, der die Migration zum EVM-Ökosystem erleichtert, und ein paralleler Beschleuniger in der EVM-Welt ist.

  Die Auflösung des parallelen Rechenmechanismus von MegaETH

  unterscheidet sich von der L1-Positionierung von Monad, und MegaETH ist als EVM-kompatibler modularer Hochleistungs-Parallelausführungslayer positioniert, der als unabhängige L1-Public-Chain, als Ausführungsverbesserungsschicht oder modulare Komponente auf Ethereum verwendet werden kann. Das Hauptziel des Entwurfs besteht darin, die Kontologik, die Ausführungsumgebung und die Zustandsisolation in die kleinste Einheit zu zerlegen, die unabhängig voneinander geplant werden kann, um eine Ausführung mit hoher Parallelität und eine Reaktionsfähigkeit mit geringer Latenz innerhalb der Kette zu erreichen. Die von MegaETH vorgeschlagene Schlüsselinnovation besteht darin, dass die Micro-VM-Architektur + State Dependency DAG (Directed and Acyclic State Dependency Graph) und der modulare Synchronisationsmechanismus gemeinsam ein paralleles Ausführungssystem für "Intra-Chain-Threading" aufbauen.

  Micro-VM-Architektur: Konten sind Threads

  MegaETH führt das Ausführungsmodell "eine Micro-VM pro Konto" ein, das die Ausführungsumgebung "threads" und eine minimale Isolationseinheit für die parallele Planung bereitstellt. Diese VMs kommunizieren miteinander über asynchrones Messaging anstelle von synchronen Aufrufen, und eine große Anzahl von VMs kann unabhängig voneinander ausgeführt, unabhängig gespeichert und natürlich parallel gespeichert werden.

  DAG für Zustandsabhängigkeiten: ein diagrammgesteuerter Planungsmechanismus

  MegaETH hat ein DAG-Planungssystem entwickelt, das auf der Zugriffsbeziehung zwischen Kontostatus und Konto basiert, und das System verwaltet ein globales Abhängigkeitsdiagramm in Echtzeit, und welche Konten für jede Transaktion geändert und welche Konten gelesen werden, werden in Abhängigkeiten modelliert. Konfliktfreie Transaktionen können direkt parallel ausgeführt werden, und abhängige Transaktionen werden seriell geplant und sortiert oder in topologischer Reihenfolge zurückgestellt. Abhängigkeitsdiagramme stellen die Zustandskonsistenz und nicht doppelte Schreibvorgänge während der parallelen Ausführung sicher.

  Der

  asynchrone Ausführungs- und Callback-Mechanismus

  MegaETH baut auf dem asynchronen Programmierparadigma auf, ähnlich wie die asynchrone Nachrichtenweitergabe des Actor-Modells, um das Problem traditioneller serieller EVM-Aufrufe zu lösen. Vertragsaufrufe sind asynchron (nicht rekursive Ausführung), und wenn Vertrag A -> B -> C aufgerufen wird, ist jeder Aufruf asynchron, ohne das Warten zu blockieren. Die Aufrufliste wird zu einem asynchronen Aufrufdiagramm erweitert. Transaktionsverarbeitung = Durchlaufen eines asynchronen Graphen + Auflösung von Abhängigkeiten + parallele Planung.

  Alles in allem bricht MegaETH mit dem traditionellen EVM-Single-Thread-Zustandsmaschinenmodell, implementiert die Kapselung von Mikro-Virtual-Machine-Maschinen auf Konto-für-Konto-Basis, führt die Transaktionsplanung über zustandsabhängige Diagramme durch und ersetzt den synchronen Aufrufstapel durch einen asynchronen Messaging-Mechanismus. Es handelt sich um eine parallele Computing-Plattform, die von allen Dimensionen der "Kontostruktur→ der Planungsarchitektur → des Ausführungsprozesses neu gestaltet wurde und eine neue Idee auf Paradigmenebene für den Aufbau eines Hochleistungs-On-Chain-Systems der nächsten Generation bietet.

  MegaETH hat sich für den Refactoring-Weg entschieden: Es abstrahiert Konten und Verträge vollständig in unabhängige VMs und entfaltet das ultimative Parallelitätspotenzial durch asynchrone Ausführungsplanung. Theoretisch hat MegaETH eine höhere parallele Obergrenze, aber es ist auch schwieriger, die Komplexität zu kontrollieren, und es ähnelt eher einem superverteilten Betriebssystem nach dem Ethereum-Konzept.

  

  Monad und MegaETH Beide haben unterschiedliche Designkonzepte als Sharding: Sharding unterteilt die Blockchain horizontal in mehrere unabhängige Sub-Chains (Shards), von denen jede für einen Teil der Transaktionen und des Zustands verantwortlich ist, wodurch die Single-Chain-Begrenzung durchbrochen und auf der Netzwerkebene skaliert wird; Auf der anderen Seite behalten sowohl Monad als auch MegaETH die Integrität der einzelnen Kette bei, skalieren horizontal nur auf der Ausführungsschicht und führen parallel Optimierungsdurchbrüche an der Grenze der einzelnen Kette durch. Die beiden stehen für zwei Richtungen: die vertikale Stärkung und die horizontale Expansion auf dem Blockchain-Expansionspfad.

  Parallele Computing-Projekte wie Monad und MegaETH konzentrieren sich hauptsächlich auf den Weg zur Durchsatzoptimierung, mit dem Kernziel, On-Chain-TPS zu verbessern und eine parallele Verarbeitung auf Transaktions- oder Kontoebene durch verzögerte Ausführung und Mikro-VM-Architekturen zu erreichen. Pharos Network ist ein modulares, paralleles L1-Blockchain-Netzwerk mit vollem Stack, dessen Kernsystem als "Rollup Mesh" bezeichnet wird. Diese Architektur unterstützt Multi-Virtual-Machine-Umgebungen (EVM und Wasm) durch die Synergie von Mainnet und Special Processing Networks (SPNs) und integriert fortschrittliche Technologien wie Zero-Knowledge-Proofs (ZK) und Trusted Execution Environments (TEEs).

  Rollup Mesh Parallel Computing Analysis:

  1. Asynchronous Pipelining über den gesamten Lebenszyklus: Pharos entkoppelt die verschiedenen Phasen einer Transaktion (z. B. Konsens, Ausführung und Speicherung) und übernimmt die asynchrone Verarbeitung, sodass jede Phase unabhängig und parallel ausgeführt werden kann, wodurch die Gesamtverarbeitungseffizienz verbessert wird.
  2. Duale VM-Parallelausführung: Pharos unterstützt sowohl EVM- als auch WASM-Umgebungen für virtuelle Maschinen, sodass Entwickler die richtige Ausführungsumgebung für ihre Anforderungen auswählen können. Diese Dual-VM-Architektur erhöht nicht nur die Flexibilität des Systems, sondern erhöht auch die Transaktionsverarbeitung durch parallele Ausführung.
  3. Special Processing Networks (SPNs): SPNs sind Schlüsselkomponenten in der Pharos-Architektur, ähnlich wie modulare Subnetzwerke, die für bestimmte Arten von Aufgaben oder Anwendungen entwickelt wurden. Mit SPNs ermöglicht Pharos die dynamische Zuweisung von Ressourcen und die parallele Verarbeitung von Aufgaben, wodurch die Skalierbarkeit und Leistung des Systems weiter verbessert wird.
  4. Modularer Konsens und Wiederherstellung: Pharos führt einen flexiblen Konsensmechanismus ein, der mehrere Konsensmodelle (wie PBFT, PoS, PoA) unterstützt und eine sichere gemeinsame Nutzung und Ressourcenintegration zwischen dem Mainnet und SPNs über das Restaking Protocol ermöglicht.

  Darüber hinaus rekonstruiert Pharos das Ausführungsmodell von der untersten Schicht der Speicher-Engine durch Multi-Version-Merkle-Baum, Delta Encoding, Versioned Addressing und ADS Pushdown-Technologie und bringt Pharos Store auf den Markt, eine Hochleistungs-Speicher-Engine für die native Blockchain, um einen hohen Durchsatz, eine geringe Latenz und starke überprüfbare On-Chain-Verarbeitungsfunktionen zu erreichen.

  Im Allgemeinen erreicht die Rollup Mesh-Architektur von Pharos durch modulares Design und asynchrone Verarbeitungsmechanismen hochleistungsfähige parallele Rechenkapazitäten.

  Zusätzlich zu den parallelen Ausführungsarchitekturen von Monad, MegaETH und Pharos stellen wir auch fest, dass es einige Projekte auf dem Markt gibt, die den Anwendungspfad der GPU-Beschleunigung im parallelen EVM-Computing als wichtige Ergänzung und hochmodernes Experiment zum parallelen EVM-Ökosystem untersuchen. Unter ihnen sind Reddio und GatlingX zwei repräsentative Richtungen:

  • Reddio ist eine Hochleistungsplattform, die zkRollup und GPU Parallel Execution Architecture kombiniert, und ihr Kern liegt in der Rekonstruktion des EVM-Ausführungsprozesses und der Realisierung der nativen Parallelisierung der Ausführungsschicht durch Multithreaded Scheduling, asynchrone Zustandsspeicherung und GPU-beschleunigte Ausführung von Transaktionsbatches. Parallele Granularität auf Transaktionsebene + auf Betriebsebene (Multithreaded Execution Opcode). Es wurde entwickelt, um die Multithread-Batch-Ausführung, das asynchrone Laden des Zustands und die GPU-Parallelverarbeitungstransaktionslogik (CUDA-Compatible Parallel EVM) einzuführen. Wie Monad / MegaETH konzentriert sich auch Reddio auf die parallele Verarbeitung auf der Ausführungsschicht, mit dem Unterschied, dass die Ausführungs-Engine durch eine GPU-parallele Architektur rekonstruiert wird, die für hochdurchsatz- und rechenintensive Szenarien wie KI-Inferenz ausgelegt ist. GatlingX,
  • das sich selbst "GPU-EVM" nennt, schlägt eine radikalere Architektur vor, die versucht, das Modell der seriellen Ausführung auf Befehlsebene traditioneller virtueller EVM-Maschinen auf eine GPU-native parallele Laufzeitumgebung zu migrieren. Der Kernmechanismus besteht darin, den EVM-Bytecode dynamisch in parallele CUDA-Aufgaben zu kompilieren und den Befehlsstrom über die GPU Multi-Core auszuführen, um den sequenziellen Engpass der EVM auf der untersten Ebene zu durchbrechen. Parallele Granularität, die zu ILP (Instruction-Level Parallelism) gehört. Verglichen mit der parallelen Granularität von Monad / MegaETH auf "Transaktionsebene/Kontoebene" gehört der Parallelitätsmechanismus von GatlingX zum Optimierungspfad auf Instruktionsebene, der näher am zugrunde liegenden Refactoring der VM-Engine liegt. Es befindet sich derzeit in der Konzeptphase, mit einem veröffentlichten Whitepaper und einer Architekturskizze und noch keinem SDK oder Mainnet.

  Artela schlägt ein differenziertes, paralleles Designkonzept vor. Mit der Einführung der virtuellen Maschine WebAssembly (WASM) der EVM++-Architektur können Entwickler mithilfe des Aspect-Programmiermodells dynamisch Erweiterungen on-chain hinzufügen und ausführen, während die EVM-Kompatibilität erhalten bleibt. Er verwendet die Granularität des Vertragsaufrufs (Funktion/Erweiterung) als minimale parallele Einheit und unterstützt die Injektion von Erweiterungsmodulen (ähnlich wie bei "steckbarer Middleware"), wenn der EVM-Vertrag ausgeführt wird, um eine logische Entkopplung, einen asynchronen Aufruf und eine parallele Ausführung auf Modulebene zu erreichen. Besonderes Augenmerk wird auf die Composability und die modulare Architektur der Ausführungsschicht gelegt. Das Konzept liefert neue Ideen für komplexe mehrmodulige Anwendungen in der Zukunft.

  3. Native parallele Architekturkette: Das EVM-Ausführungsmodell von Ethereum, die Ausführungsontologie der rekonstruierten VM,

  hat seit Beginn seines Designs eine Single-Thread-Architektur von "vollständiger Transaktionsauftrag + serieller Ausführung" angenommen, die darauf abzielt, die Sicherheit und Konsistenz von Zustandsänderungen für alle Knoten im Netzwerk zu gewährleisten. Diese Architektur weist jedoch einen natürlichen Engpass bei der Leistung auf, der den Systemdurchsatz und die Skalierbarkeit einschränkt. Im Gegensatz dazu sind native parallele Computing-Architekturketten wie Solana (SVM), MoveVM (Sui, Aptos) und Sei v2, die auf dem Cosmos SDK basieren, auf die parallele Ausführung aus dem zugrunde liegenden Design zugeschnitten und haben die folgenden Vorteile:

  Natürliche
  • Trennung von Zustandsmodellen: Solana verwendet einen Deklarationsmechanismus für Kontosperren, MoveVM führt ein Objekteigentumsmodell ein und Sei v2 basiert auf der Klassifizierung von Transaktionstypen. Die statische Konfliktbeurteilung wird realisiert, und die gleichzeitige Planung auf Transaktionsebene wird unterstützt.
  • Virtuelle Maschinen sind für Parallelität optimiert: Die Sealevel-Engine von Solana unterstützt nativ die Multithread-Ausführung; MoveVM kann eine statische Parallelitätsdiagrammanalyse durchführen. Sei v2 integriert eine Multithread-Matching-Engine mit einem parallelen VM-Modul.

  Natürlich steht eine solche native Parallelkette auch vor der Herausforderung der ökologischen Verträglichkeit. Nicht-EVM-Architekturen erfordern in der Regel neue Entwicklungssprachen (wie Move und Rust) und Toolchains, die für Entwickler bestimmte Migrationskosten verursachen. Darüber hinaus müssen Entwickler eine Reihe neuer Konzepte beherrschen, z. B. zustandsbehaftete Zugriffsmodelle, Parallelitätsgrenzwerte, Objektlebenszyklen usw., die höhere Anforderungen an das Verständnis von Schwellenwerten und Entwicklungsparadigmen stellen.

  3.1 Das Sealevel-Parallelmotorprinzip von Solana und SVM

  Das Sealevel-Ausführungsmodell von Solana ist ein kontoparalleler Planungsmechanismus, der die Kern-Engine ist, die von Solana verwendet wird, um die Ausführung paralleler Transaktionen innerhalb der Kette zu realisieren, und der durch den Mechanismus "Kontodeklaration + statische Planung + Multithread-Ausführung" eine leistungsstarke Parallelität auf Smart-Contract-Ebene erreicht. Sealevel ist das erste Ausführungsmodell im Blockchain-Bereich, das erfolgreich Intra-Chain-Concurrent Scheduling in einer Produktionsumgebung implementiert hat, und seine Architekturideen haben viele nachfolgende parallele Computing-Projekte beeinflusst und sind ein Referenzparadigma für hochleistungsfähiges paralleles Layer-1-Design.

  Kernmechanismus:

  1. Explizite Kontozugriffslisten: Jede Transaktion muss das beteiligte Konto bei der Übermittlung deklarieren (Lese-/Schreibzugriff), und das System ermittelt, ob es einen Zustandskonflikt zwischen Transaktionen gibt.

  2. Konflikterkennung und Multithread-Scheduling

  • Wenn es keine Schnittmenge zwischen den Kontensätzen gibt, auf die die beiden Transaktionen zugreifen→ können sie parallel ausgeführt werden.
  • Es gibt einen Konflikt→ der seriell in abhängiger Reihenfolge ausgeführt wird.
  • Der Scheduler ordnet Transaktionen basierend auf dem Abhängigkeitsdiagramm verschiedenen Threads zu.

  3. Programmaufrufkontext: Jeder Vertragsaufruf wird in einem isolierten Kontext ohne gemeinsamen Stack ausgeführt, um Interferenzen zwischen Aufrufen zu vermeiden.

  Sealevel ist die parallele Ausführungsplanungs-Engine von Solana, während SVM eine Smart-Contract-Ausführungsumgebung ist, die auf Sealevel aufbaut (unter Verwendung der virtuellen BPF-Maschine). Zusammen bilden sie das technische Fundament des hochperformanten Parallel Execution Systems von Solana.

  Eclipse ist ein Projekt, das Solana-VMs auf modularen Chains wie Ethereum L2 oder Celestia bereitstellt und dabei die parallele Ausführungs-Engine von Solana als Rollup-Ausführungsschicht nutzt. Eclipse ist eines der ersten Projekte, das vorschlägt, die Solana-Ausführungsschicht (Sealevel + SVM) vom Solana-Mainnet zu lösen und auf eine modulare Architektur zu migrieren, und das modulare Ergebnis des "Super Concurrent Execution Model" von Solana ist Execution Layer-as-a-Service, so dass Eclipse auch zur Kategorie des parallelen Rechnens gehört.

  Die Route von Neon ist anders, sie führt die EVM für den Betrieb in einer SVM / Sealevel-Umgebung ein. Erstellen Sie eine EVM-kompatible Laufzeitschicht, Entwickler können Solidity verwenden, um Verträge zu entwickeln und in der SVM-Umgebung auszuführen, aber die Planungsausführung verwendet SVM + Sealeve. Neon tendiert eher zur Kategorie der modularen Blockchain als zur parallelen Computing-Innovation.

  Alles in allem verlassen sich Solana und SVMs auf die Sealevel-Ausführungs-Engine, und die OS-basierte Planungsphilosophie von Solana ähnelt dem Kernel-Scheduler, der schnell, aber relativ unflexibel ist. Es handelt sich um eine native öffentliche Hochleistungs-Kette für paralleles Computing.

  3.2 MoveVM-Architektur: Ressourcen- und objektgesteuert

  MoveVM ist eine virtuelle Smart-Contract-Maschine, die für die Sicherheit von On-Chain-Ressourcen und die parallele Ausführung entwickelt wurde, und ihre Kernsprache Move wurde ursprünglich von Meta (ehemals Facebook) für das Libra-Projekt entwickelt, wobei das Konzept "Ressourcen sind Objekte" betont wird, und alle On-Chain-Zustände existieren als Objekte mit klaren Eigentumsverhältnissen und Lebenszyklen. Auf diese Weise kann MoveVM analysieren, ob es während der Kompilierungszeit Zustandskonflikte zwischen Transaktionen gibt, und die statische parallele Planung auf Objektebene implementieren, die in nativen parallelen öffentlichen Ketten wie Sui und Aptos weit verbreitet ist.

  Das Objekteigentumsmodell von SuiDie

  parallelen Rechenfähigkeiten von Sui beruhen auf seinem einzigartigen Ansatz zur Zustandsmodellierung und statischen Analyse auf Sprachebene. Im Gegensatz zu herkömmlichen Blockchains, die globale Zustandsbäume verwenden, hat Sui ein objektzentriertes Modell auf der Grundlage des "Objekts" entwickelt, das mit dem linearen Typsystem von MoveVM zusammenarbeitet, um die parallele Planung zu einem deterministischen Prozess zu machen, der zur Kompilierzeit abgeschlossen werden kann.

  • Das Objektmodell ist die Grundlage der parallelen Architektur von Sui. Sui abstrahiert alle Zustände in der Kette in separate Objekte, jedes mit einer eindeutigen ID, einem eindeutigen Besitzer (Konto oder Vertrag) und einer Typdefinition. Diese Objekte haben keinen gemeinsamen Zustand und sind inhärent isoliert. Der Vertrag muss die Sammlung der beteiligten Objekte explizit deklarieren, wenn er aufgerufen wird, um das Zustandskopplungsproblem des traditionellen "globalen Zustandsbaums" auf der Kette zu vermeiden. Dieses Design teilt den On-Chain-Zustand in mehrere unabhängige Einheiten auf, wodurch die gleichzeitige Ausführung zu einer strukturell machbaren Planungsprämisse wird.
  • Die statische Besitzanalyse ist ein Analysemechanismus zur Kompilierzeit, der mit Unterstützung des linearen Typsystems der Move-Sprache implementiert wurde. Es ermöglicht dem System, die parallele Ausführung von Transaktionen zu planen, indem vor der Ausführung abgeleitet wird, welche Transaktionen keine Zustandskonflikte durch den Objektbesitz aufweisen. Im Vergleich zur Konflikterkennung und zum Rollback herkömmlicher Laufzeiten reduziert der statische Analysemechanismus von Sui die Planungskomplexität erheblich und verbessert gleichzeitig die Ausführungseffizienz, was der Schlüssel zum Erreichen eines hohen Durchsatzes und deterministischer paralleler Verarbeitungsfunktionen ist.

  Sui unterteilt den Zustandsraum objektweise, kombiniert mit einer Kompilierzeit-Besitzanalyse, um eine kostengünstige, Rollback-freie parallele Ausführung auf Objektebene zu erreichen. Im Vergleich zur seriellen Ausführung oder Laufzeiterkennung herkömmlicher Ketten hat Sui signifikante Verbesserungen bei der Ausführungseffizienz, dem Systemdeterminismus und der Ressourcennutzung erzielt.

  Aptos' Block-STM Execution

  MechanismAptos ist eine hochperformante Layer1-Blockchain, die auf der Sprache Move basiert und deren parallele Ausführungsfähigkeit hauptsächlich aus dem selbst entwickelten Block-STM (Block-level Software Transactional Memory) Framework abgeleitet ist. Im Gegensatz zu Suis Strategie der "statischen Parallelität zur Kompilierzeit" gehört Block-STM zum dynamischen Scheduling-Mechanismus der "optimistischen Parallelität zur Laufzeit + Konflikt-Rollback", der sich für den Umgang mit Transaktionsmengen mit komplexen Abhängigkeiten eignet.

  Block-STM unterteilt die Transaktionsausführung eines Blocks in drei Phasen:

  • Spekulative Ausführung: Alle Transaktionen sind standardmäßig vor der Ausführung konfliktfrei, und das System plant Transaktionen parallel zu mehreren Threads, um zu versuchen, gleichzeitig ausgeführt zu werden, und zeichnet den Kontostatus (Lese-/Schreibsatz) auf, auf den sie zugegriffen haben.
  • Validierungsphase: Das System überprüft das Ausführungsergebnis: Wenn es einen Lese-/Schreibkonflikt zwischen zwei Transaktionen gibt (z. B. liest Tx1 den Status, von Tx2 geschrieben zu werden), wird für eine von ihnen ein Rollback ausgeführt.
  • Wiederholungsphase: In Konflikt stehende Transaktionen werden neu geplant, bis ihre Abhängigkeiten aufgelöst sind und schließlich alle Transaktionen eine gültige, deterministische Sequenz von Zustandsübermittlungen bilden.

  Block-STM ist ein dynamisches Ausführungsmodell mit "optimistischer Parallelität + Rollback und Wiederholungen", das sich für zustandsintensive und logisch komplexe On-Chain-Transaktions-Batch-Verarbeitungsszenarien eignet und den parallelen Computing-Kern für Aptos bildet, um eine öffentliche Chain mit hoher Vielseitigkeit und hohem Durchsatz aufzubauen.

  

  Solana ist eine Ingenieursplanungsschule, eher wie ein "Betriebssystem-Kernel", geeignet für klare Staatsgrenzen, kontrollierbaren Hochfrequenzhandel, ist ein Hardware-Ingenieur-Stil, um die Kette wie Hardware auszuführen (parallele Ausführung auf Hardware-Niveau); Aptos ist ein System Fault Tolerant, eher eine "Datenbank-Nebenläufigkeits-Engine", geeignet für Vertragssysteme mit starker Zustandskopplung und komplexen Aufrufketten. Aptos und Sui sind wie Programmierspracheningenieure, und die Ressourcensicherheit in Softwarequalität stellt den technischen Implementierungspfad des parallelen Web3-Computings unter unterschiedlichen Philosophien dar.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 ist eine hochleistungsfähige transaktionale öffentliche Chain, die auf dem Cosmos SDK basiert, und ihre Parallelitätsfähigkeit spiegelt sich hauptsächlich in zwei Aspekten wider: der Multithreaded Matching Engine (Parallel Matching Engine) und der Optimierung der parallelen Ausführung der virtuellen Maschinenschicht, die für On-Chain-Transaktionsszenarien mit hoher Frequenz und geringer Latenz ausgelegt ist, wie z. B. Orderbuch-DEX. On-Chain-Exchange-Infrastruktur usw.

  Core Parallelism Mechanism:

  1. Parallel Matching Engine: SEI V2 führt einen Multi-Thread-Ausführungspfad in die Order-Matching-Logik ein, der das Pending-Orderbuch und die Matching-Logik auf Thread-Ebene aufteilt, so dass die Matching-Aufgaben zwischen mehreren Handelspaaren parallel verarbeitet werden können und der Single-Thread-Engpass vermieden wird.
  2. Parallelitätsoptimierung auf VM-Ebene: Sei V2 erstellt eine CosmWasm-Laufzeitumgebung mit Funktionen für die gleichzeitige Ausführung, die die parallele Ausführung einiger Vertragsaufrufe ohne Zustandskonflikte ermöglicht, und arbeitet mit dem Klassifizierungsmechanismus für Transaktionstypen zusammen, um eine höhere Durchsatzsteuerung zu erreichen.
  3. Parallele Konsens- und Ausführungsschichtplanung: Der sogenannte "Twin-Turbo"-Konsensmechanismus wird eingeführt, um den Durchsatz und die Entkopplung zwischen der Konsensschicht und der Ausführungsschicht zu stärken und die Gesamteffizienz der Blockverarbeitung zu verbessern.

  3.4 UTXO-Modell Reformer Fuel Fuel

  ist eine Hochleistungs-Ausführungsschicht, die auf der modularen Architektur von Ethereum basiert, und ihr zentraler Parallelitätsmechanismus leitet sich vom verbesserten UTXO-Modell (Unspent Transaction Output) ab. Im Gegensatz zum Kontomodell von Ethereum verwendet Fuel eine UTXO-Struktur zur Darstellung von Vermögenswerten und Staaten, die von Natur aus zustandsisoliert ist, sodass leicht zu bestimmen ist, welche Transaktionen sicher parallel ausgeführt werden können. Darüber hinaus führt Fuel seine selbst entwickelte Smart-Contract-Sprache Sway (ähnlich wie Rust) in Kombination mit statischen Analysetools ein, um Eingabekonflikte vor der Ausführung von Transaktionen zu ermitteln und so ein effizientes und sicheres paralleles Scheduling auf Transaktionsebene zu erreichen. Es handelt sich um eine EVM-Alternative Ausführungsschicht, die Leistung und Modularität in Einklang bringt.

  4. Akteurmodell: Ein neues Paradigma der gleichzeitigen Ausführung

  von Agenten Das Akteurmodell ist ein paralleles Ausführungsparadigma, das auf einem Agenten oder Prozess basiert und sich vom traditionellen synchronen Berechnen des globalen Zustands auf der Kette (Solana/Sui/Monad und andere "parallele On-Chain-Computing"-Szenarien unterscheidet), das betont, dass jeder Agent einen unabhängigen Zustand und ein unabhängiges Verhalten hat und über asynchrone Nachrichten kommuniziert und plant. Unter dieser Architektur kann das On-Chain-System von einer großen Anzahl von Prozessen gleichzeitig ausgeführt werden, die voneinander entkoppelt sind, und verfügt über eine starke Skalierbarkeit und asynchrone Fehlertoleranz. Zu den repräsentativen Projekten gehören AO (Arweave AO), ICP (Internet Computer) und Cartesi, die die Entwicklung der Blockchain von einer Ausführungs-Engine zu einem "On-Chain-Betriebssystem" vorantreiben und eine native Infrastruktur für KI-Agenten, Multi-Task-Interaktionen und komplexe Logikorchestrierung bereitstellen.

  Während das Design des Akteurmodells in Bezug auf oberflächliche Merkmale (z. B. Parallelität, Zustandsisolierung und asynchrone Verarbeitung) dem Sharding ähnelt, stellen die beiden im Wesentlichen völlig unterschiedliche technische Pfade und Systemphilosophien dar. Das Akteurmodell legt den Schwerpunkt auf "asynchrones Rechnen mit mehreren Prozessen", bei dem jeder Agent unabhängig ausgeführt wird, den Zustand unabhängig voneinander beibehält und auf nachrichtengesteuerte Weise interagiert. Sharding hingegen ist ein "horizontales Sharding von Staat und Konsens"-Mechanismus, der die gesamte Blockchain in mehrere Subsysteme (Shards) aufteilt, die Transaktionen unabhängig voneinander verarbeiten. Akteurmodelle ähneln in der Web3-Welt eher einem "verteilten Agenten-Betriebssystem", während Sharding eine strukturelle Skalierungslösung für On-Chain-Transaktionsverarbeitungsfunktionen ist. Beide erreichen Parallelität, haben aber unterschiedliche Ausgangspunkte, Ziele und Ausführungsarchitekturen.

  4.1 AO (Arweave), ein superparalleler Computer auf der SpeicherschichtAO

  ist eine dezentrale Computing-Plattform, die auf der permanenten Speicherschicht von Arweave läuft, mit dem Kernziel, ein On-Chain-Betriebssystem aufzubauen, das den Betrieb großer asynchroner Agenten unterstützt.

  Kernfunktionen der Architektur:

  • Prozessarchitektur: Jeder Agent wird als Prozess bezeichnet, mit unabhängigem Status, unabhängigem Scheduler und Ausführungslogik.
  • Keine Blockchain-Struktur: AO ist keine Kette, sondern eine dezentrale Speicherschicht + Multi-Agent Message-driven Execution Engine auf Basis von Arweave;
  • Asynchrones Nachrichtenplanungssystem: Prozesse kommunizieren über Nachrichten miteinander, übernehmen ein sperrfreies asynchrones Betriebsmodell und unterstützen auf natürliche Weise die gleichzeitige Erweiterung.
  • Permanente Zustandsspeicherung: Alle Agentenzustände, Nachrichtendatensätze und Anweisungen werden dauerhaft auf Arweave aufgezeichnet, um vollständige Überprüfbarkeit und dezentrale Transparenz zu gewährleisten.
  • Agent-nativ: Es eignet sich für die Bereitstellung komplexer mehrstufiger Aufgaben (z. B. KI-Agenten, DePIN-Protokoll-Controller, automatische Task-Orchestratoren usw.) und kann einen "On-Chain-KI-Coprozessor" erstellen.

  AO wählt den ultimativen Weg von "Agent Native + Storage Driver + Chainless Architecture", wobei der Schwerpunkt auf Flexibilität und Modulentkopplung liegt, und ist ein "Mikrokernel-Framework auf der Kette, das auf der Speicherschicht aufbaut", wobei die Systemgrenze bewusst verkleinert wird, wobei Lightweight Computing + Composable Control Structure im Vordergrund steht.

  4.2 ICP (Internet Computer), eine Full-Stack-Web3-Hosting-PlattformICP

  ist eine Web3-native Full-Stack-On-Chain-Anwendungsplattform, die von DFINITY mit dem Ziel eingeführt wurde, die On-Chain-Rechenleistung auf Web2-ähnliche Erfahrungen zu erweitern und vollständiges Service-Hosting, Domain Name Binding und Serverless-Architektur zu unterstützen.

  Kernfunktionen der Architektur:

  • Canister-Architektur (Container als Agenten): Jeder Canister ist ein Agent, der auf einer Wasm-VM mit unabhängigen Status-, Code- und asynchronen Planungsfunktionen ausgeführt wird.
  • Subnet Distributed Consensus System (Subnetz): Das gesamte Netzwerk besteht aus mehreren Subnetzen, von denen jedes einen Satz von Behältern verwaltet und den Konsens über den BLS-Signaturmechanismus erreicht.
  • Asynchrones Aufrufmodell: Canister kommuniziert mit Canister über asynchrone Nachrichten, unterstützt die nicht blockierende Ausführung und verfügt über natürliche Parallelität.
  • On-Chain-Webhosting: Es unterstützt Smart Contracts zum direkten Hosten von Frontend-Seiten, natives DNS-Mapping und ist die erste Blockchain-Plattform, die Browser für den direkten Zugriff auf dApps unterstützt;
  • Das System verfügt über vollständige Funktionen: Es verfügt über System-APIs wie On-Chain-Hot-Upgrade, Identitätsauthentifizierung, verteilte Zufälligkeit und Timer, der für die Bereitstellung komplexer On-Chain-Dienste geeignet ist.

  ICP wählt ein Betriebssystemparadigma mit starker Plattform, integrierter Paketierung und starker Plattformkontrolle und verfügt über ein "Blockchain-Betriebssystem", das Konsens, Ausführung, Speicherung und Zugriff integriert, vollständige Service-Hosting-Funktionen betont und die Systemgrenze zu einer Full-Stack-Web3-Hosting-Plattform erweitert.

  Darüber hinaus können die parallelen Computing-Projekte anderer Akteursmodell-Paradigmen auf die folgende Tabelle bezogen werden:

  

  5. Zusammenfassung und AusblickBasierend

  auf den Unterschieden zwischen der Architektur virtueller Maschinen und dem Sprachsystem können Blockchain-Parallel-Computing-Lösungen grob in zwei Kategorien unterteilt werden: EVM Parallel Enhancement Chain und Native Parallel Architecture Chain (Non-EVM).

  Auf der Grundlage der Beibehaltung der Kompatibilität des EVM/Solidity-Ökosystems erreicht ersteres einen höheren Durchsatz und parallele Verarbeitungsfähigkeiten durch eine tiefgreifende Optimierung der Ausführungsschicht, die sich für Szenarien eignet, die Ethereum-Assets und Entwicklungstools erben und gleichzeitig Leistungsdurchbrüche erzielen wollen. Zu den repräsentativen Projekten gehören:

  • Monad: Implementiert ein optimistisches paralleles Ausführungsmodell, das mit EVM kompatibel ist, durch verzögerte Schreib- und Laufzeitkonflikterkennung, erstellt Abhängigkeitsdiagramme und plant die Ausführung nach Abschluss des Konsenses.
  • MegaETH: Abstrahiert jedes Konto/jeden Vertrag in eine unabhängige Micro-VM und implementiert eine hochgradig entkoppelte parallele Planung auf Kontoebene, die auf asynchronem Messaging und zustandsabhängigen Diagrammen basiert.
  • Pharos: Erstellen Sie eine Rollup-Mesh-Architektur, um eine parallele Verarbeitung auf Systemebene über Prozesse hinweg über asynchrone Pipelines und SPN-Module zu erreichen.
  • Reddio: Verwendet die zkRollup + GPU-Architektur, um den Off-Chain-Verifizierungsprozess von zkEVM durch Batch-SNARK-Generierung zu beschleunigen und den Verifizierungsdurchsatz zu verbessern.

  Letzteres beseitigt die Einschränkungen der Kompatibilität von Ethereum vollständig und gestaltet das Ausführungsparadigma von der virtuellen Maschine, dem Zustandsmodell und dem Planungsmechanismus neu, um eine native Hochleistungsparallelität zu erreichen. Zu den typischen Unterklassen gehören:

  • Solana (SVM): ein paralleles Ausführungsmodell auf Kontoebene, das auf Kontozugriffsansprüchen und der Planung statischer Konfliktdiagramme basiert;
  • Sui / Aptos (MoveVM-System): Basierend auf dem Ressourcenobjektmodell und dem Typsystem unterstützt es die statische Analyse zur Kompilierzeit und realisiert Parallelität auf Objektebene.
  • Sei V2 (Cosmos SDK-Route): Führt eine Multithread-Matching-Engine und die Parallelitätsoptimierung virtueller Computer in der Cosmos-Architektur ein, die für transaktionale Hochfrequenzanwendungen geeignet ist.
  • Fuel (UTXO + Sway-Architektur): Parallelität auf Transaktionsebene durch statische Analyse des UTXO-Eingabesatzes, Kombination einer modularen Ausführungsschicht mit einer angepassten Smart-Contract-Sprache Sway;

  Darüber hinaus baut das Akteurmodell als allgemeineres paralleles System ein On-Chain-Ausführungsparadigma von "Multi-Agent-unabhängiger Betrieb + nachrichtengesteuerter Zusammenarbeit" durch einen asynchronen Prozessplanungsmechanismus auf, der auf Wasm oder benutzerdefinierten VMs basiert. Zu den repräsentativen Projekten gehören:

  • AO (Arweave AO): Aufbau eines asynchronen On-Chain-Mikrokernelsystems basierend auf der persistenten speichergesteuerten Agentenlaufzeit;
  • ICP (Internet Computer): verwendet den containerisierten Agenten (Canister) als kleinste Einheit, um eine asynchrone und hochgradig skalierbare Ausführung durch Subnetzkoordination zu erreichen.
  • Cartesi: Führt das Linux-Betriebssystem als Off-Chain-Computing-Umgebung ein, um einen On-Chain-Verifizierungspfad für vertrauenswürdige Computing-Ergebnisse bereitzustellen, der für komplexe oder ressourcenintensive Anwendungsszenarien geeignet ist.

  Basierend auf der obigen Logik können wir das aktuelle Mainstream-Schema für die öffentliche Kette des parallelen Rechnens in einer Klassifizierungsstruktur zusammenfassen, wie in der folgenden Abbildung gezeigt:

  

  Aus einer breiteren Skalierungsperspektive konzentrieren sich Sharding und Rollup (L2) auf horizontale Skalierung durch State-Sharding oder Off-Chain-Ausführung, während parallele Computing-Ketten (z. B. Monad, Sui, Solana) und akteursorientierte Systeme (z. B. AO, ICP) das Ausführungsmodell direkt rekonstruieren und native Parallelität innerhalb der Kette oder auf der Systemebene erreichen. Ersteres verbessert den Intra-Chain-Durchsatz durch Multithread-VMs, Objektmodelle, Transaktionskonfliktanalysen usw.; Letzteres verwendet den Prozess/Agenten als Basiseinheit und verwendet nachrichtengesteuerte und asynchrone Ausführungsmodi, um einen gleichzeitigen Betrieb mit mehreren Agenten zu erreichen. Im Gegensatz dazu sind Sharding und Rollups eher wie das "Aufteilen der Last auf mehrere Ketten" oder das "Outsourcing außerhalb der Kette", während das parallele Ketten- und Akteursmodell "das Leistungspotenzial der Ausführungs-Engine selbst freisetzt", was eine gründlichere architektonische Entwicklung widerspiegelt.

  Paralleles Rechnen vs. Sharding-Architektur vs. Rollup-Skalierung vs. aktororientierter Skalierungspfad Vergleich

  

  Es sollte darauf hingewiesen werden, dass die meisten der nativen Chains mit paralleler Architektur in die Startphase des Mainnets eingetreten sind, obwohl das gesamte Entwickler-Ökosystem immer noch schwer mit dem Solidity-System des EVM-Systems zu vergleichen ist, aber die von Solana und Sui vertretenen Projekte mit ihrer leistungsstarken Ausführungsarchitektur und dem allmählichen Wohlstand ökologischer Anwendungen sind zu den wichtigsten öffentlichen Chains geworden, denen der Markt große Aufmerksamkeit schenkt.

  Im Gegensatz dazu befindet sich das Ethereum Rollup (L2)-Ökosystem zwar in der Phase von "10.000 Chains auf einmal" oder sogar "Überkapazität", aber die aktuelle Mainstream-EVM-Parallelerweiterungskette befindet sich im Allgemeinen noch in der Testnet-Phase und wurde noch nicht von der eigentlichen Mainnet-Umgebung verifiziert, und ihre Skalierungsfähigkeit und Systemstabilität müssen noch weiter getestet werden. Es bleibt abzuwarten, ob diese Projekte die EVM-Leistung deutlich verbessern und ökologische Sprünge machen können, ohne die Kompatibilität zu beeinträchtigen, oder ob sie die Liquidität und die Entwicklungsressourcen von Ethereum weiter differenzieren können.