Carte panoramique de la piste de calcul parallèle Web3 : Quelle est la meilleure solution d'extension native ?

I. Aperçu du calcul parallèle Web3

Le « triangle impossible » de la blockchain (Blockchain Trilemma) « sécurité », « décentralisation », « évolutivité » révèle le compromis essentiel dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain d'atteindre simultanément « une sécurité maximale, 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é se classent selon des paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœurs.
• Isolation des états par extension : partitionnement horizontal des états / 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
• Extension découplée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonneur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle Actor, isolation des processus, pilotage par messages, par exemple agents, chaînes asynchrones multithread

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

Calcul parallèle intra-chaîne (intra-chain parallelism), qui se concentre 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'expansion peuvent être divisées en cinq grandes catégories, chacune représentant des quêtes de performance, des modèles de développement et des philosophies d'architecture différents, 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 de plus en plus élevée, ainsi qu'une complexité de programmation et une difficulté de mise en œuvre de plus en plus grandes.

• 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
• Niveau de transaction (Transaction-level) : représente les projets Monad, Aptos
• Niveau d'appel / Micro VM en 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), 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 de bloc), chaque Agent fonctionne comme un "processus intelligent" indépendant, utilisant des messages asynchrones en mode parallèle, piloté par des événements, sans avoir besoin d'un ordonnancement synchronisé. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension par Rollup ou par sharding, que nous connaissons bien, appartiennent à des 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 l'extension 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. Ces solutions d'extension ne sont pas au cœur de la discussion de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences dans les concepts architecturaux.

II. Chaîne améliorée parallèle EVM : Briser 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 telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus importants. Par conséquent, la chaîne d'amélioration parallèle EVM est une voie clé qui prend en compte la compatibilité écologique et l'amélioration des performances d'exécution, devenant ainsi une direction importante pour la prochaine évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle EVM axée sur les scénarios à haute concurrence et à haut débit, en partant de l'exécution retardée et de la décomposition des états.

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 par pipeline (Pipelining) et exécutant de manière asynchrone au niveau du consensus (Asynchronous Execution) et de manière optimiste en parallèle au niveau d'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), permettant une optimisation de bout en bout.

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

Le Pipelining est le concept fondamental de l'exécution parallèle des Monades, dont l'idée centrale est de décomposer le processus d'exécution de la blockchain en plusieurs étapes indépendantes et de traiter ces étapes en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque étape s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent inter-blocs, visant à améliorer le débit et à réduire la latence. Ces étapes comprennent : la proposition de transaction (Propose), l'atteinte du consensus (Consensus), l'exécution de la transaction (Execution) et la soumission du bloc (Commit).

Exécution Asynchrone : Consensus - Exécution découplée asynchrone

Dans une chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce modèle sériel limite gravement l'évolutivité des performances. Monad réalise l'asynchrone au niveau du consensus, de l'exécution et du stockage 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, les processus de traitement plus segmentés et l'utilisation des ressources plus efficace.

Conception de base :

• 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.
• Après la réalisation du consensus, le processus de consensus du prochain bloc commence immédiatement, sans avoir besoin d'attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

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 », 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 conflit d'état entre la plupart des transactions.
• Exécutez 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é, la transaction conflictuelle sera réexécutée de manière séquentielle pour garantir la cohérence de l'état.

Monad a choisi un chemin compatible : minimiser les modifications des règles EVM, en réalisant le parallélisme par le biais du report de l'écriture des états et de la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, ce qui en fait un accélérateur de parallélisme dans le monde EVM.

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

Contrairement à la localisation L1 de Monad, MegaETH se positionne comme une couche d'exécution parallèle haute performance et modulaire compatible avec l'EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration de l'exécution sur Ethereum (Execution Layer) ou de composant modulaire. Son objectif de conception principal est de déconstruire la logique des comptes, l'environnement d'exécution et l'état en unités minimales pouvant être programmées indépendamment, afin d'atteindre une exécution concurrente élevée et une faible latence de réponse au sein de la chaîne. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + le DAG de dépendance d'état (Directed Acyclic Graph de dépendance d'état) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers le "filtrage au sein de la chaîne".

Architecture Micro-VM : Un 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 une unité d'isolement minimale pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones, et non d'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 naturellement parallèle.

DAG de dépendance d'état : mécanisme de planification piloté par un graphique de dépendance

MegaETH a construit un système de planification basé sur une relation d'accès à l'état des comptes, utilisant un DAG. Le système maintient en temps réel un graphique de dépendance global (Dependency Graph), modélisant toutes les transactions qui modifient et lisent des comptes 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 en série ou différées selon un ordre topologique. Le graphique de dépendance garantit la cohérence de l'état et l'écriture non 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 encapsulant les micro-machines virtuelles par unité de compte, en réalisant le plan de transaction via un graphique de dépendance d'état, 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, de « structure de compte → architecture de planification → processus d'exécution », qui offre une nouvelle approche paradigmatique pour construire le système de chaîne 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 super distribué sous l'idée d'Ethereum.

Les conceptions de Monad et MegaETH diffèrent considérablement de celles du sharding : le sharding divise la blockchain horizontalement 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 meilleure évolutivité au niveau du réseau ; alors que Monad et MegaETH conservent l'intégrité de la chaîne unique, ne s'étendant horizontalement qu'au niveau de l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour surmonter les performances. Les deux représentent deux directions dans le chemin de l'évolutivité 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 on-chain, 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 entièrement parallèle, a pour mécanisme de calcul parallèle central ce qu'on appelle le "Rollup Mesh". Cette architecture, grâce à la coopération entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-machines virtuelles (EVM et Wasm), et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance (ZK) et les environnements d'exécution de confiance (TEE).

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

1. Traitement asynchrone de 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 de manière indépendante et parallèle, augmentant ainsi 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 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 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éciaux (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, renforçant ainsi l'évolutivité et la performance du système.
4. Consensus modulable et mécanisme de restaking (Modular Consensus & Restaking) : Pharos a introduit un mécanisme de consensus flexible, prenant en charge plusieurs modèles de consensus (comme PBFT, PoS, PoA), et via un protocole de restaking (