Paysage de la course à la calculabilité parallèle Web3 : la meilleure solution pour l'extension native ?

I. Calcul parallèle : une nouvelle direction pour l'extension de la blockchain

Le "trilemme blockchain" (Blockchain Trilemma) de la blockchain, qui comprend la "sécurité", la "décentralisation" et la "scalabilité", révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément une "sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de la "scalabilité", les solutions d'extension blockchain dominantes sur le marché sont classées par paradigmes, y compris :

• Exécution d'une extensibilité améliorée : augmentation des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœur
• Type d'extension par isolation d'état : partitionnement horizontal de l'état / Shard, par exemple partition, UTXO, sous-réseaux multiples
• Expansions hors chaîne de type sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Expansion asynchrone et concurrente : 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 en chaîne, 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 d'extension complet "coopération multi-niveaux, combinaison modulaire". Cet article met principalement l'accent sur les méthodes d'extension axé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 d'extension 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 architecturales 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 de plus en plus élevée, 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), 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 des blocs), chaque agent agissant comme un "processus intelligent autonome", avec des messages asynchrones en mode parallèle, évènementiel, sans planification de synchronisation, les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension bien connues comme Rollup ou le sharding 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 le sujet principal de cet article, mais nous les utiliserons tout de même pour comparer les similarités des concepts d'architecture.

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

L'architecture de traitement sériel 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 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 solides. Ainsi, la chaîne d'amélioration parallèle EVM, qui vise à concilier la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé dans la nouvelle phase d'é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 orientée vers des scénarios à haute concurrence et à haut débit, respectivement à 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 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement par pipeline (Pipelining), avec exécution asynchrone au niveau du consensus (Asynchronous Execution) et exécution parallèle optimiste 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), réalisant une optimisation de bout en bout.

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

Le pipelining est le principe de base de l'exécution parallèle des monades. 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, réalisant un traitement concurrent à travers les blocs, et atteignant finalement une augmentation du débit et une réduction de 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 les chaînes traditionnelles, le consensus et l'exécution des transactions se déroulent généralement en processus synchrones, ce modèle sériel limite gravement l'évolutivité des performances. Monad réalise un consensus asynchrone, une exécution asynchrone et un stockage asynchrone grâce à "l'exécution asynchrone". Cela réduit significativement le temps de bloc (block time) et la latence 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 de contrat.
• Le processus d'exécution (couche d'exécution) est déclenché de manière asynchrone après la réalisation du consensus.
• Une fois le consensus atteint, le processus de consensus du prochain bloc commence immédiatement, sans attendre la fin de l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

L'Ethereum traditionnel adopte 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 conflits d'état entre la plupart des transactions.
• Exécuter simultanément un "Détecteur de conflits (Conflict Detector))" pour surveiller si des transactions ont accédé au même état (par exemple, conflit de lecture / écriture).
• Si un conflit est détecté, les transactions conflictuelles seront exécutées de manière séquentielle pour garantir l'exactitude de l'état.

Monad a choisi une voie de compatibilité : en modifiant le moins possible les règles de l'EVM, en réalisant le parallélisme par le biais d'une écriture d'état différée et d'une détection dynamique des conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, agissant comme un accélérateur parallèle dans le monde de l'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 modulaire à haute performance 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 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 programmées indépendamment, afin d'atteindre 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 + DAG de dépendance d'état 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 : le compte est un thread

MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "thréadise" l'environnement d'exécution, fournissant ainsi une unité d'isolement minimale pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones, plutôt que par des appels synchrones, ce qui permet à un grand nombre de VM d'exécuter indépendamment et de stocker indépendamment, de manière naturellement parallèle.

DAG de dépendance d'état : Mécanisme de planification basé sur un graphe de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état des comptes, qui maintient en temps réel un graphique de dépendance global (Dependency Graph). Chaque transaction modifie quels comptes, lit quels comptes, et tout cela est modélisé sous forme de 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 en série ou retardées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence de l'é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 traditionnel de machine d'état monocore EVM, réalisant un encapsulage de micro-machine virtuelle par unité de compte, en programmant des transactions via 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 une nouvelle approche paradigmique pour la construction de systèmes de chaîne en ligne 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, libérant ainsi 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.

Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux du sharding : le sharding divise la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et de l'état, brisant ainsi la limite d'une chaîne unique pour l'extension au niveau réseau ; alors que Monad et MegaETH conservent l'intégrité de la chaîne unique, se concentrant uniquement sur l'extension horizontale au niveau d'exécution, réalisant des optimisations de performances par une exécution parallèle extrême à l'intérieur de la chaîne unique. Les deux représentent les directions de renforcement vertical et d'extension horizontale dans les chemins d'expansion de la blockchain.

Les projets de calcul parallèle comme Monad et MegaETH se concentrent principalement sur l'optimisation du chemin de traitement pour améliorer le TPS en chaîne, avec l'objectif central d'atteindre 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 full stack parallèle, a son mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture prend en charge un environnement multi-machine virtuelle (EVM et Wasm) grâce à la collaboration entre la chaîne principale 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 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, ce qui améliore 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 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é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, renforçant 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