Panorama de la piste de calcul parallèle Web3 : la meilleure solution d'extension native ?

I. Aperçu du contexte

Le "triangle impossible" de la blockchain "sécurité", "décentralisation", "scalabilité" révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité ultime, une participation universelle, un traitement rapide". Concernant le sujet éternel de la "scalabilité", les solutions d'extension de blockchain actuellement sur le marché sont classées selon des paradigmes, y compris:

• Exécuter une extension améliorée : améliorer la capacité d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Isolation de l'état par extension : division horizontale de l'état / Shard, par exemple le sharding, UTXO, plusieurs sous-réseaux
• Scalabilité hors chaîne par externalisation : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par la structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Extension de type concurrent asynchrone : modèle Actor, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'évolutivité 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 tels que l'exécution, l'état, les données et la structure. C'est un "système d'évolutivité complet basé sur une collaboration multi-niveaux et une combinaison modulaire". Cet article met l'accent sur les méthodes d'évolutivité dominées par 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 de la blockchain. 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 aspirations en matière de performance, de modèles de développement et de philosophie 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 également croissante, ainsi qu'une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.

• Niveau de compte parallèle ( Niveau de compte ) : représente le projet Solana
• Parallélisme de niveau objet ( : représente le projet Sui
• Niveau de transaction parallèle ) Transaction-level ( : représente les projets Monad, Aptos
• Appel niveau/ Micro VM parallèle ) Appel-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 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 non-synchrone de blocs (, chaque agent fonctionne comme un "processus d'agent intelligent" indépendant, de manière parallèle avec des messages asynchrones, orienté événements, sans planification synchrone. Les 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, relèvent de mécanismes de concurrence au niveau système et ne font pas partie 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 augmentant le degré de parallélisme à l'intérieur d'un seul bloc/VM. 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 conception architecturale.

![Web3 Computation Parallel Track Overview: La meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

II. Chaîne améliorée de parallélisme EVM : Dépasser les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant subi plusieurs tentatives d'extension, notamment 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 résolu. Cependant, en même temps, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents avec la plus grande base de développeurs et le potentiel écologique. Par conséquent, les chaînes parallèles basées sur l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la nouvelle évolution des extensions. 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 de haute concurrence et de haut débit à partir 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 Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le traitement en pipeline ###Pipelining(, qui est un concept fondamental de parallélisme. Il exécute de manière asynchrone au niveau de consensus )Asynchronous Execution( et utilise 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(, permettant 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 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 tridimensionnelle. Chaque étape s'exécute 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(, 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é l'asynchrone au niveau du consensus, l'asynchrone au niveau de l'exécution et l'asynchrone au niveau du stockage 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, avec des processus de traitement plus segmentés et une 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.
• Processus d'exécution ) couche d'exécution ( déclenché de manière asynchrone après la complétion du consensus.
• Après la consensus, le processus de consensus du prochain bloc commence immédiatement, sans attendre la fin de l'exécution.

Exécution parallèle optimiste : Exécution parallèle optimiste

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écutera 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 ) 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 compatible : en modifiant autant que possible les règles de l'EVM, en réalisant le parallélisme en retardant l'écriture d'état et en détectant dynamiquement les conflits, ce qui le rend plus comme une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, c'est un accélérateur parallèle dans le monde de l'EVM.

![Web3 et le paysage des compétitions de calcul parallèle : 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, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'augmentation 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 d'atteindre une exécution haute concurrence 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 d'acyclicité orientée des dépendances d'état( et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le threading interne de la chaîne".

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

MegaETH introduit le modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "threadise" l'environnement d'exécution, fournissant 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 indépendamment et de stocker de manière autonome, naturellement en parallèle.

Mécanisme de planification basé sur un graphe de dépendance : DAG 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 relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, tandis que les transactions avec des relations de dépendance seront planifiées et triées en série ou retardées selon l'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 somme, MegaETH brise le modèle traditionnel de machine d'état à thread unique EVM, en réalisant l'encapsulation de micro-machines virtuelles au niveau du compte, en utilisant un graphe de dépendance d'état pour le plan de transaction, 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 → flux d'exécution", fournissant une nouvelle approche de niveau paradigme pour la construction des systèmes en ligne haute performance de prochaine génération.

MegaETH a choisi une voie de reconstruction : abstraire complètement les comptes et les contrats en VM indépendants, 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 également plus difficile de contrôler la complexité, ressemblant davantage à un super système d'exploitation distribué sous l'idée d'Ethereum.

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

La conception de Monad et MegaETH diffère considérablement de celle du sharding )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 de l'état, brisant les limites d'une chaîne unique pour s'étendre 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 les performances par une exécution parallèle extrême à l'intérieur de la chaîne unique. Les deux représentent deux directions 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 en 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, a un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture soutient un environnement multi-VM )EVM et Wasm( grâce à la collaboration entre le réseau principal et un réseau de traitement spécial )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 de pipeline sur l'ensemble du cycle de vie )Full Lifecycle Asynchronous Pipelining( : Pharos découple les différentes étapes des transactions ) telles que le consensus, l'exécution, le stockage ( et adopte une méthode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et en parallèle, ce qui améliore l'efficacité globale du traitement.
2. Exécution parallèle de double VM)Exécution parallèle de double 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 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) tels que PBFT, PoS, PoA(, et réalise le partage sécurisé et l'intégration des ressources entre la chaîne principale et les SPNs via le protocole de restaking)Restaking(.