Feuille de route de l'interopérabilité accélérée : après la mise à niveau de Fusaka, l'interopérabilité avec Ethereum pourrait franchir une étape clé

Auteur : imToken

Lien :

Déclaration : Cet article est une reprise de contenu, les lecteurs peuvent obtenir plus d’informations via le lien de l’article original. Si l’auteur a des objections concernant la forme de republication, veuillez nous contacter, nous modifierons conformément à la demande de l’auteur. La republication est uniquement destinée au partage d’informations, elle ne constitue en aucun cas un conseil d’investissement ni une position officielle de Wu.

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

Mais pour réaliser une « expérience de chaîne unique » parfaite, il faut également faire un compromis entre vitesse et confiance. En effet, dans l’expérience actuelle d’interopérabilité, il faut soit supporter la lenteur (comme Optimistic Rollup qui nécessite d’attendre 7 jours de période de contestation pour confirmer la finalité), soit sacrifier la décentralisation (en dépendant de la confiance dans les ponts multi-signatures).

Briser ce « triangle impossible » nécessite une feuille de route d’interopérabilité sur Ethereum, axée sur « l’accélération » (Acceleration) et la capacité fondamentale de finalisation (Finalisation) — la « preuve en temps réel » apportée par la technologie ZK (lecture complémentaire : « Feuille de route d’Interop Ethereum : comment débloquer le dernier kilomètre de l’adoption à grande échelle »).

Et dans la mise à jour Fusaka récemment activée, un EIP discret, l’EIP-7825, a justement permis de supprimer le plus grand obstacle technique à cet objectif final.

1. Derrière la mise à jour Fusaka, l’EIP-7825 sous-estimé

Le 4 décembre, la mise à jour Ethereum Fusaka a été officiellement activée sur le réseau principal. Contrairement à l’époque de la mise à jour Dencun, elle n’a pas fait beaucoup de bruit, et l’attention du marché s’est principalement concentrée sur l’extension de capacité de Blob et PeerDAS, et sur la réduction continue des coûts de données L2.

Mais en dehors de cet éclat, il y a un autre proposition discrète, l’EIP-7825, qui a permis de lever le plus grand obstacle à la réalisation du zkEVM L1 et à la preuve en temps réel sur Ethereum, et qui, on peut le dire, prépare silencieusement le terrain pour la finalisation de l’Interop.

Dans cette mise à jour Fusaka, l’attention est presque entièrement portée sur l’extension de capacité : le Blob voit sa capacité multipliée par 8, combinée à la validation par échantillonnage aléatoire PeerDAS, rendant la narration autour du coût de la disponibilité des données (DA) obsolète.

Évidemment, des L2 moins chers sont une bonne chose, mais pour la feuille de route ZK à long terme d’Ethereum, c’est surtout l’EIP-7825 qui change la donne, car il fixe une limite de Gas pour chaque transaction individuelle (environ 16 780 000 Gas).

Il est bien connu que le Gas Limit des blocs Ethereum cette année a été porté à 60 millions. Mais même si cette limite continue d’augmenter, en théorie, si quelqu’un est prêt à payer un prix du Gas très élevé, il pourra toujours envoyer une « méga-transation » extrêmement complexe, occupant tout le bloc avec 60 millions de Gas, bloquant ainsi tout le bloc.

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

Pourquoi limiter la taille d’une seule transaction ? En réalité, cette modification n’affecte en rien les transferts classiques des utilisateurs ordinaires, 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 ses preuves.

Prenons un exemple simple : avant l’EIP-7825, si un bloc contenait une « méga-transation » consommant 60 millions de Gas, le ZK Prover devait traiter cette transaction extrêmement complexe dans l’ordre, sans pouvoir la diviser ou la paralléliser. C’est comme une autoroute à voie unique, avec un énorme camion roulant très lentement devant, et toutes les autres voitures (autres transactions) devant attendre qu’il passe.

Cela condamnait sans doute la « preuve en temps réel » — car le temps nécessaire pour générer la preuve était totalement imprévisible, pouvant durer des dizaines de minutes ou plus.

Après l’EIP-7825, même si la capacité du bloc future est portée à 100 millions de Gas, la restriction de 16 780 000 Gas par transaction impose de décomposer chaque bloc en « petites unités de tâche » prévisibles, délimitées et traitables en parallèle. Cela signifie que la génération de preuve ZK d’Ethereum, qui était autrefois une « énigme logique » difficile, devient simplement un problème de « puissance de calcul » (Money Problem) :

si l’on peut investir suffisamment de puissance parallèle, on peut traiter simultanément ces petites tâches divisées en un temps très court, permettant ainsi de générer une preuve ZK pour un grand bloc.

Comme l’a dit Michael, co-fondateur et CEO de Brevis, l’EIP-7825 est la mise à jour la plus sous-estimée dans la voie vers la ZK et la scaling 100 fois d’Ethereum, car elle permet de faire passer la « preuve en temps réel » d’« impossible sur le plan théorique » à « réalisable en pratique » — en résolvant le problème de la puissance de calcul par le calcul parallèle, même un bloc de 200 millions de Gas pourrait obtenir une preuve en quelques secondes. C’est une avancée non seulement pour la technologie ZK, mais aussi la base physique permettant un règlement inter-chaînes en secondes sur Ethereum.

Donc cette mise à jour peut sembler secondaire, mais en réalité, elle représente une avancée majeure pour la feuille de route ZK et l’avenir de l’extension Ethereum en 2026.

2. L1 zkEVM : l’« ancre de confiance » de l’interopérabilité Ethereum

Cependant, bien que l’EIP-7825, en limitant la taille d’une transaction, prépare la voie pour la preuve en temps réel (par parallélisation), il reste une question : comment le réseau principal Ethereum lui-même va-t-il exploiter cette capacité ?

Cela touche à la narration la plus hardcore de la feuille de route Ethereum — le L1 zkEVM.

Depuis longtemps, le zkEVM est considéré comme le « graal » pour étendre Ethereum, non seulement parce qu’il résout les problèmes 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 aux autres nœuds (notamment les light clients et les L2) de confirmer la validité des résultats sans recalculs exhaustifs — si la capacité de générer une preuve ZK est intégrée directement dans la couche protocolaire d’Ethereum (L1), le proposant (Proposer) qui assemble un bloc et produit une preuve ZK n’aura plus besoin de relancer tous les calculs, il suffira de vérifier cette petite preuve mathématique.

Que signifie cela pour l’interopérabilité ?

Dans le contexte de l’Interop, la signification du L1 zkEVM dépasse largement la simple extension de capacité, c’est une « ancre de confiance » pour tous les L2 : si la couche principale Ethereum peut générer des preuves en temps réel, cela signifie que tous les L2 peuvent accéder à la finalité en temps réel, de manière vérifiable et sans confiance — deux changements majeurs :

· Fin de la période de contestation : la confirmation entre chaînes passera de « 7 jours (mécanisme OP) » à « quelques secondes (mécanisme ZK) » ;

· Interconnexion décentralisée : le cross-chain ne nécessitera plus de faire confiance à des ponts multi-signatures tiers, mais à la vérité mathématique de la couche principale Ethereum ;

C’est aussi la base physique permettant à notre précédente discussion sur l’EIL (niveau d’interopérabilité) de fonctionner réellement — sans la finalité en temps réel du L1, l’interopérabilité entre L2 resterait toujours sous l’ombre de « la latence ».

Avec le L1 zkEVM (objectif), la limitation physique levée (EIP-7825), quels outils concrets restent ?

Cela met en lumière une évolution subtile dans la pile technologique ZK : du zkEVM vers le zkVM.

3. Fusaka & EIP-7825 : la voie de l’interopérabilité libérée

Si l’EIP-7825 fournit une « plateforme matérielle » pour la ZK en limitant la taille de transaction, alors l’évolution de la stack ZK vise à rechercher une « architecture logicielle plus efficace » — même si cela ressemble à un jeu de mots, la différence est grande et elle marque deux phases du développement ZK (lecture complémentaire : « La « lueur d’aube » de la feuille de route ZK : le calendrier de l’achèvement d’Ethereum s’accélère-t-il ? »).

La première phase est naturellement zkEVM, qu’on peut voir comme une approche compatible ou améliorée.

L’idée est d’imiter autant que possible chaque instruction de l’EVM d’Ethereum, afin de permettre aux développeurs de déployer directement du code Solidity, en réduisant les coûts et la difficulté de migration.

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

Cependant, cette compatibilité a aussi ses limites : conçue à l’origine sans considération ZK, la preuve du zkEVM est souvent limitée par sa faible efficacité, avec des temps de preuve plus longs et un poids historique considérable.

Le zkVM, quant à lui, est une approche plus radicale : il construit une machine virtuelle très ZK-friendly (par exemple basée sur RISC-V ou WASM), pour accélérer le temps de preuve, tout en offrant de meilleures performances d’exécution.

Mais il perd aussi une partie de la compatibilité avec les fonctionnalités EVM et la capacité à utiliser des outils existants (débogueurs, etc.), même si la tendance actuelle montre que de plus en plus de projets L2 déchargent cette charge, optimisent la vitesse et le coût des preuves, et explorent des architectures basées sur zkVM.

Pourquoi dit-on que la mise à jour Fusaka est un déblocage ?

Car avant l’EIP-7825, que ce soit zkEVM ou zkVM, lorsqu’une méga-transation Ethereum était rencontrée, le temps pour générer la preuve explosait à cause de l’incapacité à diviser la tâche.

Désormais, avec la restriction EIP-7825 de diviser la transaction en petites unités prévisibles, et avec l’environnement de parallélisation, l’architecture zkVM à haute efficacité peut atteindre son plein potentiel : même pour des blocs complexes, en plaçant le tout dans un zkVM et en utilisant la puissance de calcul parallèle, la preuve en temps réel devient envisageable.

Que cela signifie-t-il pour l’interopérabilité ? La généralisation du zkVM, combinée à EIP-7825, implique que le coût de génération de preuve sera considérablement réduit. Si le coût devient négligeable et la vitesse aussi rapide qu’un envoi d’email, alors les ponts inter-chaînes traditionnels disparaîtront complètement, remplacés par des protocoles de messagerie universels sous-jacents.

En conclusion

Comme mentionné dans plusieurs articles précédents de la série Interop, l’objectif ultime de l’interopérabilité n’est pas seulement le transfert d’actifs « cross-chain », mais une notion plus large qui inclut un ensemble complet de capacités systémiques : communication de données cross-chain, exécution logique cross-chain, expérience utilisateur cross-chain, sécurité et consensus cross-chain.

Sous cet angle, l’interopérabilité peut être vue comme le langage commun des futurs protocoles de l’écosystème Ethereum, dont la signification dépasse le simple transfert de valeur. Son rôle essentiel est de partager la logique, et ZK y joue un rôle clé pour garantir la correction de l’exécution, soutenir la vérification de l’état en temps réel, et rendre l’appel inter-domaines « audacieux et faisable ». Sans ZK en temps réel, une véritable expérience utilisateur cross-chain serait difficile à réaliser.

Ainsi, avec l’activation discrète de l’EIP-7825 dans Fusaka et la réalisation progressive du L1 zkEVM, nous approchons inexorablement de cette fin ultime : l’exécution, la finalité et la preuve étant entièrement abstraites en arrière-plan, pour que l’utilisateur n’en perçoive pas l’existence.

C’est aussi cette fin ultime de l’interopérabilité que nous attendons tous.