Transférer le titre original : Analyse technique Artela : Pourquoi le “Parallel EVM” est-il lié à la bataille pour la survie de l'écosystème de l'EVM Ethereum ?

L'investissement récent de Paradigm de 225 millions de dollars dans le tour de financement de Monad a envoyé des ondes de choc à travers le marché, enflammant une vague d'intérêt pour "EVM parallèle". Mais que traite exactement "EVM parallèle"? Quels sont les goulots d'étranglement et les principaux défis dans le développement de l'EVM parallèle? Je crois que l'EVM parallèle représente le dernier rempart de la chaîne EVM contre les chaînes de couche 1 à haute performance, une bataille qui déterminera la survie de l'écosystème Ethereum EVM. Pourquoi? Plongeons dans ma compréhension:

La capacité de traitement des transactions « sérielles » inhérente à la machine virtuelle EVM d'Ethereum a imposé des contraintes de performance significatives à la fois aux chaînes de couche 1 compatibles avec l'EVM et aux chaînes de couche 2 compatibles avec l'EVM. Cela découle du fait qu'elles reposent toutes fondamentalement sur le même cadre pour traiter l'état et la finalité des transactions.

En revanche, les chaînes de couche 1 haute performance telles que Solana, Sui et Aptos possèdent des avantages inhérents de traitement parallèle. Dans ce contexte, les chaînes basées sur l'EVM doivent résoudre leur manque inhérent de capacités parallèles pour rivaliser efficacement avec ces chaînes publiques de couche 1 haute performance. Explorons les différentes approches pour mettre en œuvre l'EVM parallèle, en utilisant l'exemple d'Artela Network, une étoile montante dans l'espace parallèle de l'EVM :

1) Représentées par des chaînes telles que Monad, Artela et SEI, ces chaînes améliorent considérablement le TPS tout en permettant des capacités de transaction parallèles au sein d'un environnement quasi-EVM. Ces chaînes indépendantes parallèles de couche 1 EVM possèdent des mécanismes de consensus et des caractéristiques techniques uniques, mais elles conservent néanmoins l'objectif de compatibilité et d'expansion au sein de l'écosystème EVM. Fondamentalement, elles reconstruisent les chaînes EVM en "changeant leur lignée" pour mieux servir l'écosystème EVM.

2） Illustré par des chaînes telles que Eclipse et MegaETH, ces chaînes exploitent le consensus indépendant et les capacités de "prétraitement" des transactions des chaînes de couche 2 pour filtrer et traiter les états des transactions avant de les regrouper sur le mainnet. Elles peuvent également sélectionner la couche d'exécution de n'importe quelle autre chaîne pour finaliser les états des transactions. Cette approche abstrait essentiellement l'EVM en un module d'exécution enfichable, permettant la sélection de la meilleure "couche d'exécution" en fonction des besoins, ce qui permet d'atteindre des capacités parallèles. Cependant, bien que ces solutions puissent servir l'EVM, elles fonctionnent en dehors du cadre EVM.

3）Représentés par des chaînes comme Polygon et BSC, ces chaînes ont atteint un certain degré de capacité de traitement EVM parallèle. Cependant, leurs optimisations se limitent à la couche algorithmique, sans approfondir les couches de consensus et de stockage. Par conséquent, leurs capacités parallèles ressemblent davantage à une fonctionnalité spécifique qu'à une solution complète aux défis de parallélisation de l'EVM.

4) Exemplifié par des chaînes comme Aptos, Sui et Fuel, ces chaînes ne sont pas strictement des chaînes EVM. Au lieu de cela, elles capitalisent sur leurs capacités d'exécution à haute concurrence inhérentes et utilisent des techniques de middleware ou d'analyse de code pour atteindre la compatibilité avec l'environnement EVM. Cela est évident dans le cas de Starknet, une solution de couche 2 d'Ethereum. La compatibilité de Starknet avec l'EVM nécessite un conduit spécial en raison de son langage Cario et de ses fonctionnalités d'abstraction de compte. Ce défi de compatibilité est un problème courant avec les chaînes non-EVM tentant de se connecter aux chaînes EVM.

Les quatre approches mentionnées ci-dessus ont chacune leur propre accent. Par exemple, la couche 2 avec des capacités parallèles met l'accent sur la flexibilité des combinaisons modulaires des chaînes de la \u201ccouche d'exécution\u201d, tandis que les chaînes compatibles EVM mettent en avant les fonctionnalités personnalisées de fonctions spécifiques. En ce qui concerne les autres chaînes non EVM avec des fonctionnalités de compatibilité EVM, elles visent davantage à exploiter la liquidité d'Ethereum. Le véritable objectif est de consolider complètement l'écosystème EVM, ne laissant qu'une seule piste renforcée de couche 1 EVM pour améliorer les capacités parallèles.

Alors, quels sont les principaux facteurs de renforcement d'une couche publique parallèle EVM de niveau 1 ? Comment pouvons-nous reconstruire une chaîne EVM tout en continuant à servir l'écosystème EVM ? Il y a deux points clés :

1. La capacité d'accéder à la lecture du disque E/S de l'état et aux informations de sortie. Étant donné que la lecture et l'écriture de données prennent du temps, simplement trier et planifier les transactions ne peut pas améliorer fondamentalement les capacités de traitement parallèle. Cela nécessite également l'introduction de mises en cache, de la découpe de données, voire de technologies de stockage distribué pour équilibrer la vitesse de lecture et la possibilité de conflits d'état issus du processus fondamental de stockage et de lecture d'état.

2. Avoir une communication réseau efficace, une synchronisation des données, une optimisation des algorithmes, un renforcement de la machine virtuelle, et diverses optimisations de composants de la couche de mécanisme de consensus telles que la séparation des tâches de calcul et d'E/S, nécessitant une optimisation complète et une amélioration de divers aspects, y compris l'architecture des composants de la couche inférieure et les processus collaboratifs. Cela conduit finalement à la capacité d'exécuter rapidement des transactions parallèles, avec une consommation de calcul contrôlable et une grande précision.

En ce qui concerne le projet spécifique de la couche parallèle EVM de la chaîne de niveau 1 elle-même, quelles innovations technologiques et quels optimisations de framework sont nécessaires pour réaliser la "EVM parallèle" ?

Pour réaliser pleinement les capacités de coordination et d'optimisation des ressources de la « EVM parallèle » à partir de l'architecture de couche inférieure, Artela introduit l'informatique élastique et l'espace de bloc élastique. Comment les comprendre ? L'informatique élastique permet au réseau d'allouer et d'ajuster dynamiquement les ressources de calcul selon la demande et la charge, tandis que l'espace de bloc élastique ajuste dynamiquement la taille des blocs en fonction du nombre de transactions et de la taille des données dans le réseau. Le principe de conception élastique dans son ensemble fonctionne de manière similaire aux escalators dans les centres commerciaux qui détectent automatiquement le flux des piétons, ce qui a un sens parfait.

Comme mentionné précédemment, la performance de la lecture de disque d'entrée/sortie de l'état est cruciale pour l'EVM parallèle. Les chaînes compatibles avec l'EVM comme Polygon et BSC obtiennent des améliorations d'efficacité de 2 à 4 fois grâce au parallélisme algorithmique, mais il ne s'agit là que d'une optimisation au niveau algorithmique. La couche de consensus et la couche de stockage n'ont pas encore subi d'optimisation approfondie. À quoi ressemblerait une véritable optimisation approfondie ?

En réponse à cela, Artela s'appuie sur des solutions technologiques de base de données, améliorant à la fois la lecture et l'écriture de l'état. Pour l'écriture des états, il introduit la technologie Write-Ahead Logging (WAL), qui enregistre les modifications avant de les écrire sur le disque. Cette opération asynchrone évite l'écriture immédiate sur le disque lorsque l'état change, réduisant les opérations d'E/S sur disque. Pour la lecture de l'état, il adopte essentiellement des opérations asynchrones par des stratégies de préchargement pour améliorer l'efficacité de la lecture. En prévoyant quels états seront nécessaires en fonction de l'historique de l'exécution du contrat et en les préchargeant en mémoire, cela améliore l'efficacité des demandes d'E/S sur disque.

En bref, il s'agit d'un algorithme qui échange du temps d'exécution contre de l'espace mémoire, améliorant fondamentalement les capacités de traitement parallèle de la machine virtuelle EVM et optimisant le problème de conflit d'état dès le départ.

De plus, Artela introduit les capacités de programmation modulaire d'Aspect pour mieux gérer la complexité et améliorer l'efficacité du développement. En introduisant l'analyse du codage WASM pour améliorer la flexibilité de la programmation et en fournissant des autorisations d'accès à l'API de bas niveau, il parvient à isoler de manière sécurisée la couche d'exécution. Cela permet aux développeurs de développer, déboguer et déployer efficacement des contrats intelligents dans l'environnement d'Artela, activant les capacités de personnalisation et d'extension de la communauté de développeurs. En particulier, les développeurs seront encouragés à optimiser leur code de contrat intelligent pour le parallélisme, car réduire la probabilité de conflits d'état est crucial pour la logique d'invocation et l'algorithme de chaque contrat intelligent.

C'est tout.

Il n'est pas difficile pour tout le monde de voir que le concept de "Parallel EVM" optimise essentiellement le processus d'exécution de l'état de la transaction.@monad_xyzprétend pouvoir réaliser 10 000 transactions par seconde, et son cœur technique ne consiste rien de plus qu'à réaliser un traitement parallèle de transactions à grande échelle grâce à des bases de données spécialisées, à la convivialité des développeurs, au consensus d'exécution différée et à la technologie de pipeline superscalaire, etc. Cela ne diffère pas beaucoup du traitement élastique et des opérations asynchrones d'EVM.

Ce que je veux réellement exprimer, c'est que ce type de chaîne EVM parallèle haute performance est en réalité le résultat de l'intégration de produits et de capacités techniques web2. Il adopte en effet l'essence de la "gestion technique" sous charge élevée de temps en temps sur le marché des applications matures de web2.

Si vous regardez le futur lointain de l'adoption massive, le "Parallel EVM" est en effet l'infrastructure de base pour l'écosystème EVM afin de faire face à un marché plus large du web2, et il est raisonnable que le marché capital soit si haussier.

déclaration :

1. Cet article est reproduit à partir de [Vue sur la chaîne], les droits d'auteur appartiennent à l'auteur original [Hao Tian], si vous avez des objections à la réimpression, veuillez contacter le Gate Learnl'équipe, et l'équipe le traitera dès que possible selon les procédures pertinentes.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en investissement.

3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées dans Gate, l'article traduit ne peut être reproduit, distribué ou plagié.