Fusakaアップグレードのまとめ

サマリー

Fusaka は、2025年12月3日にメインネットでアクティベートされた Ethereum の大型ハードフォークで、2025年5月の Pectra に続くその年2回目のメジャーアップグレードです。

一言でいうと、

• L2 ロールアップのためのデータ可用性レイヤーを大きく拡張しつつ

• 各ノードの負荷をむしろ軽くするための仕組み（PeerDAS と Verkle Trees）を導入し

• 同時に L1 ブロックガス上限の引き上げ と トランザクションごとのガス上限キャップ によって

  • スループット向上

  • DoS 耐性

  • 将来の並列実行（Glamsterdam 以降）への布石

をまとめて実施したアップグレードです。

また、passkey 対応（P-256）や CLZ opcode など UX や開発者体験に関わる細かい改善も多数含まれます。

結果として、

• L2 向けの blob データ容量は 最大8倍 に拡張され

• ロールアップ手数料はすでに 数十％〜70％程度下がっている とするレポートも出ています

• ETH のバーン量も増え、「Ethereum のキャッシュフロー資産としての側面が一段強化された」と評価するレポートもある状況です
  

---

1. Fusaka とは

• 名称

  • コンセンサスレイヤー側のコードネーム「Fulu」と、実行レイヤー側の「Osaka」を合わせた造語が Fusaka。

• アクティベーション

  • メインネット: 2025年12月3日

  • Epoch 411392 の slot 13164544 で有効化

• ハードフォークの性質

  • 後方互換性のないプロトコル変更（ハードフォーク）であり、クライアントはアップデート必須

  • 約 12 個前後の EIP から構成される「束」としてのアップグレード（正式な一覧は Meta EIP-7607 にまとまっている）

主な目的

1. L2 中心の世界に合わせたデータ可用性の拡張

   • Rollup が L1 に投稿する blob データの処理方式を抜本的に変え、L2 のスループットを 8 倍レベルで拡張すること

2. ノードリソースの抑制と分散性の維持

   • PeerDAS（Peer Data Availability Sampling）と Verkle Trees を組み合わせて
     「たくさんのデータを扱うのに、各ノードはすべてをダウンロードしなくてもよい」状態を作る

3. ユーザー体験と開発者体験のアップグレード

   • ブロックガス増加＋preconfirmations によるほぼ即時の UX

   • P-256（secp256r1）サポートによる passkey ログイン対応

   • EVM opcode 追加や fee market の調整によるプロトコルの「掃除」

---

2. Ethereum ロードマップの中での Fusaka の位置付け

2.1 Dencunからの流れ

• Dencun（Deneb + Cancun, 2024年3月13日）

  • EIP-4844（proto-danksharding）で「blob 取引」を導入し、L2 が書き込むデータを安価な一時ストレージに分離

  • L2 手数料は最大 90％以上削減され、「ロールアップ向けの専用バスレーン」を作ったイメージとよく説明されますKuCoin+2a16z crypto+2

ここで「L2 のデータを blob に逃がす」まではできたものの、

• L2 の利用が増えると 全ノードがすべての blob をダウンロードする構造がボトルネックになりつつあった、というのが Fusaka につながる問題意識です。

2.2 Pectraから Fusaka へ

• Pectra（Prague + Electra, 2025年5月7日） は、

  • EIP-7702 によるアカウントアブストラクション（EOA を一時的にスマートアカウントとして扱える）

  • EIP-7251 などによるステーキング UX・セキュリティの改善
    で、「ウォレット体験」「ステーキング体験」の改善にフォーカスしたアップグレードでした。

• Fusaka はその 約半年後の第2弾として、

  • 「スケーリングの本丸（The Surge 路線）」にもう一歩踏み込むアップグレードという位置付けです。ロールアップ向けデータの処理と、L1 のガス上限引き上げが中心。
    

2.3 Glamsterdam や Surge / Verge / Purge との関係

• Glamsterdam（2026予定）

  • ePBS（enshrined Proposer-Builder Separation, EIP-7732）で MEV とブロックビルダーの集中を和らげる

  • BALs（Block-level Access Lists, EIP-7928）でブロック内でアクセスする state を事前宣言し、実行の予測可能性を高める
    

• The Surge / The Verge / The Purge の中で見ると

  • Surge: ロールアップとデータ可用性の拡張により 100,000+ TPS を目指すフェーズ

  • Verge: Verkle Trees による軽量ノードと stateless client

  • Purge: 履歴データ削除とプロトコルの簡素化によるノード負担の削減
    

Fusaka はここで

「Surge のスケーリング（PeerDAS / blob 拡張）」と
「Verge / Purge 系の準備（Verkle, state / history の整理）」

を一つのハードフォークに束ねた“橋渡し”的なアップグレードになっています。

---

3. Fusaka が解決しようとしている具体的な問題

3.1 L2 ロールアップの“データ詰まり”

• L2 はトランザクションの実行そのものは L2 で行うものの、
  最終的なデータ（ログ・ state 差分）を L1 に blob として投稿します。

• Dencun 以降、この blob が激増し、

  • L2 側は「もっと blob を使いたい」

  • L1 ノードは「全部ダウンロードするのはキツい」
    という利害のズレが顕在化し始めていました。

3.2 ノードスペックのインフレと分散性のトレードオフ

• ブロックガスリミットを上げればスループットは増えますが、

  • フルノードの CPU / 帯域 / ストレージ要件が重くなり

  • 結果として「データセンターっぽい強いマシンしかフルノードを回せない」世界になりかねない

• Ethereum の開発者はずっと「スケーラビリティと分散性を同時に満たす」ことを強く意識しており、Fusaka では PeerDAS や Verkle でこのトレードオフを押し返そうとしています。
  

3.3 UX と経済設計のラグ

• ユーザー目線では

  • 数分かかるコンファーム

  • メールアドレスや passkey に慣れた世界から見ると、シードフレーズ中心の UX
    が Web2 と比べて見劣りしていました。
    

• 経済設計としても

  • blob 手数料がほぼゼロ近辺に張り付く期間が長く、データの価値が価格に反映されにくい

  • L2 オペレーターのコスト負担と ETH ホルダーの価値捕捉の整合性が弱い
    といった指摘がありました。
    
    

---

4. Fusaka を構成する主要コンポーネントと EIP

ここでは、実際の EIP ベースで「何がどう変わったのか」を整理します。

4.1 PeerDAS（EIP-7594）

• PeerDAS（Peer Data Availability Sampling）は、
  「各ノードが blob 全体をダウンロードする代わりに、小さな断面サンプルだけを検証する」仕組みです。

ざっくり技術イメージ

• これまで:

  • 各ノードは blob データを丸ごと（row）取得して検証

• Fusaka 以降

  • blob 全体を「行」ではなく「列（column）」方向に分割し、

  • 各ノードはランダムにいくつかの列をサンプリング

  • 再構成可能性（全体がちゃんとあるか）は、サンプルの成功/失敗確率から統計的に保証する

→ 全ノードがデータの断面だけを見る構造にすることで、

• 見ているデータ量は大幅に減る

• しかし「誰も全体を持っていない」という状況は、確率的にほぼ起こらないよう設計されている

結果として、Ethereum は

• blob 容量を最大 8 倍まで増やしつつ

• 各ノードの帯域やストレージ要求を制御できるようになります。

これが 「The Surge で目指す 100,000 TPS」 に向けた実質的な第一歩とされています。

4.2 Verkle Trees 関連

Verkle Tree とは

• Merkle Patricia Tree の代わりに使う新しい state データ構造で、

  • 高い分岐数（高 branching factor）

  • ベクターコミットメント（vector commitment）を使ったコンパクトな証明
    が特徴です。

Fusaka で入った要素

• 代表的には

  • EIP-6800（統一 Verkle state 提案）とその周辺の state 変換系 EIP（EIP-7748 など）が一部取り込まれた

  • state を Verkle 向けに整理していくための足場が作られています。
    

役割

• Verkle Trees を導入していくことで、

  • witness（検証に必要な最小限の state + 証明）を非常に小さくできる

  • それにより「ローカルにフル state を持たない stateless client でもブロック検証が可能」になる
    

• 長期的には

  • フルノードのストレージ要件を減らし

  • より多くの個人がノードを走らせられる環境を作ることが狙いです。
    

Fusaka 時点では Verkle 完全移行ではなく、「Verkle 時代に入るための前処理」という位置づけですが、これが Verge / Purge フェーズの実現に直結します。

4.3 ガスリミット

4.3.1 ブロックガスリミット引き上げ（EIP-7935 ほか）

• 複数のリサーチ/取引所レポートによると、Fusaka によって

  • ブロックガスリミットはおおよそ 45M → 最大 150M まで拡張可能になったとまとめられています。
    

• ただし、実際の「運用上のデフォルト値」は慎重に上げていく前提で、

  • EIP-7935 ではクライアントのデフォルト値を 60M にする、というような保守的な設定からスタートし、

  • ネットワーク状況を見ながら段階的に引き上げるというアプローチがとられています。

→ 重要なのは、「ガス上限を上げることが本質ではなく、それを安全にやるためのガードレール群とセット」で入っているという点です。

4.3.2 トランザクションごとのガスキャップ（EIP-7825）

• EIP-7825 は、1トランザクションあたりのガス使用量を 2^24 ≒ 16.78M にキャップする提案です。

• これにより、

  • 「1つの巨大トランザクションがブロック全体を食い尽くす」事態を防ぎ、

  • 将来の並列実行（マルチスレッド EVM や Glamsterdam 以降の実行モデル）への準備にもなります。

開発者視点のインパクト

• 大型デプロイや巨大バッチトランザクションは、
  「1 tx に全部詰め込む」のではなく、「複数 tx に分割する設計」が必要になります。

• これは「DoS になりうるパターンを、EIP レベルで構造的に潰しに行っている」と理解すると見通しが良くなります。
  

4.4 Blob fee market と DA 経済設計（EIP-7918 ほか）

• EIP-7918 は「blob の base fee を L1 ガスコストにバインドする」提案で、

  • blob 手数料がほぼゼロに張り付くのを防ぎ

  • L2 が使うデータ資源のコストが、より正しく ETH 経済に反映されるようにします。
    

• これにより

  • L2 オペレーターは「タダ同然の blob」を使い倒すことが難しくなり

  • 代わりに、安くはあるけど現実的な価格を支払うことで、
    ETH のバーンやバリデータ報酬とよりきれいに整合するようになります。
    

4.5 UX と開発者体験 – P-256, CLZ, calldata fee market

代表例:

1. P-256 / secp256r1 サポート（EIP-7951）

   • WebAuthn / passkey に使われる楕円曲線 P-256 をネイティブサポートし、

   • 「スマホの生体認証 → そのまま Ethereum アカウントにサイン」という UX を実現しやすくします。
     

2. CLZ opcode 追加（EIP-7939）

   • 「先頭のゼロビットの数を数える」命令で、

   • bit 操作が多い zk 系プロトコルやパッキングされたデータ処理を高速化します。
     

3. Calldata 用の独立 fee market（EIP-7706）

   • calldata に専用の base fee と per-block limit を導入し、

   • blob と同様に、用途別に料金体系を分ける動きの一環です。
     

こうした小さめの EIP 群をまとめてみると、Fusaka は

「L2 とデータ可用性だけではなく、ウォレット UX や zk / ロールアップインフラの開発体験も同時にチューニングする“インフラ世代交代”」

という性格を強く持っています。

---

5. 実際の影響

※初日〜数週間時点の観測

5.1 L2 手数料と blob 容量

• 各種レポートによると、

  • PeerDAS と blob パラメータ調整により、L2 の DA コストが 40〜70％程度削減される可能性が示されています。

  • 実際に Fusaka アクティベーション後、主要ロールアップ（Base, Arbitrum, Optimism など）の手数料低下が観測されているとする記事も出ています。

• blob 容量は理論上 8倍 に拡張され、ロールアップのトランザクション容量が大きく増えました。
  

5.2 ETH のバーンと価格への示唆

• blob base fee の下限が L1 ガス価格に紐付けられたことで、

  • L2 が高負荷なときには ETH のバーンが増える構造が強まっています。

• 一部の市場レポートは、

  • Fusaka によってネットワークの料金収入とバーンが増え、

  • ETH が「キャッシュフローを持つプロトコルトークン」としての性格を強めた、と評価しています。
    

5.3 ノードオペレーターへの影響

• ブロックガスリミットの引き上げにより

  • 1ブロックあたりの処理量とインデックス対象データが増える一方で

  • PeerDAS / Verkle によって「個々のノードが実際に処理・保存するデータ量」は抑制されます。

• 実際、Fusaka 有効化直後には、

  • Prysm クライアントで一時的にバリデータ参加率が 25％ほど落ち込んだものの、

  • 迅速なパッチにより数時間でほぼ回復した、とレポートされています。
    

→ これは、ブロックチェーンレベルの「大手術」をやりながらもネットワークを止めずに乗り切ったという意味で、
開発体制の成熟を示すデータポイントでもあります。

5.4 ユーザー体験とウォレット

• Fusaka により

  • passkey / P-256 サポートがプロトコルレベルで入り、

  • 大手ウォレットや取引所は passwordless ログインや端末の生体認証を活用した UX の実装を進めています
    

• preconfirmations による「ミリ秒〜数秒レベルの事前コンファーム」基盤が整ったことで、

  • ユーザーから見える「送金したのにいつまでも pending」という体験は
    今後徐々に解消されていくと考えられます。

---

6. Glamsterdam と長期ロードマップ

Fusaka はGlamsterdamのような次フェーズへの前提条件としての側面をもちます。

6.1 Glamsterdam（2026）の主役 EIP

• 既に資料が出ているものだけでも、

  • EIP-7732: ePBS (enshrined Proposer-Builder Separation)

  • EIP-7928: BALs (Block-level Access Lists)

  • gas / state の大規模な再プライシングパッケージ
    といった EIP 群が Glamsterdam のコアとして検討されています

• block time の短縮（12秒 → 6秒）案も議論されており、
  Fusaka で太くなったブロックを、Glamsterdam で「より細かい刻みで流す」ような世界観が見えています。
  

6.2 Surge / Verge / Purge のステージング

• Fusaka: PeerDAS と Verkle 前処理で「データ可用性」と「state の構造」を整えた

• Glamsterdam: ePBS と BALs で、ブロックビルドと実行のパイプラインを整理

• その後のフェーズ

  • full danksharding

  • 完全な Verkle stateless client

  • history expiry（EIP-4444 系）
    などが入る、と整理すると、全体像が掴みやすくなります。
    
    

---

7. まとめ

1. Fusaka は“また1回のハードフォーク”ではなく、Ethereum のインフラ構造を一段階引き上げる節目だった

   • データ可用性（PeerDAS）

   • state 表現（Verkle 前処理）

   • ガスと fee market の構造
     を同時にいじり、「L2 中心の Ethereum」を現実的な形にしたアップグレードと捉えるのが本質的です。

2. スケーラビリティと分散性のトレードオフに対する Ethereum 流の回答が具体化した

   • 単純にブロックガスを上げるのではなく、
     「サンプリング」「統計的保証」「コンパクトな証明」といった暗号学的・統計的な工夫を組み合わせることで、
     各ノードの負担を抑えたままスループットを上げる道筋を見せたと言えます。
     

3. アップグレードは L1 の話ではなく、L2 / インフラ / ウォレットを含むエコシステム全体の再設計だった

   • OP Stack の「Fusaka readiness」や、L2 各社の事前調整

   • passkey 対応や preconfirmations による UX 変化
     など、実際にはかなり多くのプレイヤーを巻き込んだ協調行動として進んでいます。

4. Fusaka 自体が終点ではなく、Glamsterdam と Surge / Verge / Purge への“準備運動”

   • ここで得られる運用データや、PeerDAS / Verkle 実戦投入の経験が、
     次の ePBS や full danksharding, 完全 stateless client の設計にそのままフィードバックされていきます。

5. 投資・ビジネス的には、「ETH がどこで価値を回収するのか」がかなりクリアになってきた

   • blob fee の下限設定や L2 DA コストの見直しにより、
     「L2 経済圏の成長＝ETH の手数料収入とバーンの増加」に近づく構造が明確になっています。

最後まで読んでくださりありがとうございました。

by Keita, Fracton