Vue d'ensemble du secteur du calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
I. Introduction : Évolution technologique du calcul parallèle dans la blockchain
Le "triangle impossible" de la blockchain (Blockchain Trilemma) – "sécurité", "décentralisation", "extensibilité" – révèle les compromis essentiels dans la conception des systèmes de 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'extensibilité", les principales solutions d'extension de blockchain sur le marché actuel sont classées 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 pour l'extension : partitionnement horizontal de l'état / Shard, par exemple, sharding, UTXO, sous-réseaux multiples
Scalabilité hors chaîne par sous-traitance : exécuter en dehors de la chaîne, par exemple Rollup, Coprocesseur, DA
Scalabilité par découplage de structure : modularité de l'architecture, fonctionnement collaboratif, par exemple chaînes modulaires, ordonnanceurs partagés, Rollup Mesh
Expansion asynchrone et concurrente : modèle d'Acteur, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread.
Les solutions d'extension de la blockchain incluent : le calcul parallèle au sein de la chaîne, Rollup, le sharding, le module DA, une 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, formant un système complet d'extension "multi-niveau, combinaison modulaire". Cet article se concentre sur les méthodes d'extension principalement basées sur le calcul parallèle.
Calcul parallèle intra-chaîne (, 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 des objectifs de performance, des modèles de développement et des philosophies architecturales différents, avec une granularité parallèle 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
Appel niveau / 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ésentant un système d'agents (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 fonctionne comme un "processus intelligent autonome", permettant l'échange de messages de manière asynchrone en parallèle, basé sur des événements, sans nécessité de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions Rollup ou de sharding que nous connaissons bien appartiennent à des mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle interne à la chaîne. Elles réalisent l'évolutivité en "exécutant plusieurs chaînes/domaines d'exécution en parallèle", plutôt qu'en augmentant le degré de parallélisme au sein d'un seul bloc/ machine virtuelle. Ce type de solution d'évolutivité n'est pas le point central de cet article, mais nous l'utiliserons néanmoins pour comparer les similitudes et les différences des concepts architecturaux.
![Web3 Calcul de la piste parallèle : La meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
II. Chaîne améliorée parallèle EVM : Dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extensibilité 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 trouvé de percée fondamentale. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents les plus établies en termes de base de développeurs et de potentiel écologique. Par conséquent, les chaînes parallèles de la série EVM, qui équilibrent compatibilité écologique et amélioration des performances d'exécution, deviennent une voie clé dans la nouvelle évolution de l'extensibilité. 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 de haute concurrence et de haute capacité d'exécution, respectivement à partir de l'exécution différée et de la décomposition d'état.
) Analyse du mécanisme de calcul parallèle de Monad
Monad est une blockchain Layer1 haute performance repensé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 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 de base 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 en trois dimensions. Chaque phase fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement l'objectif d'améliorer le débit et de réduire la latence. Ces phases comprennent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de Consensus et d'Exécution
Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, et 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, les processus de traitement plus segmentés et l'utilisation des ressources plus efficace.
Conception de base :
Le processus de consensus (couche de consensus) est uniquement responsable de l'ordonnancement 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 bloc suivant commence immédiatement, sans attendre l'exécution.
L'Ethereum traditionnel adopte un modèle d'exécution strictement séquentiel pour éviter les conflits d'état. En revanche, Monad utilise une stratégie d'"exécution parallèle optimiste", ce qui permet d'augmenter 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, supposant qu'il n'y a pas de conflits d'état entre la plupart des transactions.
Exécutez simultanément un "Détecteur de Conflits (Conflict Detector###)" pour surveiller si les transactions accèdent au même état (comme les conflits de lecture/écriture).
Si un conflit est détecté, les transactions conflictuelles seront sérialisées et réexécutées 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 le parallélisme via le report de l'écriture des états et la détection dynamique des 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 EVM.
) Analyse du mécanisme de calcul parallèle de MegaETH
Contrairement à la position L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulaire à haute performance compatible avec l'EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée (Execution Layer) ou de composant modulaire sur Ethereum. 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 planifiées indépendamment, 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 + State Dependency DAG (graphique 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 au sein de la chaîne".
Architecture Micro-VM : le compte est un fil d'exécution
MegaETH introduit un modèle d'exécution de "Micro-VM par compte", qui "thréadise" l'environnement d'exécution, fournissant ainsi la plus petite unité d'isolement pour le plan de programmation parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones, plutôt que par des appels synchrones, permettant à de nombreuses VM de s'exécuter indépendamment et de stocker de manière autonome, ce qui les rend naturellement parallèles.
État de dépendance DAG : Mécanisme de planification basé sur le graphe de dépendance
MegaETH a construit un système de planification DAG basé sur les 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 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 de l'é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
MegaETH est construit sur le paradigme de la programmation asynchrone, similaire à la transmission de messages asynchrones du modèle Actor, résolvant les problèmes d'appels séquentiels traditionnels de l'EVM. Les appels de contrat sont asynchrones (exécution non récursive), lorsque le contrat A appelle B, puis C, chaque appel est asynchronisé, sans avoir besoin d'attendre de manière bloquante ; la pile d'appels est développée en un graphique d'appels asynchrones (Call Graph) ; le traitement des transactions = parcours du graphique asynchrone + résolution des dépendances + planification parallèle.
En somme, MegaETH brise 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 programmant les 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, passant de "structure de compte → architecture de planification → flux 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 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 à l'exécution asynchrone. Théoriquement, la limite de parallélisme de MegaETH est plus élevée, mais il est aussi plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation distribué super selon la philosophie d'Ethereum.
Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux du sharding : le sharding divise la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et de l'état, ce qui brise les limitations d'une seule chaîne pour étendre la couche réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, s'étendant horizontalement uniquement au niveau 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 dans le chemin d'extension de la blockchain : le renforcement vertical et l'expansion horizontale.
![Web3 paysage complet de la piste de calcul parallèle : la meilleure solution d'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
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 de la chaîne. Ils réalisent un traitement parallèle au niveau des transactions ou des comptes grâce à l'exécution différée (Deferred Execution) et à l'architecture de micro-machine virtuelle (Micro-VM). En revanche, Pharos Network, en tant que réseau de blockchain L1 modulaire et full-stack, dispose d'un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture supporte un environnement multi-machine virtuelle (EVM et Wasm) grâce à la coopération entre la chaîne principale 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 du 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 ainsi à chaque étape de se dérouler de manière indépendante et en 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, renforçant ainsi l'évolutivité et la performance du système.
Consensus modulaire et mécanisme de restaking (Modular Consensus & Restaking) : Pharos introduit un mécanisme de consensus flexible, soutenant divers modèles de consensus (comme PBFT, PoS, PoA), et réalise le partage sécurisé et l'intégration des ressources entre le réseau principal et les SPNs grâce au protocole de restaking.
De plus, Pharos a reconstruit le modèle d'exécution depuis le niveau du moteur de stockage grâce à des technologies telles que les arbres Merkle à multiples versions, l'encodage différentiel (Delta Encoding), l'adressage versionné (Versioned Addressing) et l'ADS Pushdown, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, pour réaliser un haut débit.
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.
17 J'aime
Récompense
17
3
Partager
Commentaire
0/400
NotGonnaMakeIt
· 07-19 16:28
Encore ces concepts vides qui prennent les gens pour des idiots
Voir l'originalRépondre0
token_therapist
· 07-19 16:24
Yo, ce n'est pas encore le拼tps.
Voir l'originalRépondre0
PerpetualLonger
· 07-19 16:14
buy the dip augmenter la positioning il ne reste plus qu'une demi-bouteille de sauce soja à investir en plus. chute sous le coût, réapprovisionnement de la marge à 100%. Ne pas regarder la capitalisation boursière, mais la technique. Ce coup-ci, ce n'est pas des bearish Traders ni des investisseurs détaillant qui peuvent gérer ça.
Panorama de la piste de calcul parallèle Web3 : innovations architecturales de Monad, MegaETH et Pharos
Vue d'ensemble du secteur du calcul parallèle Web3 : la meilleure solution d'extensibilité native ?
I. Introduction : Évolution technologique du calcul parallèle dans la blockchain
Le "triangle impossible" de la blockchain (Blockchain Trilemma) – "sécurité", "décentralisation", "extensibilité" – révèle les compromis essentiels dans la conception des systèmes de 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'extensibilité", les principales solutions d'extension de blockchain sur le marché actuel sont classées selon des paradigmes, y compris :
Les solutions d'extension de la blockchain incluent : le calcul parallèle au sein de la chaîne, Rollup, le sharding, le module DA, une 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, formant un système complet d'extension "multi-niveau, combinaison modulaire". Cet article se concentre sur les méthodes d'extension principalement basées sur le calcul parallèle.
Calcul parallèle intra-chaîne (, 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 des objectifs de performance, des modèles de développement et des philosophies architecturales différents, avec une granularité parallèle 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 un système d'agents (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 fonctionne comme un "processus intelligent autonome", permettant l'échange de messages de manière asynchrone en parallèle, basé sur des événements, sans nécessité de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions Rollup ou de sharding que nous connaissons bien appartiennent à des mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle interne à la chaîne. Elles réalisent l'évolutivité en "exécutant plusieurs chaînes/domaines d'exécution en parallèle", plutôt qu'en augmentant le degré de parallélisme au sein d'un seul bloc/ machine virtuelle. Ce type de solution d'évolutivité n'est pas le point central de cet article, mais nous l'utiliserons néanmoins pour comparer les similitudes et les différences des concepts architecturaux.
![Web3 Calcul de la piste parallèle : La meilleure solution pour l'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
II. Chaîne améliorée parallèle EVM : Dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extensibilité 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 trouvé de percée fondamentale. Cependant, l'EVM et Solidity restent actuellement les plateformes de contrats intelligents les plus établies en termes de base de développeurs et de potentiel écologique. Par conséquent, les chaînes parallèles de la série EVM, qui équilibrent compatibilité écologique et amélioration des performances d'exécution, deviennent une voie clé dans la nouvelle évolution de l'extensibilité. 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 de haute concurrence et de haute capacité d'exécution, respectivement à partir de l'exécution différée et de la décomposition d'état.
) Analyse du mécanisme de calcul parallèle de Monad
Monad est une blockchain Layer1 haute performance repensé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 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 de base 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 en trois dimensions. Chaque phase fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent entre les blocs, et atteignant finalement l'objectif d'améliorer le débit et de réduire la latence. Ces phases comprennent : proposition de transaction (Propose), atteinte du consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de Consensus et d'Exécution
Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, et 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, les processus de traitement plus segmentés et l'utilisation des ressources plus efficace.
Conception de base :
Exécution parallèle optimiste : Exécution parallèle optimiste
L'Ethereum traditionnel adopte un modèle d'exécution strictement séquentiel pour éviter les conflits d'état. En revanche, Monad utilise une stratégie d'"exécution parallèle optimiste", ce qui permet d'augmenter 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 le parallélisme via le report de l'écriture des états et la détection dynamique des 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 EVM.
![Web3 calcul parallèle panorama : la meilleure solution d'extension 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é comme une couche d'exécution parallèle modulaire à haute performance compatible avec l'EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée (Execution Layer) ou de composant modulaire sur Ethereum. 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 planifiées indépendamment, 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 + State Dependency DAG (graphique 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 au sein de la chaîne".
Architecture Micro-VM : le compte est un fil d'exécution
MegaETH introduit un modèle d'exécution de "Micro-VM par compte", qui "thréadise" l'environnement d'exécution, fournissant ainsi la plus petite unité d'isolement pour le plan de programmation parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones, plutôt que par des appels synchrones, permettant à de nombreuses VM de s'exécuter indépendamment et de stocker de manière autonome, ce qui les rend naturellement parallèles.
État de dépendance DAG : Mécanisme de planification basé sur le graphe de dépendance
MegaETH a construit un système de planification DAG basé sur les 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 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 de l'é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
MegaETH est construit sur le paradigme de la programmation asynchrone, similaire à la transmission de messages asynchrones du modèle Actor, résolvant les problèmes d'appels séquentiels traditionnels de l'EVM. Les appels de contrat sont asynchrones (exécution non récursive), lorsque le contrat A appelle B, puis C, chaque appel est asynchronisé, sans avoir besoin d'attendre de manière bloquante ; la pile d'appels est développée en un graphique d'appels asynchrones (Call Graph) ; le traitement des transactions = parcours du graphique asynchrone + résolution des dépendances + planification parallèle.
En somme, MegaETH brise 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 programmant les 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, passant de "structure de compte → architecture de planification → flux 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 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 à l'exécution asynchrone. Théoriquement, la limite de parallélisme de MegaETH est plus élevée, mais il est aussi plus difficile de contrôler la complexité, ressemblant davantage à un système d'exploitation distribué super selon la philosophie d'Ethereum.
Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux du sharding : le sharding divise la blockchain en plusieurs sous-chaînes indépendantes (shards), chaque sous-chaîne étant responsable d'une partie des transactions et de l'état, ce qui brise les limitations d'une seule chaîne pour étendre la couche réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, s'étendant horizontalement uniquement au niveau 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 dans le chemin d'extension de la blockchain : le renforcement vertical et l'expansion horizontale.
![Web3 paysage complet de la piste de calcul parallèle : la meilleure solution d'extension native ?]###https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
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 de la chaîne. Ils réalisent un traitement parallèle au niveau des transactions ou des comptes grâce à l'exécution différée (Deferred Execution) et à l'architecture de micro-machine virtuelle (Micro-VM). En revanche, Pharos Network, en tant que réseau de blockchain L1 modulaire et full-stack, dispose d'un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture supporte un environnement multi-machine virtuelle (EVM et Wasm) grâce à la coopération entre la chaîne principale 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 :
De plus, Pharos a reconstruit le modèle d'exécution depuis le niveau du moteur de stockage grâce à des technologies telles que les arbres Merkle à multiples versions, l'encodage différentiel (Delta Encoding), l'adressage versionné (Versioned Addressing) et l'ADS Pushdown, lançant ainsi le moteur de stockage haute performance natif de la blockchain, Pharos Store, pour réaliser un haut débit.