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

I. La position et la valeur de la technologie de calcul parallèle dans l'extension de la blockchain

Le "trilemme" de la blockchain (Blockchain Trilemma) qui consiste en "sécurité", "décentralisation" et "extensibilité" révèle les compromis essentiels dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de "l'extensibilité", les solutions d'extension blockchain actuellement sur le marché se distinguent par leur paradigme, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœurs.
• Scalabilité par isolation d'état : partitionnement horizontal de l'état/Shard, par exemple sharding, UTXO, multi-sous-réseaux
• Scalabilité par externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Extensibilité déconnectée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh.
• Extension de type asynchrone et concurrent : Modèle d'acteur, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extensibilité de la blockchain comprennent : le calcul parallèle sur 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, constituant un système complet d'extensibilité "multicouche et en combinaison modulaire". Cet article met l'accent sur les méthodes d'extensibilité avec le calcul parallèle comme principal courant.

Parallélisme intra-chaîne (, se concentrant 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 des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, avec une granularité parallèle de plus en plus fine, une intensité parallèle 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é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 le projet Monad, Aptos
• Appel de niveau / MicroVM parallèle (Call-level / MicroVM) : représentant 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 non-synchronisation de la blockchain), chaque agent fonctionne comme un "processus d'agent intelligent" exécuté de manière indépendante, traitant les messages de manière asynchrone en parallèle, basé sur des événements et sans nécessité de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que Rollup ou le sharding, appartiennent aux 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 focal de cet article, mais nous l'utiliserons néanmoins pour comparer les similarités et les différences des concepts architecturaux.

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

Deuxième, chaîne d'amélioration parallèle EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à aujourd'hui, passant par plusieurs essais d'extension tels que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement en termes de débit au niveau d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents avec la plus grande base de développeurs et un potentiel écologique actuel. Par conséquent, les chaînes parallèles améliorées par l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour 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 pour des 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 redéveloppé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 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 en plusieurs étapes

Le pipelining est le principe 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 en trois dimensions. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement l'effet d'augmentation du débit et de réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte du 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 la blockchain 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 l'asynchrone au niveau du consensus, de l'exécution et du stockage grâce à l'"exécution asynchrone". Cela réduit considérablement le temps de bloc et le délai de confirmation, rendant le système plus résilient, les processus plus segmentés et l'utilisation des ressources plus efficace.

Conception de base :

• 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.
• Après la validation du consensus, entrez immédiatement dans le processus de consensus du prochain bloc, sans attendre la fin de 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", 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écutez en même temps 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 réexécutées de manière séquentielle pour garantir la validité de l'état.

Monad a choisi une voie de compatibilité : en modifiant le moins possible les règles de l'EVM, en réalisant des parallèles grâce à l'écriture d'état différée et à la détection dynamique des conflits, semblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, agissant comme un accélérateur parallèle dans le monde de l'EVM.

![Web3 et le paysage de la compétition de calcul parallèle : 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

Contrairement à la position L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulable à haute performance compatible avec EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'exécution améliorée (Execution Layer) ou de composant modulable sur Ethereum. 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 indépendamment, afin de réaliser une exécution à haute concurrence au sein de la 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 (graphique de dépendance d'état acyclique) et un mécanisme de synchronisation modulable, qui construisent ensemble un système d'exécution parallèle orienté vers "la threadisation au sein de la chaîne".

Architecture Micro-VM (micro-machine virtuelle) : le 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, 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, ce qui est naturellement parallèle.

DAG de dépendance d'état : Mécanisme de planification piloté par un graphique de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état du compte, qui maintient en temps réel un graphique de dépendance global. Chaque transaction modifie quels comptes et lit quels comptes, tous modélisés en tant que 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 de manière séquentielle ou différée selon un ordre topologique. Le graphique de dépendance garantit la cohérence de l'état et l'absence d'écriture répétée lors du 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 d'état à thread unique EVM, en réalisant un encapsulage de micro-machines virtuelles au niveau des comptes, en utilisant un graphe de dépendances d'état pour le planning 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, depuis "la structure des comptes → l'architecture de planification → le processus d'exécution", qui offre de nouvelles idées de niveau paradigme pour construire le prochain système en chaîne haute performance.

MegaETH a choisi un chemin de reconstruction : en abstraisant complètement les comptes et les contrats en VM indépendantes, et en libérant 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 distribué super basé sur la philosophie d'Ethereum.

![Web3 paysage de la compétition de calcul parallèle : 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 : 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 les limitations d'une seule chaîne pour l'expansion au niveau du réseau ; alors que Monad et MegaETH conservent l'intégrité de la chaîne unique, en s'étendant horizontalement uniquement au niveau de l'exécution, optimisant l'exécution parallèle extrême à l'intérieur d'une seule chaîne pour améliorer les performances. 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 comme Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec pour objectif central 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 de blockchain L1 modulaire et full-stack, possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture soutient le travail collaboratif entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-VM (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 asynchrone de 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 utilise un 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 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é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, ce qui renforce encore 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 réalise le partage sécurisé et l'intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking.

De plus, Pharos a reconstruit le modèle d'exécution depuis le bas du moteur de stockage grâce à des technologies telles que les arbres de Merkle multi-version, l'encodage delta, l'adressage versionné et la poussée ADS, lançant ainsi le moteur de stockage haute performance de blockchain natif Phar.