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

I. Introduction : Application du calcul parallèle dans la blockchain

Le "triangle impossible" de la blockchain (Blockchain Trilemma) de "sécurité", "décentralisation" et "extensibilité" révèle le compromis essentiel dans la conception des systèmes de blockchain, à savoir qu'il est difficile pour un projet de 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 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 sur place des capacités d'exécution, telles que le parallélisme, le GPU, le multicœur
• Capacité d'isolement d'état : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, multi-sous-réseaux
• Scalabilité hors chaîne par sous-traitance : déplace l'exécution hors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité 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 Actor, isolation des processus, pilotage par message, par exemple agents, chaînes asynchrones multithread

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 de preuve 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'extensibilité à plusieurs niveaux, en collaboration et en combinaison de modules". Cet article met l'accent 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 à l'intérieur des blocs. En fonction du 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 architecturales, 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élisme 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), appartenant à un autre paradigme de calcul parallèle, comme un système de messages inter-chaînes / asynchrone (modèle de non-synchronisation de bloc), chaque Agent agissant comme un "processus intelligent autonome" fonctionnant indépendamment, avec des messages asynchrones en mode parallèle, déclenchés par des événements, sans planification de synchronisation, les projets représentés incluent AO, ICP, Cartesi, etc.

Les solutions d'extension telles que Rollup ou le sharding, que nous connaissons bien, appartiennent aux mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle à l'intérieur de la chaîne. Elles réalisent l'extension en "faisant fonctionner plusieurs chaînes / domaines d'exécution en parallèle", et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons tout de même pour comparer les similitudes et les différences des concepts architecturaux.

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

L'architecture de traitement en série d'Ethereum a évolué au fil du temps, passant par des tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement du débit au niveau de l'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents avec la plus grande base de développeurs et un potentiel écologique. Ainsi, la chaîne d'extension parallèle EVM est en train de devenir une voie clé pour équilibrer la compatibilité écologique et l'amélioration des performances d'exécution, et elle se présente comme une direction importante pour la nouvelle génération d'évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, chacun construisant une architecture de traitement parallèle EVM axée sur des scénarios de haute concurrence et de haut débit, en partant respectivement de l'exécution différé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 en pipeline (Pipelining), avec exécution asynchrone au niveau de consensus (Asynchronous Execution) et exécution parallèle optimiste (Optimistic Parallel Execution) au niveau d'exécution. De plus, au niveau de consensus et de stockage, Monad introduit respectivement un protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB) pour réaliser une optimisation de bout en bout.

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

Le pipelining est le principe 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 é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 à travers les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de la transaction (Execution) et 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 une exécution asynchrone grâce à "l'exécution asynchrone", ce qui permet un consensus asynchrone, une exécution asynchrone et un stockage asynchrone. Cela réduit considérablement le temps de bloc (block time) et le délai de confirmation, rendant le système plus résilient, les processus 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 pour le prochain bloc commence immédiatement, sans attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

L'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", 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écutez simultanément un "Détecteur de Conflits (Conflict Detector))" pour surveiller si les transactions accèdent au même état (par exemple, des conflits de lecture / écriture).
• Si un conflit est détecté, la transaction conflictuelle sera réexécutée en série 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 le parallélisme grâce à un état écrit différé et une détection dynamique des conflits, ressemblant plus à une version performante d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, servant d'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 modulaire à haute performance compatible avec EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration d'exécution sur Ethereum ou 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 pouvant être planifié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 + State Dependency DAG (graphique de dépendance d'état acyclique) 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 un modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte", qui "thréadise" 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 (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter 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, lit quels comptes, tout cela est modélisé en relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, tandis que les transactions avec des relations de dépendance seront planifiées et triées en série ou retardé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 monothread EVM, en réalisant un encapsulage de micro-machine virtuelle par unité de compte, en utilisant un graphe de dépendance d'état pour le plan de transaction, et remplace 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 la construction de systèmes en chaîne 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, et libérer un potentiel de parallélisme extrême grâce à une planification d'exécution asynchrone. Théoriquement, 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 très différentes 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 limites 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 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'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 l'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). Pharos Network, en tant que réseau blockchain L1 modulaire et entièrement parallèle, a un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture supporte un environnement multi-VM (EVM et Wasm) grâce à la collaboration entre la chaîne principale et le réseau de traitement spécial (SPNs), 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 en pipeline asynchrone 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 utilise une méthode 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 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é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 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, 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, prenant en charge plusieurs modèles de consensus (comme PBFT