La feuille de route d’Interop « s’accélère » : après la mise à niveau Fusaka, l’interopérabilité d’Ethereum pourrait franchir une étape clé

Chainfeeds Guide :

Sans ZK en temps réel, il est difficile d’avoir une véritable expérience utilisateur Interop utilisable.

Source de l’article :

Auteur de l’article :

imToken Labs

Opinion :

imToken Labs : Le 4 décembre, la mise à niveau Fusaka d’Ethereum a été officiellement activée sur le mainnet, mais contrairement à la mise à niveau Dencun de l’époque, elle n’a pas suscité un grand engouement, et les projecteurs du marché se sont surtout concentrés sur l’expansion des Blobs et PeerDAS, avec beaucoup de discussions sur la réduction continue des coûts de données sur L2. Pourtant, en dehors de cette agitation, il existe une proposition discrète, EIP-7825, qui a levé le plus grand obstacle à la réalisation du L1 zkEVM et des preuves en temps réel sur Ethereum, et l’on peut même dire qu’elle prépare silencieusement le terrain pour l’aboutissement de l’Interop. Lors de cette mise à niveau Fusaka, l’attention s’est presque entièrement portée sur l’expansion : la capacité des Blobs a été multipliée par 8, et avec la vérification par échantillonnage aléatoire de PeerDAS, la narration sur la réduction des coûts de la DA (Data Availability) appartient désormais à l’histoire. Il est vrai que des L2 moins chers sont une bonne chose, mais pour la feuille de route ZK à long terme d’Ethereum, l’EIP-7825 est le véritable game changer, car il fixe une limite de Gas pour chaque transaction sur Ethereum (environ 16,78 millions de Gas). Comme tout le monde le sait, cette année, la limite de Gas par bloc sur Ethereum a été portée à 60 millions, mais même si cette limite continue d’augmenter, en théorie, si quelqu’un est prêt à payer un prix de Gas extrêmement élevé, il peut toujours envoyer une « méga-transaction » très complexe qui occupera à elle seule toute la capacité de 60 millions de Gas du bloc, bloquant ainsi tout le bloc. Pourquoi alors limiter la taille d’une transaction ? En réalité, ce changement 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, car cela est étroitement lié à la façon dont les systèmes ZK génèrent des preuves. Prenons 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 cette transaction extrêmement complexe de manière séquentielle, 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, forçant toutes les petites voitures (autres transactions) à attendre derrière lui. Cela condamnait directement la « preuve en temps réel » — car le temps de génération de la preuve devenait totalement imprévisible, pouvant prendre des dizaines de minutes, voire plus. Mais après l’EIP-7825, même si la capacité des blocs atteint un jour 100 millions de Gas, chaque transaction étant limitée à 16,78 millions de Gas, chaque bloc est découpé en « petites unités de tâches » prévisibles, bornées et pouvant être traitées en parallèle. Cela signifie que la génération de preuves sur Ethereum passe d’un « problème logique » épineux à un simple « problème de puissance de calcul (Money Problem) » : tant que l’on peut investir suffisamment de puissance de calcul parallèle, on peut traiter simultanément ces petites tâches fragmentées en très peu de temps, générant ainsi une preuve ZK pour d’énormes blocs. Cependant, même si l’EIP-7825 a ouvert la voie physique (parallélisation) à la preuve en temps réel en limitant la taille des transactions, ce n’est qu’une facette de la médaille. L’autre question est de savoir comment le mainnet Ethereum peut exploiter cette capacité ? Cela touche à la narration la plus technique de la feuille de route Ethereum — le L1 zkEVM. Depuis longtemps, le zkEVM est considéré comme le « Saint Graal » de l’extension d’Ethereum, non seulement parce qu’il résout les goulets d’étranglement de performance, mais aussi parce qu’il redéfinit le mécanisme de confiance de la blockchain. Son idée centrale est de permettre au mainnet Ethereum de générer et de vérifier des preuves ZK. Autrement dit, à l’avenir, chaque bloc exécuté sur Ethereum pourra produire une preuve mathématique vérifiable, permettant aux autres nœuds (en particulier les light nodes et les L2) de confirmer la validité des résultats sans avoir à recalculer — si la capacité de générer des preuves ZK est directement intégrée dans le protocole Ethereum (L1), chaque proposeur, à chaque fois qu’il assemble un bloc et génère une preuve ZK, permet aux nœuds validateurs de ne plus avoir à réexécuter les transactions, mais simplement à vérifier cette minuscule preuve mathématique.