Analyse technique d'Artela : pourquoi l'« EVM parallèle » est-il crucial pour la survie de l'écosystème EVM d'Ethereum ?
TechFlow SélectionTechFlow Sélection
Analyse technique d'Artela : pourquoi l'« EVM parallèle » est-il crucial pour la survie de l'écosystème EVM d'Ethereum ?
« L'EVM parallèle » est le dernier recours des chaînes EVM pour contrer les blockchains de niveau 1 à hautes performances, une bataille vitale pour la survie de l'écosystème EVM d'Ethereum.
Dédié à des analyses Web3 approfondiesRédaction : Haotian
Récemment, Paradigm a misé gros en menant un tour de financement massif de 225 millions de dollars pour Monad, suscitant un vif intérêt du marché autour du concept d’« EVM parallèle ». Alors, quel problème l’« EVM parallèle » cherche-t-il précisément à résoudre ? Quels sont les obstacles et enjeux clés dans son développement ? Selon moi, l’« EVM parallèle » représente le dernier recours des chaînes EVM pour contrer les blockchains hautement performantes de layer1 — une bataille décisive pour la survie de l’écosystème EVM d’Ethereum. Pourquoi ? Voici mon analyse :
Étant donné que la machine virtuelle EVM ne peut traiter les transactions qu’en mode « séquentiel », cela limite naturellement les performances des blockchains layer1 compatibles EVM ainsi que celles des layer2 compatibles EVM, car elles reposent fondamentalement toutes sur le même cadre pour gérer l’état et atteindre la finalité des transactions.
En revanche, des blockchains layer1 axées sur les hautes performances comme Solana, Sui ou Aptos bénéficient dès leur conception d’un avantage intrinsèque en matière de traitement parallèle. Dans ce contexte, si les chaînes héritières de l’ADN EVM veulent faire face frontalement à l’offensive des blockchains layer1 performantes, elles doivent impérativement combler leur lacune structurelle en matière de parallélisme. Comment procéder ? En abordant les principes techniques et détails, j’utiliserai la jeune blockchain émergente @Artela_Network comme exemple illustratif :
1) Des blockchains renforcées de type EVM layer1 telles que Monad, Artela ou SEI visent à augmenter considérablement le TPS tout en permettant un traitement parallèle des transactions dans un environnement simulant l’EVM, tout en maintenant une compatibilité élevée avec l’EVM. Ces chaînes indépendantes disposent de mécanismes de consensus et de caractéristiques technologiques propres, mais poursuivent néanmoins l’objectif de s’intégrer et étendre l’écosystème EVM. Autrement dit, elles reconstruisent les chaînes EVM via un « changement de lignage », tout en continuant de servir l’écosystème EVM ;
2) Les chaînes layer2 compatibles EVM axées sur l’extension, telles qu’Eclipse ou MegaETH, exploitent le consensus indépendant des layer2 et leur capacité de « prétraitement » des transactions. Elles peuvent ainsi filtrer et traiter les états avant que les lots de transactions ne soient soumis au réseau principal, et choisir librement n’importe quelle autre chaîne comme couche d’exécution finale. Cela revient à rendre l’EVM modulaire, interchangeable selon les besoins, permettant ainsi d’atteindre le parallélisme. Toutefois, ces solutions, bien qu’utiles pour l’EVM, sortent du cadre strict de l’architecture EVM ;
3) Les chaînes Alt-layer1 dites équivalentes, telles que Polygon ou BSC, ont partiellement mis en œuvre le traitement parallèle EVM, mais uniquement via des optimisations algorithmiques superficielles, sans toucher aux couches profondes de consensus ou de stockage. Ce parallélisme reste donc limité à une fonctionnalité spécifique, sans véritablement résoudre le problème fondamental du parallélisme dans l’EVM ;
4) Les chaînes Non-EVM parallèles de type différentiel, telles qu’Aptos, Sui ou Fuel, ne cherchent pas réellement à être des chaînes EVM, mais plutôt à intégrer la compatibilité EVM via des middlewares ou des moteurs de parsing spécifiques, tout en s’appuyant sur leurs capacités natives de haute concurrence. Prenez Starknet, un layer2 d’Ethereum : grâce au langage Cairo et à l’abstraction des comptes, il dispose d’une capacité de parallélisme, mais sa compatibilité EVM passe par un canal spécifique. La plupart des chaînes Non-EVM rencontrent ce type de limitation lorsqu’elles tentent d’interagir avec l’écosystème EVM.
Ces quatre approches présentent chacune leurs priorités : les layer2 parallèles mettent l’accent sur la flexibilité modulaire de la couche d’exécution ; les chaînes compatibles EVM se distinguent par des fonctionnalités personnalisées ; quant aux chaînes non-EVM, leur compatibilité EVM vise souvent à capter la liquidité d’Ethereum. Seul le segment des chaînes EVM renforcées vise véritablement à consolider durablement l’écosystème EVM en transformant radicalement ses capacités de parallélisme à la base.
Quels sont alors les éléments clés pour construire une blockchain publique EVM parallèle de type renforcé ? Comment reconstruire une chaîne EVM tout en servant toujours l’écosystème EVM ? Deux points sont essentiels :
1) La capacité d’accès aux entrées/sorties (I/O) de l’état, c’est-à-dire la lecture et l’écriture sur disque. Le simple réordonnancement ou planification des transactions ne suffit pas à améliorer fondamentalement le traitement parallèle. Il faut introduire des caches, la découpe des données (data sharding), voire des technologies de stockage distribué afin d’équilibrer efficacité de lecture et risques de conflits d’état au niveau fondamental du stockage et du flux d’accès aux états ;
2) Disposer d’un réseau de communication efficace, d’une synchronisation rapide des données, d’algorithmes optimisés, d’une machine virtuelle renforcée, ainsi que d’optimisations variées au niveau du mécanisme de consensus, notamment la séparation des tâches de calcul et des tâches I/O. Cela exige une refonte systémique complète de l’architecture des composants de base, des processus de collaboration, etc., afin d’obtenir un traitement parallèle offrant rapidité de réponse, consommation de calcul maîtrisée et grande précision ;
Concrètement, quels types d’innovations technologiques et d’optimisations structurelles un projet de chaîne EVM parallèle layer1 doit-il mettre en œuvre pour réaliser un « EVM parallèle » ?
Pour parvenir à une capacité d’« EVM parallèle » pleinement optimisée au niveau architectural, Artela a introduit le calcul élastique (Elastic Computing) et l’espace de blocs élastique (Elastic Block Space). Comment comprendre cela ? Le calcul élastique permet au réseau d’allouer dynamiquement les ressources de calcul selon la demande et la charge ; l’espace de blocs élastique ajuste automatiquement la taille des blocs en fonction du volume et de la taille des transactions. L’ensemble de cette conception élastique fonctionne un peu comme un escalator dans un centre commercial qui s’active automatiquement selon le flux de personnes — une logique parfaitement cohérente.
Comme mentionné précédemment, les performances de lecture/écriture sur disque (State I/O) sont cruciales pour un EVM parallèle. Des chaînes compatibles EVM comme Polygon ou BSC obtiennent via des optimisations algorithmiques un gain d’efficacité de 2 à 4 fois, mais ces gains restent limités à la couche algorithmique : leurs couches de consensus et de stockage n’ont pas été profondément optimisées. À quoi ressemblerait une optimisation véritablement poussée ?
À cet égard, Artela s’inspire des solutions utilisées en base de données pour améliorer significativement la lecture et l’écriture d’état. Concernant l’écriture d’état, elle utilise la technique du journal d’écriture anticipée (Write-Ahead Log, WAL) : lorsque l’état change, les modifications sont d’abord enregistrées dans un journal puis validées en mémoire, ce qui est considéré comme une opération d’« écriture » terminée. Cette méthode rend l’opération asynchrone, évitant ainsi d’écrire immédiatement sur disque lors d’un changement d’état, réduisant ainsi fortement les opérations d’entrée/sortie sur disque. Pour la lecture d’état, une stratégie similaire d’asynchronisation est adoptée : une précharge intelligente prédit, à partir des historiques d’exécution des contrats, les états susceptibles d’être sollicités lors des prochains appels, et les charge en mémoire à l’avance, améliorant ainsi drastiquement l’efficacité des requêtes I/O.
En résumé, il s’agit d’un algorithme qui sacrifie de l’espace mémoire pour gagner du temps d’exécution, améliorant ainsi fondamentalement la capacité de traitement parallèle de la machine virtuelle EVM, et attaquant directement le problème des conflits d’état.
Par ailleurs, Artela intègre la programmation modulaire via les « Aspects », facilitant la gestion de la complexité et améliorant l’efficacité du développement. Elle prend également en charge le codage WASM pour plus de flexibilité, tout en offrant un accès aux API de bas niveau, assurant une isolation sécurisée de la couche d’exécution. Cela permet aux développeurs de créer, déboguer et déployer efficacement des contrats intelligents dans l’environnement Artela, stimulant ainsi leur capacité à étendre et personnaliser l’écosystème. Notamment, les développeurs sont incités à optimiser leurs codes dès la conception vers une exécution parallèle, car chaque logique d’appel et algorithme de contrat influence directement la probabilité de conflits d’état.
En somme,
On comprend aisément que le concept d’« EVM parallèle » consiste fondamentalement à optimiser le processus d’exécution des états transactionnels. @monad_xyz affirme pouvoir atteindre 10 000 transactions par seconde, grâce à des technologies telles que bases de données spécialisées, convivialité pour les développeurs, consensus à exécution différée, et techniques de pipeline superscalaire. Sur le fond, la logique est très similaire à celle d’Artela avec son calcul élastique et ses opérations I/O asynchrones.
Mais ce que je souhaite surtout souligner, c’est que ces chaînes EVM parallèles ultra-performantes résultent en réalité d’une intégration des produits et technologies web2. Elles s’inspirent effectivement des meilleures pratiques éprouvées dans les applications web2 confrontées à des pics de trafic et charges élevées.
Si l’on envisage un futur lointain de mass adoption, l’« EVM parallèle » constitue incontestablement l’infrastructure de base pour que l’écosystème EVM s’ouvre au grand public web2. Que les marchés financiers y soient aussi favorables est donc tout à fait compréhensible.
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
Haotian | CryptoInsight
