Vue d'ensemble du secteur de calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
Le "trilemme de la blockchain" (Blockchain Trilemma) - "sécurité", "décentralisation", "extensibilité" - révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain de réaliser simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain actuellement dominantes sur le marché sont classées par paradigmes, y compris :
Exécution de l'extension améliorée : augmentation des capacités d'exécution sur place, par exemple, par parallélisme, GPU, multicœurs.
Isolation des états pour l'évolutivité : fragmentation horizontale des états / Shard, par exemple, le sharding, UTXO, plusieurs sous-réseaux
Extensibilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
Scalabilité par découplage de la structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
Scalabilité asynchrone et concurrente : Modèle Actor, isolation des processus, piloté par les messages, par exemple agents, chaînes asynchrones multithread.
Les solutions d'extension de la blockchain comprennent : le calcul parallèle en 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. Cela couvre plusieurs niveaux d'exécution, d'état, de données et de structure, formant un système complet d'extension "multicouche et combiné des modules". Cet article se concentre sur la méthode d'extension principalement 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 des blocs. 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 quêtes 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ésentant 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 synchronisation non blockchain), chaque agent fonctionne comme un "processus intelligent indépendant", envoyant des messages de manière asynchrone et piloté 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, telles que 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 au sein d'un seul bloc / machine virtuelle. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts d'architecture.
II. Chaîne d'amélioration parallèle EVM : dépasser les frontières de performance dans la compatibilité
L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension telles que le sharding, Rollup et l'architecture modulaire, mais le goulet d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus populaires, bénéficiant d'une base de développeurs solide et d'un écosystème dynamique. Ainsi, la chaîne améliorée par des parallèles EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé 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 à haute concurrence et à haute capacité de traitement, 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 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 en plusieurs étapes
Le pipelining est le concept fondamental de l'exécution parallèle des Monades, dont l'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 s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement l'objectif d'augmenter le débit et de réduire la latence. Ces phases comprennent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
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, le processus de traitement plus détaillé et l'utilisation des ressources plus efficace.
Conception de base :
Le processus de consensus (couche de consensus) ne s'occupe que 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'achèvement de l'exécution.
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écutez simultanément un "Détecteur de conflit (Conflict Detector))" pour surveiller si les transactions accèdent au même état (par exemple, conflits de lecture / écriture).
Si un conflit est détecté, les transactions conflictuelles seront réexécutées de manière sérielle pour garantir l'intégrité 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 par le biais du report de l'écriture de l'état et de la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité permettant une migration facile de l'écosystème EVM, agissant comme un 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 hautes performances compatible EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'exécution améliorée (Execution Layer) ou de composant modulaire sur Ethereum. L'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 concurrente élevée sur la chaîne et une capacité de réponse à faible latence. 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 un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers la "threadisation intra-chaîne".
Architecture Micro-VM : le compte est un thread
MegaETH introduit un modèle d'exécution de "micro-vm par compte" qui "met en fil" l'environnement d'exécution, offrant une unité d'isolation minimale pour l'ordonnancement 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, de manière intrinsèquement parallèle.
É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 de compte, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifiant quels comptes et lisant 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 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'é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 rompt avec le modèle traditionnel de machine d'état à thread unique EVM, en encapsulant des micro-machines virtuelles par unité de compte, en effectuant la planification des 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, de "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles idées de niveau paradigme pour la construction de systèmes en chaîne haute performance de nouvelle 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 à une planification d'exécution asynchrone. Théoriquement, la limite parallèle de MegaETH est plus élevée, mais il est aussi plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.
Monad et MegaETH ont des conceptions assez différentes 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 limitations 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, s'étendant uniquement horizontalement au niveau de l'exécution, optimisant l'exécution parallèle au sein de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin d'expansion de la blockchain, à savoir 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 chemin de débit, avec pour objectif central d'améliorer le TPS sur la chaîne. Ils réalisent le 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, possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture supporte un environnement multi-machine virtuelle (EVM et Wasm) par le biais d'une collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), 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 :
Traitement asynchrone de pipeline 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, le stockage) et adopte une approche de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et en parallèle, améliorant ainsi l'efficacité globale du traitement.
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.
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 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 les performances du système.
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 met en œuvre le réseau principal et les SPNs grâce au protocole de restaking.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Panorama du calcul parallèle Web3 : qui sera la meilleure solution d'extension native
Vue d'ensemble du secteur de calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
Le "trilemme de la blockchain" (Blockchain Trilemma) - "sécurité", "décentralisation", "extensibilité" - révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain de réaliser simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de "l'extensibilité", les solutions d'extension de blockchain actuellement dominantes sur le marché sont classées par paradigmes, y compris :
Les solutions d'extension de la blockchain comprennent : le calcul parallèle en 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. Cela couvre plusieurs niveaux d'exécution, d'état, de données et de structure, formant un système complet d'extension "multicouche et combiné des modules". Cet article se concentre sur la méthode d'extension principalement 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 des blocs. 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 quêtes 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.
Modèle de concurrence asynchrone hors chaîne, représentant 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 synchronisation non blockchain), chaque agent fonctionne comme un "processus intelligent indépendant", envoyant des messages de manière asynchrone et piloté 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, telles que 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 au sein d'un seul bloc / machine virtuelle. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts d'architecture.
II. Chaîne d'amélioration parallèle EVM : dépasser les frontières de performance dans la compatibilité
L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension telles que le sharding, Rollup et l'architecture modulaire, mais le goulet d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus populaires, bénéficiant d'une base de développeurs solide et d'un écosystème dynamique. Ainsi, la chaîne améliorée par des parallèles EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une direction clé 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 à haute concurrence et à haute capacité de traitement, 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 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 en plusieurs étapes
Le pipelining est le concept fondamental de l'exécution parallèle des Monades, dont l'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 s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement l'objectif d'augmenter le débit et de réduire 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 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, le processus de traitement plus détaillé et l'utilisation des ressources plus efficace.
Conception de base :
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 a choisi un chemin compatible : modifier le moins possible les règles de l'EVM, en réalisant le parallélisme par le biais du report de l'écriture de l'état et de la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité permettant une migration facile de l'écosystème EVM, agissant comme un 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 hautes performances compatible EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'exécution améliorée (Execution Layer) ou de composant modulaire sur Ethereum. L'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 concurrente élevée sur la chaîne et une capacité de réponse à faible latence. 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 un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers la "threadisation intra-chaîne".
Architecture Micro-VM : le compte est un thread
MegaETH introduit un modèle d'exécution de "micro-vm par compte" qui "met en fil" l'environnement d'exécution, offrant une unité d'isolation minimale pour l'ordonnancement 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, de manière intrinsèquement parallèle.
É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 de compte, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifiant quels comptes et lisant 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 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'é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 rompt avec le modèle traditionnel de machine d'état à thread unique EVM, en encapsulant des micro-machines virtuelles par unité de compte, en effectuant la planification des 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, de "structure de compte → architecture de planification → processus d'exécution", offrant de nouvelles idées de niveau paradigme pour la construction de systèmes en chaîne haute performance de nouvelle 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 à une planification d'exécution asynchrone. Théoriquement, la limite parallèle de MegaETH est plus élevée, mais il est aussi plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.
Monad et MegaETH ont des conceptions assez différentes 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 limitations 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, s'étendant uniquement horizontalement au niveau de l'exécution, optimisant l'exécution parallèle au sein de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans le chemin d'expansion de la blockchain, à savoir 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 chemin de débit, avec pour objectif central d'améliorer le TPS sur la chaîne. Ils réalisent le 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, possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture supporte un environnement multi-machine virtuelle (EVM et Wasm) par le biais d'une collaboration entre le réseau principal et les réseaux de traitement spéciaux (SPNs), 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 :