解決策：このEIPは、特別な「Blobパラメータ専用ハードフォーク（Blob Parameter Only Hardfork, BPO）」の仕組みを定義します。このアップグレードは非常に軽量で、Blobに関連するいくつかのパラメータだけを変更します（たとえば1ブロックあたりの目標Blob数など）。複雑なコード改修は行いません。ノード運用者はクライアントソフトのアップグレードすら不要で、指定された時刻に新しいパラメータを受け取るだけで済みます。これは、ソフトウェアにオンラインで設定ファイルを更新するように簡単です。
スケールアップと同時に、ネットワークの安全性と安定性を確保しなければなりません。イーサリアム財団は2025年5月に「万億ドル安全計画（Trillion Dollar Security, 1TS）」を開始し、万億ドル規模の資産を安全に担保できるイーサリアムネットワークを構築することを目標としています。Fusakaに含まれる複数のEIPは、1TS計画の推進そのものであり、高速走行するイーサリアムに、より信頼できる「ブレーキ」と「ガードレール」を取り付けるようなものです。
拡張と安全性の両立：イーサリアム Fusaka アップグレードの12のEIPを徹底解説
作成者：@ChromiteMerge
イーサリアムは2025年12月3日に「Fusaka」と呼ばれるハードフォークのアップグレードを迎えます。このアップグレードには全部で12件のイーサリアム改善提案（EIP）が含まれており、12個の精密な部品のように連携して、イーサリアムのスケーラビリティ、安全性、そして稼働効率を共に高めます。以下、筆者がこの12個のEIPをカテゴリ別に、わかりやすい言葉で、それぞれがどんな問題を解決するのか、そしてなぜそれがイーサリアムの未来にとって重要なのかを解説します。
スケールアップ！イーサリアムをより速く、より多くの取引を
これがFusakaアップグレードの中核テーマです。イーサリアムは世界のデジタル経済を支える必要があるため、取引の混雑と高額な手数料の問題を解決しなければなりません。以下のEIP群はまさにこの目標のために設計されており、とりわけLayer 2の拡張でコストを下げ、効率を高めることに焦点が当てられています。
EIP-7594: PeerDAS - データ可用性のサンプリング
課題：DencunアップグレードでLayer 2向けの安価なデータ保存として「Blob」が導入されたことで、次の重要な問題が生じました。それは、これらの大量のデータが本当に利用可能であることをどう保証するか、という点です。現状では、各バリデータノードが、あるブロックに含まれるblobデータの全てをダウンロードして検証することが求められています。1つのブロックに最大9個のBlobまで含まれるのであれば、このやり方でもまだ現実的です。しかし将来的にBlobの数がさらに増える（たとえば128個）と、全blobのダウンロードと検証のコストが高騰し、バリデータが参加するためのハードルが引き上げられ、ネットワークの分散化が脅かされます。
解決策：PeerDAS（Peer Data Availability Sampling）は、従来の「全部チェック」を「サンプリングして抽出確認」へと置き換えます。簡単に言うと：
ネットワークは完全なblobデータをスライスする。
各バリデータは、全てのblobをダウンロードする必要はなく、いくつかのデータ断片をランダムにダウンロードして確認するだけでよい。
その後、みんなが互いに抽出確認し、検証結果を交換することで、blobデータ一式の完全性と可用性を共同で確証できる。
これは、大型のパズルゲームのようなものです。各人は手元に数枚のピースしか持っていなくても、重要な接続部分を互いに照合できれば、パズル全体が無事であると判断できます。なお、PeerDASは全く新しい発明というわけではありません。その中核となるDASの考え方はCelestiaなどのサードパーティDAプロジェクトで既に成功裏に実践されています。PeerDASの実装は、イーサリアムの長期的な拡張ロードマップに対し、重要な「技術的負債」の穴埋めをするようなものです。
意義：PeerDASはバリデータの保管負担を大幅に軽減し、イーサリアムが大規模なデータ拡張を行う際に分散化を弱めかねない障害を取り除きます。将来的には、各ブロックに数百個のBlobを収容できる可能性があり、Teragasが掲げる最大1000万TPSというビジョンを支えます。同時に、一般の人でもバリデータを容易に運用でき、ネットワークの分散化を維持できます。
EIP-7892: BPOハードフォーク - パラメータ更新の軽量化
課題：Layer 2のデータ容量に対する市場の需要は瞬く間に変動します。もしBlobの上限値を調整するたびに、Fusakaのような大規模アップグレードを待つ必要があるなら、それでは遅すぎて、生態系の発展のテンポに追いつけません。
解決策：このEIPは、特別な「Blobパラメータ専用ハードフォーク（Blob Parameter Only Hardfork, BPO）」の仕組みを定義します。このアップグレードは非常に軽量で、Blobに関連するいくつかのパラメータだけを変更します（たとえば1ブロックあたりの目標Blob数など）。複雑なコード改修は行いません。ノード運用者はクライアントソフトのアップグレードすら不要で、指定された時刻に新しいパラメータを受け取るだけで済みます。これは、ソフトウェアにオンラインで設定ファイルを更新するように簡単です。
意義：BPOの仕組みにより、イーサリアムはネットワーク容量を迅速かつ安全に調整する能力を持てます。たとえば今回のFusakaアップグレード後、コミュニティは短期間に連続して2回BPOアップグレードを実施し、段階的にBlob容量を2倍にする計画です。これにより、イーサリアムは必要に応じて、柔軟かつ漸進的にblob空間を拡張でき、L2のコストとスループットが滑らかに向上し、リスクもより制御しやすくなります。
EIP-7918: 安定したBlob手数料市場
課題：従来のBlob手数料の調整メカニズムは「需給に追随しすぎる」ため、いくつかの意図しない問題が生まれていました。まず、Blobに対する需要が非常に低いと手数料がほぼゼロまで下がりますが、これは新たな需要を効果的に刺激するどころか、異常な「歴史的最安値」という状況を作り出します。逆に需要が高いと、blob feeは急騰し、もう一つの極端な高価格の状況を作ります。このような激しい価格の「価格競争（内巻き）」によって、Layer 2の手数料計画は左右に振られ、難しい判断を迫られます。
解決策：EIP-7918の核心は、Blob手数料を際限なく無制限に変動させるのではなく、妥当な価格レンジ、つまり弾力的な「最低限の支払い（最低消費）」を設定することです。実現方法は、blob feeの上下限（limits）を、Layer 1上でのLayer 2の実行コスト（execution fee）に連動させることです。状態ルートの更新であれ、ZK証明を1回検証することであれ、これらの実行コストは比較的安定しており、L2ブロック内の取引量との関係は大きくありません。したがって、blob feeの上下限をこの安定した「アンカー」に結びつければ、価格の乱高下を防げます。
意義：この改善の直接的な利点は、Blob手数料市場の「内巻き」を防ぎ、Layer 2プロジェクトの運営コストモデルをより予測可能にすることです。そうすることで、Layer 2はエンドユーザーに対し、より安定的で合理的な取引手数料を設定でき、「今日は無料、明日は天文学的な値段」というジェットコースターのような体験を避けられます。
EIP-7935: メインネットの取引容量の向上
課題：イーサリアムの各ブロックが収容できる取引の総量は、「ブロックGas上限」（現在は約3000万）によって決まっており、何年も調整されていません。ネットワーク全体のスループットを高める最も直接的な方法は、この上限を引き上げることですが、必ずバリデータノードのハードウェア要件を引き上げないこと、そして分散化の度合いを低下させないことを保証しなければなりません。
解決策：この提案は、ブロックのデフォルトのGas上限を新しい水準まで引き上げることを示唆します（具体的な数値は未確定で、4500万、あるいはそれ以上の可能性があります）。これは強制的に固定するものではなく、新たな推奨デフォルト値を提示して、合意層のバリデータが段階的により高いGas上限を受け入れるよう導くものです。
意義：これは、各Layer 1ブロックにより多くの取引をパッケージングできることを意味し、イーサリアムのメインネットのTPSが直接的に向上します。ネットワークの混雑やGas手数料の急騰は緩和されるでしょう。もちろん、バリデータにはより高い要件が課されるため、コミュニティは慎重にテストし、推進していきます。
安全と安定！ネットワークに盤石な防衛線を
スケールアップと同時に、ネットワークの安全性と安定性を確保しなければなりません。イーサリアム財団は2025年5月に「万億ドル安全計画（Trillion Dollar Security, 1TS）」を開始し、万億ドル規模の資産を安全に担保できるイーサリアムネットワークを構築することを目標としています。Fusakaに含まれる複数のEIPは、1TS計画の推進そのものであり、高速走行するイーサリアムに、より信頼できる「ブレーキ」と「ガードレール」を取り付けるようなものです。
EIP-7934: ブロックの物理サイズ上限を設定
課題：イーサリアムの「ブロックGas上限」は、ブロック内の全取引の総計算量だけに関心があり、ブロックの物理サイズについては規定されていません。これにより穴が生じます。攻撃者は、膨大な「低コスト・大容量」の取引を巧妙に構築できます（例：大量のアドレスへ0 ETHを送金するなど）。計算量は極めて低いのにデータ量は大きいからです。その結果、計算量は上限を大きく超えないのに、物理的な体積が異常に大きいブロックがパッケージされます。このような「データ爆弾」ブロックはネットワーク内で極めてゆっくり伝播し、一部のノードがデータをタイムリーに受け取れずに遅れを生じ、深刻なDoS（サービス拒否）攻撃リスクにつながります。
解決策：各ブロックのサイズに10MBのハード上限を設定します。この体積を超えるブロックは、ネットワークにより拒否されます。
意義：これは、公道のトラックに最大サイズを定めるようなものです。「過度に幅広い・長すぎる」車両が交通に悪影響を与えることを防ぎます。これにより、ブロックがネットワーク内で素早く伝播でき、遅延が減り、ネットワークの安定性と攻撃耐性が高まります。
EIP-7825: 1件あたりの取引Gas上限を設定
課題：現在はブロックに総Gas上限がありますが、単一の取引には上限がありません。理論上、誰かがブロック資源のほぼ全てを消費するような取引を構築し、他の全員の取引を押し出すことができます。これは不公平であり、安全上のリスクもあります。
解決策：各取引に1677万Gasのハード上限を設定します。この規模を超える複雑な操作は、提出前に複数の取引へ分割してから行う必要があります。
意義：これによりネットワークの公平性と予測可能性が向上します。どの取引も「貸し切り」をできないようにし、ユーザーの通常の取引が「超大型の一口（スーパー大口）」のせいで過度に遅延しないようにします。
EIP-7823 & EIP-7883: ModExpのプリコンパイル安全性強化
課題：ModExpは、イーサリアムにおいて大きな数のべき乗剰余（幂模演算）を処理する機能で、よく暗号学的なアプリケーションで使われます。しかし2つのリスクがあります。1つ目は、入力数字の長さに上限がないため、悪意ある超巨大な入力で「処理を詰まらせる／撑爆」可能性があること。2つ目は、Gasの課金基準が低すぎて、攻撃者が低コストで大量に呼び出し、ノードのリソースを消費し得ることです。
解決策：
EIP-7823：ModExpの入力長に8192ビットの上限を設定し、この長さは実際のアプリケーション要件を十分に満たす。
EIP-7883：ModExpのGas課金を引き上げます。特に入力が大きい場合には料金が急激に増加するようにし、計算コストとリソース消費が見合うようにする。
意義：この2つの改善は二正面から攻撃ベクトルを取り除きます。これは、計算サービスに「最大作業量」を定め、さらに「段階的な電力価格」を調整して、濫用を防ぐようなものです。これによりネットワーク全体の堅牢性が高まります。
機能アップグレード！開発者により強力なツールを
スケーラビリティと安全性に加えて、Fusakaは開発者のためにいくつかの実用的な新ツール／機能も提供し、イーサリアム上でのアプリ構築をより効率的で、より強力にします。
EIP-7951: 主流ハードウェア署名への互換
課題：日常的に使っているスマホ（例：iPhone）、銀行のU盾、ハードウェアセキュリティモジュールなどのデバイスには、内蔵のセキュリティチップが、secp256r1（P-256とも呼ばれる）という暗号標準を使っていることが一般的です。一方、イーサリアムのデフォルトは別の標準secp256k1を使用しているため、これらの主流デバイスがイーサリアムと直接安全に連携できず、Web3の大規模普及が制限されています。
解決策：新たなプリコンパイルのコントラクトを追加し、イーサリアムがネイティブにsecp256r1曲線からの署名をサポート・検証できるようにします。
意義：これは画期的な改善です。イーサリアムが、世界中の数十億台のハードウェアデバイスへ向けた扉を開くことになります。将来的にあなたはスマホ内のセキュリティチップで直接イーサリアム取引に署名でき、追加のウォレットアプリや複雑な変換は不要になります。よりスムーズで、安全性も高い体験が得られるはずです。これにより、従来の世界からイーサリアムへ接続する際のハードルが大きく下がり、Web2とWeb3の融合にとって大きな追い風となります。
EIP-7939: 新しいCLZ高効率計算命令
課題：スマートコントラクトや暗号学的アプリケーションでは、256ビットの数の先頭に存在する連続したゼロビット数（たとえばハッシュアルゴリズム、圧縮アルゴリズム、ゼロ知識証明などの場面）を計算する必要があることがよくあります。現在、イーサリアムのEVMには、この操作を直接サポートするOpcodeがありません。開発者は複雑なSolidityコードで実装せざるを得ず、コストが高くつき、効率も低くなります。
解決策：EVMに「CLZ（Count Leading Zeros）」というOpcodeを追加し、ワンステップで計算を完了させます。
意義：これは、開発者に時短・省力のためのプロ向けツールを提供するようなものです。関連演算のGasコストを大きく削減でき、複雑な数学計算に依存するアプリケーション（特にZK Rollups）をより安価に、より効率的に動かせます。
ネットワーク最適化！見えない改良で、健全なエコシステムへ
最後の2つのEIPは、ユーザーの体感は弱いものの、ネットワークが長期的に健全に稼働し、調整効率を高めるうえで極めて重要です。
EIP-7642: 新規ノードの同期負担を軽減
課題：時間の経過とともに、イーサリアムは膨大な量の過去データを蓄積してきました。新規ノードがネットワークに参加するには、それら全てのデータをダウンロードして同期する必要があり、時間も労力もかかって、門戸はますます高くなっています。さらに、イーサリアムはThe Merge以降PoSの合意に移行したため、旧来の取引受領（取引収集）情報の中には、もはや保存する必要のないいくつかのフィールドが残っており、冗長性が生じています。
解決策：新規ノードが同期時に一部のあまりにも古いデータをスキップできるようにする「履歴データの期限切れ」戦略を導入します。同時に、取引領収書のフォーマットを簡素化し、不要な冗長フィールドを削除します。これにより、新規ノードが創世ブロックから同期を行う際に、大量の無用データのダウンロードを省けます。
意義：この改善は、ノード運用を「スリム化」するためのものであり、毎回の全ノード同期で約530GBのデータ転送を削減できます。門戸が低くなることで、より多くの人がノードを運用でき、ネットワークの分散化と堅牢性が強化されます。
EIP-7917: 決定的なブロック生成順序と事前確認（預確認）
課題：このEIPの重要性を理解するには、まず現在のLayer 2 Rollupが抱える核心的な課題である集中化されたシーケンサー（Sequencer）について話す必要があります。現在、ほとんどのRollupは単一の主体がユーザーのL2取引を受け取り、順序付けすることに依存しています。これにより、それらは取引の検閲やMEVの抽出を行う権限を持ってしまい、分散化の精神と相反します。この問題を解決するため、コミュニティはBased Rollupという構想を提起しました。L2自身のシーケンサーをあえて捨て、L2取引を並べ替えるためにイーサリアムL1のブロックProposerを直接利用し、L1の分散性と中立性を継承する、という考えです。
しかし、この方式には致命的な欠点があります。それは遅いことです。Layer2はL1ブロックがチェーンに書き込まれてから取引を実行し始める必要があり、遅延が大きく、体験が悪いのです。この唯一の解法は「事前確認（pre-confirmation／預確認）」の仕組みを導入することです。つまり、L2のGatewayが将来のL1提案者から前もって約束を取り付けます：「あなたが提出した取引を必ずブロック上に載せる。さもなければ補償する」。そうすればLayer 2はユーザーの待ち時間を減らすために、アカウント残高などの状態を先に更新できるのです。ですが、現在のように提案者がランダムに決まる仕組みでは、ゲートウェイは誰に連絡して交渉すべきかを知ることができず、信頼できる事前確認は成立しません。
解決策：EIP-7917は合意プロトコルを変更し、今後一定期間のProposerの順序が、事前に計算されて確定的に公開されるようにします。これは「その場の抽選」ではなく、誰もが確認でき、事前に並べられた「ブロック生成の当番表（出番表）」になります。
意義：この改善は、Based Rollupなどの次世代分散化ソリューションを実現するための重要な土台です。この「当番表」があれば、L2ゲートウェイは将来のあるブロックの提案者を事前に特定し、直接交渉して、Slash（スラッシュ）罰金で担保された信頼できる事前確認を得られます。これにより、Based RollupはL1レベルの分散性と安全性を享受しつつ、ユーザーに対して中心化されたSequencerに近い即時取引体験も提供できます。つまり、EIP-7917はイーサリアム・エコシステムをより深い「分散化」へ向けて拡張し、極めて重要な扉を開くものだと言えます。
なぜ Fusaka のアップグレードはちょうどいいタイミングなのか？
今回のFusakaアップグレードは、単なる技術の反復ではなく、伝統的金融がRWAとステーブルコインを大量にオンチェーンする時代背景のもとでのイーサリアムの重要な戦略的アップグレードでもあります。現在、主戦場であるイーサリアムは、全ネットワークのステーブルコイン供給の56%以上を担っており、グローバルなデジタル・ドル経済の中核決済レイヤーになっています。Fusakaの目的は、「ウォール街」級の資産と取引量を迎える準備が整うことです。
伝統的金融機関の参入が進むにつれ、特定ニーズ（例：KYCのコンプライアンス）に合わせてカスタムされたLayer 2の「専用チェーン」が増えていくでしょう。これらの専用チェーンには、イーサリアムのメインネットが、膨大で安価かつ安全なデータ保存領域（＝Data Availability）を提供する必要があります。
Fusakaに含まれるEIP-7594、EIP-7892、そしてEIP-7918などの提案は、この需要を満たすことを目的としています。その核心的な目標は1つだけです。Layer 2のデータ公開コストを大幅に引き下げ、必要に応じて拡張できる柔軟性を提供することです。
実際のところPectraアップグレード後はBlobの手数料はすでにかなり低いのに、なぜさらに圧縮するのか？ Fusakaは「短期の手数料収入を犠牲にし、その代わりにより大規模な経済活動を得る」という戦略を採っています。ネットワーク全体のGDPを押し上げ、より多くの取引をより多くのステーキングとETHのバーンにつなげることで、ネットワーク全体の価値を支える狙いです。
万億ドル規模の資産を管理する金融機関にとって、安全性は越えられない最低ラインです。イーサリアム・コミュニティも「万億ドル安全」という壮大な目標を掲げています。Fusakaに含まれるEIP-7934、EIP-7825、EIP-7823、EIP-7883は、まさに城壁を強固にし、潜在的な安全上のリスクを除去して、この目標に向かうためのものです。
要するに、Fusakaアップグレードの主軸は明確で揺るぎません。スケールアップと安全性です。規制面での追い風と市場の熱狂という二重の推進力のもと、Fusakaのアップグレードはまさに時宜を得ています。これはイーサリアムが政策の追い風をつかみ、ステーブルコインや資産のオンチェーン分野での覇権的地位を強固にし、イーサリアムをさらに「投機資産」から主流の金融インフラへと進化させる手助けになるでしょう。
結語：静かな水の流れのような変革
2025年末の重要なアップグレードとして、Fusakaは大規模な市場の投機的炒り上げがないまま、黙々とイーサリアムに強力な内的推進力を注入しました。含まれる12件の改善はすべて、スケールアップ、安全性、効率の3つの主要な課題を真正面から捉えています。Fusakaがやっているのは、イーサリアムという「価値の高速道路」の道幅を広げ、その収容能力と信頼性を高め、将来の大量のユーザー、資産、そしてアプリに備えることです。
一般のユーザーにとっては、これらの変化は「静かに」見えるかもしれませんが、その影響は計り知れません。より強力で、より高効率で、より安全なイーサリアムは、これまで想像するしかなかった壮大なビジョンを実現できる力を持ちます。たとえば、世界規模の即時決済ネットワークや、「オンチェーン・ウォール街」です。Fusakaは、その未来へ向かう確かな一歩なのです。