La guerre secrète en période de marché baissier : les ZK-EVM mettront-elles fin aux conflits entre chaînes publiques ?
TechFlow SélectionTechFlow Sélection
La guerre secrète en période de marché baissier : les ZK-EVM mettront-elles fin aux conflits entre chaînes publiques ?
Tout produit dont le principal argument de vente est une caractéristique technique est un produit semi-fini.
Dédié à des analyses Web3 approfondiesTout produit dont la principale caractéristique de vente repose sur des aspects techniques est un produit inachevé.
La spéculation et les débats autour de l'EVM et du ZK EVM durent depuis un certain temps déjà, en particulier après que Vitalik ait classifié les différents types de ZK EVM. Des articles vulgarisant des concepts complexes comme le bytecode, les machines virtuelles ou encore la compatibilité ont alors vu le jour en nombre. Pourtant, ces textes n'ont pas permis d'éclaircir clairement ce que signifient réellement ces termes, ni vers quel avenir évolueraient les blockchains publiques grâce à la généralisation du ZK EVM.
Le domaine du ZK commence désormais véritablement à s'embraser. Si auparavant le ZK-Rollup limitait son application au niveau L2, on assiste aujourd'hui à une tendance émergente où le ZK deviendrait une technologie universelle pour l'ensemble du réseau blockchain. Selon R3PO, le ZK EVM aura potentiellement pour effet de mettre fin à la coexistence multipolaire des blockchains.
Dans ce processus historique de remplacement, de nouveaux projets vont inévitablement émerger. R3PO s'engage à identifier les valeurs cachées, en partant d'une compréhension intuitive de l'EVM pour explorer l'avenir des blockchains publiques.
Légende de l'image : Solution pour transférer des fichiers entre systèmes d'exploitation différents Source : R3PO
Imaginez le scénario suivant :
Alice souhaite envoyer à Bob un document Word fonctionnant sous Windows, mais Bob ne possède qu’un Mac utilisant Pages, et ne peut donc pas ouvrir le fichier. Comment résoudre ce problème ? En excluant l’installation par Bob d’une version Mac de Word ou la simple copie du texte du document, il reste quatre solutions possibles :
1. Alice téléverse le document dans le cloud, par exemple Google Docs, permettant ainsi à Bob d’ouvrir et d’éditer le document via un navigateur compatible multiplateforme ;
2. Alice transmet à Bob à la fois le fichier Word.exe et le document. Bob peut alors utiliser Crossover ou une machine virtuelle (VM) pour simuler un environnement Windows et exécuter l’application .exe sur Mac ;
Crossover ne permet que l’exécution isolée de Word.exe, sans prise en charge des autres applications .exe ;
Une machine virtuelle (VM) installe un sous-système Windows à l’intérieur du Mac, permettant d’exécuter n’importe quelle application .exe dans cet environnement ;
3. Alice convertit le document dans un format interprétable par Java, puis le transmet à Bob, qui pourra l’ouvrir après avoir installé un environnement Java sur son Mac ;
4. Alice transforme le document en fichier binaire et l’envoie à Bob, qui pourra l’ouvrir grâce à une compatibilité fondamentale au niveau le plus bas.
Si vous comprenez ce processus, procédons maintenant à une analogie conceptuelle :
Les systèmes d'exploitation comme Windows et macOS --> Les blockchains publiques comme Ethereum et Cosmos ;
Les formats d'applications comme .exe et .dmg --> Les Dapps sur différentes blockchains ;
Le document Word --> Les actifs sur la blockchain ;
Crossover --> Les ponts cross-chain ;
Machine virtuelle (VM) --> Une EVM à compatibilité réduite, comme Polygon Hermez, qui constitue une ZK VM réalisant les fonctions de l'EVM par réplication manuelle nécessitant des mises à jour constantes pour rester synchronisée ;
JVM --> EVM, compatibilité au niveau langage, comme Scroll (en projet), dont le ZK EVM est entièrement équivalent à l'EVM, pouvant être considéré comme une version de l'EVM enrichie de fonctionnalités ZK ;
Compatibilité binaire --> L'EVM elle-même ou le noyau d'Ethereum ;
Les caractéristiques décrites ci-dessus concernant les VM et l’EVM fonctionnent essentiellement de manière analogue au transfert de fichiers entre systèmes d’exploitation. Selon R3PO, la grande tendance sera que le ZK EVM non seulement remplacera progressivement les solutions actuelles de compatibilité EVM, mais conduira également à faire d’Ethereum le protocole unique de communication au niveau applicatif. Toutes les autres blockchains deviendront alors des chaînes spécialisées destinées à des usages spécifiques, de la même façon que Linux domine le secteur des serveurs tandis que Windows prévaut chez les utilisateurs grand public.
Les raisons soutenant cette conclusion seront développées ci-dessous.
Pour comprendre autrui, il faut d’abord se comprendre soi-même :l’écosystème, c’est la convergence mutuelle entre développeurs et utilisateurs
L’EVM a joué un rôle clé dans la victoire d’Ethereum face aux autres blockchains. Cette suprématie ne provient pas d’une « supériorité technique » en matière de puissance de calcul, car des blockchains telles qu’EOS (ancien challenger), Solana (challenger précédent) ou Aptos (nouveau challenger) ont toutes vanté leurs vitesses de TPS extrêmement élevées.
Pourtant, Ethereum reste inébranlable, conservant une avance écrasante en termes de TVL (valeur totale verrouillée) et de nombre de Dapps malgré un TPS à un seul chiffre. Ce succès s’explique par un effet de concentration écologique. Mais pourquoi, alors que d'autres blockchains adoptent la compatibilité EVM et développent activement des ponts cross-chain, l’écart ne se réduit-il pas — voire semble-t-il s’accroître durant le marché baissier ?
R3PO pense qu’il est possible de partir d’un point de départ relativement certain pour trouver la réponse.
Ce point de départ est l’expérience des développeurs. Actuellement, Web3 en est encore à ses tout débuts, comparable à Internet avant l’an 2000 : un terrain de jeu pour les passionnés et les premiers utilisateurs. Même avec des mécanismes de jetons, la majorité des utilisateurs restent confinés dans les CEX et les institutions CeDeFi construites par le monde traditionnel de la finance (TradiFi). Les véritables utilisateurs sur chaîne sont très peu nombreux — Ethereum compte environ 400 000 adresses actives, mais un TVL de 32 milliards de dollars et une capitalisation de 200 milliards.
Face à ce contraste marqué entre le faible nombre d'utilisateurs et l'importance des capitaux immobilisés, attirer les développeurs devient la voie principale pour maintenir un écosystème. La logique est simple : la blockchain capable d’attendre jusqu’à l’apparition d’applications grand public atteignant l’échelle du milliard d’utilisateurs deviendra l’infrastructure fondamentale du prochain Internet, à l’image de ce qu’ont été le World Wide Web et le navigateur Netscape.
Et l’expérience de développement offerte par Ethereum est la plus complète.
En un sens, cela reprend le modèle du succès du langage Java. Avant Java, les langages C/C++ obligeaient les programmeurs à gérer manuellement la compatibilité logiciel/matériel — par exemple, un type numérique 32 bits ne pouvait pas être directement exécuté sur une machine 16 bits.
Légende de l'image : Architecture de la JVM Source : Wikipédia
Outre sa facilité d’utilisation, l’amélioration majeure apportée par Java fut la conception de la JVM. En résumé, elle repose sur un principe de « virtualisation matérielle » : grâce au langage, une même application peut s’exécuter indifféremment sur différents matériels. Une fois développée pour la JVM, une application peut tourner sur n’importe quel appareil, rendant le développement véritablement multiplateforme, sans souci de compatibilité matérielle.
Grâce à la JVM, Java est devenu l’un des langages de programmation les plus populaires au monde — pas nécessairement le meilleur dans chaque domaine, mais applicable à tous. Tel est le cœur de la compatibilité.
Il en va de même pour l’EVM et l’écosystème de développement Ethereum : les développeurs n’ont besoin de s’adapter qu’une seule fois à l’EVM, et peuvent ensuite évoluer continuellement avec l’écosystème Ethereum, sans se soucier des mises à jour de la blockchain ou des différences matérielles.
Légende de l'image : Architecture de l'EVM Source : ethereum.org
Solidity n’est pas parfait, l’EVM comporte aussi des défauts, mais sa meilleure compatibilité suffit à assurer la fidélité des développeurs. Et plus les blockchains adoptent la compatibilité EVM, plus celle-ci bénéficie d’un effet de réseau passif : le coût de migration entre chaînes devient négligeable, et les autres blockchains ne deviennent guère plus que des versions localisées des Dapps d’Ethereum, renforçant ainsi l’hégémonie de l’écosystème Ethereum.
Légende de l'image : Fonctionnement schématisé de l'EVM Source : R3PO
Par ailleurs, la compatibilité au niveau du langage contribue aussi à garantir efficacité et sécurité de l’EVM.
La machine virtuelle (VM) mentionnée dans l’image ci-dessus fait référence au mode de fonctionnement entre systèmes d’exploitation, par exemple Parallels Desktop, qui permet d’exécuter un sous-système Windows sur Mac. Cela implique d’allouer d’abord des ressources système spécifiques pour créer le sous-système, puis d’y installer l’application Windows. Toutefois, en raison des limitations liées à l’allocation des ressources, l’efficacité d’exécution reste inférieure à celle d’une application native.
L’EVM, quant à elle, est similaire à la JVM : elle assure la compatibilité au niveau du langage Solidity. Les développeurs interagissent avec le réseau principal via les API fournies par Infura, développent, testent et déploient leurs contrats intelligents avec Truffle, etc. L’ensemble de l’environnement de développement est disponible. Une fois adapté à l’EVM, un Dapp peut fonctionner sur n’importe quelle blockchain compatible EVM.
Non seulement pour les développeurs, mais aussi pour tous les utilisateurs, la compatibilité au niveau EVM garantit une expérience uniforme, préservant ainsi un groupe minimal d’utilisateurs pilotes. Grâce uniquement aux développeurs et à quelques utilisateurs, l’écosystème Ethereum conserve son avance sur les autres blockchains.
L’EVM s’inspire de la JVM, évitant de devoir gérer trop de questions matérielles ou de codage, et permettant aux développeurs de se concentrer uniquement sur les fonctionnalités réelles de l’application. Une adaptation, utilisation universelle.
Un écosystème, c’est développement + applications + utilisateurs. L’EVM a joué un rôle de déclenchement initial, tel un volant d’inertie.
Pour juger autrui, il faut d’abord s’analyser soi-même :la compatibilité EVM ne favorise pas la victoire des concurrents
L’EVM a contribué au succès d’Ethereum, mais pourquoi les autres blockchains compatibles EVM, ou les projets « vampires » aspirant à drainer l’écosystème d’Ethereum, n’arrivent-ils pas à réussir ?
La logique des blockchains compatibles :
Aux développeurs : proposer la compatibilité EVM afin de réduire les coûts de migration, tout en offrant de nouvelles fonctionnalités comme un TPS plus élevé ;
Aux utilisateurs : offrir des incitations sous forme de jetons pour encourager leur migration ;
Objectif final : remplacer Ethereum.
Les failles dans cette logique :
Pour les développeurs : la compatibilité EVM n’est jamais l’EVM natif ; il existe toujours des coûts invisibles de migration ;
Pour les utilisateurs : la sécurité d’Ethereum est la plus élevée après Bitcoin, une qualité que des incitations à court terme (airdrops, farming) ne peuvent surpasser ;
Conséquence : Ethereum conserve sa position dominante.
En réalité, les autres blockchains sont confrontées à un dilemme : adopter la compatibilité EVM risque de les transformer en sidechains d’Ethereum, mais ne pas l’adopter les condamne à l’isolement. Dans un contexte où chacun cherche désespérément du trafic, la compatibilité devient une décision forcée, presque désespérée.
Légende de l'image : Aperçu des solutions de compatibilité EVM Source : R3PO
À ce stade, ce sont principalement les autres blockchains qui prennent l’initiative, tandis qu’Ethereum travaille silencieusement à corriger ses anciens problèmes : passage du PoW au PoS, choix de la voie L2, mise en œuvre de l’abstraction des comptes, DankSharding, etc. Concernant la compatibilité, trois approches principales existent : implémenter l’EVM, réaliser la compatibilité inter-chaînes via des applications, ou créer des chaînes compatibles EVM.
Compatibilité EVM intégrée à la blockchain, représentée par BNB Chain.
Des blockchains d’échanges comme BNB Chain ou OKX Chain, profitant de leur base utilisateur massive et de leur capacité opérationnelle, ont su construire des écosystèmes et accumuler un TVL non négligeable. Prenons BNB Chain : selon DeFi Llama, 492 protocoles y sont déployés, avec un TVL de 6 milliards de dollars. En taille et volume, c’est la deuxième plus grande blockchain publique, juste après Ethereum.
Son modèle principal consiste à « imiter » Ethereum. Par exemple, son plus grand DEX, Pancakeswap, était initialement un fork d’Uniswap. Un même Dapp peut ainsi basculer sans friction entre les deux blockchains, grâce justement à la compatibilité EVM. Les équipes projets peuvent alors se concentrer sur l’opérationnel plutôt que de tout reconstruire depuis zéro.
Compatibilité EVM au niveau de la chaîne, représentée par Solana.
Solana est une blockchain monolithique utilisant un mécanisme PoH, longtemps le seul projet parmi les dix premières capitalisations à ne pas être compatible EVM. Cependant, cela ne signifie pas qu’elle ne peut pas communiquer avec les chaînes compatibles EVM. Son projet Neon, fonctionnant sur Solana, fournit justement une compatibilité EVM.
On peut voir cette compatibilité comme une « poupée russe », une couche ajoutée, plutôt qu’une intégration directe au niveau de la blockchain elle-même.
Neon offre une expérience de développement très proche de l’EVM native : prise en charge du langage Solidity, déploiement fluide de contrats intelligents, compatibilité directe avec MetaMask et les outils de développement comme Truffle.
Chaîne compatible EVM, représentée par Evmos.
Les blockchains modulaires comme Cosmos ou Polkadot offrent davantage d'options. Leurs applications peuvent elles-mêmes devenir des blockchains de niveau L1. Evmos est à la fois une sous-chaîne de Cosmos et une blockchain compatible EVM, ce qui lui permet non seulement de diffuser la compatibilité EVM au sein de l’écosystème Cosmos, mais aussi entre n’importe quelles autres blockchains.
Outre son rôle de fournisseur de compatibilité EVM, Evmos peut aussi accueillir des applications comme des DeFi. Par exemple, son DEX Exswap est un fork d’Uniswap.
Synthèse de cette section : C’est précisément cette large compatibilité qui permet d’unifier le monde des blockchains, grâce aux liens que sont la compatibilité EVM, les ponts cross-chain et les exchanges. Sur cette base, R3PO présente ici les grandes familles de compatibilité, préparant ainsi le terrain pour le rôle de « vainqueur final » du ZK EVM.
Pour vaincre autrui, il faut d’abord se vaincre soi-même :le ZK EVM, c’est l’offensive proactive d’Ethereum
Alors que les autres blockchains étaient occupées à devenir compatibles EVM pendant qu’Ethereum semblait absorbé par ses propres ajustements, le succès du passage au PoS et le choix clair de la voie L2 ont changé la donne. Le ZK est désormais une technologie universelle pour l’ensemble du secteur des blockchains, et son association avec l’EVM va permettre d’achever l’évolution vers une architecture modulaire d’Ethereum.
La technologie ZK ne se limite pas au domaine L2 ; elle trouve des applications à tous les niveaux, des Dapps aux blockchains. Toutefois, le secteur très porteur du ZK EVM reste encore hétérogène. R3PO propose ici un bref classement, dans le but de distinguer le bon grain de l’ivraie.
Légende de l'image : Niveaux de compatibilité EVM et performance Source : vitalik.eth
Vitalik a déjà présenté une classification illustrant le rapport entre compatibilité EVM et performance : plus l’implémentation est profonde (proche du noyau), meilleure est la compatibilité, mais plus la performance est limitée. Cela paraît logique : comparez la faible performance d’Ethereum à sa sécurité exceptionnelle.
Plus on s’approche du niveau fondamental, plus on se rapproche du fonctionnement natif de l’EVM, donc meilleure est la compatibilité, mais au prix d’une limitation sévère de la performance ;
Plus on monte vers les couches supérieures, plus on dépend de la capacité propre de la solution EVM, avec des divergences croissantes par rapport à l’EVM natif d’Ethereum, donc une compatibilité moindre, mais une plus grande liberté de personnalisation permettant d’optimiser fortement la performance.
Nous avons précédemment mentionné Polygon Hermez, le classant dans la catégorie ZK VM. Or, Hermez se qualifie lui-même de solution ZK EVM. Cette différence d’un seul caractère masque en réalité des écarts significatifs en termes de compatibilité et de sécurité.
Le ZK VM/EVM mis en œuvre par Polygon Hermez reproduit fonction par fonction l’EVM, comme une copie conforme — similaire à la relation entre WBTC et BTC, ou entre une ombre et son objet. En pratique, tant que l’équipe maintient les mises à jour, l’expérience utilisateur est quasi identique à celle de l’EVM. Mais ce n’est pas une implémentation au niveau du langage. Il s’agit, en somme, d’un habillage commercial.
Récemment, StarkNet a lancé Kakarot, un ZK EVM utilisant le langage Cairo, permettant d’exécuter des contrats intelligents Ethereum sur StarkNet. Cela marque probablement la première entrée en phase de test d’un vrai ZK EVM. D’autres projets sont en attente, notamment Taiko, Scroll, zkSync 2.0, etc.
Pourquoi le ZK EVM suscite-t-il un tel engouement ? Et pourquoi serait-ce le « vainqueur final » des blockchains ?
Actuellement, les informations commerciales des projets restent incomplètes. R3PO livre ici sa propre interprétation, en espérant susciter le débat.
Légende de l'image : Architecture d’Ethereum à l’ère du ZK EVM Source : R3PO
Pour la première question, la réponse est que le ZK EVM est en réalité l’habitat naturel futur des Dapps.
Selon la perception actuelle, un Dapp fonctionne soit sur une blockchain, soit sur un réseau L2. Mais selon R3PO, le ZK EVM accueillera directement la couche applicative à l’avenir.
Comme illustré ci-dessus, le ZK EVM futur combinera les fonctions de l’EVM, des Rollups et des ponts cross-chain. Qu’il soit une EVM ne nécessite pas d’explication. Concentrons-nous sur les deux autres fonctions.
Les Rollups de niveau L2 sont trop basiques. Pour viser de meilleures performances, prenons l’exemple de StarkNet développé par StarkWare : il prévoit d’utiliser des preuves ZK récursives pour valider la validité des données. Grâce à la récursivité, on peut étendre indéfiniment « l’après par l’avant », tout en gardant une taille de données globalement maîtrisée grâce au ZK. Ainsi, StarkNet peut servir de couche de validation pour les applications et les L3 qui reposent sur lui.
Quant au pont cross-chain, son rôle est plus facile à comprendre : il permet d’échanger et de transférer des actifs entre différentes blockchains. Si celles-ci sont toutes compatibles EVM, le pont devient inutile comme intermédiaire. De plus, le ZK est intrinsèquement plus sûr que les ponts actuels, souvent vulnérables. Ainsi, le ZK EVM constitue une meilleure solution pour le cross-chain.
Pour la deuxième question, la réponse est que le ZK EVM transformera toutes les blockchains en chaînes EVM.
Même des blockchains comme Solana ou Aptos, qui ne sont pas natives EVM, pourront s’y connecter via des solutions comme Evmos. De ce point de vue, le ZK EVM représente une offensive proactive d’Ethereum : « Si tu ne veux pas te connecter à moi, je vais quand même t’intégrer ». Cela amplifiera encore l’avantage écologique d’Ethereum.
Concernant les blockchains Move comme Aptos ou Sui, leur Move VM revendiquée comme un mécanisme de développement similaire à l’EVM. Théoriquement, le langage Move, dérivé de Rust, est effectivement supérieur à Solidity. Mais leur principal handicap est le facteur temps : construire un écosystème et un flux d’utilisateurs autonomes reste incertain. Elles tombent alors dans le même dilemme que les autres blockchains : compatibilité EVM ou isolement ?
Conclusion
Le succès d’une blockchain dépend certes de ses propres efforts, mais aussi du cours de l’histoire.
Dans l’évolution du ZK EVM, on perçoit clairement la difficulté du combat entre blockchains. Le bras de fer entre Ethereum et les autres chaînes a donné naissance à d’innombrables histoires passionnantes. Aujourd’hui, le moment décisif oppose de nouvelles entités comme Evmos ou Move VM au ZK EVM. R3PO estime que l’avenir des blockchains devra nécessairement s’appuyer sur l’interopérabilité issue de la compatibilité EVM comme condition de compétition. Les développeurs et les utilisateurs resteront au cœur de toute l’histoire.
Si le développement du ZK EVM progresse comme prévu, Ethereum pourrait bien devenir le « Windows » du monde des blockchains : hébergeant la couche applicative la plus riche, et servant de couche de règlement la plus sûre et la plus stable.
La technologie ZK nécessitera encore au moins cinq ans pour maturer à grande échelle. Sous la pression du capital et du marché, ce délai pourrait être réduit à environ trois ans. À ce moment-là, nous saurons si nos prévisions d’aujourd’hui se seront réalisées.
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
