Carte panoramique du secteur de calcul parallèle Web3 : la meilleure solution d'extension native ?
I. Introduction : Le « triangle impossible » de la blockchain et les solutions d'évolutivité
Le « triangle impossible » de la blockchain, qui comprend la « sécurité », la « décentralisation » et la « scalabilité », 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é extrême, une participation universelle et un traitement rapide ». Concernant le sujet éternel de la « scalabilité », les solutions d'extension de blockchain actuellement sur le marché se distinguent selon des paradigmes, y compris :
Exécution de l'extension améliorée : amélioration des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
Isolation de l'état par extension : partitionnement horizontal de l'état/Shard, par exemple le sharding, UTXO, multi-sous-réseaux
Extensibilité hors chaîne par sous-traitance : déplacer l'exécution en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
Scalabilité découplée par structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonneur partagé, Rollup Mesh
Extension de type asynchrone et concurrent : 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 au sein de la chaîne, Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression par preuve zk, l'architecture Stateless, etc. Elles couvrent plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extension « multi-niveau collaboratif, combinaison modulaire ». Cet article se concentre sur la méthode d'extension principalement axée sur le calcul parallèle.
Calcul parallèle intra-chaîne (, se concentrant 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 classées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec un degré de parallélisme de plus en plus fin, une intensité de parallélisme de plus en plus élevée, une complexité de planification croissante, 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 le projet 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), appartenant à 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 fonctionnant comme un « processus intelligent » indépendant, gérant de manière parallèle des messages asynchrones, des événements déclencheurs, sans planification synchronisée. Les projets représentés incluent AO, ICP, Cartesi, etc.
Les solutions d'extension bien connues telles que Rollup ou le sharding appartiennent aux 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/une seule machine virtuelle. Ces solutions d'extension ne sont pas le point focal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts architecturaux.
![Web3, panorama de la piste de calcul parallèle : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
II. 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, passant par plusieurs tentatives d'extension, notamment le sharding, le Rollup et l'architecture modulable, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus solides en termes de base de développeurs et de potentiel écologique. Par conséquent, les chaînes parallèles renforcées par l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé dans 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 axée sur des scénarios à haute concurrence et à haut débit, en partant 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 par 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 sein des couches de consensus et de 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 centrale est de décomposer le processus d'exécution de la blockchain en plusieurs étapes indépendantes et de traiter ces étapes en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque étape s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, pour finalement atteindre une augmentation du débit et une réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), réalisation du consensus (Consensus), exécution de la transaction (Execution) et soumission du bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de Consensus et d'Exécution
Dans une chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement des processus synchrones, et ce modèle sériel limite gravement l'extension 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 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 (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.
L'Ethereum traditionnel utilise un modèle d'exécution strictement sériel 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 conflit 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 conflictuelles seront réexécutées de manière séquentielle pour garantir l'exactitude de l'état.
Monad a choisi un chemin compatible : le moins de modifications possible aux règles de l'EVM, en réalisant des parallèles à travers le report de l'écriture d'état et la détection dynamique de conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, agissant comme un accélérateur de parallélisme dans le monde de l'EVM.
![Web3 et la carte panoramique des pistes de calcul parallèle : la meilleure solution pour l'extensibilité native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) Analyse du mécanisme de calcul parallèle de MegaETH
Contrairement à la position L1 de Monad, MegaETH est positionnée comme une couche d'exécution parallèle hautes performances et modulaire compatible avec EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée sur Ethereum (Execution Layer) 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 de réaliser 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 + le DAG de dépendance d'état (Directed Acyclic Graph) et le mécanisme de synchronisation modulaire, qui ensemble construisent un système d'exécution parallèle orienté vers le "multi-threading au sein de la chaîne".
Architecture Micro-VM (micro machine virtuelle) : le compte est un thread
MegaETH introduit un modèle d'exécution de « micro-machine virtuelle (Micro-VM) par compte », rendant l'environnement d'exécution « threadé », offrant ainsi une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par des messages asynchrones (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à de nombreuses VM d'exécuter et de stocker de manière indépendante, et d'être naturellement parallèles.
DAG de Dépendance d'État : Mécanisme de Planification Basé sur le Graphique de Dépendance
MegaETH a construit un système de planification DAG basé sur des 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, et 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 avec des relations de dépendance seront planifiées et triées en série ou retardées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'absence d'écriture répétée 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 réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en utilisant un graphe de dépendance d'état pour le plan de transaction, et en remplaçant la pile d'appel synchrone par un mécanisme de message asynchrone. 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 une nouvelle perspective de niveau paradigme pour construire le système en ligne 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 à une exécution asynchrone. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais cela rend également le contrôle de la complexité plus difficile, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.
![Web3 Calculs parallèles : Quelle est la meilleure solution d'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
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, ce qui brise les limitations d'une seule chaîne pour une mise à l'échelle 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 l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour surmonter 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 principal d'améliorer le TPS sur la chaîne, en réalisant le 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 parallèle, a pour mécanisme de calcul parallèle central ce qu'on appelle le "Rollup Mesh". Cette architecture prend en charge le travail collaboratif entre la chaîne principale et les réseaux de traitement spéciaux (SPNs), supporte 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 de confiance (TEE).
Analyse du mécanisme de calcul parallèle Rollup Mesh :
Traitement asynchrone en pipeline sur l'ensemble 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, augmentant 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 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.
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 le partage sécurisé et l'intégration des ressources entre le mainnet et les SPN grâce au protocole de restaking.
De plus, Pharos reconstruit le modèle d'exécution à partir du bas du moteur de stockage grâce à des techniques telles que l'arbre Merkle multi-version, l'encodage delta, l'adressage versionné et la poussée ADS, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, pour réaliser un haut débit et une faible latence.
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.
9 J'aime
Récompense
9
5
Reposter
Partager
Commentaire
0/400
CryptoMom
· Il y a 14h
Alors le sharding est plus fiable.
Voir l'originalRépondre0
ApeShotFirst
· Il y a 19h
La sécurité et la vitesse ne peuvent pas être conciliées.
Voir l'originalRépondre0
RugpullTherapist
· Il y a 19h
L'exécution peut-elle vraiment renforcer?
Voir l'originalRépondre0
MidnightTrader
· Il y a 19h
L'efficacité n'est pas aussi importante que la sécurité.
Voir l'originalRépondre0
MaticHoleFiller
· Il y a 19h
Les sharding de la marque claire sont toujours fiables.
Web3 Calcul parallèle panorama : Analyse des cinq grandes pistes et innovations des chaînes compatibles EVM
Carte panoramique du secteur de calcul parallèle Web3 : la meilleure solution d'extension native ?
I. Introduction : Le « triangle impossible » de la blockchain et les solutions d'évolutivité
Le « triangle impossible » de la blockchain, qui comprend la « sécurité », la « décentralisation » et la « scalabilité », 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é extrême, une participation universelle et un traitement rapide ». Concernant le sujet éternel de la « scalabilité », les solutions d'extension de blockchain actuellement sur le marché se distinguent selon des paradigmes, y compris :
Les solutions d'extension de la blockchain comprennent : le calcul parallèle au sein de la chaîne, Rollup, le sharding, le module DA, la structure modulaire, le système Actor, la compression par preuve zk, l'architecture Stateless, etc. Elles couvrent plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extension « multi-niveau collaboratif, combinaison modulaire ». Cet article se concentre sur la méthode d'extension principalement axée sur le calcul parallèle.
Calcul parallèle intra-chaîne (, se concentrant 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 classées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec un degré de parallélisme de plus en plus fin, une intensité de parallélisme de plus en plus élevée, une complexité de planification croissante, 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), appartenant à 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 fonctionnant comme un « processus intelligent » indépendant, gérant de manière parallèle des messages asynchrones, des événements déclencheurs, sans planification synchronisée. Les projets représentés incluent AO, ICP, Cartesi, etc.
Les solutions d'extension bien connues telles que Rollup ou le sharding appartiennent aux 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/une seule machine virtuelle. Ces solutions d'extension ne sont pas le point focal de cet article, mais nous les utiliserons néanmoins pour comparer les similitudes et les différences des concepts architecturaux.
![Web3, panorama de la piste de calcul parallèle : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
II. 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, passant par plusieurs tentatives d'extension, notamment le sharding, le Rollup et l'architecture modulable, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity restent les plateformes de contrats intelligents les plus solides en termes de base de développeurs et de potentiel écologique. Par conséquent, les chaînes parallèles renforcées par l'EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé dans 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 axée sur des scénarios à haute concurrence et à haut débit, en partant 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 par 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 sein des couches de consensus et de 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 centrale est de décomposer le processus d'exécution de la blockchain en plusieurs étapes indépendantes et de traiter ces étapes en parallèle, formant ainsi une architecture de pipeline tridimensionnelle. Chaque étape s'exécute sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, pour finalement atteindre une augmentation du débit et une réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), réalisation du consensus (Consensus), exécution de la transaction (Execution) et soumission du bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de Consensus et d'Exécution
Dans une chaîne traditionnelle, le consensus et l'exécution des transactions sont généralement des processus synchrones, et ce modèle sériel limite gravement l'extension 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 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 :
Exécution parallèle optimiste : Optimistic Parallel Execution
L'Ethereum traditionnel utilise un modèle d'exécution strictement sériel 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 a choisi un chemin compatible : le moins de modifications possible aux règles de l'EVM, en réalisant des parallèles à travers le report de l'écriture d'état et la détection dynamique de conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, agissant comme un accélérateur de parallélisme dans le monde de l'EVM.
![Web3 et la carte panoramique des pistes de calcul parallèle : la meilleure solution pour l'extensibilité native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) Analyse du mécanisme de calcul parallèle de MegaETH
Contrairement à la position L1 de Monad, MegaETH est positionnée comme une couche d'exécution parallèle hautes performances et modulaire compatible avec EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée sur Ethereum (Execution Layer) 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 de réaliser 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 + le DAG de dépendance d'état (Directed Acyclic Graph) et le mécanisme de synchronisation modulaire, qui ensemble construisent un système d'exécution parallèle orienté vers le "multi-threading au sein de la chaîne".
Architecture Micro-VM (micro machine virtuelle) : le compte est un thread
MegaETH introduit un modèle d'exécution de « micro-machine virtuelle (Micro-VM) par compte », rendant l'environnement d'exécution « threadé », offrant ainsi une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par des messages asynchrones (Asynchronous Messaging), plutôt que par des appels synchrones, permettant à de nombreuses VM d'exécuter et de stocker de manière indépendante, et d'être naturellement parallèles.
DAG de Dépendance d'État : Mécanisme de Planification Basé sur le Graphique de Dépendance
MegaETH a construit un système de planification DAG basé sur des 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, et 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 avec des relations de dépendance seront planifiées et triées en série ou retardées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'absence d'écriture répétée 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 réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en utilisant un graphe de dépendance d'état pour le plan de transaction, et en remplaçant la pile d'appel synchrone par un mécanisme de message asynchrone. 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 une nouvelle perspective de niveau paradigme pour construire le système en ligne 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 à une exécution asynchrone. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais cela rend également le contrôle de la complexité plus difficile, ressemblant davantage à un système d'exploitation super distribué sous l'idée d'Ethereum.
![Web3 Calculs parallèles : Quelle est la meilleure solution d'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
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, ce qui brise les limitations d'une seule chaîne pour une mise à l'échelle 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 l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour surmonter 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 principal d'améliorer le TPS sur la chaîne, en réalisant le 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 parallèle, a pour mécanisme de calcul parallèle central ce qu'on appelle le "Rollup Mesh". Cette architecture prend en charge le travail collaboratif entre la chaîne principale et les réseaux de traitement spéciaux (SPNs), supporte 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 de confiance (TEE).
Analyse du mécanisme de calcul parallèle Rollup Mesh :
De plus, Pharos reconstruit le modèle d'exécution à partir du bas du moteur de stockage grâce à des techniques telles que l'arbre Merkle multi-version, l'encodage delta, l'adressage versionné et la poussée ADS, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, pour réaliser un haut débit et une faible latence.