L'avenir de la mise à l'échelle : Cartographie complète du secteur du calcul parallèle Web3
TechFlow SélectionTechFlow Sélection
L'avenir de la mise à l'échelle : Cartographie complète du secteur du calcul parallèle Web3
Interprétation approfondie du calcul parallèle en Web3.
Dédié à des analyses Web3 approfondiesRédaction : 0xjacobzhao et ChatGPT 4o
Le « trilemme de la blockchain » (Blockchain Trilemma), composé de la « sécurité », de la « décentralisation » et de la « scalabilité », révèle les compromis fondamentaux dans la conception des systèmes blockchain, à savoir qu'il est difficile pour un projet blockchain d'atteindre simultanément une sécurité maximale, une participation universelle et un traitement à haute vitesse. Concernant ce sujet éternel de la « scalabilité », les solutions actuelles de mise à l'échelle des blockchains peuvent être classées selon leur paradigme en :
-
Mise à l'échelle par renforcement de l'exécution : amélioration directe des capacités d'exécution, par exemple parallélisme, GPU, multi-cœurs
-
Mise à l'échelle par isolation d'état : découpage horizontal de l'état / Shard, par exemple sharding, UTXO, multi-sous-réseaux
-
Mise à l'échelle par externalisation hors chaîne : déplacement de l'exécution hors chaîne, par exemple Rollup, Coprocessor, DA
-
Mise à l'échelle par découplage structurel : modularité architecturale et fonctionnement collaboratif, par exemple blockchains modulaires, séquenceurs partagés, Rollup Mesh
-
Mise à l'échelle par concurrence asynchrone : modèle Actor, isolement des processus, piloté par messages, par exemple agents intelligents, chaînes multithread asynchrones
Les solutions de mise à l'échelle blockchain incluent le calcul parallèle intra-chaîne, les Rollups, le sharding, les modules DA, les architectures modulaires, les systèmes Actor, la compression par preuves zk, les architectures sans état, couvrant plusieurs niveaux comme exécution, état, données et structure. Il s'agit d'un système complet de mise à l'échelle basé sur une « coordination multicouche et combinaison modulaire ». Cet article se concentre principalement sur les approches de mise à l'échelle dominées par le calcul parallèle.
Le parallélisme intra-chaîne (intra-chain parallelism) concerne l'exécution parallèle des transactions / instructions au sein d'un bloc. Selon le mécanisme de parallélisme, ces méthodes peuvent être divisées en cinq catégories, chacune représentant des objectifs de performance, des modèles de développement et des philosophies architecturales différents, avec une granularité croissante, une intensité de parallélisme accrue, une complexité croissante du planificateur, ainsi qu'une augmentation de la complexité de programmation et de la difficulté de mise en œuvre.
-
Parallélisme au niveau du compte (Account-level) : projet représentatif Solana
-
Parallélisme au niveau de l'objet (Object-level) : projet représentatif Sui
-
Parallélisme au niveau de la transaction (Transaction-level) : projets représentatifs Monad, Aptos
-
Parallélisme au niveau de l'appel / micro-machine virtuelle (Call-level / MicroVM) : projet représentatif MegaETH
-
Parallélisme au niveau des instructions (Instruction-level) : projet représentatif GatlingX
Le modèle de concurrence asynchrone hors chaîne, représenté par les systèmes d'agents intelligents (modèle Agent / Actor), relève d’un autre paradigme de calcul parallèle. En tant que système inter-chaîne / message asynchrone (non basé sur un modèle de synchronisation par blocs), chaque agent fonctionne comme un « processus intelligent indépendant », communiquant via des messages asynchrones, piloté par des événements, sans nécessiter de synchronisation. Les projets représentatifs incluent AO, ICP, Cartesi, etc.
En revanche, les solutions bien connues de mise à l’échelle telles que les Rollups ou le sharding appartiennent à des mécanismes de concurrence au niveau système, et ne relèvent pas du parallélisme intra-chaîne. Elles atteignent la mise à l’échelle en « exécutant plusieurs chaînes / domaines d’exécution en parallèle », plutôt qu’en augmentant le degré de parallélisme au sein d’un seul bloc / machine virtuelle. Ces solutions ne sont pas le principal sujet de cet article, mais seront tout de même comparées en termes de philosophie architecturale.
Deux : Blockchains EVM parallèles améliorées – repousser les limites de performance tout en assurant la compatibilité
L’architecture séquentielle d’Ethereum a subi plusieurs tentatives de mise à l’échelle, notamment le sharding, les Rollups et les architectures modulaires, mais le goulot d’étranglement au niveau de l’exécution n’a toujours pas été fondamentalement résolu. Toutefois, EVM et Solidity restent la plateforme de contrats intelligents la plus adoptée par les développeurs et la plus dynamique en termes d’écosystème. Ainsi, les blockchains EVM parallèles améliorées, qui conjuguent compatibilité écosystémique et amélioration des performances d’exécution, deviennent une direction clé dans l’évolution de la mise à l’échelle. Monad et MegaETH sont deux projets emblématiques de cette voie, construisant respectivement des architectures EVM parallèles à haut débit et forte concurrence à partir de l'exécution différée et de la décomposition d’état.
Analyse du mécanisme de calcul parallèle de Monad
Monad est une blockchain Layer1 à haute performance, conçue pour redéfinir la machine virtuelle Ethereum (EVM). Basé sur le principe fondamental du traitement en pipeline (Pipelining), il implémente une exécution asynchrone au niveau de la consensus (Asynchronous Execution) et une exécution concurrente optimiste au niveau de l'exécution (Optimistic Parallel Execution). De plus, au niveau du consensus et du stockage, Monad introduit un protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB), permettant une optimisation bout-en-bout.
Pipelining : mécanisme d'exécution parallèle en plusieurs étapes
Le pipelining est le principe fondamental de l’exécution parallèle de Monad. L’idée centrale consiste à diviser le processus d’exécution de la blockchain en plusieurs étapes indépendantes, puis à les traiter en parallèle afin de former une architecture en pipeline multidimensionnel. Chaque étape s’exécute sur un thread ou un noyau distinct, permettant un traitement concurrent entre blocs, ce qui augmente le débit et réduit la latence. Ces étapes comprennent : proposition de transaction (Propose), accord de consensus (Consensus), exécution de transaction (Execution) et validation du bloc (Commit).
Asynchronous Execution : découplage asynchrone entre consensus et exécution
Dans les blockchains traditionnelles, le consensus et l’exécution des transactions suivent généralement un flux synchrone, un modèle séquentiel qui limite fortement l’évolutivité. Monad utilise l’« exécution asynchrone » pour découpler le consensus, l’exécution et le stockage de manière asynchrone, réduisant significativement le temps de bloc (block time) et la latence de confirmation, rendant le système plus souple, les traitements plus segmentés et l’utilisation des ressources plus efficace.
Conception principale :
-
La phase de consensus (couche de consensus) se charge uniquement de l’ordonnancement des transactions, sans exécuter la logique des contrats.
-
La phase d’exécution (couche d’exécution) est déclenchée de manière asynchrone après l’achèvement du consensus.
-
Dès que le consensus est terminé, le système passe immédiatement au processus de consensus du bloc suivant, sans attendre la fin de l’exécution.
Optimistic Parallel Execution : exécution parallèle optimiste
Ethereum traditionnel applique un modèle strictement séquentiel aux transactions afin d’éviter les conflits d’état. Monad adopte quant à lui 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écute toutes les transactions en parallèle de manière optimiste, en supposant que la majorité des transactions n’ont pas de conflits d’état.
-
Un « détecteur de conflits (Conflict Detector) » surveille en parallèle si des transactions accèdent au même état (conflits lecture/écriture).
-
En cas de conflit détecté, les transactions concernées sont re-exécutées en série pour garantir la cohérence d’état.
Monad a choisi la voie de compatibilité : modifier le moins possible les règles EVM, en reportant l’écriture d’état et en détectant dynamiquement les conflits pour réaliser le parallélisme. C’est essentiellement une version performante d’Ethereum, facile à migrer pour l’écosystème EVM, agissant comme un accélérateur parallèle dans le monde EVM.
Analyse du mécanisme de calcul parallèle de MegaETH
À la différence de Monad positionné comme L1, MegaETH est conçu comme une couche d’exécution parallèle haute performance, compatible EVM, pouvant fonctionner soit comme une blockchain L1 indépendante, soit comme une couche d’amélioration de l’exécution (Execution Layer) ou un composant modulaire sur Ethereum. Son objectif 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 d’atteindre une exécution hautement concurrente et une réponse à faible latence au sein de la chaîne. L’innovation clé de MegaETH réside dans l’architecture Micro-VM + DAG de dépendance d’état (graphe orienté acyclique de dépendances) et un mécanisme de synchronisation modulaire, formant ensemble un système d’exécution parallèle orienté vers le « threading intra-chaîne ».
Architecture Micro-VM (micro-machine virtuelle) : un compte, un thread
MegaETH introduit un modèle d’exécution où « chaque compte dispose d’une micro-machine virtuelle (Micro-VM) », transformant l’environnement d’exécution en « threads », fournissant l’unité d’isolation minimale pour la planification parallèle. Ces VM communiquent via des messages asynchrones (Asynchronous Messaging) plutôt que par des appels synchrones, permettant à de nombreuses VM de s’exécuter et de stocker indépendamment, favorisant naturellement le parallélisme.
DAG de dépendance d’état : mécanisme de planification piloté par graphe
MegaETH construit un système de planification basé sur un DAG de dépendance d’état, modélisant les relations d’accès aux comptes. Le système maintient en temps réel un graphe global de dépendances. À chaque modification ou lecture de compte par une transaction, une relation de dépendance est créée. Les transactions sans conflits peuvent s’exécuter en parallèle ; celles ayant des dépendances sont ordonnées en série ou retardées selon l’ordre topologique. Ce graphe garantit la cohérence d’état et évite les écritures multiples durant l’exécution parallèle.
Exécution asynchrone et mécanisme de rappel
MegaETH repose sur un paradigme de programmation asynchrone, similaire au modèle Actor, utilisant le passage de messages asynchrones pour résoudre le problème des appels séquentiels dans l’EVM traditionnelle. Les appels de contrat sont asynchrones (non récursifs) ; lorsqu’un appel contractuel A -> B -> C est effectué, chaque appel est asynchronisé sans bloquer l’attente ; la pile d’appels est transformée en graphe d’appels asynchrone (Call Graph) ; le traitement d’une transaction équivaut à parcourir ce graphe asynchrone + résolution des dépendances + planification parallèle.
En résumé, MegaETH rompt avec le modèle monolithique à fil unique de l’EVM traditionnelle, encapsule chaque compte et contrat dans une micro-VM, utilise un graphe de dépendance d’état pour planifier les transactions, et remplace la pile d’appels synchrones par un mécanisme de messages asynchrones. C’est une plateforme de calcul parallèle entièrement repensée à tous les niveaux : « structure du compte → architecture du planificateur → flux d’exécution », offrant une nouvelle orientation paradigmatique pour les futurs systèmes blockchain haute performance.
MegaETH a choisi la voie de la refonte : abstraire radicalement les comptes et contrats en VM indépendants, libérant tout le potentiel parallèle via une planification asynchrone. Théoriquement, la limite de parallélisme de MegaETH est plus élevée, mais sa complexité est plus difficile à maîtriser. C’est une sorte de super système distribué inspiré de l’Ethereum.
Les philosophies de conception de Monad et MegaETH diffèrent fortement du sharding : ce dernier découpe horizontalement la blockchain en plusieurs sous-chaînes indépendantes (shards), chacune gérant une partie des transactions et de l’état, dépassant ainsi les limites d’une seule chaîne au niveau réseau ; tandis que Monad et MegaETH conservent l’intégrité de la chaîne unique, n’élargissant que la couche d’exécution horizontalement, en optimisant au maximum l’exécution parallèle interne. Ils incarnent respectivement les directions de renforcement vertical et d’extension horizontale dans l’évolution des blockchains.
Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur l’optimisation du débit, visant à augmenter le TPS intra-chaîne, grâce à l’exécution différée (Deferred Execution) et à l’architecture de micro-machine virtuelle (Micro-VM) pour réaliser un traitement parallèle au niveau des transactions ou des comptes. Pharos Network, quant à lui, est un réseau blockchain L1 modulaire et entièrement parallèle, dont le mécanisme central de calcul parallèle est nommé « Rollup Mesh ». Cette architecture, via la collaboration entre le réseau principal et des réseaux de traitement spéciaux (SPNs), prend en charge plusieurs environnements de machines virtuelles (EVM et Wasm), et intègre des technologies avancées comme les preuves à connaissance nulle (ZK) et les environnements d'exécution fiables (TEE).
Analyse du mécanisme de calcul parallèle de Rollup Mesh :
-
Traitement en pipeline asynchrone sur tout le cycle de vie (Full Lifecycle Asynchronous Pipelining) : Pharos découple les différentes phases de la transaction (consensus, exécution, stockage) et les traite de façon asynchrone, permettant à chaque phase de s’exécuter indépendamment et en parallèle, améliorant ainsi l’efficacité globale.
-
Exécution parallèle double VM (Dual VM Parallel Execution) : Pharos prend en charge les deux environnements de machines virtuelles EVM et WASM, permettant aux développeurs de choisir l’environnement adapté à leurs besoins. Cette architecture double VM améliore non seulement la flexibilité du système, mais aussi les capacités de traitement via l’exécution parallèle.
-
Réseaux de traitement spéciaux (SPNs) : Les SPNs sont des composants clés de l’architecture Pharos, similaires à des sous-réseaux modulaires spécialisés dans le traitement de tâches ou applications spécifiques. Grâce aux SPNs, Pharos peut réaliser une allocation dynamique des ressources et un traitement parallèle des tâches, renforçant davantage 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 (PBFT, PoS, PoA), et assure le partage de sécurité et l’intégration des ressources entre le réseau principal et les SPNs via un protocole de restaking.
En outre, Pharos reconstruit son modèle d’exécution au niveau du moteur de stockage grâce à des arbres Merkle multi-versions, au codage delta (Delta Encoding), à l’adressage par version (Versioned Addressing) et à la descente ADS (ADS Pushdown), lançant ainsi un moteur de stockage haute performance natif pour blockchains, Pharos Store, capable de traitements rapides, à faible latence et fortement vérifiables.
En somme, l’architecture Rollup Mesh de Pharos, grâce à sa conception modulaire et à ses mécanismes de traitement asynchrone, atteint une capacité de calcul parallèle haute performance. En tant que coordinateur de parallélisme entre Rollups, Pharos n’est pas un optimiseur d’exécution parallèle intra-chaîne, mais utilise les SPNs pour supporter des tâches d’exécution hétérogènes et personnalisées.
Au-delà de Monad, MegaETH et Pharos, nous observons également des projets explorant l’application de l’accélération GPU au calcul parallèle EVM, complétant utilement l’écosystème parallèle EVM et servant d’expériences avant-gardistes. Reddio et GatlingX illustrent deux directions emblématiques :
-
Reddio est une plateforme haute performance combinant zkRollup et une architecture d’exécution parallèle GPU. Son cœur réside dans la reconstruction du flux d’exécution EVM, utilisant la planification multithread, le stockage d’état asynchrone et l’accélération GPU par lots de transactions, réalisant une parallélisation native au niveau de l’exécution. Il présente une granularité de parallélisme au niveau des transactions et des opérations (exécution multithread des opcodes). Sa conception inclut le traitement par lot multithread, 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 sur le traitement parallèle au niveau de l’exécution, mais diffère par sa refonte du moteur d’exécution via l’architecture GPU parallèle, spécialement conçu pour des scénarios à fort débit et intensifs en calcul (comme l’inférence IA). Un SDK est déjà disponible, proposant des modules d’exécution intégrables.
-
GatlingX se qualifie lui-même de « GPU-EVM », proposant une architecture encore plus radicale, cherchant à migrer le modèle d’exécution séquentielle traditionnel de l’EVM vers un environnement nativement parallèle du GPU. Son mécanisme central consiste à compiler dynamiquement le bytecode EVM en tâches parallèles CUDA, exécutant le flux d’instructions via les nombreux cœurs du GPU, brisant ainsi le goulot d’étranglement séquentiel de l’EVM à son niveau le plus fondamental. Il présente une granularité de parallélisme au niveau des instructions (Instruction-Level Parallelism, ILP). Comparé au parallélisme au niveau des transactions/comptes de Monad / MegaETH, le mécanisme de GatlingX relève d’une optimisation au niveau des instructions, proche d’une refonte complète du moteur de la machine virtuelle. Actuellement au stade conceptuel, un livre blanc et des schémas architecturaux ont été publiés, mais aucun SDK ni mainnet n’est disponible.
Artela propose quant à lui une philosophie parallèle différente. En introduisant l’architecture EVM++ et la machine virtuelle WebAssembly (WASM), il permet aux développeurs de conserver la compatibilité EVM tout en ajoutant dynamiquement et en exécutant des extensions sur la chaîne via le modèle de programmation Aspect. Il prend la granularité au niveau des appels de contrat (Fonction / Extension) comme unité minimale de parallélisme, permettant d’injecter des modules Extension (similaires à des « middlewares plug-and-play ») pendant l’exécution des contrats EVM, assurant découplage logique, appels asynchrones et exécution parallèle au niveau des modules. Il met davantage l’accent sur la composable et l’architecture modulaire au niveau de l’exécution, offrant une nouvelle piste pour les futures applications complexes et modulaires.
Trois : Blockchains à architecture parallèle native – refondre l’entité d’exécution de la VM
Le modèle d’exécution EVM d’Ethereum a adopté dès sa conception une architecture monofil séquentielle « ordre total des transactions + exécution sérielle », visant à garantir la déterminisme et la cohérence des changements d’état parmi tous les nœuds du réseau. Cependant, cette architecture présente un goulot d’étranglement inhérent, limitant le débit et l’évolutivité du système. En comparaison, des blockchains à architecture de calcul parallèle native comme Solana (SVM), MoveVM (Sui, Aptos) et Sei v2 (basé sur Cosmos SDK) sont conçues dès l’origine pour l’exécution parallèle, offrant les avantages suivants :
-
Modèles d’état naturellement séparés : Solana utilise un mécanisme de verrouillage explicite des comptes, MoveVM introduit un modèle de propriété d’objets, Sei v2 classe les transactions par type pour permettre une détection statique des conflits, autorisant une planification concurrente au niveau des transactions ;
-
VM optimisée pour la concurrence : le moteur Sealevel de Solana prend nativement en charge l’exécution multithread ; MoveVM peut analyser statiquement le graphe de concurrence ; Sei v2 intègre un moteur de matching multithread et un module VM parallèle.
Certes, ces blockchains parallèles natives font face à des défis de compatibilité écosystémique. Les architectures non-EVM nécessitent souvent de nouveaux langages (Move, Rust) et chaînes d’outils, imposant un coût de migration aux développeurs ; de plus, ils doivent maîtriser de nouveaux concepts comme les modèles d’accès à l’état, les limitations de concurrence et le cycle de vie des objets, augmentant le seuil de compréhension et les exigences du paradigme de développement.
3.1 Principe du moteur parallèle Sealevel de Solana et de la famille SVM
Le modèle d’exécution Sealevel de Solana est un mécanisme de planification parallèle au niveau des comptes, constituant le moteur central permettant l’exécution parallèle des transactions intra-chaîne. Via un mécanisme de « déclaration explicite des comptes + planification statique + exécution multithread », il atteint une concurrence performante au niveau des contrats intelligents. Sealevel est le premier modèle d’exécution à avoir réussi à mettre en œuvre une planification concurrente intra-chaîne en production, influençant de nombreux projets parallèles ultérieurs, servant de référence pour la conception de blockchains Layer1 hautes performances.
Mécanismes clés :
1. Déclaration explicite des accès aux comptes (Account Access Lists) : chaque transaction doit déclarer les comptes qu’elle lit/écrit. Le système juge ainsi s’il existe des conflits d’état entre transactions.
2. Détection des conflits et planification multithread
-
Si deux transactions n'accèdent à aucun compte commun → elles peuvent s’exécuter en parallèle ;
-
S’il y a conflit → elles s’exécutent en série selon l’ordre de dépendance ;
-
Le planificateur attribue les transactions aux différents threads selon le graphe de dépendance.
3. Contexte d’exécution isolé (Program Invocation Context) : chaque appel de contrat s’exécute dans un contexte isolé, sans pile partagée, évitant les interférences entre appels.
Sealevel est le moteur de planification parallèle de Solana, tandis que SVM est l’environnement d’exécution de contrats intelligents construit sur Sealevel (utilisant la VM BPF). Ensemble, ils forment la base technique du système parallèle haute performance de Solana.
Eclipse est un projet déployant la VM Solana sur des chaînes modulaires (comme un L2 Ethereum 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 sortir la couche d’exécution de Solana (Sealevel + SVM) de la blockchain principale pour l’intégrer dans une architecture modulaire, rendant le « modèle de concurrence extrêmement puissant de Solana » disponible comme service de couche d’exécution (Execution Layer-as-a-Service). Par conséquent, Eclipse appartient aussi à la catégorie du calcul parallèle.
La voie de Neon est différente : elle fait fonctionner EVM dans l’environnement SVM / Sealevel. Elle construit une couche d’exécution compatible EVM, permettant aux développeurs d’utiliser Solidity pour créer des contrats exécutés dans l’environnement SVM, mais utilise SVM + Sealevel pour la planification. Neon relève davantage du domaine des blockchains modulaires, sans insister sur l’innovation du calcul parallèle.
En résumé, Solana et SVM reposent sur le moteur d’exécution Sealevel. La philosophie de planification de Solana ressemble à celle d’un noyau système : rapide à exécuter, mais relativement peu flexible. C’est une blockchain publique native à haute performance et parallèle.
3.2 Architecture MoveVM : pilotée par les ressources et les objets
MoveVM est une machine virtuelle de contrats intelligents conçue pour la sécurité des ressources sur la chaîne et l’exécution parallèle. Son langage central, Move, initialement développé par Meta (ex-Facebook) pour le projet Libra, repose sur la notion que « les ressources sont des objets ». Tous les états sur la chaîne existent sous forme d’objets, possédant une propriété et un cycle de vie bien définis. Cela permet à MoveVM d’analyser au moment de la compilation si des transactions risquent des conflits d’état, réalisant ainsi une planification parallèle statique au niveau des objets. Cette approche est largement utilisée par des blockchains parallèles natives comme Sui et Aptos.
Modèle de propriété des objets de Sui
La capacité parallèle de Sui découle de son modèle d’état unique et de son mécanisme d’analyse statique au niveau du langage. Contrairement aux blockchains traditionnelles utilisant un arbre d’état global, Sui construit un modèle d’état centré sur les « objets » (modèle objet-centré), associé au système de types linéaires de MoveVM, rendant la planification parallèle déterministe dès la compilation.
-
Le modèle objet (Object Model) est la base de l’architecture parallèle de Sui. Tous les états sur la chaîne sont abstraits en objets indépendants (Object), chacun doté d’un ID unique, d’un propriétaire clair (compte ou contrat) et d’une définition de type. Ces objets n’ont pas d’état partagé, assurant une isolation naturelle. Lors d’un appel de contrat, les objets concernés doivent être explicitement déclarés, évitant ainsi les problèmes de couplage d’état présents dans l’arbre d’état global des blockchains traditionnelles. Cette conception divise l’état en unités indépendantes, rendant la concurrence faisable structurellement.
-
L’analyse statique de propriété (Static Ownership Analysis) est un mécanisme d’analyse compilateur permis par le système de types linéaires du langage Move. Il permet au système, avant même l’exécution, de déduire via la propriété des objets quelles transactions n’auront pas de conflits d’état, et donc de les planifier en parallèle. Comparé à la détection et au rollback en temps réel, ce mécanisme statique améliore l’efficacité tout en réduisant fortement la complexité de planification, clé de sa capacité à atteindre un débit élevé et un traitement parallèle déterministe.
Sui segmente l’espace d’état par objets et combine l’analyse statique de propriété pour réaliser une exécution parallèle au niveau des objets, à faible coût et sans rollback. Comparé à l’exécution sérielle ou à la détection en temps réel des blockchains traditionnelles, Sui améliore nettement l’efficacité d’exécution, la déterminisme du système et l’utilisation des ressources.
Mécanisme d’exécution Block-STM d’Aptos
Aptos est une blockchain Layer1 haute performance basée sur le langage Move, dont la capacité parallèle provient principalement de son cadre propriétaire Block-STM (Block-level Software Transactional Memory). Contrairement à la stratégie de Sui axée sur la « parallélisation statique à la compilation », Block-STM relève d’un mécanisme de planification dynamique de type « concurrence optimiste en temps réel + rollback en cas de conflit », adapté aux jeux de transactions aux dépendances complexes.
Block-STM divise l’exécution des transactions d’un bloc en trois phases :
-
Exécution concurrente optimiste (Speculative Execution) : toutes les transactions sont présumées sans conflit, exécutées en parallèle sur plusieurs threads, et leurs accès à l’état (ensembles de lecture/écriture) sont enregistrés.
-
Détection et validation des conflits (Validation Phase) : le système valide les résultats ; si deux transactions ont un conflit lecture-écriture (ex : Tx1 lit un état modifié par Tx2), l’une d’elles est annulée.
-
Retrait et réexécution des transactions en conflit (Retry Phase) : les transactions en conflit sont replanifiées jusqu’à ce que leurs dépendances soient résolues, formant finalement une séquence valide et déterministe d’état final.
Block-STM est un modèle d’exécution dynamique de type « parallélisme optimiste + retry », adapté aux scénarios de traitement par lots de transactions complexes et denses en état, constituant le cœur du calcul parallèle d’Aptos pour construire une blockchain publique hautement généraliste et à fort débit.
Solana incarne l’école de l’ingénierie de planification, proche d’un « noyau système », idéal pour les transactions fréquentes à frontières d’état claires et contrôlables, avec un style d’ingénieur matériel, visant à faire tourner la chaîne comme du matériel (exécution parallèle de qualité matérielle) ; Aptos représente l’école de tolérance aux fautes système, proche d’un « moteur de concurrence de base de données », adapté aux systèmes de contrats fortement couplés et aux chaînes d’appels complexes ; Sui est l’école de la sécurité compilée, proche d’une « plateforme linguistique orientée ressource », adaptée aux applications où les actifs sont séparés et les compositions claires. Aptos et Sui relèvent de l’ingénierie logicielle, cherchant à faire fonctionner la chaîne de manière sûre comme un logiciel (sécurité des ressources de qualité logicielle). Les trois incarnent différentes voies techniques de calcul parallèle Web3 selon leurs philosophies respectives.
3.3 Extensibilité parallèle basée sur Cosmos SDK
Sei V2 est une blockchain publique haute performance destinée aux transactions, construite sur Cosmos SDK. Sa capacité parallèle se manifeste principalement dans deux aspects : un moteur de matching parallèle (Parallel Matching Engine) et des optimisations d’exécution parallèle au niveau de la machine virtuelle, visant à servir des scénarios transactionnels fréquents et à faible latence, comme les DEX à carnet d’ordres ou les infrastructures d’échange sur chaîne.
Mécanismes parallèles principaux :
-
Moteur de matching parallèle : Sei V2 introduit des chemins d’exécution multithread dans la logique de matching, découplant le carnet d’ordres et la logique de matching au niveau des threads, permettant de traiter en parallèle les tâches de matching entre plusieurs marchés (paires de trading), évitant ainsi le goulot d’étranglement monofil.
-
Optimisation de concurrence au niveau de la VM : Sei V2 construit un environnement CosmWasm capable d’exécution concurrente, permettant à certains appels de contrats de s’exécuter en parallèle s’il n’y a pas de conflit d’état, combiné à un mécanisme de classification des types de transactions pour un meilleur contrôle du débit.
-
Consensus parallèle coordonné avec la planification de la couche d’exécution : introduction du mécanisme de consensus « Twin-Turbo », renforçant le découplage entre la couche de consensus et la couche d’exécution pour améliorer l’efficacité globale du traitement des blocs.
3.4 Fuel, le reformulateur du modèle UTXO
Fuel est une couche d’exécution haute performance conçue selon l’architecture modulaire d’Ethereum. Son mécanisme parallèle principal repose sur un modèle UTXO amélioré (Unspent Transaction Output). Contrairement au modèle de comptes d’Ethereum, Fuel utilise une structure UTXO pour représenter les actifs et l’état, bénéficiant naturellement d’une isolation d’état facilitant la détermination des transactions pouvant s’exécuter en parallèle en toute sécurité. De plus, Fuel introduit son propre langage de contrats intelligents Sway (similaire à Rust), combiné à des outils d’analyse statique, permettant de déterminer les conflits d’entrée avant l’exécution et ainsi d’assurer une planification parallèle efficace et sécurisée au niveau des transactions. C’est une alternative modulaire et performante à la couche d’exécution EVM.
Quatre : Modèle Actor – un nouveau paradigme d’exécution concurrente d’agents intelligents
Le modèle Actor est un paradigme d’exécution parallèle où l’unité est le processus agent (Agent ou Process). Contrairement au calcul synchrone sur état global traditionnel (scénarios de « calcul parallèle intra-chaîne » comme Solana/Sui/Monad), il met l’accent sur le fait que chaque agent possède un état et un comportement indépendants, communiquant et étant planifié par messages asynchrones. Dans cette architecture, le système blockchain peut exécuter simultanément un grand nombre de processus découplés, offrant une évolutivité exceptionnelle et une tolérance aux fautes asynchrone. Des projets représentatifs incluent AO (Arweave AO), ICP (Internet Computer) et Cartesi, qui poussent l’évolution de la blockchain d’un moteur d’exécution vers un « système d’exploitation sur chaîne », fournissant une infrastructure native pour les agents IA, les interactions multitâches et l’orchestration de logiques complexes.
Bien que le modèle Actor partage certaines caractéristiques superficielles (comme la parallélisation, l’isolation d’état, le traitement asynchrone) avec le sharding, il représente fondamentalement une voie technologique et une philosophie système totalement différentes. Le modèle Actor souligne le « calcul parallèle asynchrone multi-processus », chaque agent (Actor) fonctionnant indépendamment, maintenant son propre état, interagissant via des messages ; tandis que le sharding est un mécanisme de « découpage horizontal de l’état et du consensus », divisant la blockchain entière en plusieurs sous-systèmes indépendants (Shard). Le modèle Actor ressemble davantage à un « système d’exploitation d’agents distribués » dans le monde Web3, alors que le sharding est une solution de mise à l’échelle structurelle de la capacité de traitement transactionnel. Les deux réalisent la parallélisation, mais partent de points, visent des objectifs et adoptent des architectures différentes.
4.1 AO (Arweave), un supercalculateur parallèle au-dessus de la couche de stockage
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Articles connexes
Huobi Growth Academy | Étude approfondie sur le calcul parallèle dans Web3 : la voie ultime vers l'extension native
Le prochain plateforme souveraine d'exécution du monde Web3 naîtra probablement de cette lutte parallèle au sein de la chaîne.
L'ère de l'extension du Bitcoin est arrivée
StarkWare a un énorme potentiel pour démontrer sa force à l'ère du OP_CAT de Bitcoin.
La comptabilité économique du scaling Ethereum : est-il judicieux de laisser la majeure partie des revenus de séquençage aux L2 ?
Si vous pensez que la valeur à long terme de l'ETH réside dans les droits réseau au sein d'un protocole largement utilisé, alors il est nécessaire de mettre en œuvre une accumulation de valeur.
Les réseaux de couche 2 seront-ils la solution finale pour l'extension de Bitcoin ?
Un article détaillant les solutions de couche 2 telles que les sidechains, le réseau Lightning, RGB et les rollups, ainsi que des propositions populaires au sein de la communauté centrale de Bitcoin comme Drivechain et Spacechain.
La course à l'extension : OP, ZKRU et la nouvelle DA, qui sera le roi ?
Dans certains cas, les L1 et L2 peuvent effectuer des échanges d'informations arbitraires, ce que l'OP ne peut pas faire strictement parlant.
Optimism VS ZK : Quelle solution Rollup sera la plus performante ?
Pour l'instant, nous ne pouvons conclure que les couches 2 joueront un rôle important pour rendre Ethereum plus évolutif, mais il est impossible de déterminer clairement quelle solution de Rollup est supérieure.
Cobo Ventures : Analyse approfondie du scaling hors chaîne
Comment augmenter le débit et la vitesse des transactions sur une blockchain tout en préservant la décentralisation et la sécurité ?
Recherche Hotcoin｜L’ère DeFi sans seuil d’entrée est arrivée : analyse et observation des secteurs de l’abstraction et des intentions
Les nouvelles technologies d’« abstraction » et d’« intention » émergentes dans le domaine de la blockchain visent à éliminer les obstacles à l’adoption du Web3 en simplifiant les interactions multichaînes et en restructurant la logique des transactions utilisateur. Elles pourraient ainsi devenir un moteur clé de la généralisation massive des blockchains, mais font encore face à de multiples défis, notamment en matière de mise en œuvre technique, de collaboration au sein de l’écosystème, de gouvernance économique et de conformité réglementaire.
Le prochain champ de bataille trillionnaire des actifs réels (RWA) : comment le fondateur de Booking, en partenariat avec Staynex, repense la liquidité des actifs hôteliers et touristiques grâce à une « plateforme touristique sur chaîne ».
La réponse fournie par Staynex pourrait bien constituer le meilleur exemple de la voie menant les RWA à l’adoption généralisée.
Académie Huobi | Rapport approfondi sur les contrats actions : le prochain champ de bataille des dérivés blockchain, évalué à mille milliards de dollars
Les contrats perpétuels sur actions se trouvent actuellement à un stade critique de percée, passant du zéro à l’un.
