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

I. Contexte : Le sujet éternel de l'expansion de la blockchain

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

• Exécution de l'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 : partitionnement horizontal de l'état / Shard, par exemple fragmentation, UTXO, multi-sous-réseaux
• Extensibilité hors chaîne par sous-traitance : effectuer l'exécution en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par architecture : modularité des modules, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Expansion asynchrone et concurrente : modèle Actor, isolation des processus, basé sur les messages, par exemple agents, chaînes asynchrones multithread.

Les solutions d'extension de la blockchain incluent : le calcul parallèle en 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, formant un système complet d'extension "multicouche et assemblage modulaire". Cet article se concentre sur les méthodes d'extension principalement 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 à l'intérieur de la blockchain. 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 aspirations de performance, modèles de développement et philosophies architecturales, 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é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
• Niveau de transaction (Transaction-level) : représente les projets 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 des blocs), chaque Agent fonctionne comme un "processus intelligent" indépendant, avec un mode de communication par messages asynchrones, basé sur des événements, 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'extensibilité 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'extensibilité ne sont pas le point principal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts d'architecture.

II. Chaîne améliorée EVM avec parallélisme : franchir les limites de performance dans la compatibilité

L'architecture de traitement sériel d'Ethereum a évolué jusqu'à présent, passant par des tentatives d'extensibilité telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de débit de la couche d'exécution n'a toujours pas été fondamentalement surmonté. En même temps, l'EVM et Solidity restent les plateformes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus forts actuellement. Par conséquent, les chaînes parallèles de l'EVM, qui tiennent compte de la compatibilité écologique et de l'amélioration des performances d'exécution, deviennent une direction clé pour la nouvelle évolution de l'extensibilité. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement une architecture de traitement parallèle de l'EVM pour des scénarios à forte concurrence et à fort débit, en se basant sur l'exécution différée et la décomposition de l'é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 (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining), avec une exécution asynchrone au niveau de la consensus (Asynchronous Execution) et une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau d'exécution. De plus, au niveau de la 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 de base de l'exécution parallèle des monades. Son idée principale 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 tridimensionnelle. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, pour finalement améliorer le débit et réduire la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte du consensus (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, et 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 la latence de confirmation, rendant le système plus résilient, les processus de traitement plus segmentés 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 l'achèvement 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équentiel pour é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 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 en conflit sera sérialisée et réexécutée 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 à un retard d'écriture d'état et à une détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité, ce 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 EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée sur Ethereum ou de composant modulaire. Son objectif de conception central 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 hautement concurrente 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 + le DAG de dépendance d'état (Directed Acyclic Graph) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté "threading au sein de la chaîne".

Architecture Micro-VM (micro machine virtuelle) : 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 et fournit la plus petite unité d'isolement pour le planificateur parallèle. Ces VM communiquent entre elles par message asynchrone (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter et de stocker indépendamment, naturellement en parallèle.

État de dépendance DAG : Mécanisme de planification basé sur un graphique de dépendance

MegaETH a construit un système de planification DAG basé sur les relations d'accès aux états 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 est modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, tandis que les transactions avec des relations de dépendance seront programmées en série ou retardées selon un ordre topologique. Le graphique de dépendance garantit 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 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, allant de la "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles idées de niveau paradigme pour construire le système en ligne 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é 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 de l'état, brisant ainsi la limite d'une seule chaîne en matière d'évolutivité 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 de l'exécution, optimisant les performances par une exécution parallèle extrême à l'intérieur de la chaîne unique. Les deux représentent deux directions dans les chemins 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 chemin de débit, avec pour objectif principal d'améliorer le TPS sur la chaîne. Ils réalisent un traitement parallèle au niveau des transactions ou des comptes grâce à l'exécution différée (Deferred Execution) et à une architecture de micro-machine virtuelle (Micro-VM). Pharos Network, en tant que réseau de blockchain L1 modulaire et full-stack parallèle, a pour mécanisme de calcul parallèle central ce qu'on appelle le "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 des environnements multi-machines virtuelles (EVM et Wasm) 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 de pipeline asynchrone 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 utilise un traitement asynchrone, permettant à chaque étape de s'exécuter de manière indépendante et parallèle, ce qui améliore l'efficacité globale du traitement.
2. Exécution parallèle de double 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é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 la performance 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