Rédaction : 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 mono-chaîne » parfaite, il faut encore arbitrer entre 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 feuille de route d'interopérabilité d'Ethereum « l'accélération (Acceleration) » et la finalisation (Finalisation) – la « preuve en temps réel » apportée par la technologie ZK (lecture complémentaire : « Feuille de route 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 à l'ampleur de la mise à niveau Dencun à l'époque, les projecteurs du marché se sont surtout concentrés sur l'extension des Blobs et le PeerDAS, commentant avec enthousiasme la réduction supplémentaire des coûts de données des L2.
Mais au milieu de cette agitation, il y avait en fait une proposition discrète, l'EIP-7825, qui a levé 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 l'extension : la capacité des Blobs a été multipliée par 8, et associée à la vérification par échantillonnage aléatoire PeerDAS, le récit des coûts dans le domaine de la DA (disponibilité des données) est définitivement devenu de l'histoire ancienne.
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 Gas supérieure pour une transaction unique sur Ethereum (environ 16,78 millions de Gas).
Comme on le sait, la limite de Gas 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 Gas extrêmement élevé, il pourrait envoyer une « méga-transaction (Mega-Transaction) » super complexe, occupant directement toute la capacité de Gas de 60 millions du bloc, bloquant ainsi tout le bloc.
C'était autorisé auparavant, mais l'EIP-7825 introduit une nouvelle limitation : quelle que soit la taille du bloc, la consommation d'une transaction unique ne peut pas dépasser 16,78 millions de Gas.
Alors, pourquoi limiter la taille d'une transaction unique ? En réalité, 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 étroitement lié à la manière 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 Gas, le ZK Prover devait exécuter séquentiellement cette transaction extrêmement complexe, sans possibilité de la diviser ou de la paralléliser. C'est comme une autoroute à une seule voie où un énorme camion roule très lentement 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 Gas à l'avenir, comme chaque transaction est limitée à 16,78 millions de Gas, 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 ces petites tâches divisées en un temps très court, générant ainsi une preuve ZK pour d'énormes blocs.
Comme l'a déclaré Michael, co-fondateur et PDG de Brevis, l'EIP-7825 est la mise à niveau la plus sous-estimée sur la voie future du ZK et d'une extension par 100 d'Ethereum. Il a fait passer la « preuve en temps réel » de « théoriquement impossible » à « programmable techniquement », à condition que nous puissions résoudre le problème de puissance de calcul par le calcul parallèle. Même pour un bloc de 200 millions de Gas, une preuve en quelques secondes est envisageable. Ce n'est pas seulement une percée de la technologie ZK, c'est aussi la base physique permettant à la couche d'interopérabilité d'Ethereum (EIL) d'effectuer des règlements inter-chaînes en quelques secondes.
Ainsi, cette mise à niveau peut sembler ne pas être l'élément principal, mais en réalité, pour la feuille de route ZK et l'avenir de l'extension d'Ethereum en 2026, il s'agit d'une énorme avancée.
II. L1 zkEVM : Le « point d'ancrage de confiance » de l'interopérabilité d'Ethereum
Cependant, bien que l'EIP-7825 ait pavé la voie physique (parallélisable) pour 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 d'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, non seulement parce qu'il résout les goulots d'étranglement des performances, mais aussi parce qu'il redéfinit le mécanisme de confiance de la blockchain, son idée centrale est de doter le mainnet d'Ethereum de la capacité à générer et 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) emballe un bloc et génère une preuve ZK, et les nœuds validateurs n'ont plus besoin de réexécuter les transactions, ils doivent 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 l'extension 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 de faire confiance à la vérité mathématique du mainnet d'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 les L2 ne se libérera jamais de l'ombre du « retard ».
L'objectif est fixé (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 du zkEVM au zkVM.
III. Fusaka & EIP-7825 : La feuille de route de l'interopérabilité libérée
Si l'EIP-7825 fournit un « environnement matériel parallélisable » pour le ZK en limitant la taille des transactions individuelles, alors l'évolution de la stack technologique ZK vise à trouver une « architecture logicielle plus efficace ». Cela peut sembler être un jeu de mots, mais la différence est grande et représente deux phases du développement ZK (lecture complémentaire : « L'« aube » de la feuille de route ZK : La feuille de route finale d'Ethereum accélère-t-elle globalement ? »).
La première phase était 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 (y compris les clients d'exécution, les explorateurs de blocs, les 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, appartient à l'aile révolutionnaire radicale, construisant directement une machine virtuelle extrêmement 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 de performance.
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 est que de plus en plus de projets L2 commencent à se débarrasser du fardeau, optimisant de manière extrême la vitesse et le coût des preuves, explorant des architectures basées sur zkVM.
Alors, pourquoi dire que la mise à niveau de Fusaka est un déverrouilleur ?
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 décompose forcément les 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 pour des blocs Ethereum complexes, placés dans un zkVM, avec une puissance de calcul parallèle, une preuve en temps réel devient possible.
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 chutera considérablement. Lorsque le coût de génération d'une preuve inter-chaînes sera si bas qu'il deviendra négligeable, et que la vitesse sera aussi rapide que l'envoi d'un e-mail, les « ponts inter-chaînes » traditionnels disparaîtront complètement, remplacés par des protocoles de messages universels sous-jacents.
Pour conclure
Comme mentionné à plusieurs reprises dans les précédents articles 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 », mais 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, et le rôle du ZK est de garantir l'exactitude de l'exécution, de soutenir la vérification d'état en temps réel, de rendre les appels inter-domaines « osés, possibles ». On peut même dire que sans le ZK en temps réel, il est difficile d'avoir une UX Interop vraiment utilisable.
Ainsi, lorsque l'EIP-7825 a été discrètement activé dans la mise à niveau de Fusaka, lorsque le L1 zkEVM devient progressivement une réalité, nous nous rapprochons infiniment de cette finalité : l'exécution, le règlement, 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é Interop que nous attendons tous pour l'avenir.
