Web3 et calcul parallèle : explorer la meilleure solution d’évolutivité native de la Blockchain

Le “triangle impossible” de la Blockchain (sécurité, décentralisation, évolutivité) révèle les compromis essentiels dans la conception des systèmes de Blockchain. Concernant le sujet éternel de l’“évolutivité”, les principales solutions d’extension de Blockchain actuellement sur le marché se distinguent selon des paradigmes, y compris :

• Exécution d’une scalabilité améliorée : augmentation des capacités d’exécution sur place, comme le parallélisme, le GPU, le multicœur
• Scalabilité par isolation d’état : partitionnement horizontal de l’état / Shard, par exemple partitions, UTXO, sous-réseaux multiples
• Scalabilité sous-traitée hors chaîne : exécuter à l’extérieur de la chaîne, par exemple Rollup, Coprocessor, DA
• Extension par découplage de la structure : modularité de l’architecture, fonctionnement en collaboration, par exemple chaîne de modules, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread.

Les solutions d’extension de la Blockchain comprennent : le calcul parallèle au sein de la chaîne, Rollup, le sharding, les modules DA, une structure modulaire, le système Actor, la compression de preuve 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 « multi-niveaux collaboratif et combinaison modulaire ». Cet article met principalement l’accent sur la méthode d’extension dominée par 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 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é de parallélisme de plus en plus fine, une intensité de parallélisme de plus en plus élevée, une complexité de planification de plus en plus élevée, et une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.

• Parallèle 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 (Transaction-level) : représente les projets Monad, Aptos
• Niveau d’appel / MicroVM 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 synchronisation de blocs non), chaque Agent fonctionnant comme un “processus intelligent indépendant”, avec des messages asynchrones en mode parallèle, événement déclencheur, sans planification de synchronisation, les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d’extension que nous connaissons bien, comme le Rollup ou le sharding, appartiennent aux 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. Ce type de solution d’extension n’est pas le sujet principal de cet article, mais nous l’utiliserons néanmoins pour comparer les différences des concepts architecturaux.

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

L’architecture de traitement séquentiel d’Ethereum a évolué jusqu’à présent, passant par plusieurs tentatives d’extension telles que le sharding, les Rollups et les architectures modulaires, mais le goulet d’étranglement du débit au niveau d’exécution n’a toujours pas été fondamentalement surmonté. Cependant, l’EVM et Solidity restent les plateformes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus importants actuellement. Par conséquent, la chaîne d’amélioration parallèle de l’EVM, qui équilibre la compatibilité écologique et l’amélioration des performances d’exécution, devient une direction clé dans la nouvelle évolution de l’extension. 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 de haute concurrence et de haut débit, respectivement à partir de l’exécution retardé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 au niveau du consensus (Asynchronous Execution) et en utilisant une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau d’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 en plusieurs étapes

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 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 pour réaliser 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), atteinte de consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

Exécution Asynchrone : Découplage Asynchrone de la Consensus et de l’Exécution

Sur 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’asynchronisme du niveau de consensus, l’asynchronisme du niveau d’exécution et l’asynchronisme du stockage 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 le taux d’utilisation des ressources plus élevé.

Conception de base :

• 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 la fin de l’exécution.

Exécution parallèle optimiste：乐观并行执行

Ethereum traditionnel utilise un modèle d’exécution strictement séquentiel pour les transactions afin d’é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 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 au même état (comme des conflits de lecture/écriture).
• Si un conflit est détecté, les transactions conflictuelles seront réexécutées en série pour garantir la cohérence de l’état.

Monad a choisi un chemin compatible : le moins de changements possibles aux règles de l’EVM, en réalisant le parallélisme par le biais de l’écriture d’état différée et de la détection dynamique des conflits, ressemblant davantage à une version performante d’Ethereum, avec une bonne maturité et une mise en œuvre facile de la migration de l’écosystème EVM, servant d’accélérateur de parallélisme dans le monde de l’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 haute performance modulaire compatible avec l’EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d’amélioration d’exécution sur Ethereum ou de composant modulaire. 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 d’atteindre 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 (graphe acyclique dirigé de dépendance d’état) et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d’exécution parallèle orienté vers “l’exécution en fil de chaîne”.

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

MegaETH introduit un modèle d’exécution “une micro-machine virtuelle (Micro-VM) par compte”, qui “threadise” l’environnement d’exécution, fournissant une unité d’isolation minimale pour le planning 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 de manière indépendante et de stocker de manière indépendante, naturellement parallèles.

État de dépendance DAG : 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 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é sous forme de 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 et ordonnées de manière séquentielle ou différée selon un ordre topologique. Le graphique de dépendance garantit la cohérence des états 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 par unité de compte, 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 depuis “structure de compte → architecture de planification → processus d’exécution”, offrant de nouvelles idées de niveau paradigmatique pour construire le prochain système en ligne haute performance.

MegaETH a choisi une voie de reconstruction : abstraire complètement les comptes et les contrats en VM indépendants, en libérant le potentiel de parallélisme ultime grâce à un ordonnancement 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 distribué super 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 chaîne secondaire étant responsable d’une partie des transactions et des états, brisant ainsi la limitation d’une seule chaîne pour une extension au niveau du réseau ; tandis que Monad et MegaETH conservent l’intégrité de la chaîne unique, en s’étendant horizontalement uniquement au niveau de la couche d’exécution, optimisant 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 d’extension de la blockchain, à savoir 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 intra-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, possède un mécanisme de calcul parallèle central appelé “Rollup Mesh”. Cette architecture soutient la coopération entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prenant en charge des environnements multi-VM (EVM et Wasm) et intégrant des technologies avancées telles que les preuves à connaissance zéro (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 de la transaction (comme le consensus, l’exécution, le stockage) et adopte une méthode de traitement asynchrone, permettant ainsi à chaque étape de s’effectuer 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 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 réalise un partage sécurisé et une intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking.

De plus, Pharos a reconstruit le modèle d’exécution à partir du moteur de stockage sous-jacent grâce à des techniques telles que les arbres de Merkle multi-version, l’encodage delta, l’adressage versionné et le pushdown ADS, lançant ainsi le moteur de stockage haute performance natif Blockchain Pharos Store, réalisant une capacité de traitement en chaîne à haut débit, faible latence et fortement vérifiable.

En général, l’architecture Rollup Mesh de Pharos réalise une capacité de calcul parallèle haute performance grâce à une conception modulaire et un mécanisme de traitement asynchrone, Pharos.