Vue d'ensemble du paysage de la compétition de calcul parallèle Web3 : la meilleure solution d'expansion native ?

I. Classification et paradigmes technologiques du calcul parallèle Web3

Le « triangle impossible » de la blockchain (Blockchain Trilemma) « sécurité », « décentralisation », « é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é extrême, une participation universelle, un traitement rapide ». Concernant le sujet éternel de l'« évolutivité », les solutions de scalabilité blockchain dominantes sur le marché sont classées selon des paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœur
• Isolation de l'état pour l'évolutivité : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, multi-sous-réseaux
• Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité par découplage de la structure : modularité de l'architecture, fonctionnement coopératif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Extension 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 intra-chaîne, le Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture sans état, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure. C'est un système complet d'extension "multi-niveaux collaboratif et combiné par 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 à l'intérieur du bloc. En fonction du mécanisme de parallélisme, ses méthodes d'extensibilité peuvent être divisées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec une granularité de parallélisme de plus en plus fine, 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èle 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 / 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'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 synchronisation non blockchain), chaque Agent fonctionne comme un "processus intelligent" autonome, échangeant des messages de manière asynchrone en mode parallèle, basé sur des événements, sans nécessiter de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle que nous connaissons bien, comme les Rollups ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne concernent pas le 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", et non en améliorant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ces solutions de mise à l'échelle ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les différences de concepts architecturaux.

Deuxième, EVM chaîne d'amélioration parallèle : dépasser 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, le Rollup et l'architecture modulaire, mais le goulot d'étranglement du débit au niveau de l'exécution n'a toujours pas été fondamentalement surmonté. Cependant, en même temps, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus importants. Ainsi, la chaîne parallèle de l'EVM, en tant que voie clé pour concilier la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction importante pour la nouvelle phase d'évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement une architecture de traitement parallèle EVM axée sur des scénarios à haute concurrence et à haut débit, en se basant sur l'exécution différée et 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), exécutant de manière asynchrone au niveau du consensus (Asynchronous Execution) et en parallèle optimiste au niveau de l'exécution (Optimistic Parallel Execution). De plus, au niveau du consensus et de la couche de stockage, Monad introduit respectivement un protocole BFT haute performance (MonadBFT) et un système de base de données spécialisé (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 Monads. Son idée centrale est de décomposer 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 en trois dimensions. Chaque phase fonctionne sur des threads ou des cœurs indépendants, réalisant un traitement concurrent entre les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases 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 la chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce qui 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 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 fragmenté 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.
• Après la complétion du consensus, le processus de consensus du prochain bloc commence immédiatement, sans attendre l'achèvement de 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 é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écute 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écuter simultanément un « Détecteur de conflits (Conflict Detector)) » pour surveiller si les transactions accèdent au même état (par exemple, conflits de lecture / écriture).
• Si un conflit est détecté, les transactions conflictuelles seront réexécutées en série pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : minimiser les modifications des règles EVM, et réaliser le parallélisme en retardant l'écriture de l'état et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, faisant de lui un accélérateur de parallélisme 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, compatible EVM et modulaire, pouvant à la fois servir de blockchain publique L1 autonome ou 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 hautement concurrente 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 + State Dependency DAG (graphique de dépendance d'état acyclique) et les mécanismes de synchronisation modulaires, construisant ensemble un système d'exécution parallèle orienté vers le « threading au sein de la chaîne ».

Architecture Micro-VM : Le compte est un fil d'exécution

MegaETH introduit un modèle d'exécution « une micro-machine virtuelle (Micro-VM) par compte », qui « threadise » l'environnement d'exécution, fournissant une unité d'isolation minimale pour le planificateur parallèle. Ces VM communiquent par messages asynchrones, plutôt que par appels synchrones, permettant à de nombreuses VM de s'exécuter indépendamment et de stocker indépendamment, offrant ainsi un parallélisme naturel.

État de dépendance DAG : 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, 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é en 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 d'état EVM à thread unique, en réalisant une encapsulation de micro-machine virtuelle par compte, en programmant les 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 perspective 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, en utilisant la planification d'exécution asynchrone pour libérer un potentiel de parallélisme extrême. 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.

Les philosophies de conception de Monad et MegaETH diffèrent considérablement de celles 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 ainsi la limite d'une seule chaîne pour l'expansion 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 d'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 de l'expansion de la blockchain, à savoir 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 de blockchain L1 modulaire et full-stack, a un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture, par la coopération entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge un environnement multi-machine virtuelle (EVM et Wasm) 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écompose les différentes étapes des transactions (telles que 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