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

I. Calcul parallèle : le chemin clé pour l'extensibilité de la blockchain

Le "triangle impossible" de la blockchain "sécurité", "décentralisation", "extensibilité" révèle le compromis essentiel dans la conception des systèmes de blockchain, à savoir qu'il est difficile pour les projets blockchain de réaliser simultanément "une sécurité optimale, une participation universelle, un traitement rapide". En ce qui concerne le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain actuellement 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, GPU, multicœur.
• Isolation de l'état pour l'extension : partitionnement horizontal de l'état/Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Scalabilité de type externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité par découplage structurel : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle Actor, isolation des processus, pilotage par message, par exemple agents, chaîne asynchrone multithread

Les solutions d'extensibilité de la blockchain incluent : 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'extensibilité "multi-niveaux, combinaison modulaire". Cet article se concentre sur les méthodes d'extensibilité principalement basées sur le calcul parallèle.

Calcul parallèle intra-chaîne (, se concentrant sur l'exécution parallèle des transactions/instructions au sein du bloc. En fonction des mécanismes de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant différentes quêtes de performance, modèles de développement et philosophies architecturales, 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èle au niveau du compte ) Niveau du compte ( : représente le projet Solana
• Parallélisme au niveau des objets ) Object-level ( : représente le projet Sui
• Niveau de transaction parallèle)Transaction-level(: Représente le projet Monad, Aptos
• Niveau d'appel / MicroVM parallèle ) Niveau d'appel / 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 non synchronisé (, chaque Agent fonctionne comme un "processus d'agent" indépendant, de manière asynchrone avec des messages, des événements déclenchés, sans planification synchronisée, 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'extensibilité en "faisant fonctionner plusieurs chaînes/domaines d'exécution en parallèle", plutôt qu'en améliorant le degré de parallélisme à l'intérieur d'un seul bloc/ machine virtuelle. Ces solutions d'extensibilité ne sont pas le principal sujet de cet article, mais nous les utiliserons néanmoins pour comparer les différences de concepts d'architecture.

![Web3 parallèle calcul domaine panorama : La meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

Deuxième, Chaîne d'amélioration parallèle EVM : Briser les frontières de performance dans la compatibilité

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension, telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de la capacité de traitement de la couche d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et possédant un potentiel écologique. Ainsi, les chaînes parallèles renforcées par l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la prochaine évolution d'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, chacun construisant une architecture de traitement parallèle EVM axée sur des scénarios de haute concurrence et de haute capacité de traitement, en partant de l'exécution différée et de la décomposition de l'état.

) Analyse du mécanisme de calcul parallèle de Monad

Monad est une blockchain de 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 utilisant l'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 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 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 tridimensionnelle, avec chaque étape s'exécutant sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre 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 : Découplage Asynchrone de la Consensus et de l'Exécution

Dans les chaînes traditionnelles, 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 réduit considérablement le temps de bloc )block time( 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 de base:

• Processus de consensus ) couche de consensus ( ne s'occupe que du tri des transactions, sans exécuter la logique des contrats.
• Le processus d'exécution ) déclenche de manière asynchrone après l'achèvement du consensus sur le niveau d'exécution (.
• Une fois le consensus terminé, 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

Ethereum traditionnel utilise un modèle d'exécution strictement sériel 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, 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 conflictuelles seront sérialisées et réexécutées pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme au cours de l'exécution par le biais du retardement de l'écriture des états et de la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, c'est un accélérateur de parallélisme dans le monde de l'EVM.

![Web3 chemin de calcul parallèle carte panoramique : la meilleure solution d'extensibilité native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

) Analyse du mécanisme de calcul parallèle de MegaETH

Différent du positionnement L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulaire haute performance compatible avec EVM, pouvant 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 de compte, 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 et une faible latence à l'intérieur 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 orienté( et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "la threadisation au sein de la chaîne".

Micro-VM) machine virtuelle micro( architecture : compte équivaut à un fil

MegaETH introduit le modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "threadise" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour le planificateur 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 indépendamment et de stocker de manière autonome, offrant ainsi un 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 des comptes. Le système maintient en temps réel un graphique de dépendance global )Dependency Graph(, modélisant toutes les transactions qui modifient quels comptes et lisent quels comptes en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle, tandis que celles avec des relations de dépendance seront programmées et triées de manière séquentielle ou différée selon un ordre topologique. Le graphique de dépendance garantit la cohérence des états 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 brise le modèle traditionnel de machine à états à thread unique EVM, en réalisant un emballage de micro-machine virtuelle par unité de compte, en utilisant un graphe 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, passant de la "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle approche de niveau paradigme pour construire des 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, et libérer un potentiel de parallélisme extrême grâce à une 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 la philosophie d'Ethereum.

![Web3 paysage complet de la piste de calcul parallèle : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

Les concepts de conception de Monad et de MegaETH diffèrent considérablement de ceux du sharding )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 ainsi la limitation de la chaîne unique pour l'extension au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, en s'étendant uniquement au niveau de l'exécution, optimisant l'exécution parallèle extrême à 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 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, grâce à la coopération entre le réseau principal et le réseau de traitement spécial )SPNs(, prend en charge un environnement multi-machine virtuelle )EVM et Wasm(, et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance )ZK( et les environnements d'exécution de confiance )TEE(.

Analyse du mécanisme de calcul parallèle Rollup Mesh:

1. Traitement de pipeline asynchrone sur tout le cycle de vie )Full Lifecycle Asynchronous Pipelining( : Pharos découple les différentes étapes de la transaction ) telles que le consensus, l'exécution, le stockage ( et adopte une approche 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 )Exécution parallèle de deux VM (: 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. Traitement spécial du réseau )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 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, améliorant 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 ) tels que PBFT, PoS, PoA (, et permet un partage sécurisé et une intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking )Restaking (.

De plus, Pharos a reconstruit le modèle d'exécution à partir du moteur de stockage sous-jacent grâce à des techniques telles que les arbres Merkle multi-version, l'encodage Delta ), l'adressage versionné ( et l'immersion ADS ), lançant ainsi le moteur de stockage haute performance Pharos Store pour les blockchains natifs, réalisant une capacité de traitement en chaîne à haut débit, faible latence et fortement vérifiable.

![