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

I. Contexte du développement du calcul parallèle dans le domaine de la blockchain

Le "triangle impossible" de la blockchain ( "sécurité", "décentralisation", "extensibilité" ) révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité maximale, une participation universelle, et un traitement rapide". Concernant le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain dominantes sur le marché sont classées selon des paradigmes, y compris :

• Exécution d'une extension améliorée : amélioration des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœurs
• Isolation de l'état pour l'extension : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, multiples sous-réseaux
• Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par architecture : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceurs partagés, Rollup Mesh
• Extension de type concurrent asynchrone : Modèle d'Acteur, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extension 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 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'extension à plusieurs niveaux et de combinaison modulaire". Cet article se concentre sur la méthode d'extension 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 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, chaque catégorie représentant des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, 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 également croissante, ainsi qu’une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.

• Niveau de compte parallèle (Niveau de compte ) : 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ésentant le projet Monad, Aptos
• Appel de niveau / MicroVM parallèle ( Appel de niveau / 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), 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 de la blockchain), chaque agent étant un "processus intelligent" fonctionnant de manière indépendante, avec des messages asynchrones en parallèle, déclenchés par des événements, sans planification de synchronisation. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension Rollup ou de sharding, que nous connaissons bien, 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 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/virtual machine. Ce type de solution d'extension n'est pas le point principal de cet article, mais nous l'utiliserons néanmoins pour comparer les différences dans les concepts d'architecture.

Deux, EVM système de chaîne parallèle améliorée : franchir les limites de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extension telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution demeure non résolu de manière fondamentale. Cependant, en même temps, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et ayant un potentiel écologique actuel. Par conséquent, la chaîne EVM parallèle, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une voie clé dans l'évolution de la nouvelle série d'extensions. 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, 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), exécutant de manière asynchrone (Asynchronous Execution) au niveau du consensus et en parallèle optimiste (Optimistic Parallel Execution) au niveau de l'exécution. 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 spécialisé (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 principale est de diviser 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 en trois dimensions. Chaque phase s'exécute sur des threads ou des cœurs indépendants, ce qui permet un traitement concurrent à travers les blocs, atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases comprennent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

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

Dans une chaîne traditionnelle, 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 un consensus asynchrone, une exécution asynchrone et un 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, les processus plus segmentés et l'utilisation des ressources plus efficace.

Conception centrale:

• Le processus de consensus ( la couche de consensus ) est uniquement responsable du tri des transactions, sans exécuter la logique des contrats.
• Processus d'exécution ( couche d'exécution ) déclenché de manière asynchrone après la finalisation du consensus.
• Une fois le consensus atteint, entrez immédiatement dans le processus de consensus du prochain bloc, sans avoir à attendre l'achèvement 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", 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 conflits 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 ).
• Si un conflit est détecté, les transactions en conflit seront sérialisées et réexécutées pour garantir l'exactitude de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant le parallélisme grâce au report de l'écriture d'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un accélérateur parallèle du monde EVM.

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

Différent du positionnement L1 de Monad, MegaETH est positionné 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 d'exécution sur Ethereum(Execution Layer) ou de composant modulaire. 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 programmées de manière indépendante, afin de réaliser une exécution à haute concurrence et une capacité de réponse à faible latence en chaîne. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + State Dependency DAG(graphe de dépendance d'état acyclique orienté) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "la threadisation en chaîne".

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

MegaETH introduit un modèle d'exécution "une micro-machine virtuelle par compte (Micro-VM)", qui "thréadise" 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 (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter indépendamment et de stocker indépendamment, ce qui favorise naturellement le parallélisme.

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, tout 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 programmées et triées de manière sérielle ou différée selon l'ordre topologique. Le graphique de dépendance assure 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 brise le modèle traditionnel de machine d'état à thread unique EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en planifiant les 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 "structure de compte → architecture de planification → processus d'exécution", qui fournit une nouvelle réflexion de niveau paradigmatique pour construire des systèmes en ligne de haute performance de prochaine génération.

MegaETH a choisi un chemin 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 à la planification 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 philosophies de conception de Monad et de MegaETH diffèrent considérablement de celles de la fragmentation (Sharding) : la fragmentation divise la blockchain horizontalement en plusieurs chaînes secondaires indépendantes (Shards), chaque chaîne secondaire étant responsable d'une partie des transactions et de l'état, brisant les limitations d'une chaîne unique pour une extension au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité d'une chaîne unique, s'étendant uniquement horizontalement au niveau d'exécution, optimisant l'exécution parallèle extrême à l'intérieur d'une chaîne unique pour surmonter les performances. Les deux représentent les directions de renforcement vertical et d'extension horizontale dans les chemins d'extension de la blockchain.

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 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, a son mécanisme central de calcul parallèle appelé "Rollup Mesh". Cette architecture, grâce à la collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prend en charge des environnements multi-machines virtuelles (EVM et Wasm), et intègre des technologies avancées telles que les preuves à connaissance nulle (ZK) et les environnements d'exécution fiables (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 ( telles que le consensus, l'exécution et le stockage ), et utilise un mode de traitement asynchrone, permettant à chaque étape 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 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. Traitement spécial du réseau (SPNs) : Les SPNs sont des composants clés de l'architecture Pharos, semblables à des sous-réseaux modulaires, spécialement 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 la performance du système.
4. Consensus modulaire et mécanisme de restaking(Modular Consensus & Restaking) : Pharos introduit une flexibilité