Web3 Parallel Computing Track Panorama : la meilleure solution pour le scaling natif ?

Auteur : 0xjacobzhao et ChatGPT 4oLe

« trilemme de la blockchain » de la « sécurité », de la « décentralisation » et de l'"évolutivité » de la blockchain révèle le compromis essentiel dans la conception des systèmes blockchain, c’est-à-dire qu’il est difficile pour les projets blockchain d’atteindre « une sécurité extrême, tout le monde peut participer, et un traitement à grande vitesse » en même temps. En réponse à l’éternel sujet de l'« évolutivité », les principales solutions de mise à l’échelle de la blockchain sur le marché sont divisées selon des paradigmes, notamment :

• Scaling amélioré par l’exécution : Améliore les capacités d’exécution in situ, telles que le parallélisme, le GPU et le multicœur
• Mise à l’échelle isolée de l’état : Répartition horizontale de l’état/de la partition, par exemple, shards, UTXO et multi-sous-réseaux
• Mise à l’échelle externalisée hors chaîne : Mise en place de l’exécution hors chaîne, comme les rollups, Découplage
de la structure du coprocesseur et
• de l’AD Mise à l’échelle : Architecture modulaire et fonctionnement collaboratif, tel que chaîne de modules, séquenceur partagé, Rollup Mesh
• Mise à l’échelle simultanée asynchrone : Modèle d’acteur, isolation de processus, pilotée par message, telle qu’agent, chaîne asynchrone multithread

  La solution de mise à l’échelle de la blockchain comprend : le calcul parallèle sur la chaîne, le rollup, le sharding, le module DA, la structure modulaire, le système d’acteur, la compression à l’épreuve zk, l’architecture sans état, etc., couvrant plusieurs niveaux d’exécution, d’état, de données et de structure, et constitue un système de mise à l’échelle complet de « collaboration multicouche et de combinaison de modules ». Cet article se concentre sur les méthodes de mise à l’échelle qui intègrent l’informatique parallèle.

  Le parallélisme intra-chaîne, qui se concentre sur l’exécution parallèle de transactions/instructions intra-bloc. Selon le mécanisme parallèle, ses méthodes de mise à l’échelle peuvent être divisées en cinq catégories, chacune représentant une poursuite de performance, un modèle de développement et une philosophie d’architecture différents, et la granularité parallèle devient de plus en plus fine, l’intensité du parallélisme est de plus en plus élevée, la complexité de l’ordonnancement est de plus en plus élevée, et la complexité de la programmation et la difficulté de mise en œuvre sont également de plus en plus élevées.

  • Au niveau du compte : Représente le projet
  • Niveau de l’objet : Représente le projet Niveau Sui
  • Transaction : Représente le projet Monad, au niveau de l’appel Aptos
  • / MicroVM : Niveau d’instruction MegaETH
  :
  • GatlingX

  Le modèle de concurrence asynchrone off-chain, représenté par le modèle Actor / Actor Model, appartient à un autre paradigme de calcul parallèle, en tant que système de messages inter-chaînes/asynchrones (modèle de synchronisation sans blocs), chaque agent s’exécute indépendamment en tant que « processus agent », messages asynchrones en mode parallèle, pilotés par événements, sans ordonnancement synchrone, projets représentatifs tels que AO, ICP, Cartesi, etc.

  Le schéma bien connu de cumul ou de mise à l’échelle des partitions appartient au mécanisme de simultanéité au niveau du système, et non au calcul parallèle intra-chaîne. Ils réalisent une mise à l’échelle en « exécutant plusieurs chaînes/domaines d’exécution en parallèle », plutôt qu’en augmentant le parallélisme au sein d’un seul bloc/machine virtuelle. Ce type de solution de mise à l’échelle n’est pas l’objet de cet article, mais nous l’utiliserons tout de même pour comparer les similitudes et les différences dans les concepts architecturaux.

  

  2. Chaîne d’amélioration parallèle EVM : Briser la limite de performance en matière de compatibilité

  Depuis le développement de l’architecture de traitement en série d’Ethereum, il a subi plusieurs séries de tentatives de mise à l’échelle telles que le sharding, le rollup et l’architecture modulaire, mais le goulot d’étranglement du débit de la couche d’exécution n’a toujours pas été fondamentalement brisé. Mais dans le même temps, EVM et Solidity restent les plateformes de contrats intelligents avec le plus de développeurs et de potentiel écologique. Par conséquent, la chaîne d’amélioration parallèle EVM devient une direction importante pour un nouveau cycle de mise à l’échelle et d’évolution en tant que voie clé qui prend en compte 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, à partir de l’exécution différée et de la décomposition d’état respectivement, pour construire une architecture de traitement parallèle EVM pour des scénarios de concurrence élevée et à haut débit.

  Monad est une blockchain de couche 1 haute performance repensée pour la machine virtuelle Ethereum (EVM), basée sur le concept parallèle de base du pipelining, avec une exécution asynchrone au niveau de la couche de consensus et une concurrence optimiste au niveau de la couche d’exécution Exécution parallèle) 。 De plus, au niveau des couches de consensus et de stockage, Monad a introduit le protocole BFT haute performance (MonadBFT) et un système de base de données dédié (MonadDB) respectivement pour réaliser une optimisation de bout en bout.

  Le pipelining

  est le concept de base de l’exécution parallèle de Monad, et son idée centrale est de diviser le processus d’exécution de la blockchain en plusieurs étapes indépendantes, et de traiter ces étapes en parallèle pour former une architecture de pipeline tridimensionnelle, chaque étape s’exécutant sur des threads ou des cœurs indépendants pour réaliser un traitement simultané entre blocs. Il en résulte une augmentation du débit et une réduction de la latence. Ces étapes sont les suivantes : Proposition, Consensus, Exécution et Validation.

  Exécution asynchrone : consensus : l’exécution est découplée de manière asynchroneSur

  les chaînes traditionnelles, le consensus et l’exécution des transactions sont souvent des processus synchrones, et ce modèle en série limite considérablement l’évolutivité des performances. Monad implémente la couche de consensus asynchrone, la couche d’exécution asynchrone et le stockage asynchrone par le biais d’une « exécution asynchrone ». Réduisez considérablement le temps de bloc et la latence de confirmation, ce qui rend le système plus résilient, le traitement plus segmenté et l’utilisation des ressources.

  Conception de base :

  le
  • processus de consensus (couche de consensus) est uniquement responsable du tri des transactions et n’exécute pas la logique contractuelle.
  • Le processus d’exécution (couche d’exécution) est déclenché de manière asynchrone une fois le consensus terminé.
  • Une fois le consensus terminé, il entrera immédiatement dans le processus de consensus du bloc suivant, sans attendre la fin de l’exécution.

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

  adopte un modèle strictement sériel pour l’exécution des transactions afin d’éviter les conflits d’état. Monad, quant à elle, adopte une stratégie d'« exécution parallèle optimiste » pour augmenter considérablement la vitesse de traitement des transactions.

  Mécanisme d’exécution :

  • Monad exécute toutes les transactions en parallèle, en supposant que la plupart des transactions sont sans état et sans conflit.
  • Exécutez également un « détecteur de conflits » pour vérifier si le même état (par exemple, les conflits de lecture/écriture) est accessible entre les transactions.
  • Si un conflit est détecté, la transaction en conflit est sérialisée et réexécutée pour s’assurer que l’état est correct.

  Monad a choisi une voie compatible : déplacer le moins de règles EVM possible, réaliser le parallélisme en différant l’état d’écriture et en détectant dynamiquement les conflits pendant l’exécution, ce qui ressemble plus à une version performance d’Ethereum, avec un niveau de maturité qui facilite la migration vers l’écosystème EVM, et est un accélérateur parallèle dans le monde EVM.

  La résolution du mécanisme de calcul parallèle de MegaETH

  est différente de celle du positionnement L1 de Monad, et MegaETH est positionné comme une couche d’exécution parallèle haute performance modulaire compatible EVM, qui peut être utilisée comme une chaîne publique L1 indépendante, comme une couche d’amélioration de l’exécution ou un composant modulaire sur Ethereum. Son objectif principal est de déconstruire la logique de compte, l’environnement d’exécution et l’isolation d’état en la plus petite unité pouvant être planifiée indépendamment pour obtenir une exécution à haute simultanéité et une capacité de réponse à faible latence au sein de la chaîne. L’innovation clé proposée par MegaETH est que l’architecture Micro-VM + State Dependency DAG (graphe de dépendance d’état dirigé et acyclique) et le mécanisme de synchronisation modulaire construisent conjointement un système d’exécution parallèle pour le « threading intra-chaîne ».

  MegaETH

  introduit le modèle d’exécution d'« une micro-VM par compte », qui « enchaîne » l’environnement d’exécution et fournit une unité d’isolation minimale pour la planification parallèle. Ces machines virtuelles communiquent entre elles par le biais d’une messagerie asynchrone au lieu d’appels synchrones, et un grand nombre de machines virtuelles peuvent être exécutées indépendamment, stockées indépendamment et naturellement parallèles.

  DAG State Dependency : un mécanisme de planification piloté par des graphes

  MegaETH a construit un système de planification DAG basé sur la relation d’accès à l’état du compte, et le système maintient un graphique de dépendance global en temps réel, et quels comptes sont modifiés et quels comptes sont lus pour chaque transaction sont tous modélisés en dépendances. Les transactions sans conflit peuvent être exécutées directement en parallèle, et les transactions dépendantes seront planifiées et triées en série ou différées dans l’ordre topologique. Les graphes de dépendances garantissent la cohérence de l’état et l’absence de doublons dans les écritures lors de l’exécution parallèle.

  Le

  mécanisme d’exécution et de rappel asynchrone

  MegaETH est construit sur le paradigme de programmation asynchrone, similaire au passage de messages asynchrones du modèle d’acteur, pour résoudre le problème des appels série EVM traditionnels. Les appels de contrat sont asynchrones (exécution non récursive), et lorsque le contrat A -> B -> C est appelé, chaque appel est asynchrone sans bloquer l’attente ; La pile d’appels est développée en un graphique d’appels asynchrone ; Traitement des transactions = traversée d’un graphe asynchrone + résolution de dépendances + ordonnancement parallèle.

  Dans l’ensemble, MegaETH brise le modèle traditionnel de machine d’état monothread EVM, implémente l’encapsulation de micro-machines virtuelles compte par compte, effectue la planification des transactions via des graphiques dépendants de l’état et remplace la pile d’appels synchrone par un mécanisme de messagerie asynchrone. Il s’agit d’une plate-forme de calcul parallèle qui est repensée à partir des dimensions complètes de la « structure de compte→ de l’architecture de planification → du processus d’exécution », fournissant une nouvelle idée au niveau du paradigme pour la construction d’un système on-chain haute performance de nouvelle génération.

  MegaETH a choisi la voie du refactoring : elle abstrait complètement les comptes et les contrats en VM indépendantes, et libère le potentiel ultime de parallélisme grâce à une planification d’exécution asynchrone. Théoriquement, MegaETH a un plafond parallèle plus élevé, mais il est également plus difficile de contrôler la complexité, et il s’agit plutôt d’un système d’exploitation super-distribué selon le concept Ethereum.

  

  Monad et MegaETH Les deux ont des concepts de conception différents du sharding : le sharding divise horizontalement la blockchain en plusieurs sous-chaînes indépendantes (shards), chacune d’entre elles étant responsable d’une partie des transactions et de l’état, brisant la limitation d’une seule chaîne et mettant à l’échelle au niveau de la couche réseau ; D’autre part, Monad et MegaETH maintiennent tous deux l’intégrité de la chaîne unique, en s’adaptant horizontalement uniquement au niveau de la couche d’exécution et en effectuant des percées d’optimisation en parallèle à la limite de la chaîne unique. Les deux représentent deux directions : le renforcement vertical et l’expansion horizontale dans le chemin d’expansion de la blockchain.

  Les projets de calcul parallèle tels que Monad et MegaETH se concentrent principalement sur le chemin d’optimisation du débit, avec pour objectif principal d’améliorer le TPS on-chain, et d’obtenir 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 est un réseau blockchain L1 parallèle modulaire et complet, et son système de calcul parallèle de base est appelé « Rollup Mesh ». Cette architecture prend en charge les environnements de machines multi-virtuelles (EVM et Wasm) grâce à la synergie du réseau principal et des réseaux de traitement spéciaux (SPN), et intègre des technologies avancées telles que les preuves à divulgation nulle de connaissance (ZK) et les environnements d’exécution de confiance (TEE).

  Analyse de calcul parallèle Rollup Mesh :

  1. Pipeline asynchrone tout au long du cycle de vie : Pharos découple les différentes étapes d’une transaction (telles que le consensus, l’exécution et le stockage) et adopte un traitement asynchrone afin que chaque étape puisse être réalisée indépendamment et en parallèle, améliorant ainsi l’efficacité globale du traitement.
  2. Exécution parallèle à double VM : Pharos prend en charge les environnements de machines virtuelles EVM et WASM, ce qui permet aux développeurs de choisir l’environnement d’exécution adapté à leurs besoins. Cette architecture à double VM augmente non seulement la flexibilité du système, mais augmente également le traitement des transactions par le biais d’une exécution parallèle.
  3. Réseaux de traitement spéciaux (SPN) : les SPN sont des composants clés de l’architecture Pharos, similaires à des sous-réseaux modulaires conçus pour gérer des types spécifiques de tâches ou d’applications. Avec les SPN, Pharos permet l’allocation dynamique des ressources et le traitement parallèle des tâches, améliorant ainsi l’évolutivité et les performances du système.
  4. Consensus modulaire et restaking : Pharos introduit un mécanisme de consensus flexible qui prend en charge plusieurs modèles de consensus (tels que PBFT, PoS, PoA), et permet un partage sécurisé et une intégration des ressources entre le réseau principal et les SPN via le protocole de retaking.

  En outre, Pharos reconstruit le modèle d’exécution à partir de la couche inférieure du moteur de stockage grâce à l’arbre de Merkle multiversion, à l’encodage Delta, à l’adressage versionné et à la technologie ADS Pushdown, et lance Pharos Store, un moteur de stockage haute performance pour la blockchain native, afin d’atteindre un débit élevé, une faible latence et de solides capacités de traitement vérifiables sur la chaîne.

  En général, l’architecture Rollup Mesh de Pharos atteint des capacités de calcul parallèle hautes performances grâce à une conception modulaire et à un mécanisme de traitement asynchrone.

  En plus des architectures d’exécution parallèle de Monad, MegaETH et Pharos, nous observons également qu’il existe certains projets sur le marché qui explorent la voie d’application de l’accélération GPU dans le calcul parallèle EVM, en tant que complément important et expérience de pointe à l’écosystème parallèle EVM. Parmi elles, Reddio et GatlingX sont deux directions représentatives :

  • Reddio est une plate-forme haute performance qui combine zkRollup et l’architecture d’exécution parallèle GPU, et son cœur réside dans la reconstruction du processus d’exécution EVM et la réalisation de la parallélisation native de la couche d’exécution grâce à la planification multithread, au stockage d’état asynchrone et à l’exécution accélérée par GPU de lots de transactions. Granularité parallèle au niveau de la transaction + niveau de l’opération (opcode d’exécution multithread). Il est conçu pour introduire l’exécution par lots multithread, le chargement d’état asynchrone et la logique de transaction de traitement parallèle GPU (EVM parallèle compatible CUDA). À l’instar de Monad / MegaETH, Reddio se concentre également sur le traitement parallèle au niveau de la couche d’exécution, à la différence que le moteur d’exécution est reconstruit par le biais d’une architecture parallèle GPU, conçue pour des scénarios à haut débit et à forte intensité de calcul tels que l’inférence d’IA. GatlingX,
  • qui s’appelle lui-même « GPU-EVM », propose une architecture plus radicale qui tente de migrer le modèle d'"exécution en série au niveau des instructions » des machines virtuelles EVM traditionnelles vers un environnement d’exécution parallèle natif GPU. Le mécanisme de base consiste à compiler dynamiquement le bytecode EVM dans des tâches parallèles CUDA, et à exécuter le flux d’instructions via le multicœur du GPU, afin de briser le goulot d’étranglement séquentiel de l’EVM au niveau le plus bas. Granularité parallèle qui appartient au parallélisme au niveau de l’instruction (ILP). Par rapport à la granularité parallèle « niveau transaction/compte » de Monad / MegaETH, le mécanisme de parallélisme de GatlingX appartient au chemin d’optimisation au niveau de l’instruction, qui est plus proche de la refactorisation sous-jacente du moteur de machine virtuelle. Il est actuellement en phase de conception, avec un livre blanc et une esquisse architecturale publiés, et pas encore de SDK ou de réseau principal.

  Artela propose un concept de design différencié et parallèle. Avec l’introduction de la machine virtuelle WASM (EVM++ architectureWebAssembly), les développeurs sont autorisés à ajouter et à exécuter dynamiquement des extensions sur la chaîne à l’aide du modèle de programmation Aspect tout en maintenant la compatibilité EVM. Il utilise la granularité d’invocation de contrat (Fonction/Extension) comme unité parallèle minimale, et prend en charge l’injection de modules d’extension (similaire à un « middleware enfichable ») lorsque le contrat EVM est en cours d’exécution, afin d’obtenir un découplage logique, une invocation asynchrone et une exécution parallèle au niveau du module. Une plus grande attention est accordée à la composabilité et à l’architecture modulaire de la couche d’exécution. Le concept fournit de nouvelles idées pour des applications multi-modules complexes à l’avenir.

  3. Chaîne d’architecture parallèle native : Le modèle d’exécution EVM d’Ethereum, l’ontologie d’exécution de la VM reconstruite

  ,

  a adopté une architecture monothread de « ordre complet des transactions + exécution en série » depuis le début de sa conception, visant à assurer la certitude et la cohérence des changements d’état pour tous les nœuds du réseau. Cependant, cette architecture présente un goulot d’étranglement naturel en termes de performances, limitant le débit et l’évolutivité du système. En revanche, les chaînes d’architecture de calcul parallèle natives telles que Solana (SVM), MoveVM (Sui, Aptos) et Sei v2 basées sur le SDK Cosmos sont conçues pour l’exécution parallèle à partir de la conception sous-jacente et présentent les avantages suivants :

  • Séparation naturelle des modèles d’état : Solana utilise un mécanisme de déclaration de verrouillage de compte, MoveVM introduit un modèle de propriété d’objet et Sei v2 est basé sur la classification du type de transaction. Le jugement de conflit statique est réalisé et la planification simultanée au niveau de la transaction est prise en charge.
  • Les machines virtuelles sont optimisées pour la concurrence : le moteur Sealevel de Solana prend en charge nativement l’exécution multithread ; MoveVM peut effectuer une analyse de graphe de simultanéité statique ; Sei v2 intègre un moteur de correspondance multithread avec un module VM parallèle.

  Bien sûr, ce type de chaîne parallèle indigène est également confronté au défi de la compatibilité écologique. Les architectures non EVM nécessitent généralement de nouveaux langages de développement (tels que Move et Rust) et des chaînes d’outils, ce qui entraîne certains coûts de migration pour les développeurs. En outre, les développeurs doivent maîtriser une série de nouveaux concepts tels que les modèles d’accès avec état, les limites de simultanéité, les cycles de vie des objets, etc., qui mettent en avant des exigences plus élevées pour la compréhension des seuils et des paradigmes de développement.

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

  Le modèle d’exécution Sealevel de Solana est un mécanisme d’ordonnancement parallèle de compte, qui est le moteur central utilisé par Solana pour réaliser l’exécution de transactions parallèles au sein de la chaîne, et permet d’obtenir une concurrence haute performance au niveau du contrat intelligent grâce au mécanisme de « déclaration de compte + ordonnancement statique + exécution multithread ». Sealevel est le premier modèle d’exécution dans le domaine de la blockchain à mettre en œuvre avec succès l’ordonnancement simultané intra-chaîne dans un environnement de production, et ses idées architecturales ont influencé de nombreux projets de calcul parallèle ultérieurs, et constitue un paradigme de référence pour la conception parallèle de couche 1 haute performance.

  Mécanisme de base :

  1. Listes d’accès au compte explicites : Chaque transaction doit déclarer le compte concerné (lecture/écriture) lors de la soumission, et le système déterminera s’il y a un conflit d’état entre les transactions.

  2. Détection des conflits et planification multithread

  • S’il n’y a pas d’intersection entre les ensembles de comptes auxquels les deux transactions accèdent→ elles peuvent être exécutées en parallèle ;
  • Il y a un conflit → l’exécution en série dans l’ordre dépendant ;
  • Le planificateur alloue les transactions à différents threads en fonction du graphe de dépendances.

  3. Contexte d’appel de programme : chaque appel de contrat s’exécute dans un contexte isolé sans pile partagée pour éviter les interférences entre appels.

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

  Eclipse est un projet qui déploie des machines virtuelles Solana sur des chaînes modulaires telles qu’Ethereum L2 ou Celestia, en exploitant le moteur d’exécution parallèle de Solana comme couche d’exécution de cumul. Eclipse est l’un des premiers projets à proposer de détacher la couche d’exécution Solana (Sealevel + SVM) du réseau principal Solana et de la migrer vers une architecture modulaire, et la sortie modulaire du « modèle d’exécution super concurrente » de Solana est Execution Layer-as-a-Service, donc Eclipse appartient également à la catégorie de l’informatique parallèle.

  L’itinéraire de Neon est différent, il introduit l’EVM pour opérer dans un environnement SVM / Sealevel. Les développeurs peuvent utiliser Solidity pour développer des contrats et les exécuter dans l’environnement SVM, mais l’exécution de la planification utilise SVM + Sealeve. Neon penche plus vers la catégorie des Blockchain modulaires que vers l’innovation informatique parallèle.

  Dans l’ensemble, Solana et les SVM s’appuient sur le moteur d’exécution Sealevel, et la philosophie de planification basée sur le système d’exploitation de Solana est similaire à celle du planificateur de noyau, qui est rapide mais relativement peu flexible. Il s’agit d’une chaîne publique native de calcul parallèle haute performance.

  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, et son langage de base, Move, a été développé à l’origine par Meta (anciennement Facebook) pour le projet Libra, mettant l’accent sur le concept de « les ressources sont des objets », et tous les états on-chain existent en tant qu’objets, avec une propriété et des cycles de vie clairs. Cela permet à MoveVM d’analyser s’il existe des conflits d’état entre les transactions pendant le temps de compilation, et de mettre en œuvre la planification parallèle statique au niveau de l’objet, qui est largement utilisée dans les chaînes publiques parallèles natives telles que Sui et Aptos.

  Les

  capacités de calcul parallèle de Sui proviennent de son approche unique de la modélisation d’état et de l’analyse statique au niveau du langage. Contrairement aux blockchains traditionnelles, qui utilisent des arbres d’état globaux, Sui a construit un modèle centré sur l’objet basé sur « l’objet », qui fonctionne avec le système de type linéaire de MoveVM pour faire de l’ordonnancement parallèle un processus déterministe qui peut être complété au moment de la compilation.

  • Le modèle objet est la base de l’architecture parallèle de Sui. Sui fait abstraction de tous les états de la chaîne en objets distincts, chacun avec un ID unique, un propriétaire clair (compte ou contrat) et une définition de type. Ces objets n’ont pas le même état les uns avec les autres et sont intrinsèquement isolés. Le contrat doit déclarer explicitement l’ensemble des objets concernés lorsqu’il est appelé, évitant ainsi le problème de couplage d’état de l’arbre d’état global traditionnel sur la chaîne. Cette conception divise l’état on-chain en plusieurs unités indépendantes, ce qui fait de l’exécution simultanée une prémisse de planification structurellement réalisable.
  • L’analyse statique de la propriété est un mécanisme d’analyse au moment de la compilation mis en œuvre avec le support du système de type linéaire du langage Move. Il permet au système de planifier l’exécution des transactions en parallèle en déduisant les transactions qui n’ont pas de conflits d’état grâce à la propriété de l’objet avant qu’elles ne soient exécutées. Par rapport à la détection des conflits et à l’annulation des environnements d’exécution traditionnels, le mécanisme d’analyse statique de Sui réduit considérablement la complexité de la planification tout en améliorant l’efficacité de l’exécution, ce qui est la clé pour obtenir un débit élevé et des capacités de traitement parallèle déterministes.

  Sui divise l’espace d’état objet par objet, combiné à une analyse de propriété au moment de la compilation, pour obtenir une exécution parallèle au niveau de l’objet à faible coût et sans retour en arrière. Par rapport à l’exécution en série ou à la détection d’exécution des chaînes traditionnelles, Sui a réalisé des améliorations significatives en termes d’efficacité d’exécution, de déterminisme du système et d’utilisation des ressources.

  Mécanisme

  d’exécution Block-STM d’AptosAptos

  est une blockchain de couche 1 haute performance basée sur le langage Move, et sa capacité d’exécution parallèle est principalement dérivée du cadre Block-STM (Block-level Software Transactional Memory) auto-développé. Contrairement à la stratégie de Sui de « parallélisme statique au moment de la compilation », Block-STM appartient au mécanisme d’ordonnancement dynamique de « concurrence optimiste au moment de l’exécution + annulation du conflit », qui convient pour traiter des ensembles de transactions avec des dépendances complexes.

  Block-STM divise l’exécution d’une transaction d’un bloc en trois étapes :

  • Exécution spéculative : toutes les transactions sont sans conflit par défaut avant l’exécution, et le système planifie les transactions en parallèle à plusieurs threads pour essayer de s’exécuter simultanément, et enregistre l’état du compte (jeu de lecture/écriture) auquel ils ont accédé.
  • Phase de validation : Le système vérifie le résultat de l’exécution : s’il y a un conflit de lecture-écriture entre deux transactions (par exemple, Tx1 lit l’état d’écriture par Tx2), l’une d’entre elles est annulée.
  • Phase de nouvelle tentative : les transactions conflictuelles seront replanifiées jusqu’à ce que leurs dépendances soient résolues et, finalement, toutes les transactions forment une séquence valide et déterministe de soumissions d’états.

  Block-STM est un modèle d’exécution dynamique de « parallélisme optimiste + restauration et nouvelles tentatives », qui convient aux scénarios de traitement par lots de transactions on-chain exigeants en termes d’état et logiquement complexes, et constitue le cœur de calcul parallèle permettant à Aptos de construire une chaîne publique à haut niveau de polyvalence et à haut débit.

  

  Solana est une école d’ingénierie de planification, plus comme un « noyau de système d’exploitation », adapté pour des limites d’état claires, un trading haute fréquence contrôlable, est un style d’ingénieur matériel, pour exécuter la chaîne comme du matériel (exécution parallèle de qualité matérielle) ; Aptos est un système tolérant aux pannes, qui ressemble davantage à un « moteur de concurrence de base de données », adapté aux systèmes contractuels avec un couplage d’état fort et des chaînes d’appels complexes. Aptos et Sui sont comme des ingénieurs en langage de programmation, et la sécurité des ressources de niveau logiciel représente le chemin de mise en œuvre technique de l’informatique parallèle Web3 sous différentes philosophies.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 est une chaîne publique transactionnelle haute performance basée sur le SDK Cosmos, et sa capacité de parallélisme se reflète principalement dans deux aspects : le moteur de correspondance multithread (Parallel Matching Engine) et l’optimisation de l’exécution parallèle de la couche de machine virtuelle, qui est conçue pour servir des scénarios de transaction on-chain à haute fréquence et à faible latence, tels que le DEX de carnet d’ordres, l’infrastructure d’échange on-chain, etc.

  Mécanisme de parallélisme de base :

  1. Moteur d’appariement parallèle : SEI V2 introduit un chemin d’exécution multithread dans la logique d’appariement des ordres, en divisant le carnet d’ordres en attente et la logique d’appariement au niveau du thread, de sorte que les tâches d’appariement entre plusieurs paires de trading peuvent être traitées en parallèle et éviter le goulot d’étranglement à un seul thread.
  2. Optimisation de la simultanéité au niveau de la machine virtuelle : Sei V2 construit un environnement d’exécution CosmWasm avec des capacités d’exécution simultanée, qui permet à certains appels de contrat de s’exécuter en parallèle sans conflits d’état, et coopère avec le mécanisme de classification des types de transaction pour obtenir un contrôle de débit plus élevé.
  3. Consensus parallèle et ordonnancement de la couche d’exécution : Le mécanisme de consensus dit « Twin-Turbo » est introduit pour renforcer le débit et le découplage entre la couche de consensus et la couche d’exécution, et améliorer l’efficacité globale du traitement des blocs.

  3.4 Modèle UTXO Reformer Fuel Fuel

  est une couche d’exécution haute performance conçue sur la base de l’architecture modulaire d’Ethereum, et son mécanisme de parallélisme de base est dérivé du 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 est intrinsèquement isolée par état, ce qui permet de déterminer facilement quelles transactions peuvent être exécutées en toute sécurité en parallèle. De plus, Fuel introduit son langage de contrat intelligent développé par ses soins, Sway (similaire à Rust), combiné à des outils d’analyse statique, pour déterminer les conflits d’entrée avant l’exécution des transactions, afin d’obtenir une planification parallèle efficace et sécurisée au niveau des transactions. Il s’agit d’une couche d’exécution alternative EVM qui équilibre performance et modularité.

  4. Modèle d’acteur : un nouveau paradigme d’exécution simultanée d’agents

  Le modèle d’acteur est un paradigme d’exécution parallèle basé sur l’agent ou le processus, qui est différent du calcul synchrone traditionnel de l’état global sur la chaîne (Solana/Sui/Monad et d’autres scénarios de « calcul parallèle sur la chaîne »), qui met l’accent sur le fait que chaque agent a un état et un comportement indépendants, et communique et planifie par le biais de messages asynchrones. Dans le cadre de cette architecture, le système on-chain peut être exécuté simultanément par un grand nombre de processus découplés les uns des autres, et présente une forte évolutivité et une tolérance aux pannes asynchrones. Parmi les projets représentatifs, citons AO (Arweave AO), ICP (Internet Computer) et Cartesi, qui sont à l’origine de l’évolution de la blockchain, qui passe d’un moteur d’exécution à un « système d’exploitation on-chain », fournissant une infrastructure native pour les agents d’IA, des interactions multitâches et une orchestration logique complexe.

  Bien que la conception du modèle d’acteur soit similaire à celle du sharding en termes de caractéristiques superficielles (par exemple, le parallélisme, l’isolation d’état et le traitement asynchrone), les deux 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 l’informatique asynchrone multiprocessus, où chaque agent s’exécute indépendamment, maintient l’état de manière indépendante et interagit de manière basée sur les messages. Le Sharding, quant à lui, est un mécanisme de « sharding horizontal d’état et de consensus », qui divise l’ensemble de la blockchain en plusieurs sous-systèmes (shards) qui traitent les transactions indépendamment. Les modèles d’acteur ressemblent davantage à un « système d’exploitation d’agent distribué » 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 on-chain. Les deux atteignent le parallélisme, mais ont des points de départ, des objectifs et des architectures d’exécution différents.

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

  est une plate-forme informatique décentralisée fonctionnant sur la couche de stockage permanente Arweave, avec pour 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 base de l’architecture :

  • Architecture de processus : Chaque agent est appelé un processus, avec un état indépendant, un planificateur indépendant et une logique d’exécution ;
  • Pas de structure blockchain : AO n’est pas une chaîne, mais une couche de stockage décentralisée + un moteur d’exécution multi-agents basé sur Arweave ;
  • Système de planification asynchrone des messages : les processus communiquent entre eux par le biais de messages, adoptent un modèle de fonctionnement asynchrone sans verrouillage et prennent naturellement en charge l’expansion simultanée.
  • Stockage permanent des états : tous les états de l’agent, les enregistrements de messages et les instructions sont enregistrés en permanence sur Arweave, ce qui garantit une auditabilité totale et une transparence décentralisée.
  • Agent-natif : il convient au déploiement de tâches complexes en plusieurs étapes (telles que des agents d’IA, des contrôleurs de protocole DePIN, des orchestrateurs de tâches automatiques, etc.), et peut construire un « coprocesseur d’IA on-chain ».

  AO emprunte la voie ultime de « l’architecture agent natif + pilote de stockage + sans chaîne », mettant l’accent sur la flexibilité et le découplage des modules, et est un « cadre de micro-noyau sur la chaîne construit au-dessus de la couche de stockage », avec la limite du système délibérément réduite, mettant l’accent sur l’informatique légère + la structure de contrôle composable.

  4.2 ICP (Internet Computer), une plate-forme d’hébergement Web3 full-stackICP

  est une plate-forme d’application Web3 native full-stack on-chain lancée par DFINITY, dans le but d’étendre la puissance de calcul on-chain aux expériences de type Web2, et de prendre en charge l’hébergement de services complets, la liaison de noms de domaine et l’architecture sans serveur.

  Caractéristiques de base de l’architecture :

  • Architecture de conteneur (conteneurs en tant qu’agents) : chaque conteneur est un agent s’exécutant sur une machine virtuelle Wasm avec des capacités indépendantes d’état, de code et de planification asynchrone ;
  • Système de consensus distribué de sous-réseau (sous-réseau) : l’ensemble du réseau se compose de plusieurs sous-réseaux, chacun d’entre eux conservant un ensemble de conteneurs et atteignant un consensus via le mécanisme de signature BLS.
  • Modèle d’appel asynchrone : Canister communique avec Canister par le biais de messages asynchrones, prend en charge l’exécution non bloquante et présente un parallélisme naturel.
  • Hébergement Web on-chain : Il prend en charge les contrats intelligents pour héberger directement les pages frontales, le mappage DNS natif et est la première plate-forme blockchain qui prend en charge les navigateurs pour accéder directement aux dApps ;
  • Le système dispose de fonctions complètes : il dispose d’API système telles que la mise à niveau à chaud sur la chaîne, l’authentification d’identité, l’aléatoire distribué et le minuteur, ce qui convient au déploiement complexe de services sur la chaîne.

  ICP choisit un paradigme de système d’exploitation composé d’une plate-forme lourde, d’un emballage intégré et d’un contrôle fort de la plate-forme, et dispose d’un « système d’exploitation blockchain » qui intègre le consensus, l’exécution, le stockage et l’accès, en mettant l’accent sur les capacités d’hébergement de services complets et en élargissant les limites du système à une plate-forme d’hébergement Web3 complète.

  De plus, les projets de calcul parallèle d’autres paradigmes de modèle d’acteur peuvent être référencés au tableau suivant :

  

  5. Résumé et perspectiveSur

  la base des différences entre l’architecture de machine virtuelle et le système de langage, les solutions de calcul parallèle blockchain peuvent être grossièrement divisées en deux catégories : la chaîne d’amélioration parallèle EVM et la chaîne d’architecture parallèle native (non-EVM).

  Sur la base du maintien de la compatibilité de l’écosystème EVM/Solidity, le premier atteint un débit plus élevé et des capacités de traitement parallèle grâce à une optimisation en profondeur de la couche d’exécution, ce qui convient aux scénarios qui souhaitent hériter des actifs Ethereum et des outils de développement et réaliser des percées en même temps en matière de performances.

  • Monad : Implémente un modèle d’exécution parallèle optimiste compatible avec EVM grâce à l’écriture différée et à la détection des conflits d’exécution, crée des graphiques de dépendances et planifie l’exécution une fois le consensus atteint.
  • MegaETH : Abstrait chaque compte/contrat dans une micro-VM indépendante, et implémente une planification parallèle au niveau du compte hautement découplée basée sur une messagerie asynchrone et des graphes dépendants de l’état.
  • Pharos : Construisez une architecture de maillage rollup pour réaliser un traitement parallèle au niveau du système entre les processus via des pipelines asynchrones et des modules SPN.
  • Reddio : Utilise l’architecture zkRollup + GPU pour accélérer le processus de vérification hors chaîne de zkEVM grâce à la génération SNARK par lots et améliorer le débit de vérification.

  Ce dernier se débarrasse complètement des limites de la compatibilité d’Ethereum et redessine le paradigme d’exécution de la machine virtuelle, du modèle d’état et du mécanisme de planification pour obtenir une concurrence native haute performance. Les sous-classes typiques comprennent :

  • Solana (SVM) : un modèle d’exécution parallèle au niveau du compte basé sur les revendications d’accès au compte et la planification de graphiques de conflits statiques ;
  • 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 au moment de la compilation et réalise le parallélisme au niveau de l’objet.
  • Sei V2 (route Cosmos SDK) : introduit un moteur de correspondance multithread et l’optimisation de la concurrence des machines virtuelles dans l’architecture Cosmos, qui convient aux applications transactionnelles à haute fréquence.
  • Fuel (architecture UTXO + Sway) : Parallélisme au niveau de la transaction grâce à l’analyse statique de l’ensemble des entrées UTXO, combinant une couche d’exécution modulaire avec un langage de contrat intelligent personnalisé Sway ;

  De plus, en tant que système parallèle plus généralisé, le modèle d’acteur construit un paradigme d’exécution sur la chaîne de « fonctionnement indépendant multi-agents + collaboration pilotée par message » par le biais d’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) : Création d’un système de micro-noyau asynchrone sur la chaîne basé sur l’exécution de l’agent piloté par le stockage persistant ;
  • ICP (Internet Computer) : utilise l’agent conteneurisé (Canister) comme la plus petite unité pour réaliser une exécution asynchrone et hautement évolutive grâce à la coordination des sous-réseaux.
  • Cartesi : Introduit le système d’exploitation Linux en tant qu’environnement de calcul hors chaîne pour fournir un chemin de vérification sur la chaîne pour des résultats de calcul fiables, adapté aux scénarios d’application complexes ou gourmands en ressources.

  Sur la base de la logique ci-dessus, nous pouvons résumer le schéma actuel de chaîne publique de calcul parallèle en une structure de classification comme le montre la figure suivante :

  

  D’un point de vue plus large, le sharding et le rollup (L2) se concentrent sur la mise à l’échelle horizontale par le biais du partitionnement d’état ou de l’exécution hors chaîne, tandis que les chaînes de calcul parallèles (par exemple, Monad, Sui, Solana) et les systèmes orientés acteurs (par exemple, AO, ICP) reconstruisent directement le modèle d’exécution et obtiennent un parallélisme natif au sein de la chaîne ou au niveau de la couche système. Le premier améliore le débit intra-chaîne grâce à des machines virtuelles multithread, des modèles d’objets, l’analyse des conflits de transactions, etc. Ce dernier prend le processus/agent comme unité de base et adopte des modes d’exécution asynchrones et pilotés par message pour réaliser un fonctionnement simultané multi-agents. En revanche, le sharding et les rollups ressemblent davantage à « répartir la charge sur plusieurs chaînes » ou à « externaliser hors chaîne », tandis que le modèle de chaîne parallèle et d’acteur « libère le potentiel de performance du moteur d’exécution lui-même », reflétant une évolution architecturale plus approfondie.

  Calcul parallèle vs architecture de partitionnement vs mise à l’échelle cumulative vs mise à l’échelle orientée acteur Comparaison du chemin

  

  Il convient de souligner que la plupart des chaînes d’architecture parallèle natives sont entrées dans la phase de lancement du réseau principal, bien que l’écosystème global des développeurs soit encore difficile à comparer avec le système Solidity du système EVM, mais les 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 auxquelles le marché accorde une grande attention.

  En revanche, bien que l’écosystème Ethereum Rollup (L2) soit entré dans le stade des « 10 000 chaînes à la fois » ou même de la « surcapacité », la chaîne d’amélioration parallèle EVM actuelle est encore généralement au stade du testnet et n’a pas encore été vérifiée par l’environnement réel du réseau principal, et sa capacité de mise à l’échelle et la stabilité du système doivent encore être testées plus avant. Il reste à voir si ces projets peuvent améliorer considérablement les performances de l’EVM et faire des bonds écologiques sans sacrifier la compatibilité, ou s’ils peuvent différencier davantage les liquidités et les ressources de développement d’Ethereum.