Interopロードマップが「加速」：Fusakaアップグレード後、Ethereumの相互運用性が重要な一歩を迎える可能性

Chainfeeds ガイド：

リアルタイムZKがなければ、本当に使えるInterop UXは実現できません。

記事出典：

記事著者：

imToken Labs

見解：

imToken Labs：12月4日、EthereumのFusakaアップグレードが正式にメインネットで有効化されましたが、かつてのDencunアップグレードほど大きな話題にはなりませんでした。市場の注目もBlobスケーリングやPeerDASに集中し、L2データコストのさらなる低減が話題となっています。しかし、この喧騒の裏で、目立たない提案EIP-7825が、EthereumにL1 zkEVMとリアルタイム証明を実現する最大の障害を取り除き、ひそかにInteropの最終形に道を開いているとも言えます。今回のFusakaアップグレードでは、注目の焦点はほぼスケーリングにありました。Blob容量が8倍に拡大され、PeerDASのランダムサンプリング検証と組み合わせることで、DA（データ可用性）分野のコストストーリーは完全に過去のものとなりました。確かに、より安価なL2は良いことですが、Ethereumの長期的なZKロードマップにとって、EIP-7825こそが本当のゲームチェンジャーです。なぜなら、Ethereumの単一トランザクションにGas上限（約1678万Gas）を設定したからです。ご存知の通り、今年EthereumブロックのGas Limitは6000万に引き上げられましたが、上限がいくら上がっても、理論上は非常に高いGas Priceを支払う意思があれば、誰でも超複雑な「メガトランザクション」を送信し、ブロック全体の6000万Gas容量を占有してブロックを詰まらせることができます。 では、なぜ単一トランザクションのサイズを制限するのでしょうか？実はこの変更は一般ユーザーの送金には全く影響しませんが、ZK Prover（証明生成器）にとっては生死を分ける違いです。これはZKシステムの証明生成方法とも密接に関係しています。簡単な例を挙げると、EIP-7825以前は、ブロックに6000万Gasを消費する「メガトランザクション」が含まれている場合、ZK Proverはこの非常に複雑なトランザクションを順番に処理しなければならず、分割も並列化もできません。これはまるで一車線の高速道路で、前に非常に遅い巨大トラックがいて、後ろのすべての車（他のトランザクション）がそれを通過するのを待たなければならないようなものです。これでは「リアルタイム証明」に直接死刑宣告を下すようなもので、証明生成の時間が全く制御できず、数十分、場合によってはそれ以上かかることもあります。しかしEIP-7825以降、将来的にブロック容量が1億Gasに拡大されても、各トランザクションは強制的に1678万Gas以内に制限されるため、各ブロックは予測可能で境界があり、並列処理可能な「小タスクユニット」に分解されます。これはEthereumの証明生成が、厄介な「論理問題」から、純粋な「計算力の問題（Money Problem）」に変わったことを意味します。十分な並列計算力を投入すれば、これらの分割された小タスクを同時に非常に短時間で処理でき、大きなブロックに対してZK証明を生成できるのです。 ただし、EIP-7825は単一トランザクションのサイズを制限することでリアルタイム証明の物理的な道（並列化可能）を整えましたが、これはコインの片面に過ぎません。もう一方は、Ethereumメインネット自体がこの能力をどう活用するかです。ここでEthereumロードマップの中でも最もコアなストーリー、つまりL1 zkEVMが関わってきます。長年、zkEVMはEthereum拡張の「聖杯」と見なされてきました。性能ボトルネックを解決できるだけでなく、ブロックチェーンの信頼メカニズムを再定義するからです。その核心は、EthereumメインネットがZK証明を生成・検証する能力を持つことです。言い換えれば、将来Ethereumの各ブロック実行後、検証可能な数学的証明を出力できるようになり、他のノード（特にライトノードやL2）は再計算せずとも結果の正しさを確認できます。もしZK証明生成能力をEthereumプロトコル層（L1）に直接組み込めば、提案者（Proposer）は各ブロックをパッケージしZK証明を生成し、検証ノードはトランザクションを再実行する必要がなく、この非常に小さな数学的証明を検証するだけで済みます。