Vue d'ensemble du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?

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

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

• Exécuter une extension améliorée : améliorer la capacité d'exécution sur place, par exemple en parallèle, GPU, multi-cœurs.
• Isolation d'état par extension : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, multi-sous-réseaux
• Scalabilité par externalisation hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité par découplage de la structure : modularité de l'architecture, fonctionnement en collaboration, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Élargissement de type asynchrone et concurrent : modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread.

Les solutions d'extension de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression de preuve zk, l'architecture sans état, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure. C'est un système d'extension complet basé sur une "coopération multi-niveaux et une combinaison modulaire". Cet article se concentre sur les méthodes d'extension principalement basées sur le calcul parallèle.

Le calcul parallèle intra-chaîne ( in intra-chain parallelism ) se concentre sur l'exécution parallèle des transactions/instructions au sein des blocs. 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 quêtes de performance, modèles de développement et 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 é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 des transactions (Transaction-level) : représente les projets 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 (Agent / Actor Model), appartenant à 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 fonctionne comme un "processus d'agent intelligent" indépendant, avec des messages asynchrones en mode parallèle, basé sur des événements, sans nécessiter de planification synchrone. Des projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que Rollup ou le sharding, appartiennent aux mécanismes de concurrence au niveau système et ne relèvent pas 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/VM. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les similarités et les différences des concepts architecturaux.

Deuxième, chaîne améliorée parallèle EVM : dépasser les limites de performance tout en restant compatible.

L'architecture de traitement sériel d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement en matière de débit au niveau d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plates-formes de contrats intelligents ayant la base de développeurs et le potentiel écologique les plus importants. Par conséquent, les chaînes parallèles renforcées par l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la prochaine évolution d'extension. Monad et MegaETH sont les projets les plus représentatifs de 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 retardé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 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 à 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 étapes indépendantes, et de traiter ces étapes en parallèle, formant ainsi une architecture de pipeline en trois dimensions. Chaque étape s'exécute sur des threads ou des cœurs indépendants, réalisant un traitement concurrent entre les blocs, afin d'améliorer le débit et de réduire la latence. Ces étapes comprennent : proposition de transaction (Propose), consensus atteint (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

Exécution Asynchrone : Découplage Asynchrone de la Consensus et de l'Exécution

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce modèle sériel limite sérieusement l'évolutivité des performances. Monad réalise 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 (block time) et le délai de confirmation, rendant le système plus résilient, le processus de traitement plus segmenté et le taux d'utilisation des ressources plus élevé.

Conception clé :

• 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.
• Après la conclusion du consensus, entrez immédiatement dans le processus de consensus du prochain bloc sans attendre l'exécution.

Exécution parallèle optimiste : Optimistic Parallel Execution

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 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 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).
• En cas de détection de conflit, les transactions en conflit seront réexécutées en série pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : il modifie le moins possible les règles de l'EVM, réalisant ainsi le parallélisme en retardant l'écriture de l'état et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité qui facilite la migration de l'écosystème EVM, étant l'accélérateur de parallélisme du monde EVM.

Analyse du mécanisme de calcul parallèle de MegaETH

Contrairement à la position L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle hautes performances modulaires compatible 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 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 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 (graphe acyclique dirigé des dépendances d'état) et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté "filtrage au sein de la chaîne".

Architecture Micro-VM (micro machine virtuelle) : compte est un fil

MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "filtre" l'environnement d'exécution, fournissant ainsi l'unité d'isolation 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 d'exécuter indépendamment et de stocker de manière autonome, 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, 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 comme des 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 planifié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'é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 à états monothread EVM, en réalisant un encapsulage de micro-vérificateur par compte, en programmant les transactions à l'aide d'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 selon "structure de compte → architecture de programmation → processus d'exécution", offrant une nouvelle approche de paradigme pour la construction de systèmes de 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 exécution asynchrone. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais il est aussi plus difficile de contrôler la complexité, ressemblant davantage à un super système d'exploitation distribué sous l'idée d'Ethereum.

La conception de Monad et de MegaETH diffère considérablement de celle du sharding : le sharding divise horizontalement la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, rompant ainsi les limitations d'une seule chaîne pour l'extensibilité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, en s'étendant horizontalement uniquement au niveau de l'exécution, optimisant ainsi les performances par une exécution parallèle extrême au sein de la chaîne unique. Les deux représentent deux directions différentes dans le chemin d'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 débit, avec pour objectif central d'améliorer le TPS intra-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 full-stack, a un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture soutient un travail collaboratif entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge plusieurs environnements de 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 des pipelines asynchrones 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 ainsi à chaque étape de se dérouler indépendamment et en 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écial (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, semblables à des sous-réseaux modulaires, spécifiquement 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 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 permet un partage sécurisé et une intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking.

De plus, Pharos utilise des arbres de Merkle multiversion, un codage différentiel (Delta Encoding), des versions