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

I. Calcul parallèle : un nouveau paradigme pour l'évolutivité de la blockchain

Le "triangle impossible" de la blockchain "sécurité", "décentralisation", "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é extrême, une participation universelle, un traitement rapide". En ce qui concerne le sujet éternel de "l'extensibilité", les solutions d'extensibilité des blockchains dominantes sur le marché sont classées selon des paradigmes, y compris :

• Exécution de l'extension améliorée : amélioration de la capacité d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur
• Isolation d'état pour l'évolutivité : partitionnement horizontal de l'état / 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 la structure : architecture modulaire, fonctionnement collaboratif, par exemple, chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Élargissement asynchrone et concurrent : Modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extension de blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, les modules 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. C'est un système complet d'extension "multicouche et combinatoire de modules". 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 du bloc. En fonction du 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 matière de performance, de modèles de développement et de philosophie architecturale, 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, ainsi qu'une complexité de programmation et une difficulté de mise en œuvre également croissantes.

• Niveau de compte de parallélisme ( Niveau de compte ) : représente le projet Solana
• Niveau objet (Object-level) : représente le projet Sui
• Transactions de niveau parallèle ( : représente le projet Monad, Aptos
• Appel de niveau / MicroVM parallèle ) Appel de niveau / 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 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 fonctionnant comme un "processus d'agent intelligent" indépendant, de manière parallèle avec des messages asynchrones, des événements déclenchés, 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 Rollup ou le sharding, appartiennent à des mécanismes de concurrence au niveau du système et ne relèvent pas du calcul parallèle au sein de la chaîne. Elles réalisent l'évolutivité 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 l'objectif principal de cet article, mais nous l'utiliserons tout de même pour comparer les différences dans les concepts architecturaux.

![Web3 Computation de parallèle paysage : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

II. Chaîne d'amélioration parallèle EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement sériel d'Ethereum a évolué jusqu'à présent, passant par des tentatives d'extension 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 actuellement les plateformes de contrats intelligents avec la plus grande base de développeurs et le potentiel écologique. Ainsi, la chaîne améliorée en parallèle de l'EVM, qui équilibre compatibilité écologique et amélioration des performances d'exécution, devient une direction importante dans la nouvelle vague 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 visant des scénarios de haute concurrence et de haute capacité d'exécution, 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 en pipeline ###Pipelining(, exécutant de manière asynchrone au niveau du consensus )Asynchronous Execution( et en utilisant la concurrence optimiste au niveau de l'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 fondamental de l'exécution parallèle des Monades, son idée centrale étant 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 à travers les blocs, afin d'améliorer le débit et de réduire la latence. Ces phases comprennent : proposition de transaction )Propose(, consensus atteint )Consensus(, exécution de transaction )Execution( et soumission de bloc )Commit(.

Exécution Asynchrone : Consensus - Exécution asynchrone découplée

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 a réalisé un consensus asynchrone, une exécution asynchrone et un stockage asynchrone grâce à l'"exécution asynchrone". Cela a considérablement réduit le temps de bloc )block time( et le délai de confirmation, rendant le système plus résilient, avec des processus de traitement plus segmentés et une utilisation des ressources plus efficace.

Conception principale :

• Le processus de consensus ) la couche de consensus ( ne s'occupe que du tri des transactions, sans exécuter la logique des contrats.
• Processus d'exécution ) couche d'exécution ( 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 exécute les transactions selon un modèle 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 ")Conflict Detector(" pour surveiller si les transactions accèdent à un 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 l'exactitude de l'état.

Monad a choisi un chemin de compatibilité : en modifiant le moins possible les règles de l'EVM, il réalise le parallélisme en retardant l'écriture des états et en détectant dynamiquement les conflits, ressemblant davantage à une version performant d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un accélérateur parallèle du monde EVM.

![Web3 parcours de calcul parallèle panorama : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

) 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 avec l'EVM. Il peut fonctionner à la fois comme une chaîne publique L1 indépendante et comme une couche d'amélioration d'exécution sur Ethereum (Execution Layer) ou comme un composant modulaire. Son objectif de conception principal est de déconstruire la logique des comptes, l'environnement d'exécution et l'état en unités minimales pouvant être planifiées de manière indépendante, afin de réaliser une exécution à haute concurrence en chaîne et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + State Dependency DAG###graphe acyclique orienté de dépendance d'état( et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le threading en chaîne".

Micro-VM) machine virtuelle légère( architecture : le compte est un fil d'exécution

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "threadise" l'environnement d'exécution, fournissant une unité d'isolement 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, favorisant ainsi le parallélisme naturel.

DAG de dépendance d'état : Mécanisme de planification basé sur le graphique de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état du compte. Le système maintient en temps réel un graphique de dépendance global )Dependency Graph(, chaque transaction modifiant quels comptes, lisant quels comptes, est entièrement modélisée en tant que relation 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 et triées en série ou différées selon un ordre topologique. Le graphique de dépendance garantit la cohérence d'é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 casse le modèle traditionnel de machine d'état à thread unique EVM, 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 niveau paradigme pour construire les systèmes en chaîne 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 parallèle ultime grâce à la 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 l'idée d'Ethereum.

![Web3 Computing Parallel Track Panorama: La meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

Les philosophies de conception de Monad et de MegaETH diffèrent considérablement de celles du sharding ) Sharding ( : le sharding divise la blockchain horizontalement en plusieurs chaînes secondaires indépendantes ) Shards (, chaque chaîne secondaire étant responsable d'une partie des transactions et des états, brisant ainsi les limitations d'une chaîne unique pour une extension au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, s'étendant uniquement horizontalement au niveau de l'exécution, optimisant ainsi l'exécution parallèle au sein de la chaîne unique pour dépasser les performances. Les deux représentent deux directions dans le chemin d'extension de la blockchain, à savoir le renforcement vertical et l'extension horizontale.

![Web3 paysage panoramique de la compétition de calcul parallèle : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(

Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l'optimisation du chemin de passage pour améliorer le TPS en chaîne, en se fixant comme objectif central le 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(. En tant que réseau blockchain L1 modulaire et full stack parallèle, Pharos Network a un 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 le réseau principal et le réseau de traitement spécial )SPNs(, et intègre des technologies avancées telles que la preuve à divulgation nulle de connaissance )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 ) telles que le consensus, l'exécution et le stockage (, et utilise un mode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et parallèle, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de )Dual VM Exécution parallèle( : Pharos prend en charge deux environnements virtuels, 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. Traitement spécial du réseau )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 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 la performance du système.
4. Consensus modulaire et mécanisme de restaking)Modular Consensus & Restaking( : Pharos introduit une flexibilité