Vue d'ensemble du domaine du calcul parallèle Web3 : la meilleure solution d'extension native ?

Le "trilemme" de la blockchain (Blockchain Trilemma) "sécurité", "décentralisation", "extensibilité" 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é extrême, une participation universelle, et un traitement rapide". En ce qui concerne le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain actuellement sur le marché sont classées par paradigmes, y compris:

• Exécution d'une extension améliorée : amélioration de la capacité d'exécution sur place, par exemple, parallélisation, GPU, multicœur
• Type d'extension par isolation d'état : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, plusieurs 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
• Extension découplée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonneurs partagés, Rollup Mesh
• Extension de type concurrent asynchrone : modèle Actor, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extension de la blockchain comprennent : calcul parallèle en chaîne, Rollup, sharding, modules DA, structure modulaire, système Actor, compression de preuve zk, architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure. C'est un système d'extension complet basé sur la "coopération multi-niveaux et la combinaison de modules". 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), se concentre sur l'exécution parallèle des transactions/instructions au sein des blocs. En fonction du mécanisme de parallélisme, ses méthodes d'évolutivité peuvent être divisées en cinq grandes catégories, chacune représentant différentes ambitions de performance, modèles de développement et philosophies d'architecture, 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 de plus en plus grande, 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 en parallèle (Call-level / MicroVM) : représente le projet MegaETH
• Parallélisme au niveau des instructions (Instruction-level) : représente le projet GatlingX

Le modèle de concurrence asynchrone hors chaîne, représenté par le système d'agents intelligents (Agent / Actor Model), 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 fonctionne comme un "processus intelligent autonome", permettant un traitement parallèle des messages asynchrones, basé sur des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, comme Rollup ou le sharding, appartiennent aux 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èle à l'intérieur d'un seul bloc/VM. De telles solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les différences de concept d'architecture.

Deuxième, chaîne améliorée parallèle EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extensibilité 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 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 aujourd'hui. Ainsi, 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é pour la nouvelle évolution de l'extensibilité. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle EVM orientée vers des scénarios à haute concurrence et à fort débit à partir 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 hautes performances redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement par pipeline (Pipelining), exécutant de manière asynchrone au niveau du consensus (Asynchronous Execution) et en utilisant la concurrence optimiste (Optimistic Parallel Execution) au niveau d'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 de manière parallèle, formant ainsi une architecture de pipeline tridimensionnelle, chaque phase s'exécutant 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 phases incluent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de la transaction (Execution) et soumission du bloc (Commit).

Exécution Asynchrone : Consensus - Découplage Asynchrone de l'Exécution

Dans une blockchain 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 a réalisé 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 (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) n'est responsable 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 prochain bloc 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 les transactions, afin d'é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 en même temps un "Détecteur de Conflits (Conflict Detector)" pour surveiller si les transactions accèdent à des états identiques (comme des conflits de lecture/écriture).
• Si un conflit est détecté, les transactions en conflit seront sérialisées et réexécutées pour garantir la cohérence de l'état.

Monad a choisi un chemin de compatibilité : en perturbant aussi peu que possible les règles de l'EVM, en réalisant le parallélisme par le biais du retardement de l'écriture des états et de la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité permettant une migration facile de l'écosystème EVM, c'est un accélérateur de parallélisme dans le monde de l'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 de haute performance compatible EVM et peut servir à la fois de blockchain publique L1 indépendante et de couche d'amélioration d'exécution sur Ethereum (Execution Layer) 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 indépendamment, afin de réaliser une exécution à haute concurrence 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 (graphe de dépendance d'état acyclique) et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers "l'exécution en chaîne".

Architecture Micro-VM : le compte est un thread

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte", rendant l'environnement d'exécution "multithreadé", 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 à de nombreuses VM d'exécuter et de stocker de manière indépendante, créant ainsi une parallélisation naturelle.

DAG de dépendance d'état : mécanisme de planification basé sur le graphe 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 graphe de dépendance global, modélisant toutes les transactions qui modifient ou 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 triées par ordre topologique, soit de manière séquentielle, soit avec un retard. Le graphe de dépendance assure la cohérence d'état et l'absence d'écritures répétées pendant le processus d'exécution parallèle.

Exécution asynchrone et mécanisme de rappel

B

En résumé, MegaETH brise le modèle de machine d'état à thread unique traditionnel de l'EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en planifiant 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, de "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles idées de niveau paradigmatique pour la construction de systèmes en ligne de nouvelle génération à haute performance.

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.

Monad et MegaETH ont des conceptions très 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 de certaines transactions et états, brisant les limitations d'une seule chaîne pour l'expansion au niveau du réseau ; alors que Monad et MegaETH maintiennent l'intégrité d'une seule chaîne, en s'étendant horizontalement uniquement au niveau de la couche d'exécution, en optimisant l'exécution parallèle à l'intérieur d'une seule chaîne pour dépasser 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 sur la 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). Pharos Network, en tant que réseau blockchain L1 modulaire et entièrement parallèle, dispose d'un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture soutient un environnement multi-machine virtuelle (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 asynchrone en pipeline sur l'ensemble du cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes étapes de la transaction (telles que le consensus, l'exécution, le stockage) et utilise un mode de traitement asynchrone, permettant à chaque étape 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 VM (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é selon 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, 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 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, PoS, PoA), et réalise le mainnet via le protocole de restaking.