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

Le « trilemme de la blockchain » (Blockchain Trilemma) de la blockchain, qui comprend « sécurité », « décentralisation » et « évolutivité », révèle les compromis essentiels dans la conception des systèmes de blockchain, c'est-à-dire qu'il est difficile pour les projets de 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'évolutivité », les principales solutions d'extension de blockchain sur le marché actuel se distinguent par des paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Isolation de l'état pour l'évolutivité : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, sous-réseaux multiples
• Scalabilité hors chaîne basée sur l'externalisation : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Découplage de la structure pour l'extension : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Extension de capacité asynchrone et concurrente : 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 : 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, formant 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 d'extension peuvent être classées en cinq grandes catégories, chacune représentant une quête de performance, un modèle de développement et une philosophie d'architecture différents, avec une granularité de parallélisme de plus en plus fine, une intensité de parallélisme de plus en plus élevée, ainsi qu'une complexité de planification de plus en plus élevée, une complexité de programmation et une difficulté de mise en œuvre également croissantes.

• 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 / MicroVM 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'entités Actor (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 agissant comme un « processus d'agent intelligent » fonctionnant de manière indépendante, avec un message asynchrone en mode parallèle, basé sur des événements, sans planification synchrone, des projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de Rollup ou de sharding que nous connaissons bien 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'évolutivité par l'"exécution parallèle de plusieurs chaînes / domaines d'exécution", et non par l'augmentation du degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ces solutions d'évolutivité ne sont pas le sujet principal de cet article, mais nous les utiliserons tout de même pour comparer les différences et les similitudes des concepts d'architecture.

Deuxième point, chaîne améliorée par parallélisme EVM : dépasser 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'extensibilité telles que le sharding, le Rollup et l'architecture modulaire, mais le goulet d'étranglement du débit au niveau de l'exécution n'a toujours pas été fondamentalement résolu. Cependant, en même temps, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et avec le plus de potentiel écologique. Ainsi, la chaîne parallèle EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé dans l'évolution de la nouvelle vague d'extensibilité. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle EVM axée sur une exécution différée et une décomposition des états, adaptée aux scénarios de forte concurrence et de haut débit.

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 principe fondamental du traitement en pipeline (Pipelining), avec une exécution asynchrone au niveau du consensus (Asynchronous Execution) et une exécution concurrente 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), permettant une optimisation de bout en bout.

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

Le pipelining est le principe fondamental de l'exécution parallèle des Monads. 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 en trois dimensions. 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), Accord de consensus (Consensus), Exécution de transaction (Execution) et Soumission de 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 le consensus asynchrone, l'exécution asynchrone et le stockage asynchrone 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, le processus de traitement plus segmenté et l'utilisation des ressources plus efficace.

Conception centrale :

• Le processus de consensus (couche de consensus) ne s'occupe que de l'ordonnancement 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

L'Ethereum traditionnel utilise un modèle d'exécution strictement sériel 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 tous 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 les transactions accèdent au même état (comme des conflits de lecture/écriture).
• En cas de détection d'un conflit, les transactions conflictuelles seront sérialisées et réexécutées pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : modifier le moins possible les règles de l'EVM, en réalisant le parallélisme par le biais du report de l'écriture des états et de la détection dynamique des conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, servant d'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 hautes performances et modulaire compatible avec l'EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée 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 programmées de manière indépendante, afin d'atteindre une exécution concurrente élevée et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + le DAG de dépendance d'état (Directed Acyclic Graph) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers la "threadisation sur chaîne".

Architecture Micro-VM : Le compte est un fil

MegaETH introduit un modèle d'exécution de « micro-machine virtuelle par compte » (Micro-VM), qui « threadise » l'environnement d'exécution, fournissant ainsi l'unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par messagerie asynchrone, plutôt que par appels synchrones, permettant à de nombreuses VM d'exécuter indépendamment et de stocker de manière autonome, offrant ainsi une parallélisation naturelle.

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 (Dependency Graph) global, chaque transaction modifie quels comptes, lit quels comptes, tout cela étant modélisé en relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle, tandis que les transactions ayant des relations de dépendance seront planifié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'absence d'écriture 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 monocanale EVM, en réalisant un encapsulage de micro-machine virtuelle par unité de compte, en utilisant un graphique de dépendance d'état pour la planification des transactions, 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 perspective de niveau paradigmatique pour la construction des 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, 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 le concept d'Ethereum.

Les concepts de conception de Monad et de 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 des états, brisant les limitations d'une seule chaîne pour une extension au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, en 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 chemin de débit, avec pour objectif central d'améliorer le TPS au sein de 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 à une architecture de micro-machine virtuelle (Micro-VM). En tant que réseau blockchain L1 modulaire et à pile complète, Pharos Network repose sur un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture soutient un environnement multi-machine virtuelle (EVM et Wasm) par 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 la preuve à connaissance nulle (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 de la transaction (comme le consensus, l'exécution, le stockage) et utilise un 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é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, renforçant ainsi l'évolutivité et la performance du système.
4. Consensus modulaire et