▼目次
本レポートでは、イーサリアムの大型アップグレード、フサカ（Fusaka）について、概要を解説します。
今回のフサカ（Fusaka）アップグレードは、2025年5月のペクトラ（Pectra）アップグレードに続くメジャーアップデートであり、ロールアップ（L2）の手数料削減やユーザー体験の向上を主な内容としています。
ペクトラ（Pectra）の計画が複雑さのため二分割された結果、フサカ（Fusaka）では特にデータ可用性や性能向上に焦点を絞った内容になっています。
関連レポート：イーサリアム（ETH）の大型アップグレード｜ペクトラ（Pectra）の概要・投資家に与える影響
上記関連レポート執筆時点では、Ethereum Improvement Proposal (EIP)-7594 PeerDASを記載していますが、これはフサカ（Fusaka）に含まれることとなります。
フサカ（Fusaka）のメインネット実施は最短でもHoodiテストネット（10月28日）から30日以上後で、正式日程は日本時間2025年12月4日です。
本レポートでは、イーサリアムのフサカ（Fusaka）アップグレードに含まれるEIPの概要、主要なEIPの詳説、実施スケジュール、そして投資家への影響や関係者が取るべき対応について解説します。
イーサリアムのアッグレード・フサカ（Fusaka）の概要
フサカ（Fusaka）に含まれるEIPの一覧
EIP-7607: Hardfork Meta - Fusaka
コアEIP
- EIP-7594: PeerDAS (データ可用性サンプリング)
- EIP-7823: MODEXPの上限を設定する
- EIP-7825: 取引ガス制限キャップ
- EIP-7883: ModExp ガスコストの増加
- EIP-7917: 決定論的なプロポーザの先読み
- EIP-7918: 実行コストによって制限される BLOB 基本料金
- EIP-7934: RLP実行ブロックサイズ制限
- EIP-7939: 先頭のゼロをカウントする (CLZ) オペコード
- EIP-7951: secp256r1 曲線サポートのプリコンパイル
その他のEIP
- EIP-7892: BLOBパラメータのみのハードフォーク
- EIP-7642: eth/69 - マージ前のフィールドを削除する
- EIP-7910: eth_config JSON-RPC メソッド
- EIP-7935: デフォルトのガス制限を60Mに設定する
フサカ（Fusaka）アップグレードには13件（内9件がコア）のEIPが含まれ、大きく分けて、
- データ可用性とブロブ（Blob）拡張に関するもの
- ネットワーク性能・安全性強化に関するもの
- ユーザー体験の向上に関するもの
が実装されます。
以下、それらEIPの概要です。
なお、主要なEIPについては後段で詳細を記載します。
EIP-7594: PeerDAS（ピア・データ可用性サンプリング）
フサカ（Fusaka）最大の主要機能です。
各ノードがブロブデータの全量ではなく一部（1/8程度）を保持することで、L2が投稿するデータ（ブロブ）の負担を軽減し、データ可用性を分散チェックできるようにします。
ブロブとは、ここではL2が、Ethereum（L1）にデータを記録するため専用のデータ容量のことを指します。
これにより、データの欠落を限りなくゼロに近く押さえながら、ブロブデータ容量を理論上8倍まで拡大しつつ、データ全体の50%があれば全データを再構成できるようになります。
ノードの容量負担軽減、L2のデータ投稿量増加に対応し、手数料の低廉化とスケーリングを実現します。
EIP-7892: Blobパラメータのみのハードフォーク（BPO: Blob Parameter Only）
ブロブ数拡張の柔軟化を目的とした仕組みです。通常、ネットワーク規則を変えるには大規模ハードフォークが必要ですが、BPOフォークではブロブのターゲット数・最大数といったパラメータだけを調整する小規模フォークを可能にします。
これによりL2の需要増に合わせて主要アップグレードを待たず迅速にブロブ容量を増やすことができます。
例えば、デンクン（Dencun）アップグレードでブロブターゲット数3だったものがペクトラ（Pectra）で6に引き上げられ、フサカ（Fusaka）以降はこの値をさらに段階的に増加させていけるようになります
EIP-7918: ブロブ手数料の実行コスト連動
ブロブデータ投稿時に支払うブロブ手数料（blob fee）の価格安定化を図る改善です。現状ではL2が支払うブロブ手数料と、その検証に必要な実行Gasコストの比率によっては、ブロックが空いているとブロブ手数料が最低の1 Weiまで下がり価格シグナル機能を果たさない恐れがありました。EIP-7918では各ブロブに比例配分の最低価格（リザーブ価格）を設け、実行Gasが高騰してもブロブ手数料が1 Weiに張り付かないよう調整します。
結果として、「常にブロブ手数料がネットワーク混雑に反応する」「L2はブロブによって生じる計算負荷相応の最低手数料を支払う」「L1手数料が急騰してもブロブ手数料が無意味に安いままになる事態を防ぐ」といった効果があります。
EIP-7823: MODEXPプリコンパイルの入力サイズ上限
大きな数値のmodular exponentiation（モジュラー累乗計算）を行うMODEXPプリコンパイルについて、入力値のビット長に上限（8192ビット=1024バイト）を設定します。
従来はほぼ無制限のサイズを取れたため、異常に巨大な入力でテストやセキュリティ検証が困難でした。
上限超過の入力があればトランザクション失敗（Gasは消費）とすることで、現実的なユースケースを十分カバーしつつ極端な悪用を防止します。
ネットワークのDoS耐性を高めつつ、通常ユーザーや開発者の利用には影響しない変更です。
EIP-7825: トランザクションGas使用量の上限設定
1トランザクションで消費できるGas量の上限を16,777,216（2^24）に制限します。
現在のブロックあたりGas上限（約45M, フサカ（Fusaka）後はさらに増加予定）より小さい値を設定することで、1件の巨大トランザクションがブロック全体を占有してしまう事態を防ぐDoS対策です。
上限値2^24は現在一般的なコントラクトデプロイや複雑な計算にも十分な大きさであり、既存平均ブロックサイズにも近い妥当な水準とされています。
EIP-7883: MODEXPプリコンパイルのGasコスト増加
MODEXPのGas価格モデルを実際の計算コストに見合うよう引き上げます。
具体的には、最低料金を200→500Gasに増やし、EIP-2565由来の1/3割引を撤廃、さらに非常に長い指数（exponent）を与えた場合は長さに応じ指数関数的にコスト増加、そして巨大な底数（base）や法数（modulus）が32バイトを超える場合もサイズに比例して追加コストを課すよう変更します。
これらにより、「1件のMODEXP処理がブロック検証時間ほぼ全てを占有する」ような極端な状況を防ぎ、将来的なGas上限引き上げに耐えられるようにします。
EIP-7934: 実行ブロックのRLPエンコードサイズ上限
ブロックデータ全体のサイズ上限を10MiBに設定し、そのうち2MiBはコンセンサス用データ枠として確保します。
実行層ブロック（トランザクションなど）のRLPエンコード長（ブロックをネットワーク転送する際の実際のバイト長（符号化サイズ））が約8MiBを超えるものは無効とする予定で、これはブロック伝搬・検証時間が過度に長くなることを防ぎ、ネットワーク分岐やDoSリスクを低減する目的です。
なおコンセンサス層のゴシップネットワーク（ノード間がブロックやトランザクションをピアツーピアで広める伝達網）でも約10MiB超のブロックは元々転送されないことになるため、実行層も足並みを揃える形です。
EIP-7935: ブロックGasリミット（デフォルト値）の引き上げ
バリデータの投票によって決まるブロックあたりGas上限のデフォルト目標値を約6000万Gasに引き上げることを調整する提案です。
Merge（2022年9月）以降長らく3,000万で据え置かれていたガス上限は、2025年2月に36M、45Mまで徐々に上昇させてきました。
本EIPは各クライアント実装にFusakaサポート版でより高い標準Gas上限を採用するよう促すことを目的としたEIPです。
Fusaka時点では60M程度を目標としており、同時に前述のトランザクション単位Gas上限（EIP-7825）を導入することで、ガス枠拡大に伴う単一Txの悪影響を防ぎます。
EIP-7917: ブロック提案者の決定的先読みを可能に
コンセンサス層（Beaconチェーン）において、次のエポックにおける各スロットのブロック提案者を事前に決定・公開するよう変更する提案です。
これにより、ユーザートランザクションを事前に次提案者へコミットしてもらい「プレコンファメーション」（事前確約）を得ることが技術的に可能になります。
また提案者スケジュールを固定化することで、従来懸念されていた「バリデータが提案権を悪用してスケジュールを操作する」リスクをなくし、実装の簡素化とネットワークの安全性向上にもつながるとされます。
例えばDeFi（ディーファイ）トレード等で「次のブロックで必ず実行される」という保証を提案者から取り付けることで、ユーザー体験の向上やMEV（提案者利益）の公正な分配に繋げる試みが考えられています。
またスケジュール固定化によりごく一部とはいえバリデータが提案順を操作する余地が無くなり、ネットワークの公正性・安全性が高まるメリットもあります。
EIP-7939: 先頭ゼロビット数カウント（CLZ）オペコード
EVMに新しい命令「CLZ」を追加し、256ビット値中の先頭（最上位側）に連続するゼロビットの個数を返す機能を提供します。
これまでコントラクト上で同様のビット操作を行うには複雑な工夫が必要でしたが、ワンステップの低コストOpcode（オペコード）にすることでビット列解析や高速な数学演算がシンプルかつガス節約で実装できるようになります。
多くのCPUで一般的な命令をEVMに導入することで、効率的なコントラクト開発を支援します。
EIP-7951: secp256r1楕円曲線（P-256）対応プリコンパイル
新たな組み込みプリコンパイルコントラクトを追加し、広く用いられている楕円曲線secp256r1（別名: P-256）によるデジタル署名の検証をオンチェーンで可能にします。
アドレス0x100に固定で配置され、引数・戻り値の形式は既に多くのL2で採用されているインタフェースに合わせられているため、L2上のコントラクトやライブラリをL1へ移植しやすいよう配慮されています。
この機能追加により、ユーザーはスマートフォンやハードウェアセキュリティモジュール（Secure EnclaveやAndroid Keystore等）で生成されたデバイスネイティブ鍵（パスキー）を直接Ethereumで利用可能になります。
EIP-7642: Eth/69プロトコルからのMerge以前フィールド削除
開発者向け情報として、P2PネットワークのEth/69に残っていたプルーフオブワーク時代の不要な項目（例: 難易度）を削除する変更です。
これはコンセンサスには影響しませんが、実装各社はフサカ（Fusaka）までにこれを適用しておく必要があるとされました。
なお2025年7月には実行クライアントにおいてマージ（Merge）以前のヒストリデータ削除（History Expiry）がサポートされ、チェーン初期からの古い履歴を切り捨ててフルノードのディスク負荷を大幅軽減する措置も取られています。
フサカ（Fusaka）ではこの履歴削除機能と他変更の組み合わせテストも行われました。
EIP-7910: eth_config JSON-RPCメソッド
ノードが現在稼働中および今後予定されているアップグレード設定を問い合わせられる新RPCです。current（現在有効フォーク）、next（次回フォーク設定）、last（直近フォーク）といったスナップショットを返し、チェーンIDやフォークID、予定時刻、アクティブなプリコンパイル、システムコントラクトやブロブスケジュールなどの情報を含みます。
PectraのHoleskyテストネット適用時に一部クライアントのフォーク設定不一致から非Finalizationが起こった反省を踏まえ、バリデータや開発者が事前に設定ミスを検知できるツールとして導入されました。
以上がフサカ（Fusaka）に含まれるEIPの一覧と概要です。次章では、この中でも特に投資家やエコシステムに与える影響が大きい主要提案について掘り下げます。
主要EIPの詳細
イーサリアム（ETH）の（Fusaka）アップグレードを語る上で特に重要となる提案について、技術的背景や狙いを詳しく解説します。
ブロブデータのスケーリング – PeerDAS (EIP-7594) と BPOフォーク (EIP-7892)
L2の普及に伴い、L1にはますます大量のブロブ（Rollupトランザクションデータ）が処理されるようになっています。
出典：https://l2beat.com/scaling/activity（2025/10/28時点）
従来、各フルノードはすべてのブロブデータをダウンロード・保存してデータ可用性を確保していましたが、将来的にブロブのスループットが増え続けると各ノードへの負荷が帯域・ストレージ面で肥大化し持続不可能になり得ます。
EIP-7594 PeerDAS（Peer Data Availability Sampling）はこの課題に対するソリューションであり、データ可用性サンプリングという手法を用いて各ノードが全ブロブの一部のみを保持・検証できるようにします。
PeerDASでは、ネットワーク内のノードがそれぞれブロブデータの断片をランダムに受け持つ形で分散保管します。
各ブロックに含まれるブロブを縦横に分割した「データマトリクス」を考え、各ノードは特定の「列」部分を担当（custody）しつつ、他のノードからもいくつかランダムな列をサンプリング検証します。
これにより、理論上各ノードは全データの1/8のみを保持すれば良く、8倍のブロブ数をネットワークで安全に処理可能になります。
肝心の可用性確保については、断片化されたデータのうち半分（50%）が揃えば全体を復元可能となる高度なデータ復元コーディングが採用され、データ欠落の確率は10^(-20)〜10^(-24)程度と暗号学的に無視できる水準に抑えられています。
PeerDASの導入により、各ノードのハードウェア・回線要件を現実的な範囲に維持しながら、L2向けデータ容量を飛躍的に拡大し手数料低減を図ることができます。
出典：関連記事「イーサリアム（ETH）の大型アップグレード｜ペクトラ（Pectra）の概要・投資家に与える影響」より
もっとも、PeerDASでスケーラブルになったとはいえ、一度に扱うブロブ数を一気に増やすのはリスクがあります。
大規模アップグレードは十分なテストと全ノードの同時更新が必要で時間がかかるため、L2側の需要変化に機動的に対応しづらいという問題もありました。
そこで提案されたのがEIP-7892 BPO（Blob Parameter Only）フォークです。BPOフォークとは、ブロブ関連のパラメータ（目標ブロブ数targetおよび最大ブロブ数max）だけを変更するミニハードフォークであり、これにより主要アップグレードの合間にもブロブ数を徐々に増やすことが可能になります。
具体的には、クライアントソフトウェアがあらかじめ定めた時刻にブロブ数上限を引き上げる設定を組み込んでリリースされ、ノード運営者はそれにアップデートするだけで小規模フォークに参加できます。
ユーザーやバリデータは個別の対応を必要としない点で、従来のGasリミット投票による漸次調整に近い運用が実現します。
なお、Dencunで導入されたブロブは当初 target=3、Pectraで6に増加しましたが、フサカ（Fusaka）後はBPOフォークにより、
- メインネットBPO1（Fusaka 後数週間）：ターゲット 10、最大 15（約 2/3 増）
- メインネットBPO2（BPO1 の数週間後）：ターゲット 14、最大 21
という流れで増加させる予定です。
PeerDASおよびBPOフォークの組み合わせにより、イーサリアム（ETH）はL2の取引需要に応じて迅速にデータ容量を拡張できることになります。
これはL2手数料の低下や利便性向上を通じて、最終的に全体の利用拡大と価値向上につながる重要なステップとなるものです。
ブロブ手数料モデルの改良 – EIP-7918 (Blob Base Feeの下限設定)
L2がL1にデータを投稿する際には2種類のコストを支払っています。
ひとつはブロブ手数料、もうひとつはブロブを検証するために消費する実行レイヤーのGas手数料です。
もしL1側が混雑してGas単価が高騰すると、相対的にブロブ手数料の負担感は軽くなり、ブロブBase Feeオークションが極端に下方向へ圧力を受けます。
その結果、ブロブ手数料が1Weiまで低下して価格シグナルとして機能しない恐れが指摘されてきました。
EIP-7918では、この問題に対処するため、各ブロブに最低価格相当の底値を敷くイメージです。
これにより、
- 常にブロブ市場が需要に反応するようになり、需要減少時でも手数料がゼロ近くで固定化しにくくなる
- ブロブによってL1ノードに課す計算負荷に見合った最低限の費用を必ず支払う
- L1側のGas基本料がスパイクしても、ブロブ手数料が1Weiに張り付いてしまう現象が解消される
ことが見込めます。
secp256r1プリコンパイルによるUX向上 – EIP-7951
フサカ（Fusaka）でもっともユーザーエクスペリエンス（UX）に直結する改善が、このsecp256r1曲線対応プリコンパイルです。
secp256r1（別名P-256）はビットコイン等で使われるsecp256k1とは異なる楕円曲線ですが、現在パスキー（FIDO2/WebAuthn）やTLS証明書、スマートフォンのセキュリティチップなど幅広い分野で標準採用されているアルゴリズムです。
従来L1ではこの曲線を直接扱えず、例えばAppleのSecure Enclave（セキュアエンクレーブ）やGoogleのTitan Keyで生成した鍵を使った署名はSolidityのスマートコントラクトでは検証困難でした。そこでEIP-7951により、secp256r1署名をチェーン上で高速に検証する専用関数が提供されます。
具体的にはパスキーを使ったウォレットが実現可能となり、シードフレーズ不要で生体認証等による鍵管理が可能となります。
例えば専用デバイスやスマホの安全領域に格納された鍵で直接イーサリアム（ETH）の取引に署名できるため、秘密鍵の流出リスク低減やリカバリーの容易さが期待されます。
複数のL2（例：OP Stack系）では、RIP-7212（secp256r1/P-256 検証プリコンパイル）が既に導入されており、EIP-7951は同一インターフェースでこれをL1に導入するものです。
これにより、RIP-7212 を前提に書かれた L2 向けコントラクトの L1移植性（互換性）が高まる見込みです。
イーサリアムのアップグレード・フサカ（Fusaka）のスケジュール
フサカ（Fusaka）アップグレードはテストネットで2025年10月に段階的に実施され、本番のメインネット適用は2025年12月3日が予定されています。
具体的なスケジュールは次のとおりです。
出典：All Core Devs - Consensus (ACDC) #168より筆者作成（JST変換）
https://github.com/ethereum/pm/issues/1772
具体的なブロック高やエポックはクライアント各社のアップデートで告知される見込みですが、12月上旬のターゲットが明示されたことで利用者や事業者も準備がしやすくなりました。
上記のフサカ（Fusaka）フォーク適用後、さらにBPOフォークが順次行われ、ブロブ数の拡大が段階的に進められます。
このようにフサカ（Fusaka）本体とBPOフォークはセットで進行するため、ネットワーク参加者は両方の予定に注意を払う必要があります。
フサカ（Fusaka）アップグレードによる投資家への影響
フサカ（Fusaka）アップグレードは技術的に大きな進歩ですが、イーサリアム（ETH）保有者や一般ユーザーに直接要求される対応は基本的にありません。
まず強調すべきは、このアップグレードによって新たなコインやトークンが発行されるものではないという点です。
したがって、ウォレットにあるイーサリアム（ETH）を別のコントラクトに交換したり新チェーンのETHとスワップしたりする必要は一切ありません。
もし「アップグレードに伴いイーサリアム（ETH）を移行せよ」といった案内が出回っても、それは詐欺である可能性が極めて高いため注意する必要があります。
ネットワーク利用者（送金やDeFi利用者など）にとっても、アップグレード当日に特別な手続きは不要です。
ただし、アップグレード直後は一時的に取引所が入出金を停止したり、ブロック生成が不安定になる可能性もゼロではないため、重要な送金等は事前に済ませておく慎重さが望まれます。
このアップグレードがイーサリアム（ETH）のファンダメンタルズへどのような影響を与えるか、ですが、PeerDASとBPOフォークによりL2取引手数料が大幅に低下し得るため、アービトラム（Arbitrum）やオプティミズム（Optimism）、BaseといったL2上の利用が一段と促進されると期待されます。
L2上での活発な経済活動は最終的にL1の需要（データ投稿やブリッジ利用など）も押し上げ、ETHへの需要増につながる可能性はあります。
ただしL1のガス代自体が直ちに安くなるわけではなく、L1料金市場へ直接影響は限定的と捉えるのが一般的と思われます。
したがって、投資家としては「イーサリアム（ETH）全体のスケーラビリティやUX向上が長期的成長を支える」という視点で捉えるのが適切でしょう。
開発者への影響
ノード運営者やステーキング事業者にとって、フサカ（Fusaka）対応は必須となります。
アップグレードに参加するすべてのノード（実行クライアントとコンセンサスクライアントの双方）について、各クライアントチームがリリースするフサカ（Fusaka）対応版へバージョンアップを行う必要があります。
スマートコントラクト開発者にとって、フサカ（Fusaka）は後方互換性をほぼ損なわないアップグレードですが、ウォレット事業者にとっては、パスキー対応という大きなチャンスがあると思われます。
イーサリアム（ETH）上でのユーザー体験（UX）の改善により、オンボーディングのハードルが下がり、結果として利用者層の拡大が期待されます。
取引所やカストディアンなどイーサリアム（ETH）を預かる事業者は、社内で稼働中のノードや関連システムをアップグレードし、Forkフォーク当日の入出金停止計画を顧客に周知するなど、他のハードフォーク時と同様の対応が求められます。
今回新設されたeth_configRPCにより、自社ノード群が正しくフォーク設定されているか事前検証できるため、このようなツールも活用してダウンタイムや事故を防ぐことが重要です。
総括
フサカ（Fusaka）アップグレードは、2025年12月に予定されているイーサリアム（ETH）の主要なプロトコル改良であり、スケーラビリティ・セキュリティ・ユーザー体験を総合的に強化する重要な節目となります。
これは、Ethereum Foundation（イーサリアム・ファウンデーション）が進める「Scale L1」「Scale Blobs」「Improve UX」という3つの開発戦略の重要な実装フェーズであり、とりわけPeerDASによるレイヤー2スケーリングとsecp256r1プリコンパイルによるウォレットUXの改善が象徴的な成果です。
フサカ（Fusaka）は、イーサリアム（ETH）の「The Surge（ザ・サージ）」フェーズをさらに前進させるアップグレードとして、レイヤー2中心のエコシステムをより効率的かつ安定的に運用できる基盤を整備します。
これにより、L2取引の増加とそれに伴うL1へのデータ投稿需要が拡大し、長期的にはイーサリアム（ETH）経済圏全体の活性化につながる可能性があります。
また、次期ネットワークアップグレードとして言及される「Glamsterdam（グラムステルダム）」（仮称）では、EVM Object Format（EOF）や提案者・ビルダー分離（ePBS）、ブロックアクセスリスト（BAL）といった提案が議論されています。
これらはフサカ（Fusaka）の次段階として、EVM効率化やブロック生成構造の改善を通じ、イーサリアム（ETH）をより軽量で持続可能なネットワークへと進化させることを目指しています。
フサカ（Fusaka）は、イーサリアム（ETH）の技術的成熟とエコシステムの拡張を両立させるための重要なマイルストーンです。
今後の発展を見据えつつ、アップグレード期にはノード運営者・事業者・ユーザーそれぞれが最新情報を確認し、予期せぬトラブルに備えることが重要です。
参考文献
● EIP-7607: Hardfork Meta - Fusaka
● Fusaka 🦓: (ethereum.org) Blog
● Checkpoint #6: Oct 2025
● Checkpoint #5: July 2025
● Fusaka Update – Transaction Gas Limit Cap arrives with EIP-7825
● Fusaka Update - Information for Blob users
● Fusaka Testnet Announcement
● Fusaka $2,000,000 Audit Contest!
● Holešky Testnet Shutdown Announcement
● Protocol Update 003 — Improve UX
● Protocol Update 002 - Scale Blobs
● Protocol Update 001 – Scale L1
● lean Ethereum
【ご注意事項】
本記事は執筆者の見解です。本記事の内容に関するお問い合わせは、株式会社HashHub（https://hashhub.tokyo/）までお願いいたします。また、HashHub Researchの各種レポート（https://hashhub-research.com/）もご参照ください。
提供：HashHub Research
執筆者：HashHub Research
