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

I. Contexte technique et motivation du développement du calcul parallèle

Le « triangle impossible » de la blockchain, à savoir « sécurité », « décentralisation » et « évolutivité », révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir 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'« évolutivité », les solutions d'extension de blockchain sur le marché actuel se distinguent par des paradigmes, y compris :

• Exécution de l'extension améliorée : amélioration des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Extension par isolation d'état : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, multinet
• Extension de type externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Extensibilité découplée par 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 les messages, par exemple agents, chaîne asynchrone multithread

Les solutions d'extension 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 Stateless, etc. Cela couvre plusieurs niveaux tels que l'exécution, l'état, les données et la structure, formant un système complet d'extension "multi-niveau et combinaison modulaire". Cet article se concentre principalement sur la méthode d'extension basée sur le calcul parallèle.

Calcul parallèle intra-chaîne (intra-chain parallelism), axé sur l'exécution parallèle des transactions / instructions à l'intérieur du bloc. Classé par mécanisme de parallélisme, ses méthodes d'extension peuvent être divisé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é 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 également 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 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 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 synchronisation non blockchain), chaque agent fonctionne comme un « processus d'agent » indépendant, envoyant des messages de manière asynchrone, basé sur des événements et sans planification synchrone. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, comme les Rollup ou le sharding, appartiennent à des 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" plutôt qu'en augmentant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ce type de solution d'extension n'est pas le point principal de cet article, mais nous l'utiliserons néanmoins pour comparer les similitudes et les différences des concepts architecturaux.

II. Chaîne améliorée par parallélisme EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement sériel d'Ethereum a évolué jusqu'à présent, ayant traversé plusieurs essais d'extension, tels que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, en même temps, 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'augmentation parallèle EVM devient un chemin clé qui prend en compte la compatibilité écologique et l'amélioration des performances d'exécution, et devient 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 des architectures de traitement parallèle EVM orientées vers des scénarios à haute concurrence et à haut débit, en se basant sur l'exécution différée et 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 du 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 à plusieurs étapes

Le Pipelining est le concept de base de l'exécution parallèle des Monads, dont l'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 en parallèle, formant ainsi une architecture de pipeline en trois dimensions. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, afin d'augmenter le débit et de réduire la latence. Ces étapes incluent : Proposition de transaction (Propose), Accord de consensus (Consensus), Exécution de transaction (Execution) et Soumission de blocs (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 qui 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, affinant les processus et améliorant l'utilisation des ressources.

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 la finalisation du consensus.
• Une fois le consensus atteint, passez immédiatement au processus de consensus du bloc suivant, sans avoir besoin d'attendre la fin 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 », ce qui améliore 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écuter simultanément un « Détecteur de Conflits (Conflict Detector)) » pour surveiller si les transactions accèdent au même état (par exemple, conflit 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'exactitude de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant la parallélisation 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, faisant de lui un accélérateur de parallélisation dans le monde de l'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 modulaire haute performance compatible EVM, pouvant fonctionner à la fois comme une blockchain publique L1 indépendante et comme une couche d'amélioration d'exécution sur Ethereum ou 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 de manière indépendante, afin de réaliser une exécution concurrente élevée sur 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 + DAG de dépendance d'état (graphe acyclique de dépendance d'état) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "l'exécution en fil de chaîne".

Architecture Micro-VM : Le compte est un fil

MegaETH introduit le modèle d'exécution « une micro-machine virtuelle (Micro-VM) par compte », rendant l'environnement d'exécution « threadé », fournissant ainsi l'unité d'isolation minimale 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 et de stocker indépendamment, ce qui est naturellement 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 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 est modélisé en une relation 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 programmées en série ou retardées selon l'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 monothread EVM, en réalisant un encapsulage de micro-machine virtuelle par compte, en programmant les transactions à l'aide d'un graphe 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, allant de « structure de compte → architecture de planification → processus d'exécution », offrant une nouvelle approche paradigmatique pour construire des systèmes en ligne de haute performance de prochaine génération.

MegaETH a choisi un chemin 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 à l'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.

Monad et MegaETH ont des philosophies de conception assez différentes de celles du sharding : le sharding divise la blockchain horizontalement en plusieurs chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant les limites d'une seule chaîne pour une expansion au niveau du réseau ; tandis que Monad et MegaETH maintiennent 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 surmonter 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 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-VM (Micro-VM). En tant que réseau blockchain L1 modulaire et full-stack parallèle, Pharos Network possède un mécanisme de calcul parallèle appelé « Rollup Mesh ». Cette architecture soutient un environnement multi-VM (EVM et Wasm) grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance (ZK) et l'environnement 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 d'être réalisée de manière indépendante et parallèle, augmentant ainsi l'efficacité globale du traitement.
2. Exécution parallèle à 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 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é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, améliorant ainsi l'évolutivité et les performances du système.
4. Consensus modulaire et mécanisme de re-staking (Modular Consensus & Restaking) : Pharos introduit un mécanisme de consensus flexible, prenant en charge plusieurs modèles de consensus (comme PBFT, PoS, PoA