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

Le "triangle impossible" de la blockchain, comprenant "sécurité", "décentralisation" et "extensibilité", 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é maximale, une participation universelle et un traitement rapide". En ce qui concerne le sujet éternel de "l'extensibilité", les solutions de scalabilité 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èle, GPU, multicœur.
• Isolation de l'état pour l'extensibilité : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, plusieurs 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 structurel : modularité de l'architecture, fonctionnement coopératif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Extension de type asynchrone et concurrent : Modèle Actor, isolation des processus, piloté par des messages, par exemple agents, chaînes asynchrones multi-threads.

Les solutions d'extension de la chaîne de blocs comprennent : le calcul parallèle au sein de la chaîne, le 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 collaboratif, combinaison modulaire". 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 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 différentes aspirations en termes de performance, de modèles de développement et de 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 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 (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 des messages asynchrones en parallèle, déclenchés par des événements, sans planification synchronisée, des projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle que nous connaissons bien, telles que les Rollups 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 la mise à l'échelle 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. Ce type de solution de mise à l'échelle n'est pas le point central de cet article, mais nous l'utiliserons néanmoins pour comparer les similarités et les différences conceptuelles de l'architecture.

Deux, Chaîne d'amélioration parallèle EVM : franchir 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, le Rollup 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 les plus prometteuses en termes de base de développeurs et de potentiel écologique. Ainsi, les chaînes parallèles de l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une voie clé pour la nouvelle évolution d'extensibilité. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant une architecture de traitement parallèle de l'EVM axée sur les scénarios à haute concurrence et à haut débit, en partant 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 une exécution asynchrone au niveau du consensus (Asynchronous Execution) et une exécution parallèle 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 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 monades. Son idée principale 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 tridimensionnelle. Chaque phase s'exécute 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), atteinte du consensus (Consensus), exécution de la transaction (Execution) et soumission du 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 (block time) et le délai de confirmation, rendant le système plus résilient, les processus de traitement plus segmentés et l'utilisation des ressources plus efficace.

Conception principale :

• 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.
• 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équentiel pour éviter les conflits d'état. En revanche, Monad adopte une stratégie « d'exécution parallèle optimiste », augmentant 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 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 validité de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, et en réalisant le parallélisme par le biais d'un état d'écriture différé et d'une détection dynamique des conflits pendant l'exécution, 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 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 compatible avec l'EVM. Elle peut servir à la fois de chaîne 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 indépendamment planifiables, 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 + DAG de dépendance d'état (Directed Acyclic Graph) et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers la "threadisation au sein de la chaîne".

Architecture Micro-VM : compte équivaut à un fil

MegaETH introduit le modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte", qui "threadise" l'environnement d'exécution, offrant une unité d'isolation minimale 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 à un grand nombre de VM d'exécuter de manière indépendante et de stocker de manière indépendante, ce qui favorise la 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, 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 et triées en série ou différées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'absence d'écritures redondantes 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 à un seul thread EVM, en réalisant un encapsulage de micro-vm par compte, en effectuant la planification 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, allant de « structure de compte → architecture de planification → processus d'exécution », offrant une nouvelle approche de paradigme pour la construction de systèmes de 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, afin de libérer un potentiel de parallélisme extrême grâce à l'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 philosophies de conception très différentes de celles du sharding : le sharding divise la blockchain horizontalement en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limitations d'une chaîne unique en matière d'évolutivité 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, réalisant des optimisations de performance grâce à une exécution parallèle maximale au sein de la chaîne unique. Les deux représentent deux directions différentes 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 principal 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-VM (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture prend en charge un environnement multi-VM (EVM et Wasm) grâce à la coopération 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 phases des transactions (comme le consensus, l'exécution, le stockage) et utilise un traitement asynchrone, permettant à chaque phase 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 machines virtuelles, 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 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. Mécanisme de consensus modulaire et de re-staking (Mo