Carte panoramique du secteur du calcul parallèle Web3 : la meilleure solution d'extensibilité native ?

I. Contexte et aperçu

Le "trilemme" de la blockchain (Blockchain Trilemma) met en lumière les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle et un traitement rapide". En ce qui concerne le sujet éternel de "l'évolutivité", les solutions d'extension de blockchain actuellement sur le marché sont classées selon des paradigmes, y compris :

• Exécution d'une extension améliorée : augmenter la capacité d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Isolation de l'état de type extensible : partitionnement horizontal de l'état / Shard, par exemple le sharding, UTXO, plusieurs sous-réseaux
• Extensibilité par externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Extension de capacité asynchrone et concurrente : Modèle Actor, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread.

Les solutions d'extension de blockchain comprennent : le calcul parallèle sur la chaîne, Rollup, le sharding, les modules DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système d'extension complet « multi-niveaux et combinatoire de modules ». Cet article se concentre sur les méthodes d'extension principalement basées sur le calcul parallèle.

Calcul parallèle intra-chaîne (intra-chain parallelism), se concentre sur l'exécution parallèle des transactions / instructions au sein des blocs. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec une granularité de parallélisme de plus en plus fine, une intensité de parallélisme de plus en plus élevée, une complexité de planification également croissante, ainsi qu'une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.

• Parallélisme au niveau du compte (Account-level) : représente le projet Solana
• Parallélisme au niveau des objets : représente le projet Sui
• Parallélisme au niveau des transactions (Transaction-level) : représente le projet Monad, Aptos
• Niveau d'appel / Micro VM parallèle (Call-level / MicroVM) : représente le projet MegaETH
• Parallélisme au niveau des instructions (Instruction-level) : représente le projet GatlingX

Modèle de concurrence asynchrone hors chaîne, représenté par le système d'agents (Agent / Actor Model), qui appartient à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes / asynchrones (modèle de synchronisation non blockchain), chaque agent fonctionnant comme un "processus d'agent intelligent" indépendant, utilisant des messages asynchrones en parallèle, piloté par des événements, sans nécessiter de planification synchronisée, les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que Rollup ou le sharding, appartiennent aux mécanismes de concurrence au niveau du système et ne relèvent pas du calcul parallèle au sein de la chaîne. Elles réalisent l'extension en "exécutant plusieurs chaînes / domaines d'exécution en parallèle", et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ces solutions d'extension ne sont pas le point principal de cet article, mais nous allons néanmoins les utiliser pour comparer les similarités et les différences des concepts d'architecture.

II. Chaîne d'amélioration parallèle EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, subissant plusieurs tentatives d'extension telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement du débit au niveau d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents les plus soutenues par les développeurs et avec le plus de potentiel écologique. Par conséquent, les chaînes parallèles basées sur l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la nouvelle évolution d'expansion. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle EVM orientée vers des scénarios à haute concurrence et à haut débit, respectivement à partir de l'exécution différée et de la décomposition des états.

Analyse du mécanisme de calcul parallèle de Monad

Monad est une blockchain de Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining), avec une exécution asynchrone au niveau du consensus (Asynchronous Execution) et une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau de l'exécution. De plus, au niveau du consensus et du stockage, Monad introduit respectivement un protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB), réalisant une optimisation de bout en bout.

Pipelining : Mécanisme d'exécution parallèle en plusieurs étapes

Le pipelining est le principe fondamental de l'exécution parallèle des Monads. Son idée maîtresse est de décomposer le processus d'exécution de la blockchain en plusieurs phases indépendantes et de traiter ces phases en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent à travers les blocs et atteignant finalement l'objectif d'améliorer le débit et de réduire la latence. Ces phases comprennent : proposition de transaction (Propose), atteinte de consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

Exécution Asynchrone : Consensus - Exécution Découplée Asynchrone

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce modèle en série limite gravement l'évolutivité des performances. Monad a réalisé un consensus asynchrone, une exécution asynchrone et un stockage asynchrone grâce à "l'exécution asynchrone". Cela réduit considérablement le temps de bloc (block time) et le délai de confirmation, rendant le système plus résilient, le processus de traitement plus segmenté et l'utilisation des ressources plus efficace.

Conception principale :

• Le processus de consensus (couche de consensus) ne s'occupe que du tri des transactions, sans exécuter la logique des contrats.
• Le processus d'exécution (couche d'exécution) est déclenché de manière asynchrone après l'achèvement du consensus.
• Une fois le consensus atteint, le processus de consensus du bloc suivant commence immédiatement, sans attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

L'Ethereum traditionnel utilise un modèle d'exécution strictement sériel pour éviter les conflits d'état. En revanche, Monad adopte une stratégie "d'exécution parallèle optimiste", ce qui augmente considérablement le taux de traitement des transactions.

Mécanisme d'exécution :

• Monad exécutera de manière optimiste toutes les transactions en parallèle, en supposant qu'il n'y a pas de conflits d'état entre la plupart des transactions.
• Exécutez également un "Détecteur de Conflits (Conflict Detector))" pour surveiller si les transactions accèdent au même état (comme les conflits de lecture / écriture).
• En cas de détection de conflit, les transactions conflictuelles seront réexécutées en série pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, il réalise le parallélisme en retardant l'écriture des états et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un accélérateur parallèle pour le monde EVM.

Analyse du mécanisme de calcul parallèle de MegaETH

Contrairement au positionnement L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulaire haute performance compatible avec l'EVM, pouvant fonctionner à la fois comme une chaîne publique L1 indépendante et comme une couche d'amélioration de l'exécution (Execution Layer) ou un composant modulaire sur Ethereum. Son objectif de conception central est de décomposer la logique de compte, l'environnement d'exécution et l'état en unités minimales pouvant être programmées de manière indépendante, afin de réaliser une exécution hautement concurrente au sein de la chaîne et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans l'architecture Micro-VM + State Dependency DAG (graphique de dépendance d'état acyclique) et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle axé sur "la threadisation au sein de la chaîne".

Architecture Micro-VM (micro machine virtuelle) : le compte est un fil

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte", qui "thréadise" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter de manière indépendante et de stocker de manière indépendante, ce qui est intrinsèquement parallèle.

DAG de dépendance d'état : Mécanisme de planification basé sur un graphique de dépendance

MegaETH a construit un système de planification basé sur un DAG (Directed Acyclic Graph) qui accède aux relations d'état des comptes. Le système maintient en temps réel un graphique de dépendance global, modélisant toutes les transactions qui modifient ou lisent des comptes en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle, tandis que celles avec des relations de dépendance seront planifiées et ordonnées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit la cohérence d'état et l'absence d'écritures répétées durant le processus d'exécution parallèle.

Exécution asynchrone et mécanisme de rappel

B

En résumé, MegaETH rompt avec le modèle traditionnel de machine d'état monothread EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en utilisant un graphe de dépendance d'état pour la planification des transactions, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, passant de "structure de compte → architecture de planification → flux d'exécution", offrant une nouvelle approche de niveau paradigmatique pour construire le système en ligne haute performance de prochaine génération.

MegaETH a choisi un chemin de reconstruction : en abstrait complètement les comptes et les contrats en une VM indépendante, en libérant un potentiel de parallélisme extrême grâce à une planification d'exécution asynchrone. Théoriquement, la limite de parallélisme de MegaETH est plus élevée, mais il est également plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.

Monad et MegaETH ont des philosophies de conception très différentes de celles du sharding : le sharding divise la blockchain horizontalement en plusieurs chaînes indépendantes (shards), chaque chaîne étant responsable d'une partie des transactions et de l'état, brisant ainsi les limitations d'une seule chaîne pour l'expansion au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, s'étendant horizontalement uniquement au niveau de l'exécution, optimisant l'exécution parallèle au sein de la chaîne unique pour améliorer les performances. Les deux représentent des directions de renforcement vertical et d'expansion horizontale dans le chemin d'expansion de la blockchain.

Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec pour objectif principal d'améliorer le TPS sur la chaîne, en réalisant un traitement parallèle au niveau des transactions ou des comptes grâce à l'exécution différée (Deferred Execution) et à l'architecture de micro-VM (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a pour mécanisme de calcul parallèle central ce que l'on appelle "Rollup Mesh". Cette architecture, grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-VM (EVM et Wasm) et intègre des technologies avancées telles que les preuves à connaissance nulle (ZK) et les environnements d'exécution de confiance (TEE).

Analyse du mécanisme de calcul parallèle Rollup Mesh :

1. Traitement asynchrone en pipeline sur l'ensemble du cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes étapes des transactions (comme le consensus, l'exécution, le stockage) et adopte une méthode de traitement asynchrone, permettant à chaque étape de se dérouler indépendamment et en parallèle, ce qui augmente l'efficacité globale du traitement.
2. Exécution parallèle de double machine virtuelle (Dual VM Parallel Execution) : Pharos prend en charge deux environnements de machine virtuelle, EVM et WASM, permettant aux développeurs de choisir l'environnement d'exécution approprié en fonction de leurs besoins. Cette architecture à double VM améliore non seulement la flexibilité du système, mais augmente également la capacité de traitement des transactions grâce à l'exécution parallèle.
3. Réseaux de traitement spécial (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, similaires à des sous-réseaux modulaires, spécialement conçus pour traiter des types spécifiques de tâches ou d'applications. Grâce aux SPNs, Pharos peut réaliser une allocation dynamique des ressources et un traitement parallèle des tâches, ce qui renforce encore l'évolutivité et les performances du système.
4. Consensus modulaire et mécanisme de restaking (Modular Consensus & Restaking) : Pharos introduit un mécanisme de consensus flexible, supportant plusieurs modèles de consensus (comme PBFT, PoS, PoA), et