Panorama du calcul parallèle Web3 : de l'exécution on-chain à l'évolution de l'évolutivité multi-chaînes

Vue d'ensemble du secteur de calcul parallèle Web3 : la meilleure solution d'extension native ?

Le "triangle impossible" de la blockchain (Blockchain Trilemma) révèle les compromis fondamentaux dans la conception des systèmes blockchain avec la "sécurité", la "décentralisation" et la "scalabilité". Il est difficile pour les projets blockchain de réaliser simultanément "une sécurité extrême, une participation universelle et un traitement rapide". Concernant le sujet éternel de la "scalabilité", les principales solutions d'extension de la blockchain sur le marché sont classées selon des paradigmes, y compris :

  • Exécution d'une extension améliorée : augmenter la capacité d'exécution sur place, par exemple le parallèle, le GPU, le multicœur
  • Isolation des états pour l'extension : partitionnement horizontal de l'état/Sharding, par exemple, sharding, UTXO, multi-sous-réseaux
  • Extension de type externalisation hors chaîne : effectuer l'exécution hors chaîne, par exemple Rollup, Coprocessor, DA
  • Extension décentralisée par découplage de la structure : modules d'architecture, fonctionnement collaboratif, par exemple chaînes de modules, ordonnanceur partagé, Rollup Mesh
  • Extension de type concurrent asynchrone : Modèle Actor, isolation des processus, basé sur les 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, la 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, constituant un système complet d'extension "multicouches et modulaires". Cet article se concentre principalement sur les méthodes d'extension basées sur le calcul parallèle.

Calcul parallèle intra-chaîne (, mettant l'accent 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 recherches de performances, modèles de développement et philosophies d'architecture, avec un degré de parallélisme de plus en plus fin, une intensité de parallélisme de plus en plus élevée, une complexité de planification 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.

  • Niveau de compte parallèle ) Niveau de compte ( : représentant le projet Solana
  • Parallélisme au niveau des objets ) Object-level ( : représente le projet Sui
  • Niveau de transaction parallèle)Transaction-level(: Représente le projet Monad, Aptos
  • Appel de niveau / Micro VM parallèle )Appel de niveau / MicroVM( : représente le projet MegaETH
  • Parallélisme au niveau des instructions )Instruction-level(: Représente le projet GatlingX

Modèle de concurrence asynchrone hors chaîne, représenté par le système d'agents intelligents )Agent / Actor Model(, qui appartient à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes/asynchrone )modèle non synchronisé de blockchain(, chaque Agent fonctionnant comme un "processus agent intelligent" autonome, mode parallèle de messages asynchrones, événementiel, sans planification synchrone, des projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, telles que le Rollup ou le sharding, appartiennent aux mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle au sein de la chaîne. Elles réalisent l'extension en "exécutant plusieurs chaînes/domaines d'exécution en parallèle", plutôt qu'en augmentant le degré de parallélisme à l'intérieur d'un seul bloc/VM. Ces solutions d'extension ne sont pas le point central de cette discussion, mais nous les utiliserons néanmoins pour comparer les différences de concepts d'architecture.

![Web3 parcours de calcul parallèle panorama : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

Deuxième, chaîne améliorée par parallélisme EVM : dépasser les limites de performance dans la compatibilité

L'architecture de traitement séquentiel d'Ethereum a évolué jusqu'à présent, passant par plusieurs tentatives d'extension telles que le sharding, le Rollup et l'architecture modulaire, mais le goulot d'étranglement de la capacité d'exécution n'a toujours pas été fondamentalement résolu. Cependant, EVM et Solidity restent les plateformes de contrats intelligents les plus dynamiques en termes de base de développeurs et de potentiel écologique. Par conséquent, la chaîne parallèle EVM, qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, devient une voie clé dans 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 axée sur des scénarios à haute concurrence et à haut débit à partir de l'exécution retardé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 en pipeline )Pipelining(, ce concept fondamental de parallélisme, exécutant de manière asynchrone au niveau du consensus )Asynchronous Execution( et une exécution parallèle optimiste au niveau d'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 concept fondamental de l'exécution parallèle des Monads, dont 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 une architecture de pipeline tridimensionnelle. Chaque étape 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 étapes incluent : proposition de transaction )Propose(, consensus atteint )Consensus(, exécution de transaction )Execution( et soumission de bloc )Commit(.

Exécution Asynchrone: Consensus - Exécution Découplée Asynchrone

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, les processus de traitement plus segmentés 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.
  • Processus d'exécution ) couche d'exécution ( déclenché de manière asynchrone après la complétion du consensus.
  • Une fois le consensus atteint, passez immédiatement au processus de consensus du prochain bloc, sans attendre l'achèvement de l'exécution.

Exécution parallèle optimiste : Exécution parallèle optimiste

L'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" 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 (.
  • S'il y a un conflit détecté, les transactions conflictuelles seront sérialisées et réexécutées pour garantir l'intégrité de l'état.

Monad a choisi un chemin compatible : le moins de modifications possible des règles EVM, en réalisant le parallélisme par le biais du report de l'écriture d'état et de la détection dynamique des conflits, ressemblant 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 et la carte panoramique de la piste de calcul parallèle : la meilleure solution pour une expansion 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 de haute performance modulaire compatible EVM, pouvant servir à la fois de chaîne publique L1 indépendante et de couche d'amélioration de l'exécution sur Ethereum###Execution Layer( ou de composant modulaire. L'objectif de conception central est de décomposer la logique de compte, l'environnement d'exécution et l'état en unités minimales pouvant être programmées de manière indépendante, afin 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 + DAG de dépendance d'état)graphe acyclique dirigé 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 "l'exécution en fil de chaîne".

Micro-VM) micro-machine virtuelle ( architecture : un compte est un fil d'exécution

MegaETH a introduit un modèle d'exécution "une micro-machine virtuelle par compte )Micro-VM(", qui "thréadise" l'environnement d'exécution, fournissant la plus petite unité d'isolation 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 indépendamment et de stocker de manière autonome, naturellement en 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, le système maintient en temps réel un graphique de dépendance global )Dependency Graph(, chaque transaction modifiant quels comptes, lisant quels comptes, tout modélisé en tant que relations de dépendance. Les transactions sans conflit peuvent être exécutées directement en parallèle, les transactions ayant des relations de dépendance seront programmées ou retardées en fonction d'un 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

B

En résumé, MegaETH brise le modèle traditionnel de machine d'état monocorde EVM en encapsulant des micro-machines virtuelles au niveau des comptes, en utilisant des graphes de dépendance d'état pour la planification des transactions, 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, allant de "la structure des comptes → l'architecture de planification → le processus d'exécution", offrant de nouvelles idées de niveau paradigmatique pour construire des systèmes de chaîne de nouvelle génération à haute performance.

MegaETH a choisi un chemin de reconstruction : abstraire complètement les comptes et les contrats en une VM indépendante, libérant ainsi 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 l'idée d'Ethereum.

![Web3 calcul parallèle panorama : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

Les concepts de conception de Monad et MegaETH diffèrent considérablement de ceux du sharding ) Sharding ( : le sharding divise 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 les limites d'une seule chaîne pour étendre le réseau. En revanche, Monad et MegaETH conservent l'intégrité de la chaîne unique, en s'étendant horizontalement uniquement au niveau d'exécution, optimisant l'exécution parallèle à l'intérieur de la chaîne unique pour surmonter les performances. Les deux représentent les directions de renforcement vertical et d'expansion horizontale dans le chemin de l'expansion de la blockchain.

![Web3 calcul parallèle paysage complet : la meilleure solution d'extension native ?])https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(

Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l'optimisation du débit, avec pour objectif principal d'améliorer le TPS sur la chaîne, 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-VM )Micro-VM(. Le Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, a pour mécanisme central de calcul parallèle ce que l'on appelle "Rollup Mesh". Cette architecture soutient un environnement multi-VM )EVM et Wasm( grâce au travail collaboratif entre le réseau principal et un réseau de traitement spécial )SPNs(, 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 :

  1. Traitement asynchrone de pipeline sur tout le cycle de vie )Full Lifecycle Asynchronous Pipelining( : Pharos découple les différentes étapes de la transaction ) 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é du traitement global.
  2. Exécution parallèle de deux machines virtuelles ) Exécution parallèle de VM duale ( : Pharos prend en charge les 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.
  3. 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 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, ce qui améliore encore l'évolutivité et les performances du système.
  4. Consensus modulaire et mécanisme de restaking )Modular Consensus & Restaking( : Pharos introduit un consensus flexible.
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.
  • Récompense
  • 7
  • Partager
Commentaire
0/400
DarkPoolWatchervip
· 07-27 23:31
Encore une série de solutions d'extension, ça s'anime.
Voir l'originalRépondre0
TokenBeginner'sGuidevip
· 07-27 10:48
Petit rappel : ce qu'on appelle l'extension, le changement d'architecture sous-jacente entraîne 90 % de risques, il est conseillé de réfléchir à deux fois.
Voir l'originalRépondre0
OnchainDetectivevip
· 07-25 08:02
Ce plan est presque terminé.
Voir l'originalRépondre0
AirdropHarvestervip
· 07-25 08:02
Attendez, comment avez-vous étendu la capacité ?
Voir l'originalRépondre0
ContractSurrendervip
· 07-25 08:01
La technologie ne peut effectivement pas résoudre l'expérience.
Voir l'originalRépondre0
ResearchChadButBrokevip
· 07-25 07:55
Il faut encore rouler le rollup.
Voir l'originalRépondre0
BuyHighSellLowvip
· 07-25 07:50
J'ai regardé une grande quantité et ça a fini par être enroulé.
Voir l'originalRépondre0
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)