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

Le « triangle impossible » de la blockchain, à savoir la « sécurité », la « décentralisation » et la « scalabilité », 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 principales solutions d'extension de la blockchain sur le marché sont classées par paradigme, y compris :

• Exécution d'une extension améliorée : augmentation des capacités d'exécution sur place, par exemple parallélisation, GPU, multicœur.
• Isolation de l'état pour l'évolutivité : partitionnement horizontal de l'état / Shard, par exemple, le sharding, UTXO, sous-réseaux multiples
• Scalabilité hors chaîne par sous-traitance : déplacez l'exécution hors chaîne, par exemple Rollup, Coprocessor, DA
• Extension par découplage de l'architecture : architecture modulaire, fonctionnement en collaboration, par exemple chaînes modulaires, ordonnanceur partagé, Rollup Mesh
• Scalabilité asynchrone et concurrente : Modèle Actor, isolation des processus, piloté par messages, par exemple agents, chaînes asynchrones multithread

Les solutions d'extension de la blockchain comprennent : le calcul parallèle sur 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. Elles couvrent plusieurs niveaux d'exécution, d'état, de données et de structure, formant un système d'extension complet basé sur une "collaboration multi-niveaux et une combinaison modulaire". Cet article se concentre sur les méthodes d'extension, avec le calcul parallèle comme méthode principale.

Calcul parallèle intra-chaîne (intra-chain parallelism), se concentre sur l'exécution parallèle des transactions / instructions à l'intérieur des blocs. En fonction du mécanisme de parallélisme, ses méthodes d'extension peuvent être classées en cinq grandes catégories, chacune représentant différentes ambitions de performance, modèles de développement et philosophies architecturales, avec un degré de parallélisme de plus en plus fin, une intensité de parallélisme de plus en plus élevée, ainsi qu'une complexité de planification et une complexité de programmation et de mise en œuvre de plus en plus élevées.

• Niveau de compte parallèle ( Niveau de compte ) : représente le projet Solana
• Niveau d'objet parallèle(Niveau d'objet) : Représente le projet Sui
• Niveau de transaction parallèle (Transaction-level) : Représente les projets Monad, Aptos
• Niveau d'appel / Micro VM 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 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 de synchronisation non blockchain), chaque Agent fonctionne comme un « processus intelligent autonome », utilisant des messages asynchrones en parallèle, pilotés par des événements, sans nécessiter de planification synchronisée. Les projets représentatifs incluent AO, ICP, Cartesi, etc.

Les solutions d'extension que nous connaissons bien, comme les Rollups ou le sharding, appartiennent à des mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle à l'intérieur 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 / machine virtuelle. Ces solutions d'extension ne sont pas le sujet principal de cet article, mais nous les utiliserons tout de même pour comparer les similitudes et les différences dans les concepts d'architecture.

II. Chaîne d'amélioration parallèle EVM : Briser les frontières de performance dans la compatibilité

L'architecture de traitement en série d'Ethereum a évolué jusqu'à présent, ayant traversé plusieurs tentatives d'extension telles que le sharding, Rollup et l'architecture modulaire, mais le goulot d'étranglement en matière de débit au niveau d'exécution n'a toujours pas été fondamentalement surmonté. Cependant, en même temps, EVM et Solidity restent actuellement les plates-formes de contrats intelligents avec la base de développeurs et le potentiel écologique les plus importants. Par conséquent, la chaîne d'amélioration parallèle EVM devient une voie clé qui équilibre la compatibilité écologique et l'amélioration des performances d'exécution, et elle est en train de devenir une direction importante pour la prochaine évolution d'extension. 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 à haute concurrence et à haut débit, respectivement à 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 de Layer 1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de traitement en pipeline (Pipelining) pour le traitement parallèle. Elle exécute de manière asynchrone au niveau de consensus (Asynchronous Execution) et utilise l'exécution parallèle optimiste (Optimistic Parallel Execution) au niveau d'exécution. De plus, au niveau de consensus et de 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. Son 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 tridimensionnelle. Chaque étape fonctionne sur des threads ou des cœurs indépendants, permettant un traitement concurrent inter-blocs, et atteignant finalement une augmentation du débit et une réduction de la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte de consensus (Consensus), exécution de transaction (Execution) et soumission de bloc (Commit).

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

Dans les chaînes traditionnelles, le consensus et l'exécution des transactions sont généralement des processus synchrones, ce qui limite gravement l'évolutivité des performances. Monad a réalisé 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, avec des processus plus segmentés et une meilleure utilisation des ressources.

Conception de base :

• Le processus de consensus ( la couche de consensus ) ne se charge que du tri des transactions, sans exécuter la logique des contrats.
• Le processus d'exécution ( déclenche de manière asynchrone après l'achèvement du consensus sur la couche d'exécution ).
• Une fois le consensus atteint, entrez immédiatement dans le processus de consensus du bloc suivant, sans attendre 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 », 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 conflit d'état entre la plupart des transactions.
• Exécutez 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 la cohérence de l'état.

Monad a choisi un chemin compatible : en modifiant le moins possible les règles de l'EVM, en réalisant un parallélisme par le biais d'un retard d'écriture d'état et de la détection dynamique des conflits, semblable à une version performante d'Ethereum, avec une bonne maturité qui facilite la migration de l'écosystème EVM, c'est un accélérateur de parallélisme dans le monde de l'EVM.

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 et modulaire compatible avec EVM, pouvant servir à la fois de chaîne publique L1 autonome 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 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(graph de dépendance d'état acyclique orienté) et le mécanisme de synchronisation modulaire, construisant ensemble un système d'exécution parallèle orienté vers le "threading interne de la chaîne".

Micro-VM( machine virtuelle micro) architecture : compte est un fil

MegaETH introduit le modèle d'exécution « une micro-machine virtuelle par compte (Micro-VM) », qui « threadise » l'environnement d'exécution, fournissant la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent entre elles via des 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 indépendamment, naturellement parallèles.

DAG de dépendance d'état : Mécanisme de planification basé sur le 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 graphe de dépendance global (Dependency Graph), chaque transaction modifie quels comptes, lit quels comptes, tout est modélisé en tant que relation 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 planifiées en séquence ou différées selon un ordre topologique. Le graphe de dépendance garantit la cohérence de l'état et l'absence d'écritures répétées au cours du processus d'exécution parallèle.

Exécution asynchrone et mécanisme de rappel

B

En résumé, MegaETH rompt avec le modèle traditionnel de machine d'état mono-fil EVM, en réalisant un encapsulage de micro-machine virtuelle par compte, en programmant les transactions à l'aide d'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 → processus d'exécution », offrant de nouvelles idées de niveau paradigme pour construire des 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 à une 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.

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 ainsi la limitation d'une chaîne unique pour permettre une expansion 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 extrême au sein de la chaîne unique pour améliorer les performances. Les deux représentent deux directions différentes dans le chemin 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 chemin de débit, avec pour objectif central d'améliorer le TPS en chaîne, en réalisant le 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). Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack, a un mécanisme de calcul parallèle central appelé « Rollup Mesh ». Cette architecture fonctionne en collaboration avec le réseau principal et les réseaux de traitement spéciaux (SPNs), supportant des environnements multi-machines virtuelles (EVM et Wasm), et intégrant 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 l'ensemble du cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes étapes des transactions ( telles que le consensus, l'exécution, le stockage ) et utilise un mode de traitement asynchrone, permettant à chaque étape de se dérouler de manière indépendante et en parallèle, améliorant ainsi l'efficacité globale du traitement.
2. Exécution parallèle de deux machines virtuelles (Exécution parallèle de la VM Dual) : 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.
3. Traitement spécial des réseaux (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, ce qui améliore encore l'évolutivité et les performances du système.
4. Consensus modulaire et mécanisme de restaking(Modular Consensus & Restaking): Phar