Carte panoramique du secteur du calcul parallèle Web3 : la meilleure solution d'expansion native ?

Le « triangle impossible » de la blockchain (Blockchain Trilemma) « sécurité », « décentralisation », « évolutivité » révèle le compromis essentiel dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain de réaliser simultanément « une sécurité extrême, une participation universelle, un traitement rapide ». Concernant le sujet éternel de l' « évolutivité », les principales solutions d'extension de blockchain sur le marché actuel sont classées selon des paradigmes, y compris :

• Exécution de l'expansion améliorée : augmentation des capacités d'exécution sur place, comme le parallélisme, le GPU, le multicœur
• Isolation de l'état par extension : partitionnement horizontal de l'état / Shard, par exemple le sharding, UTXO, sous-réseaux multiples
• Extensibilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité par dé-couplage structurel : modularité de l'architecture, fonctionnement en collaboration, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Extensibilité asynchrone et concurrente : Modèle Actor, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'évolutivité 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. Cela couvre plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système d'évolutivité complet basé sur une "collaboration multi-niveaux et une combinaison modulaire". Cet article met l'accent sur la méthode d'évolutivité 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 d'un bloc. Selon le mécanisme de parallélisme, ses modes d'extension peuvent être répartis en cinq grandes catégories, chacune représentant des aspirations de performances, des modèles de développement et des philosophies d'architecture différents, la granularité du parallélisme devenant de plus en plus fine, l'intensité du parallélisme de plus en plus élevée, la complexité de la planification également de plus en plus élevée, ainsi que la complexité de la programmation et la 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
• 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 (Agent / Actor Model), qui appartient à un autre paradigme de calcul parallèle. En tant que système de messages inter-chaînes / asynchrones (modèle de synchronisation de blocs non), chaque Agent fonctionne comme un « processus intelligent » autonome, avec un mode de messages asynchrone en parallèle, basé sur des événements et sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que les Rollups ou les 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 », et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Ces solutions d'extension ne sont pas au cœur de la discussion de cet article, mais nous les utiliserons néanmoins pour comparer les différences et similitudes des concepts architecturaux.

II. Chaîne améliorée en parallèle EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à aujourd'hui, ayant subi plusieurs tentatives d'extension, y compris 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 été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents avec la plus grande base de développeurs et un potentiel écologique. Par conséquent, la chaîne parallèle du système EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé pour 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 axée sur des scénarios à haute concurrence et à haut débit, respectivement, 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 Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining), avec exécution asynchrone au niveau du consensus (Asynchronous Execution) et exécution parallèle optimiste au niveau d'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 Monads. L'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 s'exécute sur des threads ou des cœurs indépendants, réalisant un traitement concurrent entre les blocs, atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases incluent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de la transaction (Execution) et soumission du bloc (Commit).

Exécution Asynchrone : Consensus - Exécution asynchrone découplée

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é le consensus asynchrone, l'exécution asynchrone et le 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 de base :

• 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 réalisation du consensus.
• Une fois le consensus atteint, passez immédiatement au processus de consensus du bloc suivant, sans attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

L'Ethereum traditionnel adopte 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 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 (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'exactitude de l'état.

Monad a choisi un chemin compatible : minimiser les modifications des règles de l'EVM, en réalisant le parallélisme par le report de l'écriture des états et la détection dynamique des conflits, ressemblant davantage à une version performante 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 modulaire hautes performances compatible avec EVM, pouvant servir à la fois de chaîne 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écomposer la logique de compte, l'environnement d'exécution et l'état en unités minimales pouvant être planifiées indépendamment, 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 (graphique de dépendance d'état acyclique) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers la "threadisation au sein de la chaîne".

Architecture Micro-VM (micro-machine virtuelle) : le compte est un fil d'exécution

MegaETH introduit un modèle d'exécution « une micro-machine virtuelle (Micro-VM) par compte », qui « threadise » l'environnement d'exécution, fournissant la plus petite unité d'isolation pour l'ordonnancement parallèle. Ces VM communiquent entre elles par messagerie asynchrone (Asynchronous Messaging), plutôt que par appels synchrones, permettant à un grand nombre de VM d'exécuter indépendamment et de stocker indépendamment, ce qui est naturellement 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 à l'état des comptes, 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é 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 et triées de manière séquentielle ou différée selon un ordre topologique. Le graphique de dépendance garantit la cohérence de l'é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 brise 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 utilisant un graphe de dépendance d'état pour le plan de transaction, et en remplaçant la pile d'appels synchrones par un mécanisme de message asynchrone. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, de « structure de compte → architecture de planification → flux d'exécution », offrant une nouvelle approche paradigmique pour construire des 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 à 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 système d'exploitation super distribué basé sur la philosophie d'Ethereum.

Monad et MegaETH ont des concepts de conception très différents 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 limitation d'une seule chaîne pour l'extension au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, s'étendant horizontalement uniquement au niveau de l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin de l'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 chemin de débit, avec pour objectif central d'améliorer le TPS au sein de la 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-VM (Micro-VM). Pharos Network, en tant que réseau de blockchain L1 modulaire et entièrement parallèle, a pour mécanisme de calcul parallèle central ce que l'on appelle le "Rollup Mesh". Cette architecture prend en charge un environnement multi-VM (EVM et Wasm) grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), tout en 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 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 adopte une méthode de traitement asynchrone, permettant à chaque étape de se dérouler indépendamment et en parallèle, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de 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écial (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, semblables à des sous-réseaux modulaires, 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, renforçant 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 (tels que PBFT, PoS, PoA) et réalise l'interaction entre la chaîne principale et les SPNs grâce au protocole de restaking.