Panorama du secteur des calculs parallèles Web3 : la meilleure solution d'extension native ?

Le "trilemme" de la blockchain (Blockchain Trilemma) de la "sécurité", de la "décentralisation" et de la "scalabilité" 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é ultime, une participation universelle et un traitement rapide". Concernant le sujet éternel de la "scalabilité", les principales solutions d'extension de blockchain sur le marché actuel peuvent être classées selon des paradigmes, y compris :

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

Les solutions d'extension de la blockchain comprennent : le calcul parallèle intra-chaîne, le Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc. Elles couvrent plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extension "multi-niveaux et combinaison modulaire". Cet article se concentre sur les méthodes d'extension principalement basées 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 divisées en cinq grandes catégories, chacune représentant des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, avec une granularité parallèle de plus en plus fine, une intensité parallèle 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
• Niveau de transaction parallèle (Transaction-level) : représente les projets Monad, Aptos
• Appel de niveau / 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é de blocs), chaque agent fonctionne comme un "processus intelligent" exécuté de manière indépendante, avec un mode de message asynchrone en parallèle, piloté par 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 Rollup ou le 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 l'extension 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. Ces solutions d'extension ne sont pas le point central de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts d'architecture.

Deux, chaîne d'amélioration parallèle EVM : franchir les limites de performance dans la compatibilité

L'architecture de traitement sériel d'Ethereum a évolué jusqu'à présent, ayant traversé plusieurs tentatives d'extension comme le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution demeure sans percée fondamentale. Cependant, en même temps, l'EVM et Solidity restent les plateformes de contrats intelligents avec la plus grande base de développeurs et le potentiel écologique actuel. Ainsi, la chaîne parallèle améliorée de l'EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé dans l'évolution de cette nouvelle phase d'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 à haute concurrence et à haut débit, 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 Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement par 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 en 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 phases indépendantes et de traiter ces phases de manière parallèle, formant une architecture de pipeline tridimensionnelle, chaque phase fonctionnant sur des threads ou cœurs indépendants, réalisant ainsi un traitement concurrent entre les blocs, et 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 Découplée Asynchrone

Dans une chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement un processus synchrone, ce modèle sériel limite gravement l'évolutivité des performances. Monad réalise une exécution asynchrone du consensus, une exécution asynchrone de la couche d'exécution et une asynchrone 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, avec des processus de traitement plus segmentés et une meilleure utilisation des ressources.

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.
• Après la réalisation du consensus, le processus de consensus du prochain bloc commence immédiatement, sans attendre 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", augmentant 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écuter simultanément un "détecteur de conflit (Conflict Detector))" pour surveiller si les transactions accèdent au même état (comme les conflits de lecture/écriture).
• En cas de détection d'un conflit, les transactions conflictuelles seront réexécutées de manière séquentielle pour garantir la validité de l'état.

Monad a choisi un chemin compatible : modifier le moins possible les règles de l'EVM, en réalisant le parallélisme grâce à un retard dans l'écriture de l'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa bonne maturité facilite la migration de l'écosystème EVM, en tant qu'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 parallèle modulable et 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 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 à 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 le mécanisme de synchronisation modulable, construisant ensemble un système d'exécution parallèle orienté vers "l'exécution multi-threads au sein de la chaîne".

Architecture Micro-VM : le compte est un fil

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle (Micro-VM) par compte" qui "filtre" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification 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 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 un graphique 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 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 de l'état et l'écriture non 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 EVM, en réalisant un encapsulage de micro-machines virtuelles basé sur les comptes, en programmant les transactions à l'aide d'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 des comptes → architecture de planification → flux d'exécution", offrant une nouvelle approche de niveau paradigme pour construire des systèmes de chaîne en ligne 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, libérant ainsi un potentiel de parallélisme extrême grâce à un scheduling 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é sous l'idée d'Ethereum.

Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux 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'évolutivité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité d'une seule chaîne, s'étendant horizontalement uniquement 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 d'expansion de la blockchain : le renforcement vertical et l'expansion horizontale.

Les projets de calcul parallèle comme Monad et MegaETH se concentrent principalement sur l'optimisation du chemin de débit, avec pour objectif central d'améliorer le TPS sur 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-machine virtuelle (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture, à travers la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements 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 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 utilise un 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 non seulement améliore 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, améliorant 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 réalise la liaison entre la chaîne principale et les SPNs grâce au protocole de restaking.