Carte panoramique des pistes de calcul parallèle Web3 : la meilleure solution d'extension native ?
Le "triangle impossible" de la blockchain ( Blockchain Trilemma ) "sécurité", "décentralisation", "scalabilité" révèle les compromis essentiels dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle, 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 de l'extension améliorée : amélioration de la capacité d'exécution sur place, par exemple via le parallélisme, le GPU, et le multicœur.
Isolation de l'état pour l'extension : partitionnement horizontal de l'état / Shard, par exemple le sharding, UTXO, multi-sous-réseaux.
Extensibilité de type externalisé hors chaîne : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
Scalabilité déliée par la structure : modularité architecturale, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
Scalabilité asynchrone et concurrente : Modèle Actor, isolation des processus, pilotage par messages, par exemple agents, chaînes asynchrones multithread
Les solutions d'extensibilité de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, les modules DA, la structure modulaire, le système Actor, la compression de preuves zk, l'architecture Stateless, etc. Cela couvre plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extensibilité en "coopération multi-niveaux et combinaison de modules". Cet article se concentre sur les méthodes d'extensibilité principalement basées 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 des blocs. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, avec une granularité parallèle de plus en plus fine, une intensité parallèle 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 grandes.
Niveau de compte parallèle ) Niveau de compte ( : Représente le projet Solana
Niveau d'objet en parallèle ) Niveau d'objet ( : représente le projet Sui
Niveau de transaction parallèle )Transaction-level( : Représente le projet Monad, Aptos
Niveau d'appel / MicroVM parallèle ) Niveau d'appel / 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(, 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 d'agent intelligent" indépendant, utilisant une méthode de messages asynchrones en parallèle, basée sur des événements, sans planification de synchronisation, avec des projets représentatifs tels que AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, telles que les Rollups ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne font pas partie du calcul parallèle au sein de la chaîne. Elles réalisent l'extension en "exécutant en parallèle plusieurs chaînes/domaines d'exécution", plutôt qu'en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/VM. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les différences de concepts d'architecture.
! [Web3 Parallel Computing Track Panorama : la meilleure solution pour la mise à l’échelle native ?] ])https ://img-cdn.gateio.im/social/moments-2340d8a61251ba55c370d74178eec53e(
II. Chaîne améliorée par parallélisme EVM : dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum s'est développée jusqu'à présent, ayant subi plusieurs tentatives d'extension telles que le sharding, le Rollup et les architectures modulaires, mais le goulot d'étranglement en termes de débit au niveau d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, en même temps, l'EVM et le Solidity demeurent les plateformes de contrats intelligents les plus soutenues par les développeurs et avec le plus 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é pour la nouvelle évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans ce domaine, construisant une architecture de traitement parallèle EVM adaptée à des scénarios à haute concurrence et à haut débit, 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 redessinée pour la machine virtuelle Ethereum ###EVM(, basée sur le traitement par pipeline )Pipelining(, qui applique ce principe de parallélisme fondamental, 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 phases
Le pipelining est le concept fondamental de l'exécution parallèle des Monades. L'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 en trois dimensions. Chaque étape fonctionne sur des threads ou cœurs indépendants, permettant un traitement concurrent à travers les blocs, atteignant finalement l'objectif d'augmenter le débit et de réduire la latence. Ces étapes incluent : proposition de transaction ) Proposer ( atteinte de consensus ) Consensus ( exécution de transaction ) Exécution ( et soumission de bloc ) Soumettre (.
Exécution Asynchrone : Découplage Asynchrone de la Consensus et de l'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 considérablement 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 de traitement plus segmenté et l'utilisation des ressources plus efficace.
Conception de base :
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 ) est déclenché de manière asynchrone après l'achèvement du consensus au niveau d'exécution (.
Une fois le consensus atteint, passez immédiatement au processus de consensus du prochain bloc, sans attendre l'achèvement de l'exécution.
Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", augmentant considérablement le taux de traitement des transactions.
Mécanisme d'exécution :
Monad exécutera de manière optimiste toutes les transactions en parallèle, en supposant qu'il n'y a pas de conflits d'état entre la plupart des transactions.
Exécutez simultanément un "Détecteur de 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 un parallélisme grâce au report de l'écriture d'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, en faisant un accélérateur parallèle dans le monde de l'EVM.
![Web3 Calcul de parallèle panorama : Quelle est 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 EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'amélioration d'exécution 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 planifiées de manière indépendante, afin de réaliser une exécution à haute concurrence et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + DAG de dépendance d'état )graphe acyclique orienté de dépendance d'état( et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers "la threadisation au sein de la chaîne".
Micro-VM) machine virtuelle micro( architecture : le compte est un fil
MegaETH introduit un modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "threadise" l'environnement d'exécution, fournissant une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones )Asynchronous Messaging(, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter de manière indépendante et de stocker indépendamment, ce qui est naturellement parallèle.
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 des comptes, qui maintient en temps réel un graphique de dépendance global )Dependency Graph(. Chaque transaction modifie certains comptes et lit d'autres comptes, tous modélisés en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle directement, tandis que les transactions ayant des relations de dépendance seront programmé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'é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 brise le modèle traditionnel de machine d'état mono-thread EVM, réalisant un encapsulage de micro-machine virtuelle à l'échelle de comptes, en planifiant les transactions via un graphe de dépendance d'état, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, passant de "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle approche de niveau paradigmatique pour construire les systèmes en chaîne de nouvelle génération à haute performance.
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 à 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.
![Web3 parallélisation de l'écosystème : la meilleure solution d'expansion 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 )Sharding( : le sharding divise la blockchain horizontalement en plusieurs chaînes secondaires indépendantes )Shards(, chaque chaîne secondaire étant responsable d'une partie des transactions et des états, brisant les limites d'une chaîne unique pour l'extension au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, 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 dépasser les performances. Les deux représentent les directions de renforcement vertical et d'extension horizontale dans le chemin d'extension 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 sur la chaîne. Cela se fait à travers l'exécution différée )Deferred Execution( et l'architecture de micro-machine virtuelle )Micro-VM( pour réaliser le traitement parallèle au niveau des transactions ou des comptes. 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 "Rollup Mesh". Cette architecture soutient un 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égrant des technologies avancées telles que les preuves à connaissance nulle )ZK( et les environnements d'exécution de confiance )TEE(.
Analyse du mécanisme de calcul parallèle Rollup Mesh :
Traitement asynchrone de pipeline sur tout le cycle de vie )Full Lifecycle Asynchronous Pipelining( : Pharos découple les différentes étapes des transactions ) telles que le consensus, l'exécution et le stockage (, et utilise une méthode de 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 deux machines virtuelles )Dual VM Parallel Execution( : Pharos prend en charge deux environnements de machines virtuelles, 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.
Traitement spécial du réseau )SPNs( : Les SPNs sont des composants clés de l'architecture Pharos, similaires à des sous-réseaux modulaires, spécialement conçus pour traiter des types de tâches ou d'applications spécifiques. Grâce aux SPNs, Pharos peut réaliser une allocation dynamique des ressources et un traitement parallèle des tâches, renforçant ainsi l'évolutivité et la performance du système.
Consensus modulaire et mécanisme de restaking)Modular Consensus & Restaking( : Pharos introduit un mécanisme de consensus flexible, soutenant plusieurs modèles de consensus) tels que PBFT, PoS, PoA(, et réalise le partage sécurisé et l'intégration des ressources entre la chaîne principale et les SPNs grâce au protocole de restaking)Restaking(.
De plus, Pharos a reconstruit le modèle d'exécution à partir du niveau de base du moteur de stockage grâce à des technologies telles que les arbres Merkle multi-version, l'encodage delta )Delta Encoding(, l'adressage versionné )Versioned Addressing( et l'enfoncement ADS )ADS Pushdown(, lançant le moteur de stockage haute performance Pharos Store de blockchain natif, réalisant un haut débit, une faible latence et une forte vérifiabilité.
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.
13 J'aime
Récompense
13
5
Partager
Commentaire
0/400
ZkSnarker
· 07-23 20:13
en fait, techniquement, le trilemme ressemble plus à une suggestion pour être honnête...
Voir l'originalRépondre0
OnchainDetective
· 07-23 15:07
Maigre et triste, même l'expansion ne peut pas résoudre le problème. Qui a dit que plusieurs naissances ne sont pas une maladie ?
Voir l'originalRépondre0
IfIWereOnChain
· 07-21 13:51
Certaines personnes disent que les zk sont inutiles et qu'il faut finalement revenir au TPS.
Voir l'originalRépondre0
TokenVelocity
· 07-21 13:50
bull génial Tout le monde parle de monade, nous n'avons qu'à attendre et voir.
Voir l'originalRépondre0
BearMarketNoodler
· 07-21 13:40
Il vaudrait mieux créer un layer0, c'est plus fiable.
Panorama de la piste de calcul parallèle Web3 : le chemin d'extension EVM de Monad et MegaETH
Carte panoramique des pistes de calcul parallèle Web3 : la meilleure solution d'extension native ?
Le "triangle impossible" de la blockchain ( Blockchain Trilemma ) "sécurité", "décentralisation", "scalabilité" révèle les compromis essentiels dans la conception des systèmes blockchain, c'est-à-dire qu'il est difficile pour un projet blockchain d'atteindre simultanément "une sécurité extrême, une participation universelle, 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'extensibilité de la blockchain comprennent : le calcul parallèle en chaîne, Rollup, le sharding, les modules DA, la structure modulaire, le système Actor, la compression de preuves zk, l'architecture Stateless, etc. Cela couvre plusieurs niveaux d'exécution, d'état, de données et de structure, constituant un système complet d'extensibilité en "coopération multi-niveaux et combinaison de modules". Cet article se concentre sur les méthodes d'extensibilité principalement basées 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 des blocs. Selon le mécanisme de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant des objectifs de performance, des modèles de développement et des philosophies d'architecture différents, avec une granularité parallèle de plus en plus fine, une intensité parallèle 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 grandes.
Modèle de concurrence asynchrone hors chaîne, représenté par le 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 fonctionnant comme un "processus d'agent intelligent" indépendant, utilisant une méthode de messages asynchrones en parallèle, basée sur des événements, sans planification de synchronisation, avec des projets représentatifs tels que AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, telles que les Rollups ou le sharding, relèvent des mécanismes de concurrence au niveau système et ne font pas partie du calcul parallèle au sein de la chaîne. Elles réalisent l'extension en "exécutant en parallèle plusieurs chaînes/domaines d'exécution", plutôt qu'en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/VM. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons néanmoins pour comparer les différences de concepts d'architecture.
! [Web3 Parallel Computing Track Panorama : la meilleure solution pour la mise à l’échelle native ?] ])https ://img-cdn.gateio.im/social/moments-2340d8a61251ba55c370d74178eec53e(
II. Chaîne améliorée par parallélisme EVM : dépasser les limites de performance dans la compatibilité
L'architecture de traitement en série d'Ethereum s'est développée jusqu'à présent, ayant subi plusieurs tentatives d'extension telles que le sharding, le Rollup et les architectures modulaires, mais le goulot d'étranglement en termes de débit au niveau d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, en même temps, l'EVM et le Solidity demeurent les plateformes de contrats intelligents les plus soutenues par les développeurs et avec le plus 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é pour la nouvelle évolution de l'extension. Monad et MegaETH sont les projets les plus représentatifs dans ce domaine, construisant une architecture de traitement parallèle EVM adaptée à des scénarios à haute concurrence et à haut débit, 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 redessinée pour la machine virtuelle Ethereum ###EVM(, basée sur le traitement par pipeline )Pipelining(, qui applique ce principe de parallélisme fondamental, 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 phases
Le pipelining est le concept fondamental de l'exécution parallèle des Monades. L'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 en trois dimensions. Chaque étape fonctionne sur des threads ou cœurs indépendants, permettant un traitement concurrent à travers les blocs, atteignant finalement l'objectif d'augmenter le débit et de réduire la latence. Ces étapes incluent : proposition de transaction ) Proposer ( atteinte de consensus ) Consensus ( exécution de transaction ) Exécution ( et soumission de bloc ) Soumettre (.
Exécution Asynchrone : Découplage Asynchrone de la Consensus et de l'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 considérablement 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 de traitement plus segmenté et l'utilisation des ressources plus efficace.
Conception de base :
Exécution parallèle optimiste : Exécution parallèle optimiste
Ethereum traditionnel utilise un modèle d'exécution strictement séquentiel pour éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", augmentant considérablement le taux de traitement des transactions.
Mécanisme d'exécution :
Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme grâce au report de l'écriture d'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM, en faisant un accélérateur parallèle dans le monde de l'EVM.
![Web3 Calcul de parallèle panorama : Quelle est 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 EVM, pouvant servir à la fois de blockchain publique L1 indépendante et de couche d'amélioration d'exécution 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 planifiées de manière indépendante, afin de réaliser une exécution à haute concurrence et une capacité de réponse à faible latence. L'innovation clé proposée par MegaETH réside dans : l'architecture Micro-VM + DAG de dépendance d'état )graphe acyclique orienté de dépendance d'état( et le mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers "la threadisation au sein de la chaîne".
Micro-VM) machine virtuelle micro( architecture : le compte est un fil
MegaETH introduit un modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "threadise" l'environnement d'exécution, fournissant une unité d'isolation minimale pour la planification parallèle. Ces VM communiquent entre elles par le biais de messages asynchrones )Asynchronous Messaging(, plutôt que par des appels synchrones, permettant à un grand nombre de VM d'exécuter de manière indépendante et de stocker indépendamment, ce qui est naturellement parallèle.
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 des comptes, qui maintient en temps réel un graphique de dépendance global )Dependency Graph(. Chaque transaction modifie certains comptes et lit d'autres comptes, tous modélisés en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées en parallèle directement, tandis que les transactions ayant des relations de dépendance seront programmé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'é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 brise le modèle traditionnel de machine d'état mono-thread EVM, réalisant un encapsulage de micro-machine virtuelle à l'échelle de comptes, en planifiant les transactions via un graphe de dépendance d'état, et en remplaçant la pile d'appels synchrones par un mécanisme de messages asynchrones. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, passant de "structure de compte → architecture de planification → processus d'exécution", offrant une nouvelle approche de niveau paradigmatique pour construire les systèmes en chaîne de nouvelle génération à haute performance.
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 à 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.
![Web3 parallélisation de l'écosystème : la meilleure solution d'expansion 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 )Sharding( : le sharding divise la blockchain horizontalement en plusieurs chaînes secondaires indépendantes )Shards(, chaque chaîne secondaire étant responsable d'une partie des transactions et des états, brisant les limites d'une chaîne unique pour l'extension au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité de la chaîne unique, 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 dépasser les performances. Les deux représentent les directions de renforcement vertical et d'extension horizontale dans le chemin d'extension 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 sur la chaîne. Cela se fait à travers l'exécution différée )Deferred Execution( et l'architecture de micro-machine virtuelle )Micro-VM( pour réaliser le traitement parallèle au niveau des transactions ou des comptes. 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 "Rollup Mesh". Cette architecture soutient un 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égrant 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 à partir du niveau de base du moteur de stockage grâce à des technologies telles que les arbres Merkle multi-version, l'encodage delta )Delta Encoding(, l'adressage versionné )Versioned Addressing( et l'enfoncement ADS )ADS Pushdown(, lançant le moteur de stockage haute performance Pharos Store de blockchain natif, réalisant un haut débit, une faible latence et une forte vérifiabilité.