Panorama de la piste de calcul parallèle Web3 : la meilleure solution d'expansion native ?

Le « triangle impossible » de la blockchain (Blockchain Trilemma) « sécurité », « décentralisation », « évolutivité » révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain de réaliser simultanément « une sécurité extrême, une participation universelle, et un traitement rapide ». En ce qui concerne le sujet éternel de « l'évolutivité », les principales solutions d'extension des blockchains actuellement sur le marché sont classées par paradigmes, y compris :

• Exécution d'une extensibilité améliorée : amélioration de la capacité d'exécution sur place, par exemple, parallélisme, GPU, multicœurs.
• Type d'extension par isolation d'état : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
• Extensibilité hors chaîne par sous-traitance : exécuter à l'extérieur de la chaîne, par exemple Rollup, Coprocessor, DA
• Scalabilité découplée par architecture : modularité des architectures, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnancement partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle d'acteur, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones 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, combinant des modules". Cet article se concentre sur l'approche d'évolutivité principalement basée sur le calcul parallèle.

Calcul parallèle intra-chaîne (intra-chain parallelism), axé 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 classé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, 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
• Parallélisme au niveau des transactions (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 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 de non-synchronisation des blocs), chaque Agent agissant comme un « processus intelligent » fonctionnant de manière indépendante, avec un mode de message asynchrone en parallèle, basé sur des événements, sans planification de synchronisation. 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 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", et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc / machine virtuelle. Bien que ces solutions d'extension ne soient pas le point central de cet article, 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 : dépasser 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, y compris le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution reste non résolu de manière fondamentale. Cependant, l'EVM et Solidity demeurent actuellement les plateformes de contrats intelligents les plus soutenues par les développeurs et possédant un potentiel écologique. Ainsi, les chaînes parallèles EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé pour la nouvelle é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é d'exécution, 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), avec une exécution asynchrone au niveau du consensus (Asynchronous Execution) et une exécution 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 dédié (MonadDB), permettant 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 Monads. Son idée principale 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 en trois dimensions. Chaque phase fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases incluent : la proposition de transaction (Propose), l'atteinte du consensus (Consensus), l'exécution de la transaction (Execution) et la 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 des processus synchrones, ce modèle séquentiel limite gravement l'évolutivité des performances. Monad réalise l'asynchrone du niveau de consensus, l'asynchrone du niveau d'exécution et l'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 utilisation des ressources plus efficace.

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, 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 », ce qui améliore 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 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 validité de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant du parallélisme au cours de l'exécution grâce à un report de l'écriture de l'état et à une détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité qui facilite la migration de l'écosystème EVM, agissant comme 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 fonctionner à la fois comme une blockchain publique L1 indépendante et comme une couche d'amélioration de l'exécution (Execution Layer) ou un composant modulaire sur Ethereum. 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 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 + State Dependency DAG (graphe de dépendance d'état acyclique) et le mécanisme de synchronisation modulaire, qui construisent 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-machine virtuelle (Micro-VM) par compte », qui « threadise » l'environnement d'exécution, fournissant la plus petite unité d'isolement 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 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 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, et quels comptes sont lus, tous modélisés en 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 en série ou reportées selon l'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 l'encapsulation de micro-vm par unité de compte, en programmant 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 de nouvelles idées de paradigme pour construire des systèmes en ligne de haute performance de prochaine génération.

MegaETH a choisi de reconstruire son chemin : en abstrahant 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 parallèle 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 les limites d'une seule chaîne pour l'expansion au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, n'étendant horizontalement qu'au niveau de la couche d'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour surmonter les performances. Les deux représentent les directions de renforcement vertical et d'expansion horizontale dans les voies d'expansion de la blockchain.

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 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 modulable et full-stack, a pour mécanisme central de calcul parallèle ce qu'on appelle le « Rollup Mesh ». Cette architecture soutient le travail conjoint entre le réseau principal et les réseaux de traitement spéciaux (SPNs), prenant en charge plusieurs environnements de machines virtuelles (EVM et Wasm), et intégrant 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 tout au long 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, ce qui améliore l'efficacité globale du traitement.
2. Exécution parallèle de deux machines virtuelles (Dual VM Parallel Execution) : Pharos prend en charge deux environnements de machines virtuelles, 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, semblables à 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 connexion entre le réseau principal et les SPNs grâce au protocole de restaking.