Quelle est la signification de la parallélisation de l'EVM ? Ou la fin de l'hégémonie de l'EVM ?
TechFlow SélectionTechFlow Sélection
Quelle est la signification de la parallélisation de l'EVM ? Ou la fin de l'hégémonie de l'EVM ?
Parallel EVM permettra-t-il aux applications décentralisées existantes d'atteindre des performances au niveau d'Internet ?
Dédié à des analyses Web3 approfondiesAuteur : ZHIXIONG PAN
TL;DR
-
Le concept de Parallel EVM attire plusieurs grands fonds de capital-risque comme Paradigm, Jump et Dragonfly.
-
Les projets représentatifs incluent Monad, Sei, MegaETH, Polygon, Neon EVM et BSC. Certains sont des L1, d'autres des L2. Les différences techniques précises entre ces équipes ne sont pas encore entièrement publiques.
-
Bien que le terme « Parallel EVM » signifie littéralement « parallélisation », il implique également une optimisation poussée de chaque composant de l’EVM. Ces efforts pourraient donc représenter la limite maximale des performances possibles dans le standard EVM.
-
Difficultés : en plus de la refonte complète de la pile technique, il faut anticiper efficacement les conflits potentiels entre transactions exécutées en parallèle, puis gérer efficacement leur réexécution en cas de conflit.
-
Défis : comment créer une différenciation dans un écosystème open source, et trouver un équilibre entre décentralisation et performance.
Après les algorithmes de consensus, la couche de données (DA) et les preuves à connaissance nulle, la prochaine technologie dure attendue est le Parallel EVM. Le marché du capital investissement a déjà misé plusieurs centaines de millions de dollars sur ce scénario, donnant naissance à plusieurs startups au statut de licorne.
L’intérêt communautaire pour le Parallel EVM (parallélisation de l’EVM) provient du fait que Georgios Konstantopoulos (CTO de Paradigm) et Haseeb Qureshi (Dragonfly) ont tous deux mentionné ce terme clé lors de leurs prévisions pour 2024 à la fin de l'année 2023. Toutefois, les discussions approfondies restent rares, et beaucoup considèrent que ce n’est pas un concept nouveau : l’EVM et le calcul parallèle étant chacun des concepts relativement matures. Alors pourquoi combiner ces deux termes constituerait-il une tendance importante ?
Il s'agit néanmoins toujours d’un sujet très confidentiel : si vous consultez les rapports annuels ou prévisions stratégiques de nombreux instituts de recherche, le Parallel EVM n’y est souvent même pas mentionné. Ce concept n’a donc pas encore atteint un large consensus. Comme les algorithmes de consensus ou la DA, c’est un sujet purement technique, ce qui réduit encore davantage son audience.
L’avantage direct du Parallel EVM est qu’il permet aux applications décentralisées existantes d’atteindre des niveaux de performance comparables à ceux du web traditionnel. On peut même dire que le Parallel EVM est la seule nouvelle technologie capable à la fois de tirer parti des (nombreux) contrats intelligents déjà existants, tout en offrant un débit transactionnel élevé et parallélisé.
Paradigm attendait depuis longtemps, Jump mise gros
Selon un article de « Fortune » rapportant que Paradigm prévoit de diriger le dernier tour de financement de Monad, valorisant la société à 3 milliards de dollars pour lever 200 millions. Bien que ce soit le premier investissement de Paradigm dans un projet de Parallel EVM, ils suivent cette technologie depuis plusieurs années. Georgios Konstantopoulos (CTO de Paradigm) avait déjà mentionné ce terme en 2021.
Le mot « Monad » lui-même est intéressant. Dans la philosophie de Leibniz, la monade est l’élément fondamental de l’univers : indivisible, indépendante du monde physique, chaque monade reflétant l’univers entier. En chinois, cela a été traduit par « Danzi » (« unité »).
En informatique, une monade est un patron de conception utilisé dans les langages de programmation fonctionnelle. Elle aide les développeurs à traiter la complexité du monde réel avec une grande pureté mathématique, rendant le code plus modulaire, compréhensible et maintenable.
Un autre fait amusant : « Monad » et « Nomad » sont des anagrammes. Un nomade est un voyageur sans lieu fixe, et un « digital nomad » désigne un travailleur numérique nomade.
Outre Monad, Georgios a discuté de ce sujet en mentionnant Sei et Polygon. Une autre raison de son enthousiasme pour le Parallel EVM tient au développement par son équipe d’un client Ethereum appelé Reth. Celui-ci vise à être un client haute performance pour la couche d’exécution d’Ethereum, implémenté en Rust. Développé rapidement, Reth vient d’entrer en phase bêta. Paradigm pourrait envisager d’implémenter directement le Parallel EVM sur Reth, mais vu l’ampleur du projet, investir dans d’autres équipes semble une stratégie plus efficace. Selon la documentation de Monad, leur stack technique repose principalement sur C++ et Rust.
À ses débuts, Reth a été accusé par des membres de l’équipe Erigon d’avoir copié le code open source d’Akula, conduisant à l’arrêt du développement d’Akula faute de financement. Georgios a répondu que Reth n’était pas un fork d’un autre client, ni basé sur leur code, bien qu’il ait été influencé et inspiré par Geth, Erigon et Akula. (https://thedefiant.io/paradigm-accused-copying-code)
Un autre acteur central est Jump Trading et Jump Capital. Le fondateur de Monad vient de Jump Trading, avec une solide expérience en trading haute fréquence. Jump Capital a investi dans Sei, et Jump participe activement à l’écosystème Solana, tant au niveau infrastructure que projets.
Dragonfly, investisseur précoce de Monad, suit aussi ce secteur de près, ayant investi dans NEAR (spécialiste du sharding), ainsi que dans les blockchains Aptos, Avalanche et Nervos.
Améliorer l’algorithme de consensus ne suffit plus, place à la couche d’exécution
Dans les précédentes guerres de blockchains, la couche d’exécution a été largement ignorée. Tous ne parlaient que d’innovations dans les algorithmes de consensus — que ce soit Solana, Avalanche ou EOS. Bien qu’ils aient introduit des innovations dans l’exécution, la communauté se souvient surtout de leurs algorithmes de consensus, pensant que leurs hautes performances proviennent uniquement de là.
Mais ce n’est pas vrai. Pour obtenir une blockchain performante, l’algorithme de consensus et la couche d’exécution doivent être harmonisés — conformément à la théorie du tonneau. Pour les blockchains EVM qui n’améliorent que le consensus, l’augmentation des performances nécessite des nœuds plus puissants. Par exemple, BSC limite le gaz par bloc à un niveau supportant environ 2000 TPS, ce qui exige un matériel plusieurs fois plus coûteux que celui d’un nœud complet Ethereum. Polygon affirme théoriquement atteindre 1000 TPS, mais en pratique, seulement quelques dizaines à quelques centaines.
Un nœud archive BSC requiert au minimum 16 cœurs CPU et 128 Go de RAM, contre 4 cœurs CPU et 16 Go de RAM pour un nœud Ethereum.
BSC a bien conscience de ces problèmes et collabore désormais avec NodeReal pour développer une technologie Parallel EVM. Cela permettrait d’augmenter le nombre de transactions par bloc, d’exécuter plus de transactions en parallèle, et ainsi de repousser la limite des TPS.
Parallélisme : passer du processeur monocœur au multicœur
Dans la plupart des systèmes blockchain, les transactions sont exécutées strictement dans l’ordre, comme sur un processeur monocœur : une opération doit terminer avant que la suivante commence. Cette méthode est lente, mais elle présente l’avantage d’être simple et peu complexe.
Cependant, si les blockchains veulent atteindre l’échelle des utilisateurs du web, un processeur monocœur ne suffira pas. Il faut donc adopter une machine virtuelle parallélisée, similaire à un processeur multicœur, capable de traiter plusieurs transactions simultanément, augmentant ainsi le débit. Mais cela pose des défis techniques, notamment quand deux transactions tentent d’écrire dans le même contrat intelligent. Une nouvelle mécanique est alors nécessaire pour résoudre ces conflits. En revanche, pour des contrats totalement indépendants, le débit peut croître proportionnellement au nombre de threads parallèles.
De plus, le Parallel EVM ne se contente pas d’améliorer la parallélisation : il optimise aussi l’efficacité d’exécution en mode monothread. Keone Hon, CEO de Monad, explique : « ...le véritable goulot d’étranglement réside dans les lectures et écritures fréquentes d’état... ». Il ajoute que l’exécution parallèle n’est qu’une partie du plan : la mission plus large de Monad est d’optimiser l’EVM dans son ensemble pour la rendre aussi efficace que possible.
Ainsi, bien que le terme Parallel EVM désigne littéralement la « parallélisation », il englobe aussi une optimisation poussée de chaque composant de l’EVM. Ces efforts pourraient donc représenter la limite ultime des performances dans le cadre du standard EVM.
EVM ≠ Solidity
Écrire des contrats intelligents est une compétence essentielle pour les développeurs blockchain. Ils utilisent Solidity ou d’autres langages avancés pour implémenter la logique métier. Mais l’EVM ne comprend pas directement Solidity : le code doit être « traduit » (compilé) en un langage bas niveau (opcodes / bytecode) qu’elle peut exécuter. Ce processus est transparent grâce à des outils matures.
Cette « traduction » entraîne des surcoûts (overhead). Des développeurs expérimentés peuvent utiliser directement les opcodes dans Solidity, via l’assemblage en ligne, pour maximiser l’efficacité et réduire les frais de gaz. Par exemple, le protocole Seaport d’Opensea utilise massivement l’assemblage en ligne pour minimiser les dépenses de gaz des utilisateurs.
Si le Parallel EVM aboutit, il améliorera non seulement la parallélisation, mais aussi l’ensemble de la pile EVM. Les développeurs n’auront plus besoin de consacrer d’énormes efforts à l’optimisation microscopique pour économiser quelques unités de gaz, car la machine virtuelle sous-jacente sera déjà suffisamment puissante pour neutraliser ces écarts.
Les performances de l’EVM varient, « standard » ≠ « réalisation technique »
La « machine virtuelle » est aussi appelée « couche d’exécution » : c’est le moteur qui calcule et traite les contrats après compilation en opcodes. Le bytecode défini par l’EVM est devenu une norme industrielle. Que ce soit des réseaux de niveau 2 basés sur Ethereum ou des blockchains indépendantes, presque toutes choisissent d’être pleinement compatibles avec l’EVM. Ainsi, un contrat écrit une fois peut être déployé sur plusieurs réseaux, avec un excellent rapport coût-efficacité.
Toute implémentation conforme au standard de bytecode EVM peut être qualifiée d’EVM, mais les méthodes d’implémentation peuvent varier fortement. Par exemple, le client Ethereum Geth implémente l’EVM en Go. En revanche, l’équipe Ipsilon de la Fondation Ethereum maintient une implémentation autonome en C++, que d’autres clients peuvent intégrer directement comme moteur d’exécution.
Prenons un exemple : de nombreux produits industriels suivent des normes internationales. Par exemple, un produit doit avoir un taux de colonies inférieur à un certain seuil pour être vendu — c’est la « norme ». Mais chaque usine peut choisir parmi des dizaines de méthodes de stérilisation différentes pour y parvenir, et certaines trouvent des solutions plus rentables — c’est la « pratique ».
Puisqu’il existe une implémentation comme evmone, d’autres sont possibles. Dans le cas de l’EVM, la norme définit des opérations de base (bytecode), comme les opérations arithmétiques élémentaires. Chaque opcode a une sortie déterminée pour une entrée donnée. En respectant cette norme, les implémentations peuvent varier énormément, offrant une grande marge de personnalisation et d’optimisation technique.
Similitudes et différences entre les Parallel EVM
Outre le très populaire Monad, d’autres projets comme Sei, MegaETH, Polygon, Neon EVM et BSC sont actifs dans le domaine du Parallel EVM. Même le client Reth de Paradigm vise à intégrer des fonctions de parallélisation.
Sur le plan de l’architecture, Monad, Sei, Polygon et BSC sont des blockchains de niveau 1 (L1), tandis que MegaETH serait un L2, et Neon EVM s’appuie sur le réseau Solana. Reth est un client open source, et MegaETH s’appuiera partiellement sur le travail de Reth.
Ces équipes sont concurrentes, et aucune n’a publié tous les détails techniques ni documents d’ingénierie. Des comparaisons plus fines devront attendre des divulgations futures. Peut-être que, comme pour les L2 sur BTC, le Restaking ou les L2 Ethereum, malgré des différences techniques mineures (et open source), l’enjeu principal sera la construction d’un écosystème unique.
Difficultés techniques du Parallel EVM
Pour les transactions séquentielles, le goulot d’étranglement réside dans le CPU et les opérations de lecture/écriture d’état. Mais ce modèle est simple et robuste : toutes les transactions s’exécutent correctement dans l’ordre. En revanche, dans une machine virtuelle parallèle, des conflits d’état peuvent survenir, nécessitant des vérifications supplémentaires avant ou après exécution.
Par exemple, si la VM supporte quatre threads parallèles, chacun traitant une transaction, mais que les quatre tentent d’échanger sur le même pool Uniswap, elles ne peuvent pas être exécutées en parallèle, car chaque transaction modifie le prix du pool. En revanche, si les quatre transactions concernent des contrats totalement indépendants, aucun problème.
Les différentes équipes adoptent des conceptions et implémentations spécifiques, mais au minimum, un module doit détecter les conflits après exécution, et relancer les transactions en cas de conflit. Idéalement, anticiper et filtrer les transactions potentiellement conflictuelles permettrait d’améliorer l’efficacité globale.
Au-delà de l’implémentation de la VM, chaque équipe redessine généralement la base de données d’état pour en accélérer les lectures/écritures, et conçoit un algorithme de consensus adapté — par exemple, MonadDb et MonadBFT pour Monad.
Défis
Le Parallel EVM fait face à deux défis potentiels : la valeur à long terme de l’ingénierie pourrait être absorbée par Ethereum ; et la centralisation des nœuds.
Comme les équipes sont encore en phase de développement et test, elles n’ont pas encore publié tous leurs codes. C’est l’une de leurs principales barrières actuelles. Mais une fois les réseaux de test et principaux lancés, ces codes seront publics, et pourraient être intégrés par Ethereum ou d’autres blockchains. À ce moment-là, il sera crucial d’accélérer le développement de l’écosystème pour construire des barrières durables au niveau de l’adoption.
Toutefois, ce risque n’est pas si critique. D’une part, les développeurs crypto disposent aujourd’hui de licences open source plus protectrices (comme celle d’Uniswap, qui autorise la publication mais interdit le fork commercial). D’autre part, la vision de Monad diffère fondamentalement d’Ethereum. Même si Ethereum atteint un jour la finalité en un seul slot (SSF), la finalité prendra au moins 12 secondes — insuffisant pour les applications à haute fréquence.
L’autre défi, commun à toutes les blockchains hautes performances, est le déploiement de suffisamment de nœuds pour garantir les principes fondamentaux de permissionless et trustless : la décentralisation. On pourrait même définir un indicateur quantitatif, comme « TPS divisé par la puissance matérielle requise pour un nœud », permettant de comparer objectivement les blockchains selon un critère de matériel donné. Moins les nœuds sont exigeants matériellement, plus leur nombre peut être élevé.
Nous continuerons à suivre attentivement l’évolution des projets Parallel EVM, et approfondirons leurs technologies et différences dans les prochains articles.
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
@ChainFeedsxyz
