Paysage du secteur du calcul parallèle Web3 : la meilleure solution pour l'extension native ?

I. Aperçu de la piste de calcul parallèle

Le « triangle impossible » de la blockchain, à savoir « sécurité », « décentralisation » et « évolutivité », révèle l'essence des compromis dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain d'atteindre simultanément « une sécurité maximale, une participation universelle et un traitement rapide ». En ce qui concerne le sujet éternel de l'« évolutivité », les solutions d'extension des blockchains actuellement sur le marché sont classées selon des paradigmes, y compris :

• Exécution d'une extensibilité améliorée : augmentation des capacités d'exécution sur place, par exemple, parallélisme, GPU, multicœur.
• Isolation d'état pour l'extensibilité : partitionnement horizontal de l'état, par exemple sharding, UTXO, multi-sous-réseaux
• Scalabilité hors chaîne par externalisation : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Extension de type asynchrone et concurrent : modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'évolutivité 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 des preuves zk, l'architecture Stateless, etc., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'évolutivité « multi-niveaux et combinaison modulaire ». Cet article met l'accent sur les méthodes d'évolutivité principalement basées sur le calcul parallèle.

Calcul parallèle intra-chaîne (intra-chain parallelism), axé sur l'exécution parallèle des transactions/instructions à l'intérieur 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 des aspirations de performance, des modèles de développement et des philosophies d'architecture différents. Par ordre croissant, la granularité de parallélisme devient de plus en plus fine, l'intensité de parallélisme de plus en plus élevée, la complexité de planification de plus en plus élevée, ainsi que la complexité de 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
• Niveau de transaction parallèle (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 non synchronisé par bloc), chaque agent fonctionne comme un "processus intelligent" indépendant, échangeant des messages de manière asynchrone en mode parallèle, basé sur des événements, sans nécessité de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions de scalabilité que nous connaissons bien, comme Rollup ou le sharding, appartiennent à des 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 la scalabilité 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/VM. Bien que ces solutions de scalabilité ne soient pas le sujet principal de cet article, nous les utiliserons néanmoins pour comparer les différences et similitudes des concepts architecturaux.

Deuxième, EVM chaînes parallèles améliorées : dépasser les limites de performance dans la compatibilité

L'architecture de traitement séquentiel d'Ethereum a évolué au fil du temps, passant par des tentatives d'extensibilité telles que le sharding, les Rollups et les architectures modulaires, mais le goulet d'étranglement du débit au niveau de la couche d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents ayant la plus grande base de développeurs et le plus de potentiel écologique. Ainsi, les chaînes parallèles EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la prochaine vague d'évolution de l'extensibilité. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant des architectures de traitement parallèle EVM orientées vers des scénarios à haute concurrence et à haut débit, respectivement à partir 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). Elle exécute de manière asynchrone au niveau du consensus (Asynchronous Execution) et en concurrence 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 dédié (MonadDB), réalisant une optimisation de bout en bout.

Pipelining : mécanisme d'exécution parallèle de pipeline multi-é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 étapes indépendantes et de traiter ces étapes en parallèle, formant une architecture de pipeline tridimensionnelle. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte de 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, ce qui limite gravement l'extensibilité 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, les processus de traitement plus segmentés 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 l'achèvement 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 : Exécution parallèle optimiste

L'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 et parallèle toutes les transactions, 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 à un même état (comme les conflits de lecture/écriture).
• En cas de détection de conflit, les transactions conflictuelles seront réexécutées de manière sérielle pour garantir la cohérence de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, il réalise le parallélisme en reportant l'écriture des états et en détectant dynamiquement les conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, en tant qu'accélérateur de parallélisme dans le monde EVM.

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

Contrairement à la localisation L1 de Monad, MegaETH se positionne comme une couche d'exécution parallèle modulaire à haute performance compatible EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration de l'exécution (Execution Layer) ou de 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 planifiées indépendamment, 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 + State Dependency DAG (graphique de dépendance d'état acyclique) et le 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 : le compte est un fil d'exécution

MegaETH introduit un modèle d'exécution « un micro-VM par compte » qui « met en fil d'attente » l'environnement d'exécution, fournissant une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter de manière indépendante et de stocker de manière indépendante, ce qui est naturellement parallèle.

DAG de dépendance d'état : Mécanisme de planification basé sur 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, le système maintient en temps réel un graphique de dépendance (Dependency Graph) global, modélisant toutes les transactions qui modifient ou lisent des comptes 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 planifiées en série ou différées selon un ordre topologique. Le graphique de dépendance garantit la cohérence des états 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 brise le modèle traditionnel de machine d'état à thread unique de l'EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en planifiant 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, passant de « structure de compte → architecture de planification → processus d'exécution », offrant une nouvelle approche de niveau paradigme pour la construction de systèmes en chaîne de haute performance de nouvelle 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 à un ordonnancement d'exécution asynchrone. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais elle est aussi plus difficile à contrôler en termes de complexité, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.

Monad et MegaETH ont des philosophies de conception très différentes de celles du sharding : le sharding découpe la blockchain horizontalement en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable de certaines transactions et états, brisant ainsi les limites 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, en s'étendant horizontalement uniquement au niveau de l'exécution, optimisant ainsi l'exécution parallèle extrême à 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 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 blockchain L1 modulaire et full-stack parallèle, possède un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture, par la collaboration entre le mainnet et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-VM (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 par pipeline asynchrone 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 approche de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et parallèle, ce qui améliore 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, similaires à des sous-réseaux modulaires, spécialement 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 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 réalise la connexion entre le réseau principal et SPN grâce au protocole de restaking.