Panorama du secteur de calcul parallèle Web3 : la meilleure solution d'évolutivité native ?

I. Introduction

Le "trilemme" de la blockchain (Blockchain Trilemma) "sécurité", "décentralisation", "scalabilité" révèle le compromis essentiel dans la conception des systèmes de blockchain, c'est-à-dire que les projets de blockchain ont du mal à réaliser simultanément "une sécurité extrême, une participation universelle, un traitement rapide". En ce qui concerne le sujet éternel de la "scalabilité", les solutions d'extension de blockchain dominantes sur le marché sont classées selon des paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
• Type d'extension par isolation d'état : décomposition horizontale de l'état / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux.
• Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Type d'extension découplé : architecture modulaire, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle d'Acteur, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multi-thread.

Les solutions d'extension de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, le module DA, une structure modulaire, le système Actor, la compression par preuve zk, l'architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système d'extension complet "multicouche et combinatoire de modules". Cet article se concentre principalement sur les méthodes d'extension basées 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 au sein des blocs. 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 ambitions de performance, modèles de développement et philosophies d'architecture, 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 (Account-level) : représente le projet Solana
• Parallélisme au niveau des objets (Object-level) : représente le projet Sui
• Niveau de transaction (Transaction-level) : représente le projet 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'entités Actor (Agent / Actor Model), ils appartiennent à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes / asynchrone (modèle de non-synchronisation de blocs), chaque Agent agissant comme un "processus d'agent intelligent" fonctionnant indépendamment, de manière parallèle avec des messages asynchrones, piloté par des événements, sans besoin de planification synchronisée, des 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 du système et ne font pas partie 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", plutôt qu'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 sujet principal de cet article, mais nous l'utiliserons néanmoins pour comparer les différences de concepts architecturaux.

Deuxième, chaîne renforcée par la parallélisation EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué au fil du temps, passant par des tentatives d'extension telles que le sharding, les Rollups et les architectures modulaires, mais le goulot d'étranglement en termes de débit de la couche d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus populaires en termes de base de développeurs et de potentiel écologique. Ainsi, la chaîne parallèle EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé dans 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 orientée vers des scénarios de haute concurrence et de haut débit, respectivement à partir de l'exécution différée et de la décomposition des états.

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 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 concept de base de l'exécution parallèle des monades, dont l'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 fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent à travers 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), l'atteinte du consensus (Consensus), l'exécution de la transaction (Execution) et la soumission du bloc (Commit).

Exécution Asynchrone : Consensus - Exécution du découplage asynchrone

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce qui limite gravement l'évolutivité des performances. Monad réalise une exécution asynchrone grâce à "l'exécution asynchrone", permettant un consensus asynchrone, une exécution asynchrone et un stockage 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 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, passez immédiatement au processus de consensus du prochain bloc, sans attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

L'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", 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 simultanément un "Détecteur de Conflits (Conflict Detector))" pour surveiller si les transactions accèdent au même état (par exemple, conflit de lecture / écriture).
• Si un conflit est détecté, les transactions conflictuelles seront réexécutées de manière séquentielle pour garantir l'exactitude de l'état.

Monad a choisi un chemin de compatibilité : en modifiant le moins possible les règles de l'EVM, en réalisant la parallélisation grâce au report de l'écriture de l'état et à la détection dynamique des conflits, ressemblant 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 de parallélisation dans le monde de l'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 hautes performances modulaires compatible avec l'EVM, pouvant fonctionner à la fois comme une chaîne publique L1 indépendante et comme une couche d'amélioration d'exécution sur Ethereum ou un 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 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 (graphe acyclique dirigé de dépendance d'état) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté "multithread au sein de la chaîne".

Architecture Micro-VM : le compte est un fil

MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "filialise" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour le plan de parallélisation. 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 de manière indépendante et de stocker de manière indépendante, naturellement en parallèle.

DAG de dépendance d'état : Mécanisme de planification basé sur un graphe 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 certains comptes et lit d'autres comptes, le tout modélisé sous forme de 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 planifiées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit la cohérence des états et évite les é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 mono-thread EVM, en réalisant un encapsulage de micro-machine virtuelle par unité de compte, en utilisant un graphique 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, passant de "structure de compte → architecture de planification → processus d'exécution", qui offre une nouvelle perspective de niveau paradigmatique pour la construction de systèmes en ligne haute performance de nouvelle génération.

MegaETH a choisi une voie de reconstruction : il abstrait complètement les comptes et les contrats en une VM indépendante, libérant ainsi 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 système d'exploitation super distribué sous l'idée d'Ethereum.

Monad et MegaETH ont des philosophies de conception très différentes de celles du 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 des états, brisant ainsi la limitation d'une chaîne unique pour une extension au niveau du réseau ; alors que Monad et MegaETH conservent l'intégrité de la chaîne unique, ne s'étendant que horizontalement au niveau de la couche d'exécution, optimisant l'exécution parallèle maximale à 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 débit, avec pour objectif central d'améliorer le TPS sur la chaîne. Cela est réalisé grâce à l'exécution différée (Deferred Execution) et à l'architecture de micro-virtualisation (Micro-VM) pour un traitement parallèle au niveau des transactions ou des comptes. Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture, grâce à la coopération 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 zéro connaissance (ZK) et les environnements d'exécution de confiance (TEE).

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

1. Traitement asynchrone en 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 de manière indépendante et parallèle, ce qui améliore l'efficacité globale du traitement.
2. Exécution parallèle à double machine virtuelle (Dual VM Parallel Execution) : 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. 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 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 la performance du système.
4. Consensus modulaire et mécanisme de restaking (Modular Consensus & Restaking) : Pharos a introduit un mécanisme de consensus flexible, supportant divers modèles de consensus (comme PBFT, PoS, PoA), et par le biais de restaking.