Panorama du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?
Le "trilemme" de la blockchain (Blockchain Trilemma) 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". En ce qui concerne le sujet éternel de la "scalabilité", les solutions de scalabilité blockchain actuellement disponibles sur le marché sont classées selon des paradigmes, y compris :
Exécution d'une extension améliorée : augmentation des capacités d'exécution sur place, par exemple parallélisme, GPU, multicœurs.
Isolation de l'état par extension : partitionnement horizontal de l'état / Shard, par exemple sharding, UTXO, sous-réseaux multiples.
Scalabilité hors chaîne par externalisation : exécuter en dehors de la chaîne, par exemple Rollup, Coprocessor, DA
Scalabilité par découplage de la structure : modularité de l'architecture, fonctionnement en synergie, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
Extension asynchrone et concurrente : Modèle Actor, isolation des processus, pilotage par message, par exemple agents, chaînes asynchrones multithread
Les solutions d'extension de la blockchain comprennent : le calcul parallèle intra-chaîne, Rollup, le sharding, les modules DA, une structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc., couvrant plusieurs niveaux tels que l'exécution, l'état, les données et la structure. Il s'agit d'un système complet d'extension "multi-niveaux, combinaison modulaire". Cet article se concentre sur le mode d'extension dominant basé sur le calcul parallèle.
Parallélisme 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 divisées en cinq grandes catégories, chacune représentant différentes exigences de performance, modèles de développement et philosophies architecturales, avec des granularités de parallélisme de plus en plus fines, 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 : 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 : 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 non synchronisé par blocs), chaque Agent fonctionne comme un "processus d'agent intelligent" autonome, avec des messages asynchrones en mode parallèle, basé sur des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, telles que Rollup 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 plusieurs chaînes/domaines d'exécution en parallèle", et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/ machine virtuelle. Ces solutions d'extension ne sont pas le point central de cet article, mais nous les utiliserons néanmoins pour comparer les différences et similitudes des concepts d'architecture.
) Deuxième, chaîne d'amélioration parallèle EVM : franchir les limites de performance dans la compatibilité.
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant traversé plusieurs tentatives d'expansion, telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution reste non résolu de manière fondamentale. Cependant, malgré cela, l'EVM et Solidity demeurent les plateformes de contrats intelligents avec la plus grande base de développeurs et un 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 voie clé pour une nouvelle évolution de l'expansion. 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 haut débit, respectivement, en partant de l'exécution différée et de la décomposition des états.
Analyse du mécanisme de calcul parallèle de Monad
Monad est une blockchain Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining), avec une exécution asynchrone (Asynchronous Execution) au niveau du consensus et une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau de l'exécution. 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 spécialisé (MonadDB), réalisant une optimisation de bout en bout.
Pipelining : Mécanisme d'exécution parallèle en plusieurs étapes
Le Pipelining est le concept fondamental de l'exécution parallèle des Monads. 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 entre les blocs et atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases comprennent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de 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 le consensus asynchrone, l'exécution asynchrone et le stockage asynchrone grâce à une "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 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é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 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 conflits d'état entre la plupart des transactions.
Exécuter 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).
En cas de détection de conflit, les transactions en conflit seront réexécutées de manière séquentielle 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 à un retard d'écriture d'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité facilitant la migration de l'écosystème EVM, servant d'accélérateur de parallélisme dans le monde EVM.
![Web3 parcours de 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 EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée sur Ethereum 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 planifiées de manière indépendante, afin d'atteindre 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 (graphe acyclique dirigé de dépendance d'état) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le threading au sein de la chaîne".
Architecture Micro-VM (micro machine virtuelle) : le compte est un fil
MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "met en fil" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par messagerie asynchrone (Asynchronous Messaging), plutôt que par appels synchrones, permettant à de nombreuses VM d'exécuter de manière indépendante et de stocker de manière indépendante, 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 des comptes, qui maintient en temps réel un graphe de dépendance global. Chaque transaction modifie quels comptes, lit quels comptes, et tout cela 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 triées séquentiellement ou retardées selon l'ordre topologique. Le graphe de dépendance garantit la cohérence d'état et l'absence d'écritures répétées durant le 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 à états à thread unique EVM, en réalisant un encapsulage de micro-machine virtuelle par compte, en utilisant un graphique de dépendance d'état pour le plan de transaction, et en remplaçant la pile d'appels synchrones par un mécanisme de message asynchrone. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, de la "structure de compte → architecture de planification → flux d'exécution", offrant de nouvelles idées au niveau du paradigme pour construire le prochain système en ligne haute performance.
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. 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 super distribué sous l'idée d'Ethereum.
![Web3 parcours de calcul parallèle carte panoramique : 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 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 limites d'une chaîne unique pour permettre l'expansion au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité d'une seule chaîne, s'étendant horizontalement uniquement au niveau de la couche d'exécution, optimisant l'exécution parallèle extrême au sein de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans les chemins d'expansion de la blockchain : le renforcement vertical et l'expansion horizontale.
Les projets de calcul parallèle comme Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec l'objectif central d'améliorer le TPS on-chain, en réalisant 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 tant que réseau de blockchain L1 modulaire et full-stack, Pharos Network possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture, à travers la coopération entre le mainnet et les réseaux de traitement spéciaux (SPNs), prend en charge un environnement multi-machine virtuelle (EVM et Wasm) et intègre des technologies avancées telles que la preuve à connaissance nulle (ZK) et l'environnement 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écompose 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 indépendamment et en parallèle, ce qui améliore 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 le mainnet et les SPNs grâce au protocole de restaking.
De plus, Pharos a reconstruit le modèle d'exécution à partir du niveau inférieur du moteur de stockage grâce à des techniques telles que les Merkle trees multi-versionnels, le codage delta (Delta Encoding), le versionnement d'adresses (Versioned Addressing) et la poussée ADS (ADS Pushdown), lançant ainsi le moteur de stockage haute performance natif de blockchain, Pharos Store, qui réalise une capacité de traitement en chaîne à haut débit, faible latence et fortement vérifiable.
En général, Phar
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.
11 J'aime
Récompense
11
7
Partager
Commentaire
0/400
TrustlessMaximalist
· Il y a 23h
Encore en train de parler d'extension, qu'est-ce qu'il y a à discuter?
Voir l'originalRépondre0
SolidityStruggler
· Il y a 23h
On en revient encore à l'extension, L1 utilise tous le parallélisme pour sauver.
Voir l'originalRépondre0
SchrodingerProfit
· Il y a 23h
Blockchain, c'est vraiment si rapide ? Quatre solutions vous laissent perplexe...
Voir l'originalRépondre0
DisillusiionOracle
· Il y a 23h
Pas d'argent, pas d'échelle.
Voir l'originalRépondre0
TokenomicsTherapist
· Il y a 23h
On refait des théories ici.
Voir l'originalRépondre0
HalfIsEmpty
· Il y a 23h
Qui a résolu le triangle impossible, je mets directement tout dans.
Web3 Calcul Parallèle Panorama : Cinq Paradigmes d'Extension et Comparaison avec les Chaînes Haute Performance EVM
Panorama du secteur du calcul parallèle Web3 : la meilleure solution d'extension native ?
Le "trilemme" de la blockchain (Blockchain Trilemma) 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". En ce qui concerne le sujet éternel de la "scalabilité", les solutions de scalabilité blockchain actuellement disponibles sur le marché sont classées selon des paradigmes, y compris :
Les solutions d'extension de la blockchain comprennent : le calcul parallèle intra-chaîne, Rollup, le sharding, les modules DA, une structure modulaire, le système Actor, la compression des preuves zk, l'architecture Stateless, etc., couvrant plusieurs niveaux tels que l'exécution, l'état, les données et la structure. Il s'agit d'un système complet d'extension "multi-niveaux, combinaison modulaire". Cet article se concentre sur le mode d'extension dominant basé sur le calcul parallèle.
Parallélisme 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 divisées en cinq grandes catégories, chacune représentant différentes exigences de performance, modèles de développement et philosophies architecturales, avec des granularités de parallélisme de plus en plus fines, une intensité de parallélisme de plus en plus élevée, une complexité de planification de plus en plus élevée, ainsi qu'une complexité de programmation et une difficulté de mise en œuvre de plus en plus élevées.
Modèle de concurrence asynchrone hors chaîne, représenté par le système d'agents (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 non synchronisé par blocs), chaque Agent fonctionne comme un "processus d'agent intelligent" autonome, avec des messages asynchrones en mode parallèle, basé sur des événements, sans planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
Les solutions d'extension que nous connaissons bien, telles que Rollup 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 plusieurs chaînes/domaines d'exécution en parallèle", et non en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/ machine virtuelle. Ces solutions d'extension ne sont pas le point central de cet article, mais nous les utiliserons néanmoins pour comparer les différences et similitudes des concepts d'architecture.
![Web3 parallèle calcul secteur panorama : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
) Deuxième, chaîne d'amélioration parallèle EVM : franchir les limites de performance dans la compatibilité.
L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant traversé plusieurs tentatives d'expansion, telles que le sharding, les Rollups et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution reste non résolu de manière fondamentale. Cependant, malgré cela, l'EVM et Solidity demeurent les plateformes de contrats intelligents avec la plus grande base de développeurs et un 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 voie clé pour une nouvelle évolution de l'expansion. 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 haut débit, respectivement, en partant de l'exécution différée et de la décomposition des états.
Analyse du mécanisme de calcul parallèle de Monad
Monad est une blockchain Layer1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining), avec une exécution asynchrone (Asynchronous Execution) au niveau du consensus et une exécution parallèle optimiste (Optimistic Parallel Execution) au niveau de l'exécution. 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 spécialisé (MonadDB), réalisant une optimisation de bout en bout.
Pipelining : Mécanisme d'exécution parallèle en plusieurs étapes
Le Pipelining est le concept fondamental de l'exécution parallèle des Monads. 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 entre les blocs et atteignant finalement une augmentation du débit et une réduction de la latence. Ces phases comprennent : proposition de transaction (Propose), consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).
Exécution Asynchrone : Découplage Asynchrone de 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 le consensus asynchrone, l'exécution asynchrone et le stockage asynchrone grâce à une "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 centrale :
Exécution parallèle optimiste : Optimistic Parallel Execution
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 augmente 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 à un retard d'écriture d'état et à la détection dynamique des conflits, ressemblant davantage à une version performante d'Ethereum, avec une maturité facilitant la migration de l'écosystème EVM, servant d'accélérateur de parallélisme dans le monde EVM.
![Web3 parcours de 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 EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'exécution améliorée sur Ethereum 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 planifiées de manière indépendante, afin d'atteindre 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 (graphe acyclique dirigé de dépendance d'état) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers "le threading au sein de la chaîne".
Architecture Micro-VM (micro machine virtuelle) : le compte est un fil
MegaETH introduit un modèle d'exécution de "micro-machine virtuelle (Micro-VM) par compte", qui "met en fil" l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles par messagerie asynchrone (Asynchronous Messaging), plutôt que par appels synchrones, permettant à de nombreuses VM d'exécuter de manière indépendante et de stocker de manière indépendante, 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 des comptes, qui maintient en temps réel un graphe de dépendance global. Chaque transaction modifie quels comptes, lit quels comptes, et tout cela 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 triées séquentiellement ou retardées selon l'ordre topologique. Le graphe de dépendance garantit la cohérence d'état et l'absence d'écritures répétées durant le 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 à états à thread unique EVM, en réalisant un encapsulage de micro-machine virtuelle par compte, en utilisant un graphique de dépendance d'état pour le plan de transaction, et en remplaçant la pile d'appels synchrones par un mécanisme de message asynchrone. C'est une plateforme de calcul parallèle redessinée dans toutes ses dimensions, de la "structure de compte → architecture de planification → flux d'exécution", offrant de nouvelles idées au niveau du paradigme pour construire le prochain système en ligne haute performance.
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. 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 super distribué sous l'idée d'Ethereum.
![Web3 parcours de calcul parallèle carte panoramique : 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 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 limites d'une chaîne unique pour permettre l'expansion au niveau du réseau ; tandis que Monad et MegaETH conservent l'intégrité d'une seule chaîne, s'étendant horizontalement uniquement au niveau de la couche d'exécution, optimisant l'exécution parallèle extrême au sein de la chaîne unique pour améliorer les performances. Les deux représentent deux directions dans les chemins d'expansion de la blockchain : le renforcement vertical et l'expansion horizontale.
Les projets de calcul parallèle comme Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec l'objectif central d'améliorer le TPS on-chain, en réalisant 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 tant que réseau de blockchain L1 modulaire et full-stack, Pharos Network possède un mécanisme de calcul parallèle central appelé "Rollup Mesh". Cette architecture, à travers la coopération entre le mainnet et les réseaux de traitement spéciaux (SPNs), prend en charge un environnement multi-machine virtuelle (EVM et Wasm) et intègre des technologies avancées telles que la preuve à connaissance nulle (ZK) et l'environnement 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 inférieur du moteur de stockage grâce à des techniques telles que les Merkle trees multi-versionnels, le codage delta (Delta Encoding), le versionnement d'adresses (Versioned Addressing) et la poussée ADS (ADS Pushdown), lançant ainsi le moteur de stockage haute performance natif de blockchain, Pharos Store, qui réalise une capacité de traitement en chaîne à haut débit, faible latence et fortement vérifiable.
En général, Phar