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

I. Aperçu de la course à l'extension de la blockchain

Le "Trilemme de la blockchain" (Blockchain Trilemma) qui englobe la "sécurité", la "décentralisation" et la "scalabilité" dévoile le compromis essentiel dans la conception des systèmes blockchain, à savoir 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 la "scalabilité", les solutions de scalabilité des blockchains dominantes sur le marché sont classées selon des paradigmes, y compris :

• Exécution de l'extension améliorée : augmentation des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœurs
• Type d'extension par isolation d'état : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, multiple sous-réseaux
• Scalabilité de type externalisation hors chaîne : 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 modulaires, ordonnanceur partagé, Rollup Mesh
• Extension concurrent asynchrone : Modèle Acteur, isolation des processus, pilotage par messages, par exemple agents, chaînes asynchrones multithreads

Les solutions d'extension de la blockchain incluent : 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 de preuve zk, l'architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure. Il s'agit d'un "système complet d'extension basé sur la collaboration multicouche et la combinaison modulaire". Cet article met l'accent 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 de la chaîne de 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 philosophie 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 grande, 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èle au niveau des transactions (Transaction-level) : représente le projet Monad, Aptos
• Niveau d'appel / MicroVM 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 asynchrones / inter-chaînes (modèle non synchronisé par blocs), chaque Agent étant un "processus intelligent" fonctionnant de manière indépendante, avec des messages asynchrones en parallèle, basé sur des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle 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'é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 de mise à l'échelle ne sont pas le point central de cet article, mais nous les utiliserons néanmoins pour comparer les similarités et les différences des concepts architecturaux.

Deuxième point, la chaîne améliorée par parallélisme 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, les Rollups et l'architecture modulaire, mais le goulot d'étranglement du débit au niveau d'exécution n'a toujours pas connu de percée fondamentale. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents qui possèdent la plus grande base de développeurs et un écosystème dynamique. Par conséquent, la chaîne EVM parallèle, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une voie clé dans la nouvelle phase d'é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 conçue pour 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 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 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 diviser 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 s'exécute dans des threads ou cœurs indépendants, permettant un traitement concurrent à travers les blocs, ce qui permet d'augmenter le débit et de réduire la latence. Ces phases comprennent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de la 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 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 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 principale :

• 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 la fin de 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é, les transactions conflictuelles seront sérialisées et réexécutées pour garantir l'intégrité de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant le parallélisme grâce à un retard d'écriture d'état et une détection dynamique des conflits, ressemblant davantage à une version performance d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un 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 hautes performances, compatible avec EVM et modulaire, pouvant fonctionner à la fois comme une chaîne publique L1 indépendante et comme une couche d'amélioration d'exécution (Execution Layer) ou un composant modulaire 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 modulaire, qui construisent ensemble un système d'exécution parallèle orienté "threading au sein de la chaîne".

Architecture Micro-VM : le compte est un thread

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte", qui "thréadise" l'environnement d'exécution, offrant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par des messages asynchrones, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter indépendamment et de stocker de manière indépendante, ce qui favorise naturellement le parallélisme.

DAG de dépendance d'état : Mécanisme de planification basé sur le graphe de dépendance

MegaETH a construit un système de planification DAG basé sur la relation d'accès à l'état des comptes, qui maintient en temps réel un graphique de dépendance global. À chaque transaction, les comptes modifiés et ceux lus sont tous modélisés en tant que 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 et ordonné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'écriture répétée 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 EVM à thread unique, en réalisant un encapsulage de micro-machine virtuelle par compte, en programmant les transactions via des graphes 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 une nouvelle perspective de paradigme pour la construction de systèmes en chaîne haute performance de prochaine génération.

MegaETH a choisi un chemin 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. 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é basé sur les principes d'Ethereum.

Les conceptions de Monad et de MegaETH diffèrent considérablement 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 ainsi les limites d'une seule chaîne pour l'évolutivité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité d'une seule chaîne, en 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 dépasser 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 comme Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec l'objectif central d'améliorer le TPS sur la chaîne. Cela est réalisé grâce à l'exécution différée et à l'architecture de micro-machine virtuelle, permettant un traitement parallèle au niveau des transactions ou des comptes. Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture fonctionne en collaboration avec le réseau principal et les réseaux de traitement spéciaux (SPNs), prenant en charge des environnements multi-machines virtuelles (EVM et Wasm), et intégrant 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 en pipeline sur tout le cycle de vie : Pharos découple les différentes étapes de la transaction (comme le consensus, l'exécution, le stockage) et utilise un mode de traitement asynchrone pour permettre à chaque étape de s'exécuter de manière indépendante et parallèle, augmentant ainsi l'efficacité du traitement global.
2. Exécution parallèle de deux VM (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, similaires à des sous-réseaux modulaires, spécifiquement conçus pour traiter des types de tâches ou d'applications particuliers. 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 la performance du système.
4. Consensus modulaire et mécanisme de restaking (Modular Consensus & Restaking) : Pharos introduit un mécanisme de consensus flexible qui prend en charge plusieurs modèles de consensus (comme PBFT, PoS