Auteur : imToken
Dans les articles précédents de la série Interop, nous avons exploré respectivement l'OIF (cadre d'intention) et l'EIL (couche d'interopérabilité), qui résolvent la standardisation des intentions inter-chaînes (permettre au réseau de comprendre ce que vous voulez faire) et le problème des canaux d'exécution (permettre aux fonds de circuler de manière standardisée).
Mais pour parvenir à une « expérience de chaîne unique » parfaite, il faut encore équilibrer vitesse et confiance. Après tout, dans l'expérience d'interopérabilité actuelle, il faut soit accepter la lenteur (comme les Optimistic Rollups qui nécessitent une période de défi de 7 jours pour confirmer la finalité), soit sacrifier la décentralisation (en dépendant de l'hypothèse de confiance des ponts multi-signatures).
Pour briser ce « triangle impossible », il est indispensable de disposer d'une capacité fondamentale qui traverse à la fois « l'accélération » (Acceleration) et la finalisation (Finalisation) de la feuille de route d'interopérabilité d'Ethereum – la « preuve en temps réel » offerte par la technologie ZK (lecture complémentaire : « Feuille de route d'Interop d'Ethereum : Comment débloquer le « dernier kilomètre » de l'adoption massive »).
Et dans la mise à niveau de Fusaka qui vient d'être activée, le discret EIP-7825 est précisément ce qui écarte le plus grand obstacle technique pour cette finalité.
I. Derrière la mise à niveau de Fusaka, l'EIP-7825 sous-estimé
Le 4 décembre, la mise à niveau de Fusaka d'Ethereum a été officiellement activée sur le mainnet, mais contrairement au battage médiatique de la mise à niveau de Dencun à l'époque, les projecteurs du marché se sont surtout concentrés sur l'extension des Blobs et le PeerDAS, commentant avec délectation la réduction supplémentaire des coûts de données des L2.
Mais au milieu de ce tumulte, il y a en fait une proposition discrète, l'EIP-7825, qui écarte le plus grand obstacle à la réalisation du zkEVM de L1 et de la preuve en temps réel pour Ethereum, et on peut même dire qu'elle pave discrètement la voie vers la finalité de l'Interop.
Dans cette mise à niveau de Fusaka, l'attention de tous s'est presque entièrement portée sur la scalabilité : la capacité des Blobs a été multipliée par 8, et associée à la vérification par échantillonnage aléatoire PeerDAS, elle a fait définitivement passer le récit des coûts dans le domaine de la DA (disponibilité des données) à l'histoire.
Certes, des L2 moins chères sont une bonne chose, mais pour la feuille de route ZK à long terme d'Ethereum, l'EIP-7825 est le véritable changeur de jeu, car il impose une limite de Gaz par transaction (environ 16,78 millions de Gaz) sur Ethereum.
Comme on le sait, la limite de Gaz des blocs Ethereum a été portée à 60 millions cette année, mais même si la limite supérieure augmente constamment, en théorie, si quelqu'un est prêt à payer un prix de Gaz extrêmement élevé, il peut toujours envoyer une « méga-transaction » super complexe, occupant directement toute la capacité de Gaz de 60 millions du bloc, bloquant ainsi tout le bloc.
C'était autorisé auparavant, mais l'EIP-7825 introduit une nouvelle restriction : quelle que soit la taille du bloc, la consommation d'une seule transaction ne peut dépasser 16,78 millions de Gaz.
Alors, pourquoi limiter la taille des transactions individuelles ? En fait, cette modification n'a aucun impact sur les transferts des utilisateurs ordinaires, mais pour le ZK Prover (générateur de preuves), c'est une question de vie ou de mort, et cela est également lié à la façon dont les systèmes ZK génèrent les preuves.
Pour prendre un exemple simple, avant l'EIP-7825, si un bloc contenait une « méga-transaction » consommant 60 millions de Gaz, le ZK Prover devait exécuter séquentiellement cette transaction extrêmement complexe, sans pouvoir la diviser ni la paralléliser. C'est comme une autoroute à une seule voie, avec un énorme camion très lent devant, et toutes les voitures derrière (les autres transactions) doivent attendre qu'il passe.
Cela condamnait sans aucun doute la « preuve en temps réel » – car le temps de génération de la preuve devenait complètement imprévisible, pouvant prendre des dizaines de minutes, voire plus.
Après l'EIP-7825, même si la capacité des blocs devait atteindre 100 millions de Gaz à l'avenir, comme chaque transaction est limitée à 16,78 millions de Gaz, chaque bloc est décomposé en « petites unités de tâches » prévisibles, délimitées et traitables en parallèle. Cela signifie que la génération de preuves pour Ethereum est passée d'un « casse-tête logique » épineux à un pur « problème de puissance de calcul (Money Problem) » :
À condition de pouvoir investir suffisamment de puissance de calcul parallèle, nous pouvons traiter simultanément en très peu de temps ces petites tâches divisées, générant ainsi une preuve ZK pour d'énormes blocs.
Comme l'a déclaré Michael, co-fondateur et CEO de Brevis, l'EIP-7825 est la mise à niveau la plus sous-estimée sur la voie d'un facteur 100 de scalabilité future pour ZK et Ethereum. Il fait passer la « preuve en temps réel » de « théoriquement impossible » à « programmable en ingénierie ». Tant que nous pouvons résoudre le problème de puissance de calcul par le calcul parallèle, même des blocs de 200 millions de Gaz pourraient atteindre une preuve en quelques secondes. Ce n'est pas seulement une percée technologique pour ZK, c'est aussi la base physique permettant à la couche d'interopérabilité Ethereum (EIL) d'atteindre un règlement inter-chaînes en quelques secondes.
Cette mise à niveau peut donc sembler mineure, mais elle représente en réalité une énorme avancée pour la feuille de route ZK et l'avenir de la scalabilité d'Ethereum en 2026.
II. L1 zkEVM : Le « point d'ancrage de confiance » de l'interopérabilité Ethereum
Cependant, bien que l'EIP-7825 pave la voie physique (parallélisable) vers la preuve en temps réel en limitant la taille des transactions individuelles, ce n'est qu'une face de la pièce. L'autre face est de savoir comment le mainnet Ethereum lui-même utilise cette capacité ?
Cela nous amène au récit le plus fondamental de la feuille de route d'Ethereum – le L1 zkEVM.
Longtemps considéré comme le « Graal » pour étendre Ethereum, le zkEVM n'est pas seulement capable de résoudre les goulots d'étranglement de performance, mais il redéfinit également le mécanisme de confiance de la blockchain. Son idée centrale est de doter le mainnet Ethereum de la capacité de générer et de vérifier des preuves ZK.
En d'autres termes, à l'avenir, après l'exécution de chaque bloc Ethereum, il pourra produire une preuve mathématique vérifiable, permettant à d'autres nœuds (en particulier les nœuds légers et les L2) de confirmer l'exactitude du résultat sans avoir à répéter les calculs – si la capacité de générer des preuves ZK est intégrée directement dans la couche protocolaire d'Ethereum (L1), le proposeur (Proposer) qui regroupe un bloc et génère une preuve ZK, les nœuds validateurs n'auront plus besoin de réexécuter les transactions, ils devront seulement vérifier cette minuscule preuve mathématique.
Qu'est-ce que cela signifie pour l'interopérabilité ?
Dans le contexte de l'Interop, la signification du L1 zkEVM va bien au-delà de la scalabilité elle-même. On peut dire que c'est le « point d'ancrage de confiance » de tous les L2. Après tout, si Ethereum L1 peut générer des preuves en temps réel, cela signifie que tous les L2 peuvent lire l'état final de L1 de manière instantanée et sans confiance. Cela apportera deux changements qualitatifs :
- Élimination de la période de défi : Le temps de confirmation entre les chaînes passera de « 7 jours (mécanisme OP) » à « quelques secondes (mécanisme ZK) » ;
- Interconnexion décentralisée : L'interopérabilité ne nécessitera plus de faire confiance à des ponts multi-signatures tiers, mais fera confiance à la vérité mathématique du mainnet Ethereum ;
C'est aussi la base physique dont nous avons parlé dans notre précédent article pour que l'EIL (couche d'interopérabilité) puisse vraiment fonctionner – sans la finalité en temps réel (Finality) de L1, l'interopérabilité entre L2 ne se libérera jamais de l'ombre du « délai ».
L'objectif est là (L1 zkEVM), la limitation physique est levée (EIP-7825), mais qu'en est-il des outils de mise en œuvre concrets ?
Cela nous amène à l'évolution subtile qui se produit dans la stack technologique ZK : le passage de zkEVM à zkVM.
III. Fusaka & EIP-7825 : La feuille de route de l'interopérabilité libérée
Si l'EIP-7825 fournit à ZK un « environnement matériel parallélisable » en limitant la taille des transactions individuelles, l'évolution de la stack technologique ZK, quant à elle, vise à trouver une « architecture logicielle plus efficace ». Cela peut sembler un jeu de mots, mais la différence est grande et représente deux phases du développement ZK.
La première phase est naturellement le zkEVM, que l'on peut considérer comme l'approche compatible ou réformiste.
La logique est de s'efforcer d'imiter chaque instruction de l'EVM d'Ethereum, permettant aux développeurs de déployer directement du code Solidity, réduisant ainsi les coûts et les obstacles à la migration.
En d'autres termes, le plus grand avantage du zkEVM est sa compatibilité avec les applications Ethereum existantes, réduisant considérablement la charge de travail des développeurs de l'écosystème Ethereum, qui peuvent réutiliser la plupart des infrastructures et outils existants (clients d'exécution, explorateurs de blocs, outils de débogage, etc.).
Cependant, précisément pour cette raison, comme l'EVM n'a pas été conçu à l'origine en pensant à la compatibilité ZK, pour rester compatible, l'efficacité de preuve du zkEVM a souvent un plafond, le temps de preuve est beaucoup plus lent, et le fardeau historique est lourd.
Le zkVM, quant à lui, relève de l'approche révolutionnaire radicale, construisant directement une machine virtuelle très favorable aux preuves ZK (comme basée sur RISC-V ou WASM), pour accélérer le temps de preuve et obtenir une meilleure vitesse d'exécution et des performances.
Mais cela entraîne également la perte de la compatibilité avec de nombreuses fonctionnalités de l'EVM, ainsi que la capacité d'utiliser les outils existants (comme les débogueurs bas niveau). Cependant, une tendance évidente actuelle est que de plus en plus de projets L2 commencent à se débarrasser du fardeau, optimisant au maximum la vitesse et le coût des preuves, et explorant des architectures basées sur zkVM.
Alors, pourquoi dire que la mise à niveau de Fusaka est un déverrouillage ?
Après tout, avant l'EIP-7825, qu'il s'agisse de zkEVM ou de zkVM, dès qu'une méga-transaction sur Ethereum était rencontrée, le temps de génération de la preuve explosait en raison de l'impossibilité de diviser la tâche.
Maintenant, l'EIP-7825 force la décomposition des transactions en petites unités prévisibles. Avec un environnement parallélisable, l'architecture efficace du zkVM peut déployer sa puissance maximale. Même des blocs Ethereum complexes, placés dans un zkVM, avec une puissance de calcul parallèle, peuvent atteindre une preuve en temps réel.
Qu'est-ce que cela signifie pour l'interopérabilité ? La popularisation du zkVM, combinée à l'EIP-7825, signifie que le coût de génération des preuves va considérablement baisser. Lorsque le coût de génération d'une preuve inter-chaînes sera si bas qu'il deviendra négligeable, et la vitesse aussi rapide que l'envoi d'un e-mail, les « ponts » inter-chaînes traditionnels disparaîtront complètement, remplacés par un protocole de messages universel sous-jacent.
Pour conclure
Comme nous l'avons mentionné à plusieurs reprises dans les articles précédents de la série Interop, l'objectif ultime de l'Interop n'est pas seulement l'« interopérabilité » des actifs, et ne se limite plus au concept de « pont d'actifs ». C'est un ensemble complet de capacités au niveau du système, incluant la communication de données inter-chaînes, l'exécution logique inter-chaînes, l'expérience utilisateur inter-chaînes, la sécurité inter-chaînes et le consensus.
Sous cet angle, l'Interop peut être compris comme le langage universel des protocoles de l'écosystème Ethereum futur. Sa signification ne réside pas seulement dans la transmission de la valeur, mais aussi dans le partage de la logique. Le rôle de ZK est de garantir l'exactitude de l'exécution, de soutenir la vérification d'état en temps réel, et de rendre les appels inter-domaines « audacieux et possibles ». On peut même dire que sans ZK en temps réel, il est difficile d'avoir une UX Interop vraiment utilisable.
Ainsi, lorsque l'EIP-7825 est discrètement activé dans la mise à niveau de Fusaka, et que le L1 zkEVM devient progressivement une réalité, nous nous rapprochons infiniment de cette finalité : l'exécution, le règlement et la preuve sont complètement abstraits en arrière-plan, l'utilisateur ne perçoit pas du tout l'existence de la chaîne.
C'est aussi la finalité de l'Interop que nous attendons tous.
