Vue d'ensemble du secteur du calcul parallèle Web3 : la meilleure solution d'extension 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 un projet blockchain d'atteindre simultanément « une sécurité extrême, une participation universelle et un traitement rapide ». Concernant le sujet éternel de « l'évolutivité », les solutions d'extension de blockchain 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.
• Isolation d'état pour l'évolutivité : partitionnement horizontal de l'état / Shard, par exemple le sharding, UTXO, sous-réseaux multiples
• Scalabilité par externalisation hors chaîne : déplacer l'exécution hors de la chaîne, par exemple Rollup, Coprocessor, DA
• Élargissement à structure découplée : modules architecturaux, fonctionnement coopératif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : modèle d'Acteur, isolation des processus, piloté par des messages, par exemple, agents, chaînes asynchrones multithread

Les solutions d'évolutivité de la blockchain comprennent : le calcul parallèle au sein de la 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 se concentre sur l'approche d'évolutivité principale 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 du bloc. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant différentes aspirations en matière de performance, de modèles de développement et de philosophies d'architecture, avec un degré de parallélisme de plus en plus fin, 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 également 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'entités intelligentes (Agent / Actor Model), il 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 agit comme un « processus intelligent » fonctionnant de manière indépendante, avec des messages asynchrones en mode parallèle, pilotés par des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, comme le Rollup ou le sharding, relèvent des mécanismes de concurrence au niveau 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 le point central de cet article, mais nous les utiliserons néanmoins pour comparer les similarités et les différences des concepts architecturaux.

II. 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 traversé plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, en même temps, 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 d'amélioration parallèle de 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 elle est en train de devenir 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 orientée vers des scénarios de haute concurrence et de haute capacité de traitement, respectivement à partir de l'exécution différée et de la décomposition des états.

Analyse du mécanisme de calcul parallèle de Monad ###

Monad est une blockchain de 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 du consensus (Asynchronous Execution) et une 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 de base 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 en trois dimensions. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, ce qui améliore finalement le débit et réduit 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 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 gravement l'évolutivité des performances. Monad réalise l'asynchrone au niveau du consensus, de l'exécution et 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 plus segmentés et l'utilisation des ressources plus efficace.

Conception centrale :

• Le processus de consensus (couche de consensus) est uniquement responsable de l'ordonnancement 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.
• Une fois le consensus atteint, passez immédiatement au processus de consensus du prochain bloc, sans attendre que l'exécution soit terminée.

Exécution parallèle optimiste : Exécution parallèle optimiste

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 tous les transactions en parallèle, en supposant qu'il n'y a pas de conflits d'état entre la plupart des transactions.
• Exécuter simultanément un « Détecteur de Conflits (Conflict Detector)) » pour surveiller si les transactions ont accédé au même état (par exemple, conflits de lecture / écriture).
• Si un conflit est détecté, les transactions en conflit seront sérialisées et réexécutées pour garantir la conformité de l'état.

Monad a choisi un chemin de compatibilité : en touchant le moins possible aux règles de l'EVM, en réalisant le parallélisme grâce au report de l'écriture de l'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité qui facilite la migration de l'écosystème EVM, étant un accélérateur de parallélisme dans le monde EVM.

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

Contrairement au positionnement L1 de Monad, MegaETH se positionne comme une couche d'exécution parallèle modulaire à haute performance compatible EVM, pouvant servir à la fois de blockchain 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 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 + 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

MegaETH introduit un modèle d'exécution « une Micro-VM par compte », qui « threadise » l'environnement d'exécution, fournissant l'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, offrant ainsi un parallélisme naturel.

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 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 cela 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 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 d'état EVM à thread unique, en réalisant un encapsulage de micro-machine virtuelle par unité de compte, en effectuant la planification des transactions via un graphique 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 paradigmatique pour construire les systèmes en chaîne de nouvelle génération à haute performance.

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 également plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.

La philosophie de conception de Monad et MegaETH est très différente de celle du sharding : le sharding divise la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et des états, brisant ainsi les limites d'une seule chaîne pour l'expansion 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 la couche d'exécution, optimisant ainsi l'exécution parallèle extrême à l'intérieur d'une seule chaîne pour améliorer les performances. Les deux représentent deux directions dans le chemin 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 débit, avec l'objectif central d'améliorer le TPS en 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 à une architecture de micro-machine virtuelle (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, a pour mécanisme de calcul parallèle central ce que l'on appelle le « Rollup Mesh ». Cette architecture, par la collaboration entre le mainnet et les réseaux de traitement spéciaux (SPNs), supporte un environnement multi-machine virtuelle (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 de pipeline asynchrone sur l'ensemble du cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes phases des transactions (telles que le consensus, l'exécution, le stockage) et adopte une méthode de traitement asynchrone, permettant à chaque phase de se dérouler de manière indépendante et parallèle, augmentant ainsi 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é selon 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é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, ce qui améliore encore 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 grâce au protocole de restaking (