Cartographie complète du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?

I. Le sujet éternel de l'évolutivité de la blockchain

Le "triangle impossible" de la blockchain (la trinité problématique de la blockchain) "sécurité", "décentralisation", "scalabilité" révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain de réaliser simultanément "une sécurité ultime, une participation universelle, un traitement rapide". Concernant le sujet éternel de la "scalabilité", les solutions d'extension de blockchain actuellement sur le marché peuvent être classées selon des paradigmes, y compris :

• Exécution de l'extension améliorée : amélioration de la capacité d'exécution sur place, par exemple par le parallélisme, GPU, multicœur.
• Mise à l'échelle par isolation d'état : partitionnement horizontal de l'état / Shard, comme les sharding, UTXO, sous-réseaux multiples
• Expansions hors chaîne par sous-traitance : effectuer l'exécution en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Extension découplée par la structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle d'acteur, isolation des processus, pilotage par messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extensibilité de la blockchain comprennent : le calcul parallèle intra-chaîne, Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture sans état, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extensibilité "à plusieurs niveaux et en combinaison modulaire". Cet article se concentre sur les méthodes d'extensibilité principalement basées sur le calcul parallèle.

Calcul parallèle intra-chaîne (, se concentrant sur l'exécution parallèle des transactions/instructions à l'intérieur 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 des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, avec un degré de parallélisme de plus en plus fin, une intensité parallèle de plus en plus élevée, ainsi qu'une complexité de planification et une complexité de programmation 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
• Niveau d'appel / MicroVM 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 intelligents (Agent / Actor Model), il appartient à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes / asynchrone (modèle de non-synchronisation de blocs), chaque Agent fonctionnant comme un "processus d'agent intelligent" en mode parallèle, messages asynchrones, événements déclenchés, sans programmation synchronisée, les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle que nous connaissons bien, comme Rollup ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne concernent pas le 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 central de cet article, mais nous l'utiliserons tout de même pour comparer les différences et similitudes des concepts architecturaux.

![Web3 Computation Parallel Track Panorama: La meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

II. Chaîne améliorée en parallèle EVM : dépasser les limites de performance tout en étant compatible

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution demeure fondamentalement non résolu. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents ayant la plus grande base de développeurs et le plus grand 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é dans la nouvelle phase d'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement des architectures de traitement parallèle EVM axées sur des scénarios à haute concurrence et à haut débit, en partant de l'exécution différée et de la décomposition d'état.

) 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 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 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 phases indépendantes et de les traiter en parallèle, formant une architecture de pipeline en trois dimensions. Chaque phase fonctionne sur des threads ou des cœurs indépendants, permettant un traitement parallèle entre les blocs, et atteignant finalement des résultats d'augmentation du débit et de réduction de la latence. Ces phases comprennent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de 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 qui 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 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) est uniquement responsable du tri des transactions et n'exécute pas 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 prochain bloc commence immédiatement, sans attendre la fin de l'exécution.

Exécution parallèle optimiste：Optimistic Parallel Execution

Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour les transactions, afin d'é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 Conflits (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 conflictuelles seront sérialisées et réexécutées pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : modifier le moins possible les règles de l'EVM, en réalisant le parallélisme par le biais d'une écriture d'état différée et d'une détection dynamique des conflits pendant le processus d'exécution, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, étant un accélérateur de parallélisme dans le monde de l'EVM.

![Web3 parallélisation des calculs paysage panorama : la meilleure solution d'évolutivité natif ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

) 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 et modulaire compatible avec EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration de l'exécution (Execution Layer) ou de composant modulaire sur Ethereum. Son objectif de conception principal est de décomposer la logique de compte, l'environnement d'exécution et l'état en unités minimales pouvant être planifiées de manière indépendante, afin d'atteindre une exécution haute concurrence et une capacité de réponse à faible latence au sein de la chaîne. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + DAG de dépendance d'état (Directed Acyclic Graph) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté "threading au sein de la chaîne".

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

MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "filialise" 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, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter indépendamment et de stocker indépendamment, ce qui permet une parallélisation naturelle.

DAG de dépendance d'état : mécanisme de planification piloté par le graphe de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état du compte, 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 est modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, tandis que les transactions ayant des relations de dépendance seront planifiées et ordonnées de manière sérielle ou retardée selon l'ordre topologique. Le graphique de dépendance garantit la cohérence d'état et l'absence d'écriture répétée 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-machine virtuelle par compte, en utilisant un graphique de dépendance d'état pour la planification des transactions, et en remplaçant la pile d'appels synchrones par un mécanisme de message asynchrone. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, depuis "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle perspective de niveau paradigme pour construire le prochain système de chaîne haute performance.

MegaETH a choisi une voie de reconstruction : abstraire complètement les comptes et les contrats en VM indépendantes, libérant ainsi 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.

![Web3, carte panoramique de la piste de calcul parallèle : la meilleure solution pour l'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

Les philosophies de conception de Monad et MegaETH diffèrent considérablement de celles du sharding : le sharding divise la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limitations d'une chaîne unique pour une extension 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 ainsi l'exécution parallèle extrême à l'intérieur de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin d'extension de la blockchain, à savoir le renforcement vertical et l'extension 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 en 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). Quant à Pharos Network, c'est un réseau de blockchain L1 modulaire et full-stack parallèle, dont le mécanisme de calcul parallèle central est appelé "Rollup Mesh". Cette architecture soutient un environnement multi-machine virtuelle (EVM et Wasm) grâce à la collaboration entre le réseau principal et des réseaux de traitement spéciaux (SPNs), et intègre des technologies avancées telles que la preuve à connaissance nulle (ZK) et l'environnement d'exécution fiable (TEE).

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

1. Traitement en pipeline asynchrone sur tout le cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes phases des transactions (comme le consensus, l'exécution, le stockage) et adopte une méthode de traitement asynchrone, permettant à chaque phase de se dérouler indépendamment et en parallèle, ce qui améliore 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 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 (comme PBFT, PoS, PoA), et réalise un partage sécurisé et une intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking.

![Web3 calcul parallèle panorama : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(

De plus, Pharos utilise des arbres Merkle à plusieurs versions, un encodage différentiel (Delta Encoding), et une version