Panorama du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?
1. Contexte du développement du calcul parallèle en blockchain
Le "triangle impossible" de la blockchain (sécurité, décentralisation, évolutivité) révèle le compromis essentiel dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de l'"évolutivité", les solutions d'extension de blockchain dominantes sur le marché se distinguent par des paradigmes, y compris :
Exécution d'une extension améliorée : augmentation des capacités d'exécution sur place, par exemple le parallélisme, le GPU, le multicœur.
Isolation de l'état pour l'extensibilité : partitionnement horizontal de l'état/Sharding, par exemple, le sharding, UTXO, plusieurs sous-réseaux
Scalabilité hors chaîne par outsourcing : effectuer l'exécution hors 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, ordonnanceur partagé, Rollup Mesh
Extension de type concurrent asynchrone : modèle d'Acteur, 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, les Rollups, le sharding, les modules DA, une structure modulaire, un système Actor, la compression des preuves zk, et une architecture Stateless, couvrant plusieurs niveaux tels que l'exécution, l'état, les données et la structure. C'est un système complet d'extension "multicouches et combinatoire de modules". Cet article se concentre principalement sur la méthode d'extension axée sur le calcul parallèle.
Calcul parallèle intra-chaîne (, se concentre sur l'exécution parallèle des transactions/instructions au sein du bloc. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être divisées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec une granularité parallèle de plus en plus fine, une intensité parallèle de plus en plus élevée, une complexité d'ordonnancement 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 / MicroVM parallèle (Call-level / MicroVM) : représente le projet MegaETH
Parallélisme au niveau des instructions (Instruction-level) : représente le projet GatlingX
Modèle de concurrence asynchrone hors chaîne, représenté par le système d'agents (Agent / Actor Model), qui appartient à un autre paradigme de calcul parallèle. En tant que système de messages inter-chaînes / asynchrone (modèle de non-synchronisation de la chaîne), chaque agent fonctionne comme un "processus d'agent intelligent" indépendant, utilisant la messagerie asynchrone en mode parallèle, piloté par des événements, sans planification de synchronisation. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions de mise à l'échelle que nous connaissons bien, comme les Rollups ou le sharding, relèvent de mécanismes de concurrence au niveau du 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/VM. Ce type de solution de mise à l'échelle n'est pas le point central de cet article, mais nous allons tout de même les utiliser pour comparer les similarités et les différences des concepts d'architecture.
![Web3 calcul parallèle paysage complet : Quelle est 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 telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity demeurent actuellement les plateformes de contrats intelligents avec la plus grande base de développeurs et le potentiel écologique. Par conséquent, les chaînes parallèles de type EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé dans la nouvelle vague d'évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement des architectures de traitement parallèle EVM orientées vers des scénarios de haute concurrence et de haute capacité d'exécution, 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 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 à plusieurs étapes
Le Pipelining est le principe 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 fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent à travers les blocs, pour finalement améliorer le débit et réduire la latence. Ces phases incluent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution asynchrone : découplage asynchrone de la consensus-exécution
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 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 (block time) et le délai de confirmation, rendant le système plus résilient, le processus plus segmenté et l'utilisation des ressources plus efficace.
Conception principale :
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 la finalisation du consensus.
Après la validation, passez immédiatement au processus de consensus du bloc suivant, sans attendre la fin de l'exécution.
L'Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour les transactions afin d'éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", ce qui 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é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 en conflit seront réexécutées en série pour garantir l'exactitude de l'état.
Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme par le biais du report d'écriture d'état et de la détection dynamique des conflits, il ressemble davantage à une version performante d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un accélérateur de parallélisme dans le monde EVM.
![Web3 Piste de calcul parallèle panoramique : la meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) 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 chaîne publique L1 autonome 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 des comptes, l'environnement d'exécution et l'état en unités minimales pouvant être programmées de manière indépendante, afin d'atteindre une exécution haute concurrence et une faible latence. L'innovation clé proposée par MegaETH repose sur : une architecture Micro-VM + un DAG de dépendance d'état (Directed Acyclic Graph) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le multithreading intra-chaîne".
Architecture Micro-VM : le compte c'est le fil
MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "threadise" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par message asynchrone (Asynchronous Messaging), plutôt que par appel synchronisé, 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 à l'état du compte, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifie quels comptes, lit 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 et ordonnées en série ou retardées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'écriture non 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 monothread EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en effectuant la planification des transactions via un graphique de dépendance d'état, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions de "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle approche de niveau paradigme pour construire les systèmes en chaîne haute performance de prochaine génération.
MegaETH a choisi une voie 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. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais il est également plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation distribué super sous la philosophie d'Ethereum.
![Web3 calcul parallèle paysage : la meilleure solution pour l'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
Les concepts de conception de Monad et de MegaETH diffèrent considérablement de ceux du sharding : le sharding découpe la blockchain horizontalement 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 l'évolutivité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, ne s'étendant horizontalement qu'au niveau de l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour dépasser les performances. Les deux représentent des directions de renforcement vertical et d'expansion horizontale dans le chemin 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 au sein de 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 à l'architecture des micro-VM (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, a pour mécanisme de calcul parallèle central ce qu'on appelle le "Rollup Mesh". Cette architecture soutient le travail collaboratif entre le réseau principal et le réseau de traitement spécial (SPNs), prenant en charge des environnements multi-VM (EVM et Wasm), et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance (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 (telles que le consensus, l'exécution, le stockage) et adopte une approche de traitement asynchrone, permettant à chaque étape de se dérouler indépendamment et en parallèle, ce qui augmente 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, 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, supportant plusieurs modèles de consensus (comme PBFT, PoS, PoA), et réalise un partage sécurisé et une intégration des ressources entre la chaîne principale et les SPNs grâce à un protocole de restaking.
De plus, Pharos a reconstruit le modèle d'exécution en profondeur du moteur de stockage grâce à des techniques telles que les arbres de Merkle multi-version, le codage delta, l'adressage versionné et la technique de poussée ADS, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, qui permet un traitement en chaîne à haute capacité, faible latence et fortement vérifiable.
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.
20 J'aime
Récompense
20
6
Partager
Commentaire
0/400
NftDataDetective
· 07-24 20:18
hmm le débat sur la scalabilité encore... j'ai déjà vu ce film pour être honnête. les rollups ont l'air appétissants cependant
Voir l'originalRépondre0
LayoffMiner
· 07-23 18:18
purement prendre les gens pour des idiots, prendre les gens pour des idiots, c'est tout.
Voir l'originalRépondre0
MEVSupportGroup
· 07-23 09:10
Que faire si ce TPS ne peut pas battre la centralisation...
Voir l'originalRépondre0
LidoStakeAddict
· 07-23 09:00
Qui comprend le vrai tps off-chain ? Les données sur papier ne sont que des bulles.
Voir l'originalRépondre0
GhostAddressMiner
· 07-23 08:56
Ces belles solutions d'extension... ne sont en réalité que de nouveaux outils de récolte de pigeons fabriqués pour les investisseurs. J'ai suivi quelques portefeuilles d'institutions, et ils accumulent secrètement des jetons L2.
Voir l'originalRépondre0
shadowy_supercoder
· 07-23 08:49
Encore des bruits sur l'extension, qui n'a pas encore fait quelques rollups ?
Web3 calcul parallèle panorama : comparaison des solutions d'extension intra-chaîne et tendances de développement
Panorama du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?
1. Contexte du développement du calcul parallèle en blockchain
Le "triangle impossible" de la blockchain (sécurité, décentralisation, évolutivité) révèle le compromis essentiel dans la conception des systèmes blockchain, à savoir qu'il est difficile pour les projets blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de l'"évolutivité", les solutions d'extension de blockchain dominantes sur le marché se distinguent par des paradigmes, y compris :
Les solutions d'extension de la blockchain comprennent : le calcul parallèle en chaîne, les Rollups, le sharding, les modules DA, une structure modulaire, un système Actor, la compression des preuves zk, et une architecture Stateless, couvrant plusieurs niveaux tels que l'exécution, l'état, les données et la structure. C'est un système complet d'extension "multicouches et combinatoire de modules". Cet article se concentre principalement sur la méthode d'extension axée sur le calcul parallèle.
Calcul parallèle intra-chaîne (, se concentre sur l'exécution parallèle des transactions/instructions au sein du bloc. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être divisées en cinq grandes catégories, chacune représentant différentes aspirations de performance, modèles de développement et philosophies d'architecture, avec une granularité parallèle de plus en plus fine, une intensité parallèle de plus en plus élevée, une complexité d'ordonnancement 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 (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 de la chaîne), chaque agent fonctionne comme un "processus d'agent intelligent" indépendant, utilisant la messagerie asynchrone en mode parallèle, piloté par des événements, sans planification de synchronisation. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions de mise à l'échelle que nous connaissons bien, comme les Rollups ou le sharding, relèvent de mécanismes de concurrence au niveau du 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/VM. Ce type de solution de mise à l'échelle n'est pas le point central de cet article, mais nous allons tout de même les utiliser pour comparer les similarités et les différences des concepts d'architecture.
![Web3 calcul parallèle paysage complet : Quelle est 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 telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, l'EVM et Solidity demeurent actuellement les plateformes de contrats intelligents avec la plus grande base de développeurs et le potentiel écologique. Par conséquent, les chaînes parallèles de type EVM, qui équilibrent la compatibilité écologique et l'amélioration des performances d'exécution, deviennent une direction clé dans la nouvelle vague d'évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement des architectures de traitement parallèle EVM orientées vers des scénarios de haute concurrence et de haute capacité d'exécution, 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 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 à plusieurs étapes
Le Pipelining est le principe 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 fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent à travers les blocs, pour finalement améliorer le débit et réduire la latence. Ces phases incluent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution asynchrone : découplage asynchrone de la consensus-exécution
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 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 (block time) et le délai de confirmation, rendant le système plus résilient, le processus plus segmenté et l'utilisation des ressources plus efficace.
Conception principale :
Exécution parallèle optimiste : Exécution parallèle optimiste
L'Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour les transactions afin d'éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", ce qui améliore considérablement le taux de traitement des transactions.
Mécanisme d'exécution :
Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme par le biais du report d'écriture d'état et de la détection dynamique des conflits, il ressemble davantage à une version performante d'Ethereum, avec une bonne maturité facilitant la migration de l'écosystème EVM, c'est un accélérateur de parallélisme dans le monde EVM.
![Web3 Piste de calcul parallèle panoramique : la meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) 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 chaîne publique L1 autonome 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 des comptes, l'environnement d'exécution et l'état en unités minimales pouvant être programmées de manière indépendante, afin d'atteindre une exécution haute concurrence et une faible latence. L'innovation clé proposée par MegaETH repose sur : une architecture Micro-VM + un DAG de dépendance d'état (Directed Acyclic Graph) et un mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le multithreading intra-chaîne".
Architecture Micro-VM : le compte c'est le fil
MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "threadise" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par message asynchrone (Asynchronous Messaging), plutôt que par appel synchronisé, 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 à l'état du compte, le système maintient en temps réel un graphique de dépendance global (Dependency Graph), chaque transaction modifie quels comptes, lit 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 et ordonnées en série ou retardées selon l'ordre topologique. Le graphique de dépendance garantit la cohérence des états et l'écriture non 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 monothread EVM, en réalisant un encapsulage de micro-machine virtuelle au niveau du compte, en effectuant la planification des transactions via un graphique de dépendance d'état, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions de "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle approche de niveau paradigme pour construire les systèmes en chaîne haute performance de prochaine génération.
MegaETH a choisi une voie 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. En théorie, la limite de parallélisme de MegaETH est plus élevée, mais il est également plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation distribué super sous la philosophie d'Ethereum.
![Web3 calcul parallèle paysage : la meilleure solution pour l'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
Les concepts de conception de Monad et de MegaETH diffèrent considérablement de ceux du sharding : le sharding découpe la blockchain horizontalement 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 l'évolutivité au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité de la chaîne unique, ne s'étendant horizontalement qu'au niveau de l'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour dépasser les performances. Les deux représentent des directions de renforcement vertical et d'expansion horizontale dans le chemin 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 au sein de 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 à l'architecture des micro-VM (Micro-VM). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, a pour mécanisme de calcul parallèle central ce qu'on appelle le "Rollup Mesh". Cette architecture soutient le travail collaboratif entre le réseau principal et le réseau de traitement spécial (SPNs), prenant en charge des environnements multi-VM (EVM et Wasm), et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance (ZK) et les environnements d'exécution de confiance (TEE).
Analyse du mécanisme de calcul parallèle Rollup Mesh :
De plus, Pharos a reconstruit le modèle d'exécution en profondeur du moteur de stockage grâce à des techniques telles que les arbres de Merkle multi-version, le codage delta, l'adressage versionné et la technique de poussée ADS, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, qui permet un traitement en chaîne à haute capacité, faible latence et fortement vérifiable.