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

I. Aperçu des techniques de calcul parallèle

Le "trilemme" de la blockchain (Blockchain Trilemma) "sécurité", "décentralisation", "évolutivité" 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é ultime, une participation universelle et un traitement rapide". Concernant le sujet éternel de "l'évolutivité", les solutions de mise à l'échelle des blockchains dominantes sur le marché sont classées par paradigmes, y compris :

• Exécution d'une extension améliorée : augmentation des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Isolation de l'état pour l'évolutivité : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, multi-sous-réseaux
• Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par structure : modularité de l'architecture, fonctionnement coopératif, par exemple chaînes modulaires, ordonnanceurs partagés, Rollup Mesh
• Extension de type asynchrone et concurrent : modèle d'acteur, isolation des processus, pilotage par message, par exemple agents, chaîne asynchrone multi-thread

Les solutions d'extension de la blockchain comprennent : le calcul parallèle intra-chaîne, Rollup, le sharding, le module DA, une structure modulaire, un système Actor, la compression des preuves zk, une architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un "système complet d'extension en collaboration multi-niveaux et en combinaison de modules". Cet article se concentre sur la méthode d'extension principalement 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 du bloc. En fonction des mécanismes de parallélisme, ses méthodes d'extensibilité 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 philosophies architecturales, avec un degré de parallélisme de plus en plus fin, une intensité de parallélisme de plus en plus élevée, ainsi qu'une complexité de planification et une complexité de programmation et 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
• Niveau de transaction parallèle (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 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 de synchronisation non blockchain), chaque Agent fonctionne comme un "processus intelligent" indépendant, utilisant un mode parallèle de messages asynchrones, piloté par des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que les Rollups ou les shards, relèvent de mécanismes de concurrence au niveau du système et ne concernent pas le calcul parallèle au sein de la chaîne. Elles réalisent l'expansion 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. Ces solutions d'extension ne sont pas le point central de cet article, mais nous les utiliserons néanmoins pour comparer les différences dans les concepts architecturaux.

II. EVM Système de chaîne parallèle amélioré : Briser les limites de performance dans la compatibilité

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extensibilité, telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, en même temps, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et dotées d'un potentiel écologique. Ainsi, la chaîne d'amélioration parallèle de l'EVM devient une voie clé pour concilier compatibilité écologique et amélioration des performances d'exécution, et elle est en train de devenir une direction importante pour la prochaine évolution de l'extensibilité. 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 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), avec une exécution asynchrone au niveau de consensus (Asynchronous Execution) et une exécution parallèle optimiste au niveau d'exécution (Optimistic Parallel Execution). De plus, au niveau de consensus et de 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 à plusieurs étapes

Le Pipelining est le concept 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 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 une augmentation du débit et une réduction de la latence. Ces étapes comprennent : la proposition de transaction (Propose), la réalisation du consensus (Consensus), l'exécution de la transaction (Execution) et la soumission du bloc (Commit).

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

Dans une chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement des processus synchronisés, ce modèle sériel limite gravement l'extensibilité 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, les processus plus segmentés et l'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.
• Le processus d'exécution (couche d'exécution) est déclenché de manière asynchrone après la finalisation du consensus.
• Une fois le consensus atteint, entrez immédiatement dans le 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", 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 conflit (Conflict Detector))" pour surveiller si les transactions accèdent au même état (par exemple, des 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, il réalise le parallélisme en retardant l'écriture des états et en détectant dynamiquement les conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, en faisant de lui un accélérateur de parallélisme dans le monde 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 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 des comptes, 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 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 (graphique acyclique dirigé de dépendance d'état) et le mécanisme de synchronisation modulable, construisant ensemble un système d'exécution parallèle orienté "threading au sein de la chaîne".

Architecture Micro-VM : le compte comme fil d'exécution

MegaETH introduit un modèle d'exécution de "micro-VM par compte", qui "filéralise" l'environnement d'exécution, fournissant une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent par le biais de messages asynchrones, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter et de stocker indépendamment, offrant ainsi un véritable parallélisme.

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 aux états de compte, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifie quels comptes, lit quels comptes, tout est modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, 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 des états 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 rompt avec le modèle traditionnel de machine d'état à thread unique EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en effectuant la planification des transactions via un graphique 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, de "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles perspectives de niveau paradigme pour construire des systèmes en ligne de 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, en libérant un potentiel parallèle extrême grâce à un ordonnancement 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 Parallel Computing Track Panorama : la meilleure solution pour la mise à l’échelle native ?] ](https ://img-cdn.gateio.im/social/moments-9c4a4c4309574e45f679b2585d42ea16)

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 les limitations d'une chaîne unique pour étendre au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, s'étendant horizontalement uniquement au niveau de l'exécution, optimisant l'exécution parallèle extrême à l'intérieur de la chaîne unique pour améliorer les performances. Les deux représentent des directions de renforcement vertical et d'extension horizontale dans les chemins d'expansion de la blockchain.

Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l'optimisation du chemin de débit, avec pour objectif principal d'augmenter le TPS intra-chaîne. Ils réalisent 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). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a pour mécanisme de calcul parallèle central ce qu'on appelle "Rollup Mesh". Cette architecture, par le travail collaboratif entre la chaîne principale et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-machines virtuelles (EVM et Wasm) et intègre des technologies avancées telles que la preuve à connaissance nulle (ZK) et l'environnement d'exécution de confiance (TEE).

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

1. Traitement de pipeline asynchrone 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 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 (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 non seulement améliore 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, 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, supportant plusieurs modèles de consensus (comme PBFT, PoS,