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

Le « triangle impossible » de la blockchain, à savoir « sécurité », « décentralisation » et « évolutivité », révèle le compromis essentiel 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é maximale, une participation universelle et un traitement rapide ». Concernant le sujet éternel de l'« évolutivité », les solutions d'extension de blockchain actuellement sur le marché sont classées selon différents 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 d'état pour l'extension : division horizontale de l'état / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Extension 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 coopératif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Expansion par concurrence asynchrone : Modèle Actor, isolation des processus, piloté par message, par exemple agents, chaînes asynchrones multithread

Les solutions d'extension de la blockchain comprennent : le calcul parallèle au sein de la chaîne, Rollup, le sharding, les modules DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc. Ces solutions couvrent plusieurs niveaux, tels que l'exécution, l'état, les données et la structure, formant un système complet d'extension « multi-niveaux et combinatoire de modules ». Cet article se concentre principalement sur la méthode d'extension basée sur le calcul parallèle.

Calcul parallèle intra-chaîne, se concentrant sur l'exécution parallèle des transactions/instructions à l'intérieur des blocs. En fonction du mécanisme de parallélisme, ses méthodes d'extension peuvent être divisé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 des granularités parallèles de plus en plus fines, 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 les projets Monad, Aptos
• Appel de niveau / 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 Actor, qui appartient à un autre paradigme de calcul parallèle. En tant que système de messages inter-chaînes/asynchrone, chaque Agent fonctionne comme un « processus d'agent » indépendant, traitant de manière asynchrone les messages et événements de manière parallèle, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, comme Rollup ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne concernent pas le 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/VM. Ces solutions d'extension ne sont pas le point central de cet article, mais nous les utiliserons tout de même pour comparer les différences et similitudes des concepts architecturaux.

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

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, passant par des tentatives d'extension telles que le sharding, Rollup et les architectures modulaires, mais le goulet d'étranglement de la capacité de traitement de la couche d'exécution n'a toujours pas connu de percée fondamentale. Cependant, en même temps, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et avec le plus de potentiel écologique. Par conséquent, la chaîne parallèle EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une voie clé pour cette nouvelle évolution d'expansion. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement une architecture de traitement parallèle EVM orientée vers des scénarios de haute concurrence et de haute capacité de traitement, en se basant sur l'exécution différée et 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, 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 à plusieurs étapes

Le Pipelining est le concept de base de l'exécution parallèle des Monads, dont l'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, réalisant un traitement concurrent entre les blocs, afin d'augmenter le débit et de réduire la latence. Ces étapes comprennent : Proposition de transaction (Propose), Consensus, Exécution de transaction (Execution) et Soumission de bloc (Commit).

Exécution Asynchrone : Consensus - Exécution Découplée Asynchrone

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 réalise 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 et le délai de confirmation, rendant le système plus résilient, les processus de traitement plus segmentés et l'utilisation des ressources plus efficace.

Conception centrale :

• Le processus de consensus est uniquement responsable du tri des transactions, sans exécuter la logique des contrats.
• Le processus d'exécution est déclenché de manière asynchrone après la finalisation du consensus.
• Après la réalisation du consensus, 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 utilise un modèle d'exécution strictement sériel pour les transactions afin d'é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 « détecteur de conflits » pour surveiller si les transactions accèdent au même état.
• Si un conflit est détecté, les transactions conflictuelles seront réexécutées en série 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 d'état et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, étant un accélérateur parallèle du monde EVM.

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

Contrairement au positionnement L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulable à haute performance compatible EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration d'exécution 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 programmées de manière indépendante, 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 + State Dependency DAG (graphe de dépendance d'état acyclique) et un mécanisme de synchronisation modulable, qui ensemble construisent un système d'exécution parallèle orienté "threading au sein de la chaîne".

Architecture Micro-VM : Le compte est un fil d'exécution

MegaETH introduit un modèle d'exécution « une micro-machine virtuelle par compte », qui « threadise » l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent par messages asynchrones plutôt que par appels synchrones, permettant à de nombreuses VM d'exécuter indépendamment et de stocker indépendamment, ce qui rend le tout naturellement parallèle.

DAG de dépendance d'état : Mécanisme de planification basé sur des graphes de dépendance

MegaETH a construit un système de planification DAG basé sur la relation d'accès à l'état des comptes, le système maintient en temps réel un graphique de dépendance global, 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 les transactions avec des relations de dépendance seront planifiées et triées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit la cohérence de l'é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 brise le modèle traditionnel de machine d'état EVM à thread unique, en réalisant un encapsulage de micro-vm par unité de compte, en programmant les 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, passant de « structure de compte → architecture de planification → processus d'exécution », qui offre une nouvelle perspective de niveau paradigme pour construire des systèmes en chaîne haute performance de nouvelle génération.

MegaETH a choisi une voie de reconstruction : abstraction complète des comptes et des contrats en une VM indépendante, libérant un potentiel de parallélisme extrême grâce à une exécution asynchrone. Théoriquement, 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.

Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux du sharding : le sharding divise la blockchain horizontalement en plusieurs sous-chaînes indépendantes, chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limites d'une seule chaîne pour une extensibilité 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 d'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 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 chemin de débit, avec pour objectif principal 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 et à une architecture de micro-machine virtuelle. Pharos Network, en tant que réseau blockchain L1 modulaire et à pile complète, a pour mécanisme de calcul parallèle central ce qu'on appelle le « Rollup Mesh ». Cette architecture, par la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge plusieurs environnements de machine virtuelle (EVM et Wasm) et intègre des technologies avancées telles que les preuves à connaissance zéro (ZK) et les environnements d'exécution de confiance (TEE).

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

1. Traitement asynchrone des pipelines tout au long du cycle de vie : Pharos découple les différentes étapes de la transaction et adopte une approche de traitement asynchrone, permettant à chaque étape de s'exécuter de manière indépendante et parallèle, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de deux machines virtuelles : Pharos prend en charge deux environnements de machines virtuelles, EVM et WASM, permettant aux développeurs de choisir l'environnement d'exécution approprié selon 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, renforçant ainsi l'évolutivité et les performances du système.
4. Mécanisme de consensus modulaire et de re-staking : Pharos introduit un mécanisme de consensus flexible, prenant en charge plusieurs modèles de consensus, et réalise le partage sécurisé et l'intégration des ressources entre le réseau principal et les SPNs grâce à un protocole de re-staking.

De plus, Pharos a reconstruit le modèle d'exécution à partir du moteur de stockage de bas niveau grâce à des arbres Merkle multi-version, un codage différentiel, un adressage versionnel et la technologie de descente ADS, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, qui permet un traitement élevé, une faible latence et une forte vérifiabilité des opérations sur la chaîne.