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

Le « triangle impossible » de la blockchain (Blockchain Trilemma) – « sécurité », « décentralisation », « évolutivité » – 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é absolue, une participation universelle, un traitement rapide ». En ce qui concerne le sujet éternel de « l'évolutivité », les solutions d'extension des blockchains actuellement sur le marché sont classées selon des paradigmes, notamment :

• Exécution de l'extension améliorée : amélioration des capacités d'exécution sur place, par exemple en parallèle, GPU, multicœurs.
• Isolation des états pour l'extension : partitionnement horizontal des états / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Scalabilité par externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité par découplage de structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnateur partagé, Rollup Mesh
• Extension concurrent asynchrone : Modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithreads

Les solutions d'extensibilité de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, les modules DA, la structure modulaire, le système Actor, la compression de 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'extensibilité « multi-niveau et combinaison de modules ». Cet article se concentre sur la méthode d'extensibilité axé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 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 différentes quêtes de performance, modèles de développement et philosophies architecturales, avec des granularités de parallélisme de plus en plus fines, une intensité de parallélisme de plus en plus élevée, une complexité de planification de plus en plus importante, et une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.

• Parallèle 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 de niveau transactionnel (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 messagerie inter-chaînes / asynchrone (modèle non synchronisé par blocs), chaque agent fonctionne comme un « processus intelligent » indépendant, avec une communication asynchrone par messages et événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension telles que Rollup ou le 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'extension en "exécutant 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. Ce type de solution d'extension n'est pas le point central de cet article, mais nous l'utiliserons néanmoins pour comparer les similarités et les différences des concepts d'architecture.

II. 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, ayant traversé plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement du débit au niveau de la couche d'exécution n'a toujours pas été fondamentalement résolu. Cependant, en même temps, EVM et Solidity restent les plateformes de contrats intelligents avec la plus grande base de développeurs et un 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 le cadre de la nouvelle é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 axée sur 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 principe fondamental du traitement en pipeline (Pipelining) et exécutant de manière asynchrone au niveau du consensus (Asynchronous Execution) et en utilisant la concurrence 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), réalisant une optimisation de bout en bout.

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

Le Pipelining est le concept fondamental de l'exécution parallèle des Monades. Son 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 en trois dimensions. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs et, finalement, améliorant le débit et réduisant la latence. Ces étapes incluent : 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 de transaction et l'exécution sont généralement des processus synchrones, et ce modèle sériel limite gravement l'évolutivité des performances. Monad a réalisé l'asynchronisme de la couche de consensus, l'asynchronisme de la couche d'exécution et l'asynchronisme du stockage grâce à "l'exécution asynchrone". Cela réduit considérablement 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 centrale :

• 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 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 : Optimistic Parallel Execution

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 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 (comme les 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 modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme à travers le report de l'écriture d'état et la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, en tant qu'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 modulaire haute performance compatible EVM, pouvant agir à la fois comme une blockchain publique L1 indépendante et comme une couche d'amélioration d'exécution (Execution Layer) ou un composant modulaire sur Ethereum. 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 indépendamment planifiables, afin de réaliser une exécution à haute concurrence 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 le mécanisme de synchronisation modulaire, qui ensemble construisent un système d'exécution parallèle orienté vers "la threadisation au sein de la chaîne".

Architecture Micro-VM : compte est un fil

MegaETH introduit un modèle d'exécution de « micro-machine virtuelle (Micro-VM) par compte », qui « threadise » 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 à de nombreuses VM d'exécuter de manière indépendante et de stocker de manière indépendante, ce qui est naturellement 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, qui 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é 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 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 casse le modèle traditionnel de machine d'état EVM à thread unique en réalisant un encapsulage 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 une perspective complète de « structure de compte → architecture de planification → processus d'exécution », offrant une nouvelle approche de paradigme pour construire des systèmes en ligne de haute performance de nouvelle 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 aussi plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation super distribué basé sur l'idée 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 la limitation d'une chaîne unique pour une 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 de l'exécution, optimisant ainsi l'exécution parallèle interne de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin d'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 Micro-VM. Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a pour mécanisme de calcul parallèle central ce que l'on appelle le « Rollup Mesh ». Cette architecture, grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-virtual machines (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é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 indépendamment et en 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 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éciaux (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, semblables à 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 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, PoS, PoA), et grâce au protocole de restaking (