Le "Trilemme de la blockchain" révèle les compromis essentiels dans la conception des systèmes blockchain, à savoir la difficulté d'atteindre simultanément "une sécurité ultime, une participation universelle et un traitement à haute vitesse". En ce qui concerne le sujet éternel de "l'évolutivité", les solutions de mise à l'échelle des blockchains dominantes actuellement sur le marché peuvent être catégorisées selon des paradigmes, y compris :

• Exécuter une évolutivité améliorée : Améliorer les capacités d'exécution sur le terrain, telles que le parallélisme, le GPU et le multi-cœurs.
• Expansion isolée d'état : partitionnement horizontal de l'état / Shard, tel que le sharding, UTXO, multi-sous-réseau
• Mise à l'échelle de l'externalisation hors chaîne : exécution en dehors de la chaîne, comme Rollup, Coprocessor, DA
• Expansion de structure découplée : architecture modulaire, opération collaborative, tels que des chaînes de modules, des trieurs partagés, Rollup Mesh.
• Mise à l'échelle concurrente asynchrone : modèle d'acteur, isolation des processus, basé sur les messages, tels que les agents, chaînes asynchrones multithreads.

Les solutions de mise à l'échelle de la blockchain comprennent : le calcul parallèle en chaîne, les Rollups, le sharding, les modules DA, les structures modulaires, les systèmes Actor, la compression par preuve zk, l'architecture sans état, etc., couvrant plusieurs couches d'exécution, d'état, de données et de structure, formant un système de mise à l'échelle complet de "collaboration multi-couches et combinaison modulaire". Cet article se concentre sur la méthode de mise à l'échelle grand public basée sur le calcul parallèle.

Le parallélisme intra-chaîne se concentre sur l'exécution parallèle des transactions/instructions à l'intérieur du bloc. Selon le mécanisme parallèle, ses méthodes d'évolutivité peuvent être divisées en cinq catégories, chacune représentant des quêtes de performance différentes, des modèles de développement et des philosophies architecturales. La granularité du parallélisme devient plus fine, l'intensité du parallélisme augmente, la complexité de la planification s'accroît, et la complexité de programmation et la difficulté de mise en œuvre augmentent également.

• Niveau de compte : Représente le projet Solana
• Parallélisme au niveau des objets : représente le projet Sui
• Niveau de transaction : Représente les projets Monad, Aptos
• Niveau d'appel / MicroVM : Représente le projet MegaETH
• Parallélisme au niveau des instructions : Représente le projet GatlingX

Le modèle concurrent asynchrone hors chaîne, représenté par le système Actor (Modèle Agent / Actor), appartient à un autre paradigme de calcul parallèle. En tant que système de messagerie cross-chain / asynchrone (modèle de non-synchronisation bloquante), chaque Agent fonctionne comme un « processus d'agent » s'exécutant de manière indépendante, envoyant des messages de manière asynchrone, orienté événements, et sans besoin de planification synchronisée. Parmi les projets notables, on trouve AO, ICP, Cartesi, etc.

Les solutions de scalabilité bien connues telles que les Rollups ou le sharding appartiennent aux mécanismes de concurrence au niveau système et ne relèvent pas du calcul parallèle sur chaîne. Elles réalisent la scalabilité en "exécutant plusieurs chaînes/domaines d'exécution en parallèle" plutôt qu'en améliorant le parallélisme au sein d'un seul bloc/machine virtuelle. De telles solutions de scalabilité ne sont pas l'objet principal de cet article, mais nous les utiliserons tout de même pour une analyse comparative des concepts architecturaux.

2. Chaîne Améliorée Parallèle Basée sur EVM : Briser les Limites de Performance grâce à la Compatibilité

L'architecture de traitement sériel d'Ethereum a évolué à travers plusieurs tentatives d'expansion, y compris le sharding, les Rollups et l'architecture modulaire. Cependant, le goulot d'étranglement du débit de la couche d'exécution n'a toujours pas été fondamentalement surmonté. Pendant ce temps, l'EVM et Solidity restent les plateformes de contrats intelligents les plus conviviales pour les développeurs et écologiquement puissantes aujourd'hui. Par conséquent, les chaînes améliorées en parallèle basées sur l'EVM deviennent une direction importante pour le prochain cycle d'évolution de la scalabilité, équilibrant la compatibilité écologique et l'amélioration des performances d'exécution. Monad et MegaETH sont les projets les plus représentatifs dans cette direction, construisant respectivement des architectures de traitement parallèle EVM visant des scénarios de haute concurrence et de haut débit, en partant 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 de couche 1 haute performance redessinée pour la machine virtuelle Ethereum (EVM), basée sur le concept fondamental de parallélisme par pipeline, avec une exécution asynchrone au niveau du consensus et une exécution parallèle optimiste au niveau d'exécution. De plus, Monad introduit un protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB) aux couches de consensus et de stockage, réalisant une optimisation de bout en bout.

Pipelining : Mécanisme d'exécution parallèle en pipeline multi-étapes
Le pipelining est le concept fondamental de l'exécution parallèle des Monades. Son idée principale 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 s'exécute sur des threads ou des cœurs indépendants, réalisant un traitement concurrent entre les blocs, améliorant finalement le débit et réduisant la latence. Ces étapes comprennent : proposition de transaction (Propose), atteinte de consensus (Consensus), exécution de transaction (Execution) et engagement de bloc (Commit).

Exécution Asynchrone : Consensus - Découplage Asynchrone
Dans les blockchains traditionnelles, le consensus des transactions et l'exécution sont généralement des processus synchrones, et ce modèle sériel limite sévèrement l'évolutivité des performances. Monad réalise une couche de consensus asynchrone, une couche d'exécution asynchrone et un stockage asynchrone grâce à "l'exécution asynchrone". Cela réduit considérablement le temps de bloc et les délais de confirmation, rendant le système plus résilient, les flux de traitement plus granulaires et l'utilisation des ressources plus élevée.

Conception de base :

• Le processus de consensus (couche de consensus) est uniquement responsable de l'ordonnancement des transactions et n'exécute pas la logique des contrats.
• Le processus d'exécution (couche d'exécution) est déclenché de manière asynchrone après que le consensus est terminé.
• Après que le consensus soit terminé, entrez immédiatement dans le processus de consensus pour le prochain bloc sans attendre la fin de l'exécution.

Exécution parallèle optimiste
L'Ethereum traditionnel utilise un modèle strict en série pour l'exécution des transactions afin d'éviter les conflits d'état. En revanche, Monad adopte une stratégie d'"exécution parallèle optimiste", améliorant considérablement la vitesse de traitement des transactions.

Mécanisme d'exécution :

• Monad exécutera de manière optimiste toutes les transactions en parallèle, en supposant que la plupart des transactions n'ont pas de conflits d'état.
• En même temps, exécutez un "Détecteur de Conflits" 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 justesse de l'état.

Monad choisit un chemin compatible : apportant le moins de changements possible aux règles de l'EVM, atteignant le parallélisme en différant les écritures d'état et en détectant dynamiquement les conflits pendant l'exécution, ressemblant à une version performante d'Ethereum. Sa maturité facilite la migration de l'écosystème EVM et sert d'accélérateur parallèle dans le monde de l'EVM.

Analyse du mécanisme de calcul parallèle de MegaETH

Contrairement au positionnement L1 de Monad, MegaETH est positionné comme une couche d'exécution parallèle modulaire haute performance compatible avec l'EVM, qui peut servir de chaîne publique L1 indépendante ou comme une couche d'amélioration d'exécution sur Ethereum ou comme un composant modulaire. Son objectif de conception principal est d'isoler et de décomposer la logique des comptes, l'environnement d'exécution et l'état en unités minimales programmables de manière indépendante afin d'atteindre une exécution concurrente élevée et des capacités de réponse à faible latence sur la chaîne. Les principales innovations proposées par MegaETH sont : architecture Micro-VM + DAG de dépendance d'état (Graphe acyclique dirigé des dépendances d'état) et mécanisme de synchronisation modulaire, qui construisent ensemble un système d'exécution parallèle orienté vers le "filtrage sur la chaîne".

Architecture Micro-VM : Le compte est un fil
MegaETH introduit le modèle d'exécution de « une micro-machine virtuelle (Micro-VM) par compte », qui permet de rendre l'environnement d'exécution en mode fil et fournit la plus petite unité d'isolation pour la planification parallèle. Ces VM communiquent par le biais de messages asynchrones au lieu d'appels synchrones, permettant à un grand nombre de VM d'exécuter et de stocker de manière indépendante, ce qui favorise le parallélisme naturel.

DAG de dépendance d'état : un mécanisme de planification basé sur des graphes 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, modélisant quels comptes sont modifiés et quels comptes sont lus lors de chaque transaction en tant que dépendances. Les transactions non conflictuelles peuvent être exécutées en parallèle, tandis que les transactions avec des dépendances seront planifiées dans l'ordre ou différées selon une séquence topologique. Le graphe de dépendance garantit la cohérence de l'état et l'écriture non répétitive pendant le processus d'exécution parallèle.

Exécution asynchrone et mécanisme de rappel
MegaETH est construit sur le paradigme de programmation asynchrone, similaire au passage de messages asynchrones du modèle Acteur, abordant les problèmes des appels EVM traditionnels en série. Les appels de contrat sont asynchrones (exécution non récursive), et lors de l'appel de contrat A -> B -> C, chaque appel est effectué de manière asynchrone sans blocage ; la pile d'appels est étendue en un graphique d'appels asynchrone (Graphique d'appels) ; le traitement des transactions = traversée du graphique asynchrone + résolution des dépendances + planification parallèle.

En résumé, MegaETH rompt le modèle traditionnel de machine d'état mono-thread EVM en mettant en œuvre une encapsulation de micro machine virtuelle sur une base de compte, en programmant les transactions via un graphe de dépendance d'état et en utilisant un mécanisme de message asynchrone au lieu d'une pile d'appels synchrone. C'est une plateforme de calcul parallèle qui est redessinée dans toutes les dimensions de « structure de compte → architecture de planification → flux d'exécution », offrant une approche de nouveau paradigme pour construire la prochaine génération de systèmes on-chain haute performance.

MegaETH a choisi un chemin de reconstruction : abstraire complètement les comptes et les contrats dans une VM indépendante, et libérer un potentiel parallèle extrême grâce à une planification d'exécution asynchrone. Théoriquement, la limite parallèle de MegaETH est plus élevée, mais il est également plus difficile de contrôler la complexité, ressemblant à un super système d'exploitation distribué selon le concept d'Ethereum.

Les concepts de conception de Monad et MegaETH sont très différents de la fragmentation : la fragmentation divise horizontalement 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 les limitations d'une seule chaîne pour atteindre l'évolutivité au niveau du réseau ; tandis que Monad et MegaETH maintiennent l'intégrité d'une seule chaîne et n'atteignent l'évolutivité horizontale qu'au niveau d'exécution, optimisant la performance grâce à une exécution parallèle extrême au sein de la chaîne unique. Les deux représentent deux directions dans le chemin de l'évolutivité de la blockchain : l'amélioration verticale et l'expansion horizontale.

Des projets comme Monad et MegaETH se concentrent sur les chemins d'optimisation du débit, avec pour objectif principal d'améliorer le TPS sur 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 et aux architectures Micro-VM. Pharos Network, en tant que réseau blockchain L1 modulaire et full-stack parallèle, possède un mécanisme de calcul parallèle central connu sous le nom de "Rollup Mesh". Cette architecture prend en charge des environnements multi-machines virtuelles (EVM et Wasm) grâce au travail collaboratif de la chaîne principale et des réseaux de traitement spéciaux (SPN), 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 :

• Cycle de vie complet du pipeline asynchrone : Pharos découple les différentes étapes d'une transaction (comme le consensus, l'exécution, le stockage) et adopte une approche de traitement asynchrone, permettant à chaque étape de se dérouler indépendamment et en parallèle, améliorant ainsi l'efficacité globale du traitement.
• Exécution parallèle de deux machines virtuelles : 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 améliore également les capacités de traitement des transactions grâce à l'exécution parallèle.
• Réseaux de traitement spéciaux (SPN) : Les SPN sont des composants clés de l'architecture Pharos, similaires à des sous-réseaux modulaires, spécifiquement conçus pour gérer des types de tâches ou d'applications spécifiques. Grâce aux SPN, Pharos peut atteindre une allocation dynamique des ressources et un traitement parallèle des tâches, améliorant ainsi l'évolutivité et les performances du système.
• Consensus Modulaire & Restaking : Pharos introduit un mécanisme de consensus flexible qui prend en charge plusieurs modèles de consensus (tels que PBFT, PoS, PoA) et réalise un partage sécurisé et une intégration des ressources entre la chaîne principale et les SPN grâce au protocole de Restaking.

De plus, Pharos a restructuré le modèle d'exécution du moteur de stockage sous-jacent en utilisant des arbres Merkle à versions multiples, l'encodage delta, l'adressage versionné et les technologies ADS Pushdown, lançant le moteur de stockage haute performance de blockchain natif Pharos Store, atteignant un haut débit, une faible latence et de fortes capacités de traitement vérifiables sur chaîne.

Dans l'ensemble, l'architecture Rollup Mesh de Pharos atteint des capacités de calcul parallèle haute performance grâce à un design modulaire et un mécanisme de traitement asynchrone. Pharos agit comme un coordinateur de planification pour le parallélisme inter-Rollup, non pas comme un optimiseur d'exécution pour le "parallélisme sur chaîne", mais entreprend plutôt des tâches d'exécution personnalisées hétérogènes via des SPNs.

En plus de l'architecture d'exécution parallèle de Monad, MegaETH et Pharos, nous observons également qu'il existe certains projets sur le marché explorant les voies d'application de l'accélération GPU dans le calcul parallèle EVM, qui constituent un complément important et une expérience de pointe pour l'écosystème parallèle EVM. Parmi eux, Reddio et GatlingX sont deux directions représentatives :

• Reddio est une plateforme haute performance qui combine zkRollup et une architecture d'exécution parallèle GPU. Son cœur réside dans la reconstruction du processus d'exécution EVM, réalisant une parallélisation native au niveau d'exécution grâce à la planification multi-thread, au stockage d'état asynchrone et à l'exécution accélérée par GPU des lots de transactions. Elle appartient à la granularité de parallélisme au niveau des transactions + opération (exécution multi-thread des opcodes). Son design introduit l'exécution par lots multi-thread, le chargement d'état asynchrone et le traitement parallèle GPU de la logique transactionnelle (EVM parallèle compatible CUDA). Comme Monad / MegaETH, Reddio se concentre également sur le traitement parallèle au niveau d'exécution, la différence étant la reconstruction du moteur d'exécution grâce à une architecture parallèle GPU, spécifiquement conçue pour des scénarios à fort débit et intensifs en calcul (comme l'inférence AI). Le SDK a été lancé, fournissant un module d'exécution intégrable.
• GatlingX prétend être un "GPU-EVM" et propose une architecture plus radicale qui tente de migrer le modèle d'"exécution séquentielle au niveau des instructions" de la machine virtuelle EVM traditionnelle vers un environnement d'exécution parallèle natif GPU. Son mécanisme de base implique la compilation dynamique du bytecode EVM en tâches parallèles CUDA, exécutant des flux d'instructions via le multi-cœur GPU, brisant ainsi le goulet d'étranglement séquentiel de l'EVM au niveau le plus bas. Il appartient à la granularité de parallélisme au niveau des instructions (Instruction-Level Parallelism, ILP). Comparé à la granularité de parallélisme "au niveau des transactions/au niveau des comptes" de Monad / MegaETH, le mécanisme parallèle de GatlingX est plus proche des chemins d'optimisation au niveau des instructions, plus semblable à la reconstruction sous-jacente du moteur de machine virtuelle. Actuellement, il est à l'état conceptuel, avec un livre blanc et des croquis architecturaux publiés, mais sans SDK ni mainnet pour le moment.

Artela propose un concept de conception parallèle différenciée. En introduisant l'architecture EVM++ avec une machine virtuelle WebAssembly (WASM), cela permet aux développeurs d'ajouter et d'exécuter dynamiquement des extensions sur la chaîne tout en maintenant la compatibilité EVM, en utilisant le modèle de programmation Aspect. Il prend la granularité des appels de contrat (Fonction / Extension) comme unité parallèle minimale, soutenant l'injection de modules d'Extension (similaires à des "middleware pluggables") pendant l'exécution des contrats EVM, réalisant ainsi le découplage logique, les appels asynchrones et l'exécution parallèle au niveau des modules. Il se concentre davantage sur la composabilité et l'architecture modulaire de la couche d'exécution. Ce concept offre de nouvelles idées pour de futures applications complexes multi-modules.

3. Architecture Parallèle Native de Chaîne : Reconstruction de l'Entité d'Exécution de la VM

Le modèle d'exécution EVM d'Ethereum a adopté une architecture à thread unique de "commande totale des transactions + exécution séquentielle" depuis sa conception, visant à garantir la déterminisme et la cohérence des changements d'état à travers tous les nœuds du réseau. Cependant, cette architecture présente des goulets d'étranglement de performance inhérents qui limitent le débit et l'évolutivité du système. En revanche, les chaînes d'architecture de calcul parallèle natif telles que Solana (SVM), MoveVM (Sui, Aptos) et Sei v2 construite sur Cosmos SDK sont conçues pour l'exécution parallèle dès le départ, offrant les avantages suivants:

• Le modèle d'état se sépare naturellement : Solana adopte un mécanisme de déclaration de verrouillage de compte, MoveVM introduit un modèle de propriété d'objet, et Sei v2 classe en fonction des types de transactions pour réaliser une détermination de conflit statique, soutenant la planification concurrente au niveau des transactions.
• Optimisation de la concurrence des machines virtuelles : le moteur Sealevel de Solana prend en charge nativement l'exécution multithread ; MoveVM peut effectuer une analyse de graphe de concurrence statique ; Sei v2 intègre un moteur d'appariement multithread et un module VM parallèle.

Bien sûr, ce type de chaîne parallèle native fait également face à des défis de compatibilité écologique. Les architectures non-EVM nécessitent souvent des langages de développement entièrement nouveaux (comme Move, Rust) et des chaînes d'outils, ce qui représente un certain coût de migration pour les développeurs ; de plus, les développeurs doivent également maîtriser une série de nouveaux concepts tels que les modèles d'accès à l'état, les limites de concurrence et les cycles de vie des objets, ce qui élève le seuil de compréhension et impose des exigences plus élevées en matière de paradigmes de développement.

3.1 Le principe de Solana et le moteur parallèle Sealevel de SVM

Le modèle d'exécution Sealevel de Solana est un mécanisme de planification parallèle basé sur les comptes, qui est le moteur central utilisé par Solana pour réaliser l'exécution parallèle des transactions sur la chaîne. Grâce au mécanisme « déclaration de compte + planification statique + exécution multi-thread » il réalise une concurrence de haute performance au niveau des contrats intelligents. Sealevel est le premier modèle d'exécution dans le domaine de la blockchain à avoir réussi à mettre en œuvre la planification concurrente sur la chaîne dans un environnement de production, et ses idées architecturales ont influencé de nombreux projets de calcul parallèle ultérieurs, servant de modèle de référence pour la conception parallèle de haute performance de la couche 1.

Mécanisme de base :

1. Déclaration explicite d'accès au compte (Listes d'accès au compte) : Chaque transaction doit déclarer les comptes impliqués (lecture/écriture) au moment de la soumission, permettant au système de déterminer s'il existe des conflits d'état entre les transactions.

2. Détection de conflit et planification multithread

• Si l'ensemble des comptes accessibles par les deux transactions n'a pas d'intersection → elles peuvent être exécutées en parallèle ;
• Un conflit existe → Exécutez en série dans l'ordre de dépendance;
• Le planificateur attribue des transactions à différents threads en fonction du graphe de dépendance.

3. Contexte d'exécution indépendant (Contexte d'invocation de programme) : Chaque appel de contrat fonctionne dans un contexte isolé, sans pile partagée, empêchant toute interférence entre les appels.

Sealevel est le moteur de planification d'exécution parallèle de Solana, tandis que SVM est l'environnement d'exécution des contrats intelligents construit sur Sealevel (utilisant la machine virtuelle BPF). Ensemble, ils forment la base technique du système d'exécution parallèle haute performance de Solana.

Eclipse est un projet qui déploie la VM Solana sur des chaînes modulaires (comme Ethereum L2 ou Celestia), utilisant le moteur d'exécution parallèle de Solana comme couche d'exécution Rollup. Eclipse est l'un des premiers projets à proposer de détacher la couche d'exécution Solana (Sealevel + SVM) du mainnet Solana et à la migrer vers une architecture modulaire, en modulant le "modèle d'exécution concurrente super fort" de Solana en tant que couche d'exécution en tant que service. Par conséquent, Eclipse relève également de la catégorie du calcul parallèle.

L'approche de Neon est différente; elle introduit l'EVM pour fonctionner dans l'environnement SVM / Sealevel. Elle construit une couche d'exécution compatible avec l'EVM, permettant aux développeurs d'utiliser Solidity pour développer des contrats qui fonctionnent dans l'environnement SVM, mais l'exécution programmée utilise SVM + Sealevel. Neon est davantage orienté vers la catégorie des blockchains modulaires plutôt que d'insister sur les innovations en informatique parallèle.

En résumé, Solana et SVM s'appuient sur le moteur d'exécution Sealevel, et la philosophie de planification du système d'exploitation Solana est similaire à celle d'un planificateur de noyau, s'exécutant rapidement mais avec une flexibilité relativement faible. C'est une chaîne publique native à haute performance et de calcul parallèle.

3.2 Architecture MoveVM : Pilotée par les ressources et les objets

MoveVM est une machine virtuelle de contrat intelligent conçue pour la sécurité des ressources on-chain et l'exécution parallèle. Son langage principal, Move, a été initialement développé par Meta (anciennement Facebook) pour le projet Libra, mettant l'accent sur le concept de "ressource en tant qu'objet". Tous les états on-chain existent en tant qu'objets avec une propriété et un cycle de vie clairs. Cela permet à MoveVM d'analyser s'il existe des conflits d'état entre les transactions au moment de la compilation, permettant une planification parallèle statique au niveau des objets, et il est largement utilisé dans des chaînes publiques parallèles natives telles que Sui et Aptos.

Le modèle de propriété des objets de Sui
La capacité de calcul parallèle de Sui provient de son approche unique de modélisation d'état et de son mécanisme d'analyse statique au niveau du langage. Contrairement aux blockchains traditionnelles qui utilisent un arbre d'état global, Sui a construit un ensemble de modèles d'état centrés sur les objets, combinés avec le système de types linéaires de MoveVM, permettant à la planification parallèle d'être un processus déterministe pouvant être complété au moment de la compilation.

• Le modèle d'objet est la base de l'architecture parallèle de Sui. Sui abstrait tous les états en chaîne en objets indépendants, chacun ayant un ID unique, un propriétaire clair (compte ou contrat) et des définitions de type. Ces objets ne partagent pas d'états entre eux, offrant une isolation naturelle. Les contrats doivent déclarer explicitement l'ensemble des objets impliqués lors de leur invocation, évitant ainsi les problèmes de couplage d'état de l'arbre d'état global traditionnel en chaîne. Cette conception décompose les états en chaîne en plusieurs unités indépendantes, rendant l'exécution concurrente une prémisse de planification structurellement réalisable.
• L'analyse statique de la propriété est un mécanisme d'analyse à la compilation mis en œuvre sous le soutien du système de types linéaires du langage Move. Il permet au système d'inférer quelles transactions ne provoqueront pas de conflits d'état grâce à la propriété des objets avant que les transactions ne soient exécutées, organisant ainsi leur exécution en parallèle. Par rapport à la détection de conflits traditionnelle à l'exécution et au retour arrière, le mécanisme d'analyse statique de Sui améliore considérablement l'efficacité d'exécution tout en réduisant considérablement la complexité de planification, ce qui est essentiel pour atteindre un débit élevé et des capacités de traitement parallèle déterministes.

Sui divise l'espace d'état en fonction des objets et combine l'analyse de propriété à la compilation pour atteindre une exécution parallèle au niveau des objets à faible coût et sans retour en arrière. Par rapport à l'exécution sérielle ou aux vérifications à l'exécution des chaînes traditionnelles, Sui a réalisé des améliorations significatives en matière d'efficacité d'exécution, de déterminisme du système et d'utilisation des ressources.

Le mécanisme d'exécution Block-STM d'Aptos
Aptos est une blockchain de niveau 1 haute performance basée sur le langage Move, dont la capacité d'exécution parallèle provient principalement du cadre Block-STM (mémoire transactionnelle logicielle au niveau des blocs) développé en interne. Contrairement à Sui, qui tend à adopter une stratégie de "parallélisme statique à la compilation", Block-STM appartient à un mécanisme de planification dynamique "concurrence optimiste à l'exécution + retour en arrière des conflits", adapté à la gestion d'ensembles de transactions avec des dépendances complexes.

Block-STM divise l'exécution des transactions d'un bloc en trois phases :

• Exécution spéculative : Toutes les transactions sont supposées être sans conflit avant l'exécution, et le système planifie les transactions sur plusieurs threads pour une exécution concurrente, enregistrant les états des comptes auxquels elles accèdent (ensemble de lecture / ensemble d'écriture).
• Phase de détection et de validation des conflits : Le système vérifie les résultats d'exécution : si deux transactions ont un conflit de lecture-écriture (par exemple, Tx1 lit l'état écrit par Tx2), l'une d'elles sera annulée.
• Rollback de transaction en conflit (phase de réessai) : Les transactions en conflit seront reprogrammées pour exécution jusqu'à ce que leurs dépendances soient résolues, formant finalement une séquence de validation et d'engagement d'état valide et déterministe pour toutes les transactions.

Block-STM est un modèle d'exécution dynamique qui utilise "le parallélisme optimiste + la reprise après retour en arrière", adapté aux scénarios de traitement par lots de transactions on-chain intensives en état et logiquement complexes. C'est le cœur du calcul parallèle pour Aptos afin de construire une chaîne publique hautement polyvalente et à haut débit.

Solana est la faction d'ingénierie de planification, plus proche d'un "noyau de système d'exploitation". Il est adapté aux frontières d'état claires et au trading haute fréquence contrôlable, incarnant un style d'ingénieur matériel, et est conçu pour faire fonctionner la chaîne comme du matériel (exécution parallèle de qualité matérielle). Aptos est la faction de tolérance aux pannes du système, plus proche d'un "moteur de concurrence de base de données". Il est adapté aux contrats avec un fort couplage d'état et des chaînes d'appels complexes. Sui est la faction de sécurité à la compilation, plus proche d'une "plateforme de langage intelligent orientée ressources". Il est adapté aux applications sur chaîne avec séparation des actifs et combinaisons claires. Aptos et Sui sont destinés à faire fonctionner la chaîne en tant qu'ingénieurs de langages de programme, garantissant la sécurité des ressources de qualité logicielle. Les trois représentent différentes voies philosophiques pour la mise en œuvre technique de l'informatique parallèle dans le Web3.

3.3 Type de mise à l'échelle parallèle du SDK Cosmos

Sei V2 est une chaîne publique de trading haute performance construite sur le Cosmos SDK. Ses capacités parallèles se reflètent principalement dans deux aspects : le moteur de correspondance multithread et l'optimisation de l'exécution parallèle au niveau de la machine virtuelle, visant à servir des scénarios de trading on-chain à haute fréquence et faible latence, tels que les DEXs à livre de commandes et l'infrastructure d'échange on-chain.

Mécanisme parallèle de base :

• Moteur de correspondance parallèle : Sei V2 introduit un chemin d'exécution multi-thread dans la logique de correspondance des ordres, séparant le carnet d'ordres de la logique de correspondance au niveau des threads, permettant aux tâches de correspondance entre plusieurs marchés (paires de trading) d'être traitées en parallèle, évitant ainsi les goulets d'étranglement à thread unique.
• Optimisation de la Concurrence au Niveau de la Machine Virtuelle : Sei V2 a construit un environnement d'exécution CosmWasm avec des capacités d'exécution concurrente, permettant à certains appels de contrats de s'exécuter en parallèle à condition que leurs états ne soient pas en conflit, et atteignant un meilleur contrôle du débit en conjonction avec un mécanisme de classification des types de transactions.
• Consensus parallèle combiné avec la planification de couche d'exécution : Introduction du mécanisme de consensus dit « Twin-Turbo » pour renforcer le découplage de la capacité entre la couche de consensus et la couche d'exécution, améliorant ainsi l'efficacité globale du traitement des blocs.

3.4 Carburant de reconstructeur de modèle UTXO

Fuel est une couche d'exécution haute performance conçue sur la base de l'architecture modulaire d'Ethereum, avec son mécanisme parallèle central découlant d'un modèle UTXO amélioré (Unspent Transaction Output). Contrairement au modèle de compte d'Ethereum, Fuel utilise une structure UTXO pour représenter les actifs et les états, qui possède intrinsèquement une isolation d'état, facilitant ainsi la détermination des transactions pouvant être exécutées en parallèle en toute sécurité. De plus, Fuel introduit un langage de contrat intelligent auto-développé appelé Sway (similaire à Rust) et le combine avec des outils d'analyse statique pour identifier les conflits d'entrée avant l'exécution des transactions, permettant ainsi d'atteindre une planification parallèle efficace et sécurisée au niveau des transactions. Il sert de couche d'exécution alternative EVM qui équilibre performance et modularité.

4. Modèle d'Acteur : Un Nouveau Paradigme pour l'Exécution Concurrente des Agents

Le modèle d'acteur est un paradigme d'exécution parallèle qui utilise des processus d'agent (Agent ou Processus) comme unités, différant de la computation synchrone traditionnelle avec un état global sur la chaîne (scénarios comme « le calcul parallèle sur la chaîne » tels que Solana/Sui/Monad), car il souligne que chaque agent a son propre état et comportement indépendants, communiquant et planifiant par le biais de messages asynchrones. Sous cette architecture, les systèmes sur la chaîne peuvent exécuter de manière concurrente un grand nombre de processus découplés, offrant une forte scalabilité et une tolérance aux pannes asynchrone. Les projets représentatifs incluent AO (Arweave AO), ICP (Internet Computer) et Cartesi, qui font évoluer la blockchain d'un moteur d'exécution vers un « système d'exploitation sur la chaîne », fournissant une infrastructure native pour les agents IA, les interactions multitâches et l'orchestration de logique complexe.

Bien que le design du Modèle d'Acteur présente certaines similitudes superficielles avec le Sharding (comme la concurrence, l'isolation de l'état et le traitement asynchrone), ils représentent essentiellement des chemins techniques et des philosophies de système complètement différents. Le Modèle d'Acteur met l'accent sur le "calcul asynchrone multi-processus", où chaque agent (Acteur) fonctionne de manière indépendante et maintient son propre état, interagissant par le biais d'une approche basée sur les messages ; tandis que le Sharding est un mécanisme pour "le partitionnement horizontal de l'état et du consensus", divisant l'ensemble de la blockchain en plusieurs sous-systèmes indépendants (Shards) qui traitent les transactions. Le Modèle d'Acteur ressemble davantage à un "système d'exploitation d'agents distribués" dans le monde du Web3, tandis que le Sharding est une solution de mise à l'échelle structurelle pour les capacités de traitement des transactions sur chaîne. Les deux réalisent la concurrence, mais leurs points de départ, leurs objectifs et leurs architectures d'exécution sont différents.

4.1 AO (Arweave), un super ordinateur parallèle au-dessus de la couche de stockage

AO est une plateforme de calcul décentralisée fonctionnant sur la couche de stockage permanent Arweave, avec l'objectif principal de construire un système d'exploitation on-chain qui prend en charge le fonctionnement d'agents asynchrones à grande échelle.

Caractéristiques de l'architecture de base :

• Architecture des processus : Chaque agent est appelé Processus, possédant un état indépendant, un planificateur indépendant et une logique d'exécution.
• Aucune structure blockchain : AO n'est pas une chaîne, mais une couche de stockage décentralisée basée sur Arweave + un moteur d'exécution piloté par message multi-agents ;
• Système de planification de messages asynchrone : Les processus communiquent par le biais de messages, adoptant un modèle opérationnel asynchrone sans verrou, qui prend en charge de manière inhérente l'évolutivité concurrente ;
• Stockage permanent des états : Tous les états des agents, les enregistrements de messages et les instructions sont enregistrés de manière permanente sur Arweave, garantissant une auditabilité complète et une transparence décentralisée.
• Agent-natif : Adapté au déploiement de tâches complexes en plusieurs étapes (telles que les agents IA, les contrôleurs de protocole DePIN, les orchestrateurs de tâches automatisées, etc.), peut construire un "Coprocesseur IA on-chain."

AO suit une approche extrême de « corps intelligent natif + orienté stockage + architecture sans chaîne », mettant l'accent sur la flexibilité et le découplage modulaire. Il s'agit d'un « cadre micro-noyau construit au-dessus de la couche de stockage », avec des frontières système délibérément réduites, mettant l'accent sur le calcul léger + des structures de contrôle composables.

4.2 ICP (Internet Computer), une plateforme d'hébergement Web3 full-stack

ICP est une plateforme d'application on-chain full-stack native Web3 lancée par DFINITY, visant à étendre les capacités de calcul on-chain à une expérience similaire à celle du Web2, et prend en charge l'hébergement complet de services, la liaison de domaines et une architecture sans serveur.

Caractéristiques de l'architecture de base :

• Architecture des canisters (conteneurs en tant qu'agents intelligents) : Chaque canister est un agent intelligent fonctionnant sur la machine virtuelle Wasm, possédant un état, un code et des capacités de planification asynchrone indépendants ;
• Système de consensus distribué par sous-réseau : L'ensemble du réseau est composé de plusieurs sous-réseaux, chacun maintenant un groupe de Canisters et atteignant le consensus par le biais du mécanisme de signature BLS.
• Modèle d'appel asynchrone : Les canisters communiquent entre eux par le biais de messages asynchrones, prenant en charge l'exécution non bloquante et ayant un parallélisme inhérent ;
• Hébergement Web en chaîne : Prend en charge les contrats intelligents pour héberger directement les pages front-end, avec un mappage DNS natif, faisant de lui la première plateforme blockchain à prendre en charge l'accès direct des navigateurs aux dApps.
• Fonctions système complètes : Équipé de mises à niveau à chaud en chaîne, d'authentification d'identité, de randomisation distribuée, de temporisateurs et d'autres API système, adapté au déploiement de services complexes en chaîne.

ICP sélectionne une plateforme lourde, une encapsulation intégrée et un paradigme de système d'exploitation de contrôle de plateforme fort, caractérisé par un "Système d'Exploitation Blockchain" avec un consensus, une exécution, un stockage et un accès intégrés. Il met l'accent sur des capacités d'hébergement de services complètes, et la frontière du système s'étend à une plateforme d'hébergement Web3 full-stack.

De plus, d'autres projets de calcul parallèle basés sur le paradigme du modèle d'acteur peuvent se référer au tableau ci-dessous :

V. Résumé et Perspectives

Selon les différences d'architecture de machine virtuelle et de systèmes de langage, les solutions de calcul parallèle sur blockchain peuvent être grossièrement divisées en deux catégories : les chaînes d'amélioration parallèle basées sur l'EVM et les chaînes à architecture parallèle native (non-EVM).

Le premier atteint un débit plus élevé et des capacités de traitement parallèle grâce à une optimisation approfondie de la couche d'exécution tout en maintenant la compatibilité avec l'écosystème EVM/Solidity. Il est adapté aux scénarios où il y a un désir d'hériter des actifs Ethereum et des outils de développement tout en réalisant des percées en matière de performance. Les projets représentatifs incluent :

• Monad : Réalise un modèle d'exécution parallèle optimiste compatible avec l'EVM grâce à des écritures différées et à la détection de conflits en temps réel, construisant un graphe de dépendances et planifiant l'exécution avec multithreading après que le consensus a été atteint.
• MegaETH : Abstrait chaque compte/contrat en tant que Micro-VM indépendant, réalisant une planification parallèle au niveau des comptes hautement découplée basée sur la messagerie asynchrone et les graphes de dépendance d'état.
• Pharos : Construction d'une architecture de Rollup Mesh qui collabore avec le module SPN via des pipelines asynchrones pour réaliser un traitement parallèle au niveau du système à travers les processus.
• Reddio : Adopte une architecture zkRollup + GPU, se concentrant sur l'accélération du processus de vérification hors chaîne de zkEVM grâce à la génération en masse de SNARK, améliorant le débit de vérification.

Ce dernier se libère complètement des limitations de la compatibilité avec Ethereum, redéfinissant le paradigme d'exécution à partir de la machine virtuelle, du modèle d'état et du mécanisme de planification pour atteindre des capacités de concurrence à haute performance natives. Les sous-classes typiques incluent :

• Solana (SVM System) : Basé sur les déclarations d'accès aux comptes et la planification du graphe de conflits statiques, représentant un modèle d'exécution parallèle au niveau des comptes ;
• Sui / Aptos (Système MoveVM) : Basé sur le modèle d'objet de ressource et le système de type, il prend en charge l'analyse statique à la compilation et atteint un parallélisme au niveau des objets.
• Sei V2 (Route Cosmos SDK) : Introduit un moteur de correspondance multi-threadé et une optimisation de la concurrence de machine virtuelle au sein de l'architecture Cosmos, adapté aux applications de trading haute fréquence.
• Carburant (UTXO + architecture Sway) : Réaliser un parallélisme au niveau des transactions grâce à l'analyse statique des ensembles d'entrées UTXO, combinée à une couche d'exécution modulaire et au langage de contrat intelligent personnalisé Sway.

De plus, le modèle d'acteur, en tant que système parallèle plus large, construit un paradigme d'exécution en chaîne de « fonctionnement indépendant multi-agents + collaboration dirigée par message » grâce à un mécanisme de planification de processus asynchrone basé sur Wasm ou des machines virtuelles personnalisées. Les projets représentatifs incluent :

• AO (Arweave AO) : Un environnement d'exécution d'agent piloté par un stockage permanent, construisant un système de micro-noyau asynchrone sur chaîne.
• ICP (Internet Computer) : Réalise une exécution haute évolutivité asynchrone grâce à la coordination des sous-réseaux avec l'agent conteneurisé (Canister) comme unité la plus petite.
• Cartesi : Introduit le système d'exploitation Linux comme un environnement de calcul hors chaîne, fournissant un chemin de vérification sur chaîne pour des résultats de calcul fiables, adapté à des scénarios d'application complexes ou gourmands en ressources.

Sur la base de la logique ci-dessus, nous pouvons classer les solutions de chaînes publiques de calcul parallèle grand public actuelles dans la structure de classification montrée dans le tableau ci-dessous :

D'un point de vue plus large de l'évolutivité, le sharding et le rollup (L2) se concentrent sur l'obtention d'une évolutivité horizontale du système par le biais de la partition d'état ou de l'exécution hors chaîne, tandis que les chaînes de calcul parallèle (comme Monad, Sui, Solana) et les systèmes orientés acteur (comme AO, ICP) reconstruisent directement le modèle d'exécution pour réaliser un parallélisme natif au niveau de la chaîne ou du système. Les premiers améliorent le débit on-chain par des méthodes telles que les machines virtuelles multithread, les modèles d'objet et l'analyse des conflits de transactions ; les seconds utilisent des processus/agents comme unités de base et adoptent des méthodes d'exécution asynchrone et pilotée par messages pour permettre le fonctionnement concurrent de plusieurs agents. En comparaison, le sharding et le rollup ressemblent davantage à 'distribuer la charge sur plusieurs chaînes' ou 'externaliser vers l'extérieur de la chaîne', tandis que les chaînes parallèles et le modèle d'acteur concernent 'la libération du potentiel de performance du moteur d'exécution lui-même', reflétant une direction d'évolution architecturale plus approfondie.

Comparaison de l'informatique parallèle, de l'architecture shard, de la scalabilité rollup et du chemin d'extension orienté acteur

Il convient de noter que la plupart des chaînes à architecture parallèle native sont désormais entrées dans la phase de lancement du mainnet. Bien que l'écosystème des développeurs dans son ensemble soit encore difficile à comparer avec le système Solidity basé sur EVM, des projets représentés par Solana et Sui, avec leur architecture d'exécution haute performance et la prospérité progressive des applications écologiques, sont devenus les chaînes publiques centrales qui attirent une attention significative du marché.

En revanche, bien que l'écosystème Ethereum Rollup (L2) soit entré dans la phase de "nombreuses chaînes se précipitant pour se lancer" ou même "saturation", les chaînes d'amélioration parallèles compatibles avec EVM actuellement mainstream sont encore généralement en phase de testnet et n'ont pas encore été vérifiées dans un environnement de mainnet. Leurs capacités d'évolutivité et la stabilité de leur système nécessitent encore un examen approfondi. Quant à savoir si ces projets peuvent améliorer de manière significative les performances d'EVM et promouvoir l'évolution écologique sans sacrifier la compatibilité, ou s'ils vont au contraire aggraver la différenciation des liquidités et des ressources de développement sur Ethereum, cela reste à voir.

Déclaration :

1. Cet article est reproduit à partir de [TechFlow] Le droit d'auteur appartient à l'auteur original [0xjacobzhao et ChatGPT 4o] Si vous avez des objections à la réimpression, veuillez contacter Équipe Gate LearnL'équipe le traitera dès que possible conformément aux procédures pertinentes.
2. Avertissement : Les opinions et points de vue exprimés dans cet article n'engagent que l'auteur et ne constituent pas des conseils en matière d'investissement.
3. Les autres versions linguistiques de l'article sont traduites par l'équipe de Gate Learn, sauf indication contraire.PortailEn aucun cas, les articles traduits ne doivent être copiés, diffusés ou plagiés.