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

I. Contexte de l'application du calcul parallèle dans la blockchain

Le "trilemme" de la blockchain (Blockchain Trilemma) qui consiste en "sécurité", "décentralisation" et "extensibilité" révèle les compromis essentiels dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de "l'extensibilité", les solutions de scalabilité des blockchains dominantes sur le marché sont classées par paradigme, y compris :

• Exécution d'une mise à l'échelle améliorée : amélioration de la capacité d'exécution sur place, comme le parallélisme, le GPU, et le multicœur.
• Scalabilité par isolation d'état : partitionnement horizontal de l'état/Shard, par exemple, sharding, UTXO, sous-réseaux multiples
• Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Expansion par découplage de structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Extension de type de concurrence asynchrone : Modèle Actor, isolation des processus, piloté par message, par exemple agents, chaîne asynchrone multi-thread

Les solutions d'extensibilité de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc. Cela couvre plusieurs niveaux : exécution, état, données et structure, formant un système complet d'extensibilité "multi-niveaux collaboratifs, combinaisons modulaires". Cet article se concentre principalement sur les méthodes d'extensibilité 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 divisé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 de plus en plus élevée, 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 (Object-level) : représente le projet Sui
• Parallélisme au niveau des transactions (Transaction-level) : représente les projets Monad, Aptos
• Appel de niveau / MicroVM en parallèle : 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'entités intelligentes Actor (Agent / Actor Model), qui appartient à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes / asynchrone (modèle de non-synchronisation des blocs), chaque Agent fonctionnant comme un "processus d'agent intelligent" indépendant, avec des messages asynchrones en parallèle, orientés événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle que nous connaissons bien, telles que Rollup ou le sharding, appartiennent aux mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle au sein de la chaîne. Elles réalisent la mise à l'échelle en "exécutant plusieurs chaînes/domaines d'exécution en parallèle", plutôt qu'en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/ machine virtuelle. Ce type de solution de mise à l'échelle n'est pas le point focal de cet article, mais nous l'utiliserons tout de même pour comparer les différences et similitudes des concepts d'architecture.

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

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extension, y compris le sharding, le Rollup et une architecture modulaire, mais le goulot d'étranglement de la capacité de traitement de la couche d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et possédant un écosystème dynamique. Par conséquent, la chaîne d'amélioration parallèle de l'EVM devient un chemin clé pour concilier la compatibilité écologique et l'amélioration des performances d'exécution, et elle est en train de devenir une direction importante pour la prochaine évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement une architecture de traitement parallèle de l'EVM axée sur l'exécution différée et la décomposition des états pour des scénarios à haute concurrence et à haut débit.

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

Monad est une blockchain 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 au niveau de l'exécution (Optimistic Parallel Execution). 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 spécialisé (MonadDB), réalisant une optimisation de bout en bout.

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

Le pipelining est le concept fondamental de l'exécution parallèle des monades. Son idée principale est de décomposer le processus d'exécution de la blockchain en plusieurs étapes indépendantes et de traiter ces étapes de manière parallèle, formant ainsi une architecture en pipeline tridimensionnelle. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces étapes comprennent : la proposition de transaction (Propose), la réalisation du consensus (Consensus), l'exécution de la transaction (Execution) et la soumission du bloc (Commit).

Exécution Asynchrone : Découplage Asynchrone de la Consensus et de l'Exécution

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce modèle sérialisé limite sérieusement 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 et la latence de confirmation, rendant le système plus résilient, les processus de traitement plus fragmentés et l'utilisation des ressources plus élevée.

Conception principale :

• Le processus de consensus (couche de consensus) est uniquement responsable 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 la réalisation du consensus.
• Une fois le consensus atteint, le processus de consensus du prochain bloc commence immédiatement, sans attendre l'achèvement de l'exécution.

Exécution parallèle optimiste : Exécution parallèle optimiste

L'Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", augmentant 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écuter simultanément un "Détecteur de Conflit (Conflict Detector))" pour surveiller si les transactions accèdent au même état (comme les conflits de lecture/écriture).
• Si un conflit est détecté, les transactions en conflit seront réexécutées de manière séquentielle pour garantir l'intégrité de l'état.

Monad a choisi un chemin compatible : il modifie le moins possible les règles de l'EVM, et réalise le parallélisme en retardant l'écriture de l'état et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, faisant de lui un accélérateur parallèle dans le monde de l'EVM.

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

Contrairement à la position L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle haute performance, compatible EVM et modulaire. Elle peut fonctionner à la fois comme une blockchain publique L1 indépendante et comme une couche d'amélioration de l'exécution (Execution Layer) sur Ethereum ou comme un composant modulaire. Son objectif de conception principal est de décomposer la logique des comptes, l'environnement d'exécution et l'état en unités minimales pouvant être programmées indépendamment, afin de réaliser une exécution à haute concurrence et une faible latence au sein de la chaîne. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + State Dependency DAG (graphe de dépendance d'état acyclique) et un mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers "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 "threadise" l'environnement d'exécution, fournissant ainsi l'unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par des messages asynchrones (Asynchronous Messaging), et non par des appels synchrones, permettant à de nombreuses VM d'exécuter de manière indépendante et de stocker de manière autonome, offrant ainsi un parallélisme naturel.

DAG de Dépendance d'État : Mécanisme de Planification Basé sur un Graphe de Dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état des comptes, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifie quels comptes, lit quels comptes, et tout cela est modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle directement, tandis que les transactions ayant des relations de dépendance seront programmées en série ou reportées selon un ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'absence d'écritures répétées pendant 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 EVM à thread unique, en réalisant un encapsulage de micro-VM au niveau des comptes, en utilisant des graphes 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 → processus d'exécution", offrant une nouvelle approche de niveau paradigme pour la construction des systèmes de chaîne en ligne de haute performance de prochaine génération.

MegaETH a choisi une voie de reconstruction : abstraire 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. En théorie, 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 distribué super sous l'idée d'Ethereum.

Monad et MegaETH ont des philosophies de conception très différentes de celles du sharding : le sharding découpe la blockchain en plusieurs chaînes indépendantes (shards), chaque shard étant responsable d'une partie des transactions et des états, brisant ainsi la limitation 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, se concentrant uniquement sur l'expansion horizontale au niveau de l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour dépasser les performances. Les deux représentent deux directions dans le chemin d'expansion de la blockchain : le renforcement vertical et l'expansion horizontale.

Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec pour objectif central d'améliorer le TPS intra-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-machine virtuelle (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 qu'on appelle "Rollup Mesh". Cette architecture, par le biais du travail collaboratif entre la chaîne principale et les réseaux de traitement spéciaux (SPNs), prend en charge un environnement multi-machine virtuelle (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 : 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, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de deux machines virtuelles (Dual VM Parallel Execution) : Pharos prend en charge deux environnements de machines virtuelles, EVM et WASM, permettant aux développeurs de choisir l'environnement d'exécution approprié en fonction de leurs besoins. Cette architecture à double VM non seulement améliore 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éciaux (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, similaires à des sous-réseaux modulaires, spécialement conçus pour gérer des types de tâches ou d'applications spécifiques. Grâce aux SPNs, Pharos peut réaliser une allocation dynamique des ressources et un traitement parallèle des tâches, renforçant ainsi l'évolutivité et la performance du système.
4. Consensus modulaire et mécanisme de restaking (Modular Consensus & Restaking) : Pharos introduit un mécanisme de consensus flexible, prenant en charge divers modèles de consensus (tels que PBFT, PoS, PoA) et via un protocole de restaking (