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

Le "trilemme de la blockchain" (Blockchain Trilemma) qui inclut la "sécurité", la "décentralisation" et la "scalabilité" révèle les compromis essentiels dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain de réaliser simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de la "scalabilité", les solutions d'extension de blockchain actuellement sur le marché sont classées selon des paradigmes, y compris :

• Exécution de l'extension améliorée : amélioration de la capacité d'exécution sur place, par exemple par le biais de l'exécution parallèle, des GPU et du multicœur.
• Extensibilité par isolation d'état : division horizontale de l'état / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Extensibilité par externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Extensibilité découplée de la structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle d'acteur, isolation des processus, pilotage par 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, une structure modulaire, un système Actor, la compression par preuve zk, l'architecture Stateless, etc., couvrant plusieurs niveaux tels que l'exécution, l'état, les données et la structure, constituant un "système complet d'extension en collaboration multi-niveaux et combinaisons modulaires". Cet article se concentre principalement sur la méthode d'extension 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. 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é de parallélisme de plus en plus fine, une intensité de parallélisme de plus en plus élevée, une complexité de planification également de plus en plus élevée, 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 de la 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'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 non-synchronisation de blocs), chaque agent agit comme un "processus d'agent intelligent" fonctionnant de manière indépendante, avec des messages asynchrones en mode parallèle, des événements déclenchés, sans planification synchronisée. 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 du système, et ne relèvent pas du calcul parallèle 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 / machine virtuelle. Ces solutions d'évolutivité ne sont pas au cœur de la discussion de cet article, mais nous les utiliserons néanmoins pour une comparaison des similitudes et des différences des concepts architecturaux.

II. 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, passant par plusieurs tentatives d'extension, notamment 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, EVM et Solidity restent actuellement les plateformes de contrats intelligents les plus populaires en termes de base de développeurs et de potentiel écologique. Ainsi, les chaînes parallèles basées sur l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une voie clé pour la nouvelle évolution de l'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 à forte concurrence et à fort 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 de Layer 1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental du traitement par pipeline (Pipelining), avec une exécution asynchrone au niveau du consensus (Asynchronous Execution) et une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau d'exécution. 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 spécialisé (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 Monads. 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 de manière parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase s'exécute sur des threads ou des cœurs indépendants, réalisant 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), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

Exécution Asynchrone : Consensus - Exécution découplé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 l'asynchrone au niveau du consensus, l'asynchrone au niveau de l'exécution et l'asynchrone au niveau 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, 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 fin du consensus.
• Le consensus entre immédiatement dans le processus de consensus du bloc suivant une fois terminé, 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", 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écuter 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é, les transactions conflictuelles seront réexécutées de manière séquentielle pour garantir l'exactitude de l'état.

Monad a choisi une voie compatible : minimiser les modifications des règles de l'EVM, en réalisant le parallélisme par le biais de l'écriture d'état retardée et de la détection dynamique des conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum, avec une maturité facilitant la migration de l'écosystème EVM, servant d'accélérateur de parallélisme 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 modulaire à haute performance compatible avec EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'amélioration d'exécution (Execution Layer) ou de composant modulaire sur Ethereum. Son objectif de conception principal est de déconstruire la logique de compte, l'environnement d'exécution et l'état en unités minimales pouvant être programmées indépendamment, afin d'atteindre une exécution à haute concurrence et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + DAG de dépendance d'état (Directed Acyclic Graph) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "l'exécution en chaîne".

Architecture Micro-VM : le compte est un thread

MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "threadise" l'environnement d'exécution, fournissant ainsi une unité d'isolement minimale pour la planification parallèle. 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 de s'exécuter de manière indépendante et de stocker indépendamment, ce qui favorise la parallélisation naturelle.

DAG de dépendance d'état : Mécanisme de planification piloté par des graphes 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, lit quels comptes, et tout cela est modélisé sous forme de relations de dépendance. Les transactions sans conflits peuvent être exécutées directement en parallèle, tandis que les transactions avec des relations de dépendance seront programmées et triées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit la cohérence d'é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 rompt avec le modèle traditionnel de machine à état EVM à thread unique, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en utilisant un graphe de dépendance d'état pour le plan de traitement des transactions, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plate-forme de calcul parallèle redessinée dans toutes ses dimensions, allant de "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles idées de niveau paradigme pour la construction de systèmes en chaîne 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 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 assez différentes de celles du sharding : le sharding découpe 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 la limitation d'une seule chaîne pour une évolutivité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, se concentrant uniquement sur l'évolutivité horizontale au niveau de la couche d'exécution, optimisant l'exécution parallèle au sein de la chaîne unique pour dépasser 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 tels que Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec pour objectif principal 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 de blockchain L1 modulaire et full-stack parallèle, a un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture, grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge un environnement multi-machine virtuelle (EVM et Wasm) et intègre des technologies avancées telles que les preuves à connaissance nulle (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écompose les différentes étapes de la transaction (comme le consensus, l'exécution, le stockage) et adopte une méthode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et parallèle, améliorant ainsi 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 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重