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

Le « trilemme de la blockchain » (Blockchain Trilemma) de la blockchain, qui comprend « sécurité », « décentralisation » et « évolutivité », révèle l'essence des compromis dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain de réaliser simultanément « une sécurité maximale, une participation universelle et un traitement rapide ». Concernant le sujet éternel de l'« évolutivité », les solutions d'extension de blockchain dominantes sur le marché se divisent en fonction des paradigmes, y compris :

• Exécution d'une capacité d'extension améliorée : amélioration sur place de la capacité d'exécution, par exemple parallélisation, GPU, multicœurs
• Isolation de l'état par extension : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Scalabilité par sous-traitance hors chaîne : exécuter des tâches hors chaîne, par exemple Rollup, Coprocessor, DA
• Découplage de structure pour l'extension : architecture modulaire, fonctionnement coopératif, par exemple chaîne de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité concurrente asynchrone : Modèle d'Actor, isolation des processus, piloté par messages, par exemple agents, chaîne asynchrone 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 de 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, combinaison modulaire ». Cet article se concentre 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 au sein des blocs. En fonction du mécanisme de parallélisme, ses méthodes d'extension peuvent être divisées en cinq grandes catégories, chacune représentant différentes exigences de performance, modèles de développement et philosophies d'architecture, avec des granularités parallèles de plus en plus fines, une intensité parallèle 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 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 (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 agissant comme un « processus d'agent » autonome, avec un mode de fonctionnement parallèle par messages asynchrones, déclenché par des événements, sans planification synchronisée, les projets représentés incluent AO, ICP, Cartesi, etc.

Les solutions de mise à l'échelle bien connues telles que Rollup ou les sharding 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 la mise à l'échelle 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. Ce type de solution de mise à l'échelle n'est pas le sujet principal de cet article, mais nous l'utiliserons tout de même pour comparer les similitudes et les différences des concepts architecturaux.

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

L'architecture de traitement en série 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 termes de 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 les plus soutenues par les développeurs et possédant le plus grand potentiel écologique. Par conséquent, la chaîne parallèle basée sur l'EVM est en train de devenir une voie clé pour concilier la compatibilité écologique et l'amélioration des performances d'exécution, et représente une direction importante pour la prochaine é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, 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 par pipeline (Pipelining). Elle exécute de manière asynchrone sur la couche de consensus (Asynchronous Execution) et utilise une exécution concurrente optimiste (Optimistic Parallel Execution) sur la couche d'exécution. De plus, sur les couches de consensus et de stockage, Monad introduit respectivement un protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB) pour réaliser une optimisation de bout en bout.

Pipelining : Mécanisme d'exécution parallèle en plusieurs étapes

Le pipelining est le principe de base 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 phases indépendantes et de traiter ces phases en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase fonctionne sur des threads ou cœurs indépendants, permettant un traitement concurrent à travers les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases incluent : proposition de transaction (Propose), réalisation du consensus (Consensus), exécution de la transaction (Execution) et soumission du bloc (Commit).

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

Dans une blockchain traditionnelle, le consensus et l'exécution des transactions se font généralement de manière synchrone, ce qui limite gravement l'évolutivité des performances. Monad réalise la couche de consensus asynchrone, la couche d'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 l'utilisation des ressources plus efficace.

Conception centrale :

• 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 la fin du consensus, entrez immédiatement dans le processus de consensus du prochain bloc, sans attendre la fin de 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 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 en conflit seront réexécutées de manière séquentielle 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, en réalisant la parallélisation grâce au report de l'écriture de l'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité 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 se positionne comme une couche d'exécution parallèle modulable 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 sur Ethereum (Execution Layer) ou de composant modulable. 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 + DAG de dépendance d'état (Directed Acyclic Graph) et un mécanisme de synchronisation modulable, construisant ensemble un système d'exécution parallèle orienté vers le "threading intra-chaîne".

Architecture Micro-VM : compte équivaut à un fil d'exécution

MegaETH introduit un modèle d'exécution de « machine virtuelle miniature (Micro-VM) par compte », qui « threadise » l'environnement d'exécution et fournit l'unité minimale d'isolation pour le planificateur 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 indépendamment, offrant ainsi un parallélisme naturel.

DAG de dépendance d'état : Mécanisme de planification basé sur un graphique 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 (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 en parallèle directement, tandis que les transactions ayant 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 d'état et l'absence d'écriture répétée durant 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 à état EVM mono-thread en encapsulant des micro-machines virtuelles 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 paradigmique pour la construction de systèmes en ligne de haute performance de prochaine génération.

MegaETH a choisi un chemin de reconstruction : en abstraisant complètement les comptes et les contrats en une VM indépendante, permettant ainsi une exécution asynchrone pour libérer un potentiel de parallélisme extrême. 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é sous l'idée d'Ethereum.

Monad et MegaETH ont des philosophies de conception très différentes de celles du sharding : le sharding divise la blockchain horizontalement en plusieurs chaînes secondaires indépendantes (shards), chaque shard étant responsable d'une partie des transactions et des états, ce qui brise les limitations d'une chaîne unique pour l'extensibilité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, ne s'étendant horizontalement qu'au niveau de l'exécution, optimisant ainsi 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'extensibilité 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 principal 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, a pour mécanisme de calcul parallèle central ce que l'on appelle le « Rollup Mesh ». Cette architecture supporte un environnement multi-VM (EVM et Wasm) grâce à la collaboration entre le réseau principal et le réseau de traitement spécial (SPNs), 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 méthode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et 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é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 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, supportant plusieurs modèles de consensus (comme PBFT, PoS, PoA), et grâce au protocole de restaking (