Panorama des pistes de calcul parallèle Web3 : la meilleure solution d'extensibilité native ?

I. Le sujet éternel de l'extension de la blockchain

Le "trilemme" de la blockchain (Blockchain Trilemma) - "sécurité", "décentralisation", "extensibilité" - révèle les compromis essentiels dans la conception des systèmes de blockchain, à savoir qu'il est difficile pour les projets de blockchain d'atteindre simultanément "une sécurité maximale, une participation universelle, et un traitement rapide". En ce qui concerne le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain dominantes sur le marché sont classées selon différents paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple via le parallélisme, le GPU et le multicœur.
• Scalabilité par isolation d'état : partitionnement horizontal de l'état/Shard, par exemple, sharding, UTXO, multi-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 asynchrone et concurrent : modèle Actor, isolation des processus, piloté par les messages, 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, 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'extension "multi-niveau, coopération et combinaison modulaire". 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 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 différentes aspirations en matière de performance, de modèles de développement et de 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 de plus en plus accrue, 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 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 fonctionnant comme un "processus intelligent" indépendant, utilisant des messages asynchrones en mode parallèle, piloté par des événements, sans planification synchrone. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de Rollup ou de sharding que nous connaissons bien appartiennent à des mécanismes de concurrence au niveau système, et non à des calculs parallèles au sein de la chaîne. Elles réalisent l'évolutivité 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/VM. Ces solutions d'évolutivité ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts d'architecture.

2. 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'à présent, ayant connu plusieurs tentatives d'extensibilité, y compris le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution reste inchangé. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et possédant un fort potentiel écologique. Ainsi, la chaîne améliorée par EVM en parallèle, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé pour la nouvelle é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 axée sur des scénarios à haute concurrence et à 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 en 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 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 phases indépendantes et de traiter ces phases en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase fonctionne sur des threads ou 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 phases comprennent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution des transactions (Execution) et engagement des blocs (Commit).

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

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, et 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 les délais de confirmation, rendant le système plus résilient, le processus de traitement plus segmenté et l'utilisation des ressources plus efficace.

Conception de base :

• Le processus de consensus (couche de consensus) ne s'occupe que 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 réalisation du consensus, le processus de consensus du prochain bloc commence immédiatement, sans attendre l'exécution.

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

L'Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel 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 améliore 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écutez 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é, la transaction conflictuelle sera réexécutée 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, en réalisant des parallèles grâce à un écriture d'état retardée et à une détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, en tant qu'accélérateur de parallélisme dans le monde de l'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 hautes performances compatible avec l'EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'amélioration d'exécution sur Ethereum ou de composant modulaire. 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 programmées de manière indépendante, afin de réaliser une exécution à haute concurrence sur 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 (Graphes de dépendance d'état acycliques) et un mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté "threading sur la chaîne".

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

MegaETH a introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "thréadise" 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 à de nombreuses VM d'exécuter indépendamment et de stocker de manière indépendante, naturellement parallèles.

DAG de dépendance d'état : Mécanisme de planification piloté par le graphe de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état des comptes, qui maintient en temps réel un graphique de dépendance global (Dependency Graph). Chaque transaction modifie quels comptes et lit quels comptes, le tout modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées 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 assure 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 par unité de compte, en programmant les 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, "structure de compte → architecture de planification → flux d'exécution", offrant une nouvelle perspective de niveau paradigmatique pour construire des systèmes en chaîne de nouvelle génération à haute performance.

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 de parallélisme 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 super système d'exploitation 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 (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limitations d'une chaîne unique pour l'évolutivité au niveau du réseau ; tandis 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 extrême à l'intérieur de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin de l'évolutivité 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 central d'augmenter 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-machine virtuelle (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et parallèle de bout en bout, a pour mécanisme de calcul parallèle central ce qu'on appelle "Rollup Mesh". Cette architecture soutient l'environnement multi-machine virtuelle (EVM et Wasm) grâce à la coopération entre le réseau principal et le réseau de traitement spécial (SPNs), 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écompose les différentes étapes des transactions (telles que le consensus, l'exécution, le stockage) et utilise une méthode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et en parallèle, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de double machine virtuelle (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. Réseaux de traitement spéciaux (SPN) : Les SPN sont des composants clés de l'architecture Pharos, similaires à des sous-réseaux modulaires, spécialement conçus pour traiter des types spécifiques de tâches ou d'applications. Grâce aux SPN, Pharos peut réaliser une allocation dynamique des ressources et un traitement parallèle des tâches, améliorant 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 (comme PBFT, PoS, PoA), et via le restaking...