Panorama de la piste de calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
Le « trilemme de la blockchain » révèle les compromis essentiels dans la conception des systèmes blockchain : la « sécurité », la « décentralisation » et la « scalabilité », à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément « une sécurité maximale, une participation universelle et un traitement rapide ». En ce qui concerne le sujet éternel de la « scalabilité », les solutions d'extension de blockchain actuellement sur le marché sont classées selon des paradigmes, y compris :
Exécution d'une augmentation de capacité améliorée : amélioration des capacités d'exécution sur place, par exemple par le biais de l'exécution parallèle, du GPU et du multicœur.
Isolation des états pour l'extension : partitionnement horizontal de l'état / Shard, par exemple partitionnement, UTXO, plusieurs sous-réseaux
Scalabilité hors chaîne par sous-traitance : exécuter à l'extérieur 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 de modules, ordonneurs partagés, Rollup Mesh
Extension asynchrone et concurrente : modèle Actor, isolation des processus, piloté par messages, par exemple, agents, chaînes asynchrones multithread.
Les solutions d'évolutivité de la blockchain incluent : le calcul parallèle sur la 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., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'évolutivité « collaboratif à plusieurs niveaux, combinant des modules ». Cet article se concentre principalement sur les méthodes d'évolutivité 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 une recherche de performance différente, un modèle de développement et une philosophie d'architecture, 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
Niveau de transaction parallèle (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 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 » autonome, utilisant une manière parallèle de messages asynchrones, déclenchée par des événements, sans nécessité de planification synchronisée. Parmi les projets représentatifs, on trouve AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, comme le Rollup ou le sharding, relèvent de mécanismes de concurrence au niveau système et ne sont pas considérées comme des calculs parallèles 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. 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 architecturaux.
Deux, EVM chaîne d'amélioration parallèle : dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité de traitement de la couche d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et ayant le plus de potentiel écologique. Ainsi, la chaîne parallèle de l'EVM est devenue une voie clé qui prend en compte la compatibilité de l'écosystème et l'amélioration des performances d'exécution, et elle est en train de devenir une direction importante 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 à 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 principe fondamental du traitement par pipeline (Pipelining), avec exécution asynchrone au niveau du consensus (Asynchronous Execution) et exécution concurrente optimiste au niveau d'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 en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, ce qui conduit 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).
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 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 les délais de confirmation, rendant le système plus résilient, les processus de traitement plus segmentés et l'utilisation des ressources plus élevée.
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 pour le prochain bloc commence immédiatement, sans attendre la fin 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 », 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 conflit 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 (par exemple, 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 : minimiser les modifications des règles EVM, en réalisant le parallélisme par le report de l'écriture d'état et la détection dynamique des conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, étant un accélérateur de parallélisme dans le monde 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 avec l'EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'exécution améliorée sur Ethereum ou de composant modulaire. Son objectif de conception central est de décomposer la logique de compte, 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 au sein de 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 le 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 fil
MegaETH introduit un modèle d'exécution « une Micro-VM par compte », qui « threadise » l'environnement d'exécution, fournissant l'unité d'isolation minimale 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 de s'exécuter de manière indépendante et de stocker de manière indépendante, offrant ainsi un parallélisme naturel.
État de dépendance DAG : mécanisme de planification basé sur un graphe de dépendance
MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état du compte, le système maintient en temps réel un graphe de dépendance global (Dependency Graph), chaque transaction modifiant quels comptes, lisant quels comptes, est entièrement modélisée en tant que relation 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 retardées selon un ordre topologique. Le graphe de dépendance garantit la cohérence de l'état et l'absence d'écritures répétées lors du 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 EVM à un seul thread, en réalisant un encapsulage de micro-VM par compte, en utilisant un graphe de dépendance d'état pour la planification des transactions, 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 une nouvelle perspective de niveau paradigme pour construire des systèmes en ligne de haute performance de prochaine génération.
MegaETH a choisi de reconstruire son chemin : en abstraisant complètement les comptes et les contrats en une VM indépendante, en libérant un potentiel de parallélisme extrême grâce à l'exécution asynchrone. Théoriquement, 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 MegaETH diffèrent considérablement de celles 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 la limitation d'une seule chaîne pour une évolutivité au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, n'ayant qu'une extension horizontale 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 différentes dans le chemin d'extension de la blockchain : 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 chemin de débit, avec pour objectif central d'améliorer le TPS on-chain, en réalisant un traitement parallèle au niveau des transactions ou des comptes via 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 parallèle, a un mécanisme de calcul parallèle central 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 un environnement 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 :
Traitement asynchrone par 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 méthode de traitement asynchrone, permettant à chaque étape de se dérouler indépendamment et en parallèle, améliorant ainsi l'efficacité globale du traitement.
Exécution parallèle de deux machines virtuelles (Exécution parallèle de VM double) : 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 (SPN) : Les SPN 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 SPN
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.
Vue d'ensemble de la piste de calcul parallèle Web3 : de la compatibilité EVM à l'innovation d'extensibilité Rollup Mesh
Panorama de la piste de calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
Le « trilemme de la blockchain » révèle les compromis essentiels dans la conception des systèmes blockchain : la « sécurité », la « décentralisation » et la « scalabilité », à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément « une sécurité maximale, une participation universelle et un traitement rapide ». En ce qui concerne le sujet éternel de la « scalabilité », les solutions d'extension de blockchain actuellement sur le marché sont classées selon des paradigmes, y compris :
Les solutions d'évolutivité de la blockchain incluent : le calcul parallèle sur la 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., couvrant plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'évolutivité « collaboratif à plusieurs niveaux, combinant des modules ». Cet article se concentre principalement sur les méthodes d'évolutivité 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 une recherche de performance différente, un modèle de développement et une philosophie d'architecture, 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é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 synchronisation non blockchain), chaque Agent fonctionne comme un « processus intelligent » autonome, utilisant une manière parallèle de messages asynchrones, déclenchée par des événements, sans nécessité de planification synchronisée. Parmi les projets représentatifs, on trouve AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, comme le Rollup ou le sharding, relèvent de mécanismes de concurrence au niveau système et ne sont pas considérées comme des calculs parallèles 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. 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 architecturaux.
Deux, EVM chaîne d'amélioration parallèle : dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant connu plusieurs tentatives d'extension telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité de traitement de la couche d'exécution n'a toujours pas été fondamentalement résolu. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus soutenues par les développeurs et ayant le plus de potentiel écologique. Ainsi, la chaîne parallèle de l'EVM est devenue une voie clé qui prend en compte la compatibilité de l'écosystème et l'amélioration des performances d'exécution, et elle est en train de devenir une direction importante 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 à 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 principe fondamental du traitement par pipeline (Pipelining), avec exécution asynchrone au niveau du consensus (Asynchronous Execution) et exécution concurrente optimiste au niveau d'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 en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque phase s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, ce qui conduit 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 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 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 les délais de confirmation, rendant le système plus résilient, les processus de traitement plus segmentés et l'utilisation des ressources plus élevée.
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 », ce qui augmente considérablement le taux de traitement des transactions.
Mécanisme d'exécution :
Monad a choisi un chemin compatible : minimiser les modifications des règles EVM, en réalisant le parallélisme par le report de l'écriture d'état et la détection dynamique des conflits pendant l'exécution, ressemblant davantage à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, étant un accélérateur de parallélisme dans le monde 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 avec l'EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'exécution améliorée sur Ethereum ou de composant modulaire. Son objectif de conception central est de décomposer la logique de compte, 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 au sein de 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 le 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 fil
MegaETH introduit un modèle d'exécution « une Micro-VM par compte », qui « threadise » l'environnement d'exécution, fournissant l'unité d'isolation minimale 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 de s'exécuter de manière indépendante et de stocker de manière indépendante, offrant ainsi un parallélisme naturel.
État de dépendance DAG : mécanisme de planification basé sur un graphe de dépendance
MegaETH a construit un système de planification DAG basé sur les relations d'accès à l'état du compte, le système maintient en temps réel un graphe de dépendance global (Dependency Graph), chaque transaction modifiant quels comptes, lisant quels comptes, est entièrement modélisée en tant que relation 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 retardées selon un ordre topologique. Le graphe de dépendance garantit la cohérence de l'état et l'absence d'écritures répétées lors du 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 EVM à un seul thread, en réalisant un encapsulage de micro-VM par compte, en utilisant un graphe de dépendance d'état pour la planification des transactions, 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 une nouvelle perspective de niveau paradigme pour construire des systèmes en ligne de haute performance de prochaine génération.
MegaETH a choisi de reconstruire son chemin : en abstraisant complètement les comptes et les contrats en une VM indépendante, en libérant un potentiel de parallélisme extrême grâce à l'exécution asynchrone. Théoriquement, 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 MegaETH diffèrent considérablement de celles 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 la limitation d'une seule chaîne pour une évolutivité au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, n'ayant qu'une extension horizontale 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 différentes dans le chemin d'extension de la blockchain : 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 chemin de débit, avec pour objectif central d'améliorer le TPS on-chain, en réalisant un traitement parallèle au niveau des transactions ou des comptes via 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 parallèle, a un mécanisme de calcul parallèle central 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 un environnement 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 :