Fusaka en cours de mise à niveau avec la proposition EIP-7825, en limitant le plafond de Gas pour une seule transaction, permet à Ethereum de réaliser le L1 zkEVM et la preuve en temps réel en éliminant les obstacles, transformant ainsi la « preuve en temps réel » d’une impossibilité théorique en une capacité réalisable et programmable, pavant la voie à l’interopérabilité finale.
（Contexte préalable : BitMine investit 110 millions de dollars en 33 000 ETH ! Tom Lee annonce : ETH a déjà touché le fond）
（Complément d’information : Vitalik répond à l’incident de vulnérabilité du « client Prysm » : il n’y a pas de problème si Ethereum n’a pas la finalité ultime occasionnellement ! Il faut simplement éviter les erreurs de finalisation）

Table des matières de cet article

• 1. Derrière la mise à niveau Fusaka, une EIP-7825 sous-estimée
• 2. L1 zkEVM : le « point d’ancrage de confiance » pour l’interopérabilité d’Ethereum
• 3. Fusaka & EIP-7825 : la feuille de route de l’interopérabilité vers la libération
• Épilogue

Dans les articles précédents de la série Interop, nous avons respectivement exploré OIF (cadre d’intention) et EIL (couche d’interopérabilité), qui résolvent respectivement la standardisation des intentions cross-chain (faire comprendre à tout le réseau ce que vous souhaitez faire) et la problématique de canal d’exécution (permettre aux fonds de circuler de manière standardisée).

Mais pour réaliser une expérience « mono-chaîne parfaite », il faut faire face à un compromis entre vitesse et confiance. En effet, dans l’expérience d’interopérabilité actuelle, on doit soit supporter la lenteur (comme l’Optimistic Rollup nécessitant une période de défi de 7 jours pour confirmer la finalité), soit sacrifier la décentralisation (en faisant confiance à des ponts multi-signatures).

Il faut briser ce « triangle impossible » en s’appuyant sur une capacité fondamentale de la feuille de route d’interopérabilité Ethereum — l’accélération (Acceleration) et la finalisation (Finalisation) — grâce à la technologie ZK et à la « preuve en temps réel ».

Et dans la mise à niveau Fusaka qui vient de commencer, la proposition EIP-7825, discrète mais cruciale, élimine le plus gros obstacle technique à cette finalité ultime.

1. Derrière la mise à niveau Fusaka, une EIP-7825 sous-estimée

Le 4 décembre, la mise à niveau Fusaka d’Ethereum a été officiellement déployée sur le réseau principal, mais contrairement à l’upgrade Dencun d’il y a quelques années, son retentissement était plus discret ; l’attention du marché s’est principalement portée sur l’expansion de Blob et PeerDAS, ainsi que sur la réduction des coûts des données en couche 2.

Mais en dehors de ce tumulte, il existe une proposition peu visible, EIP-7825, qui a permis à Ethereum de lever le plus grand obstacle à la réalisation du L1 zkEVM et de la preuve en temps réel, et qui pourrait même, en secret, pavé la voie à l’ultime interopérabilité.

Dans cette mise à niveau Fusaka, tout le monde se concentre presque exclusivement sur l’expansion : capacité de Blob augmentée de 8 fois, combinée à la vérification par échantillonnage aléatoire PeerDAS, rendant le coût de la route de la disponibilité des données (DA) totalement obsolète.

Certes, un L2 moins cher est une bonne chose, mais pour la feuille de route ZK à long terme d’Ethereum, c’est EIP-7825 le véritable changeur de règles, car il fixe une limite de Gas par transaction (environ 16 780 000 Gas).

Comme tout le monde le sait, le plafond de Gas des blocs Ethereum a déjà été porté à 60 millions cette année, mais même si cette limite continue d’augmenter, en théorie, si quelqu’un est prêt à payer un prix du Gas extrêmement élevé, il peut toujours envoyer une « méga-transaction » ultra-complexe consommant toute la capacité de 60 millions de Gas d’un bloc, bloquant ainsi complètement le bloc.

C’était aussi permis auparavant, mais EIP-7825 introduit une nouvelle restriction : peu importe la taille du bloc, la consommation d’une seule transaction ne peut pas dépasser 16 780 000 Gas.

Pourquoi limiter la taille d’une transaction unique ? En réalité, cette modification n’a aucun impact sur les transferts classiques des utilisateurs, mais pour le ZK Prover (générateur de preuves), c’est une différence entre vie et mort, car cela est étroitement lié à la façon dont le système ZK génère la preuve.

Prenons un exemple simple : avant EIP-7825, si un bloc comprenait une « méga-transaction » consommant 60 millions de Gas, le ZK Prover devait exécuter cette transaction extrêmement complexe dans l’ordre, sans possibilité de la diviser ou de la paralléliser. Cela revient à une autoroute à voie unique, où un camion géant très lent bloque tout le trafic derrière lui : toutes les petites voitures (autres transactions) doivent attendre qu’il passe.

Cela condamnait sans doute la « preuve en temps réel » — car la durée de génération de la preuve était totalement imprévisible, pouvant prendre plusieurs dizaines de minutes, voire plus.

Après EIP-7825, même si la capacité du bloc augmente à 100 millions ou plus, chaque transaction étant limitée à 16 780 000 Gas, chaque bloc est divisé en « petites unités de tâches » prévisibles, délimitées et pouvant être traitées en parallèle. Cela signifie que la génération de preuves ZK pour un grand bloc devient un simple « problème de puissance de calcul » (Money Problem) :

En investissant suffisamment en puissance de calcul parallèle, on peut traiter simultanément ces petites tâches découpées en un temps extrêmement court, permettant ainsi de générer une preuve ZK pour un bloc massif.

Comme l’a dit Michael, PDG de Brevis, EIP-7825 est la mise à niveau la plus sous-estimée sur la voie de l’expansion 100x d’Ethereum et du ZK, car elle transforme la « preuve en temps réel », d’« impossible théorique » en une capacité « programmée et réalisable » — en résolvant simplement la problématique de puissance de calcul. Même pour un bloc de 200 millions de Gas, la preuve pourrait être générée en quelques secondes, ce qui constitue non seulement une percée technologique ZK, mais aussi la base physique permettant à l’interopérabilité d’Ethereum (EIL) d’atteindre une confirmation en temps réel inter-chaînes.

Ainsi, cette mise à niveau peut paraître secondaire, mais en réalité, elle constitue une avancée majeure pour la feuille de route ZK et pour la future expansion d’Ethereum en 2026.

2. L1 zkEVM : le « point d’ancrage de confiance » de l’interopérabilité Ethereum

Cependant, bien que EIP-7825, en limitant la taille des transactions, ait préparé le terrain physique pour la preuve en temps réel (par parallélisation), cela n’est qu’un aspect de la pièce. L’autre aspect concerne la capacité de la propre blockchain principale d’Ethereum à exploiter cette capacité.

Il s’agit du récit le plus hardcore dans la feuille de route d’Ethereum — le L1 zkEVM.

Depuis longtemps, zkEVM est considéré comme le « Saint-Graal » pour l’expansion d’Ethereum, non seulement parce qu’il résout le problème de performance, mais aussi parce qu’il redéfinit le mécanisme de confiance de la blockchain, en permettant à la chaîne principale d’Ethereum de générer et de vérifier des preuves ZK.

Autrement dit, à l’avenir, chaque bloc d’Ethereum pourra produire une preuve mathématique vérifiable, permettant à d’autres nœuds (notamment les nœuds légers et L2) de confirmer la validité sans recalculer tout. Si cette capacité de génération de preuves ZK est intégrée directement dans le protocole d’Ethereum (L1), chaque propositionnaire (Proposer) qui packe un bloc et génère une preuve ZK ne nécessitera plus que les nœuds de validation relancent toutes les transactions, mais seulement qu’ils vérifient cette preuve mathématique très petite.

Que signifie cela pour l’interopérabilité ?

Dans le contexte de l’Interop, la L1 zkEVM a une signification bien supérieure à celle d’un simple moyen d’expansion. Elle devient le « point d’ancrage de confiance » pour tous les L2, car si la L1 d’Ethereum peut générer des preuves en temps réel, cela signifie que tous les L2 peuvent lire en temps réel l’état final de la L1, sans confiance — ce qui entraîne deux changements de paradigme :

• Suppression de la période de défi : la confirmation entre chaînes sera ramenée de « 7 jours (mécanisme OP) » à « secondes (mécanisme ZK) » ;
• Interconnexion décentralisée : les ponts cross-chain n’auront plus besoin de faire confiance à des tiers via des multi-signatures, mais feront confiance à la vérité mathématique de la chaîne principale d’Ethereum.

C’est aussi la base physique que nous avons évoquée dans notre précédent article sur l’EIL (couche d’interopérabilité) — sans la finalité en temps réel de la L1, l’interopérabilité entre L2 resterait à jamais sous l’ombre du retard.

L’objectif est posé (L1 zkEVM), la limite physique levée (EIP-7825), mais quels outils concrets pour y parvenir ?

C’est là que se produit une évolution subtile de l’écosystème ZK : la transition de zkEVM vers zkVM.

3. Fusaka & EIP-7825 : la feuille de route de l’interopérabilité en pleine libération

Si EIP-7825 a permis, en limitant la taille des transactions, de fournir un « environnement matériel parallèle » pour ZK, alors l’évolution de l’écosystème ZK consiste à rechercher une « architecture logicielle plus efficace » — bien que cela puisse sembler un jeu de mots, il s’agit d’une distinction importante, représentant deux phases dans le développement ZK.

La première phase, naturellement, concerne zkEVM, qui peut être considéré comme une approche compatible ou améliorée.

L’idée est d’imiter au maximum la machine virtuelle Ethereum (EVM) pour permettre aux développeurs de déployer directement du code Solidity, en réduisant les coûts et les barrières de migration.

En d’autres termes, le principal avantage de zkEVM est sa compatibilité avec les applications existantes d’Ethereum, ce qui réduit considérablement le travail des développeurs de l’écosystème Ethereum. Ils peuvent réutiliser la majorité de leurs infrastructures et outils existants (clients d’exécution, explorateurs de blocs, outils de débogage, etc.).

Mais, en raison de cette compatibilité, EVM n’a pas été conçu à l’origine pour être optimisé ZK, ce qui limite souvent l’efficacité des preuves et rallonge le temps de génération — un fardeau historique.

La zkVM, en revanche, constitue une approche plus radicale, construisant une machine virtuelle très compatible avec ZK (par exemple basée sur RISC-V ou WASM), dans le but d’accélérer la génération de preuves, d’améliorer la vitesse et la performance d’exécution.

Mais cela peut aussi entraîner une perte de compatibilité avec de nombreuses fonctionnalités EVM, ainsi qu’avec les outils existants (débogueurs bas-niveau, etc.), même si la tendance actuelle montre que de plus en plus de projets L2 commencent à décharger cette compatibilité pour optimiser au maximum la vitesse et le coût des preuves, en explorant des architectures basées sur zkVM.

Pourquoi disons-nous que la mise à niveau Fusaka est un « déverrouilleur » ?

Avant EIP-7825, que ce soit zkEVM ou zkVM, tout bloc contenant une « méga-transaction » ne pouvait pas être découpé, ce qui provoquait une explosion du temps de génération des preuves.

Désormais, EIP-7825 force la décomposition des transactions en unités prévisibles et parallélisables, et avec un environnement parallèle, la structure zkVM peut exploiter toute sa puissance, même pour des blocs Ethereum complexes. En associant cela à la parallélisation, la preuve en temps réel devient réalisable.

Que signifie cela pour l’interopérabilité ? La généralisation de zkVM combinée à EIP-7825 implique que le coût de génération des preuves sera considérablement réduit. Lorsque le coût de produire une preuve inter-chaînes devient négligeable et qu’elle peut être générée en quelques secondes comme un email, la « passerelle cross-chain » traditionnelle disparaîtra complètement, remplacée par un protocole de communication universel sous-jacent.

Conclusion

Comme évoqué dans plusieurs articles de la série Interop, l’objectif ultime n’est pas simplement le transfert d’actifs « cross-chain », mais une capacité système globale — communication de données cross-chain, exécution logique cross-chain, expérience utilisateur cross-chain, sécurité et consensus cross-chain.

Dans cette optique, l’interopérabilité peut être vue comme un langage universel des protocoles futurs de l’écosystème Ethereum, dont la portée ne se limite pas au transfert de valeur, mais inclut le partage de logique. Le rôle du ZK est de garantir l’exactitude de l’exécution, en supportant la vérification de l’état en temps réel, permettant aux appels inter-domaines d’être « audacieux et réalisables ». On pourrait même dire qu’sans ZK en temps réel, l’interopérabilité réellement utilisable restera inaccessible.

Ainsi, lorsque EIP-7825 s’active discrètement dans la mise à niveau Fusaka, et que le L1 zkEVM devient une réalité progressive, nous approchons de l’ultime étape : l’exécution, la compensation et la preuve étant entièrement abstraites en arrière-plan, sans que l’utilisateur ne perçoive la chaîne.

C’est cette vision que nous espérons tous pour l’avenir de l’interopérabilité.