Web3 carte panoramique du secteur du calcul parallèle : la meilleure solution d'extension native ?

I. Contexte et défis du calcul parallèle en blockchain

Le « trilemme de la blockchain » (« Blockchain Trilemma ») qui inclut « sécurité », « décentralisation » et « évolutivité » 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é 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é sont classées selon des paradigmes, y compris :

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

Les solutions d'extension de la blockchain comprennent : le calcul parallèle à l'intérieur de la 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., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extension « multi-niveaux et combinaison modulaire ». 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 à l'intérieur des blocs. Selon le mécanisme de parallélisme, ses méthodes de mise à l'échelle peuvent être divisées en cinq grandes catégories, chacune représentant différentes aspirations en matière de performance, de modèle de développement et de philosophie architecturale, 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 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èle au niveau des transactions (Transaction-level) : représente les projets 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 asynchrones / inter-chaînes (modèle de synchronisation non blockchain), chaque agent fonctionne comme un « processus intelligent » indépendant, permettant un traitement asynchrone des messages et des événements, sans planification synchronisée. Des projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle que nous connaissons bien, telles que Rollup ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne font pas partie 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. Ces solutions de mise à l'échelle ne sont pas le point focal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences de 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, telles 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, l'EVM et Solidity restent les plateformes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus forts à l'heure actuelle. Par conséquent, la chaîne parallèle de type EVM, qui vise à concilier compatibilité écologique et amélioration de la performance d'exécution, devient une direction clé dans l'évolution de la prochaine série d'extensions. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle EVM axée sur des scénarios à haute concurrence et à haut débit, respectivement à partir de l'exécution différée et de la décomposition de l'é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), exécutant des tâches de manière 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 concept fondamental de l'exécution parallèle des monades. Son idée centrale est de diviser 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 multidimensionnelle. Chaque phase fonctionne sur des threads ou cœurs indépendants, réalisant un traitement concurrent entre les blocs, pour finalement améliorer le débit et réduire la latence. Ces phases comprennent : la proposition de transaction (Propose), l'atteinte du consensus (Consensus), l'exécution de transaction (Execution) et la 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 qui limite gravement l'évolutivité des performances avec ce modèle sériel. Monad réalise le consensus asynchrone, l'exécution asynchrone et le stockage asynchrone grâce à l'« exécution asynchrone ». Cela réduit de manière significative 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 de base :

• 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 l'achèvement du consensus.
• Une fois le consensus atteint, le processus de consensus du prochain bloc commence immédiatement, sans attendre l'exécution.

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

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, supposant qu'il n'y a pas de conflit 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 sérialisées et réexécutées pour assurer l'exactitude de l'état.

Monad a choisi un chemin de compatibilité : réduire au minimum les modifications des règles EVM, en réalisant le parallélisme par le biais de l'écriture différée 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, en tant qu'accélérateur parallèle dans le monde EVM.

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

Contrairement à la localisation L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle hautes performances et modulaire compatible EVM, pouvant à la fois servir de chaîne publique L1 indépendante ou de couche d'exécution améliorée (Execution Layer) sur Ethereum, ou encore de 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 indépendamment programmables, afin d'atteindre une exécution en 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é vers "la threadisation 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 « une micro-machine virtuelle (Micro-VM) par compte », qui « threadise » l'environnement d'exécution, fournissant la plus petite unité d'isolation pour l'ordonnancement parallèle. Ces VM communiquent entre elles par messagerie asynchrone (Asynchronous Messaging), au lieu 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, naturellement en 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 et lit quels comptes, le tout 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 programmées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit la cohérence d'é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 à états single-thread EVM, en réalisant un encapsulage de micro-machine virtuelle par unité de compte, en utilisant un graphique de dépendance d'état pour le plan de transaction, 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 depuis « structure de compte → architecture de planification → processus d'exécution », offrant une nouvelle approche de niveau paradigme pour construire des systèmes en 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é basé sur la philosophie 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 sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limites d'une chaîne unique pour une évolutivité au niveau du réseau ; tandis que Monad et MegaETH maintiennent 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 à 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 : 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 sur la chaîne. Ils réalisent 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 entièrement parallèle, possède un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture supporte un environnement multi-Virtual Machine (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 à connaissance nulle (ZK) et les environnements d'exécution de confiance (TEE).

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

1. Traitement de pipeline asynchrone sur tout le 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 approche de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et parallèle, ce qui améliore 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 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, améliorant ainsi 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