Ethereum の大型アップデート「Fusaka」とは？PeerDAS を中心に解説

本記事の概要

“Fusaka” は、2025 年 12 月 3 日に Ethereum メインネットでリリースされた大型アップデートです。バリデータ・フルノードの運用に携わる方や、L2・スマートコントラクトの開発動向を追う方に向けて、技術的詳細と実務的影響を解説します。

（※ “Fusaka” は、Consensus Layer(CL)側のアップデートが “Fulu”、Execution Layer(EL)側のアップデートが “Osaka” とされていることから作られた造語です）

注: 本稿は 2025 年 10 月執筆時点の情報に基づいています。Fusaka アップデートは予定どおり 2025 年 12 月 3 日（UTC）にメインネットで有効化されました。Fusaka の次に来る大型アップデート Glamsterdam については 解説記事 を参照してください。

Fusaka アップデートの概要

目的と打ち手

本アップデートは、2025 年 5 月の Pectra に続く大型アップデートで、次を達成することを目標に開発されました。

（Blob とは、L2 などのデータを一時的に載せる安価なデータ領域のことです。「データ可用性」は、その Blob データを必要とする誰もがネットワークから取得できる状態を指します。）

• レイヤー2 におけるデータ可用性のスケーリング: PeerDAS の導入で Blob 数の上限を最大 8 倍まで拡大（理論値）し、L2 のトランザクション(TX)手数料を削減する
• レイヤー1 の TX 処理性能の改善: ブロックのデフォルトガスリミットを 45M から 60M へ引き上げ、多数の TX を発出するような DoS 攻撃の防止のため TX 単位でガス消費に上限を導入する
• ノードの運用コスト削減: PeerDAS によりストレージ要求性能を低減する
• UX と開発者体験の向上: 新規オペコード（Ethereum の実行環境が処理する基本命令）の追加で、ZKP（ゼロ知識証明）等の特定ユースケースの実装・ガスコストを削減する
• セキュリティと将来性の担保: Blob Parameter Only フォーク(BPO フォーク)による段階的な Blob スケーリングと、次エポックのブロックプロポーザーを前のエポック（約 6.4 分の単位期間）の時点で確定させる変更

Ethereum が掲げる Lean Ethereum ロードマップ（日本語の解説は 別記事 を参照）に沿った内容で、将来的な変更の下準備という性格が強いアップデートです。

対象となるEIPの一覧

本アップデートは、以下の表の EIP によって構成されます。EIP（Ethereum Improvement Proposal）とは、Ethereum の仕様変更を提案・記録する文書のことで、アップデートはこの単位で構成されます。対象範囲を定義するメタ EIP と情報提供 EIP を除くと 12 本です。

出典: EIP-7607: Hardfork Meta - Fusaka

Fusaka アップデートにおける一番の目玉機能とされている PeerDAS がどのような技術なのか、概要から説明します。

目玉機能 PeerDAS（EIP-7594: データ可用性サンプリング）

PeerDAS の概要

EIP-7594: PeerDAS は、P2P ネットワーク層に DAS（データ可用性サンプリング）機能を統合する提案です。DAS とは、データの一部だけを抜き取って検証し、全体が取得可能であることを確率的に確かめる手法です。

対象の Blob データ(128 KB)は、2024 年 3 月の Dencun アップデート（EIP-4844、Proto-Danksharding）で導入されました。EIP-7594 の目的は、この Blob の検証をしやすくすることです。

ノード間で Blob の保管責任を分散させ、全ノードに全データをダウンロードさせなくても、確率的にデータ可用性を検証できるようにします。下図は、PeerDAS が実装されたのち、Blob ごとにどのようにノードが処理することになるかを示した概略図です。

技術的詳細

ノードの処理とコンセンサスモデルを、次の前提のもとで説明します。

• 1 ブロック内には最大 48 個の Blob データが存在すると仮定する（ターゲット 6 の 8 倍という理論値で、実際のスケジュール上の最大は 21）
• 1 Blob(最大 128kB)を 64 に分割し、セル(最大 2kB)と呼ぶ
• Blob あたりのデータを符号化し、128 セルのデータに変換

※ 符号化とは、多項式化のことです。ここでは、Blob の 64 セルごとのデータ（[m_0, m_1, ..., m_63]）を使って、63 次の多項式 f(x) = m_0 + m_1 x + m_2 x^2 + ... + m_63 x^63 を生成します。128 セルのデータへの変換は、[f(0), f(1), ..., f(127)] の計算です。

直観的には、未知数（m_0 など）が 64 個なら、値も 64 個あれば方程式として解けます。解ければ任意の x に対して f(x) を求められ、係数部分を抜き出すことで元々の Blob データを復元できます。

元々は 64 セルのデータを逃さず取得しなければ Blob を復元できませんでした。符号化により、128 セルのうち 64 セルだけ取得できれば Blob を復元できる ようになりました。

PeerDAS について、処理を以下の流れで説明します。

• Blob の分割とノードへの割り当て
• コンセンサスのステップに従ったノードの PeerDAS 処理

Blobの分割とノードへの割り当て

1 Blob を 2kB ずつのセルに分割したのち、符号化によって 128 セル(各 2kB)に拡張します。例えば 6 Blob がある場合、全体は 6 行 128 列の行列です。

それぞれの列を Subnet と呼びます。各ノードが担当する Subnet 数は、おおむね ノードの合計ステークETH / 32 ETH に比例して増えます。ただし下限と上限があり、バリデータを動かすノードは最低 8 Subnet、バリデータを持たないフルノードでも 4 Subnet を担当し、上限は全 128 Subnet です。

担当する Subnet について、各ノードは Blob データのダウンロード・検証・保管・P2P での発出を行います。

また、そのノードが処理する Subnet のリストは NodeID から一意に生成できる([1,2,3,...,128] のようなリストの先頭から担当数分を用いる)ため、NodeID と担当 Subnet 数がわかれば、どの Subnet を処理するのか特定が可能です。いくつかの合計ステーク ETH の段階に分けて担当 Subnet 数を計算すると、以下のようになります。

• フルノード(ステーク 0ETH)：4 Subnet（下限）
• ソロバリデータ(ステーク 32ETH)：8 Subnet（下限）
• 中型バリデータ(ステーク 2048ETH)：64 Subnet
• 大型バリデータ(ステーク 4096ETH = 2048ETH のバリデータ 2 つ分)：128 Subnet(全 Subnet)

全ての Subnet のデータを提供するノードが Supernode です。中型バリデータの担当は 64 Subnet ですが、符号化により 128 セルのうち 64 セルあれば Blob を復元できるため、中型バリデータ以上は実質的に全 Subnet のデータを復元できます。

コンセンサスのステップに従ったノードのPeerDAS処理

PeerDAS は、ビーコンチェーンで次のように処理されます。1 スロット（12 秒）は 3 つのフェーズに分かれ、ブロックデータ生成・送信フェーズが 4 秒、受信・署名フェーズが 4 秒、残り 4 秒が署名の集約フェーズです（署名集約に PeerDAS は関係しないため、記載しません）。

最初のブロックデータ生成・送信フェーズ(0~4 秒)では、ブロックプロポーザーが全ての Blob データを集約し、ブロックデータを生成します。その後、Gossip プロトコル（受け取ったデータを隣接ピアへ次々と中継して網全体に広める P2P の伝搬方式）でピアに共有します。ブロックプロポーザーが実際に行う作業は、以下の通りです。

• Blob データを符号化し、Blob 数の行×128 列の行列に変換する
• Blob ごとに KZG コミットメント・KZG 証明（セルが確かにその Blob の一部であることを検証するための暗号学的データ）を発行する
• ブロックデータ・Blob データをピアに送信する

続くブロックデータの受信・署名フェーズ(4~8 秒)では、各ノードがブロックデータ及び Blob データを Gossip プロトコルでピアから受信します。次のような作業を各ノードが行います。

• 自分のノード ID といくつの Subnet を保有しているかを共有する
• 必要な Subnet に応じて、Gossip プロトコルで他のピアから Subnet のデータを送受信する
• Blob ごとの KZG コミットメント・KZG 証明を用いて、取得した Subnet データが確かにその Blob に含まれていることを検証する （※実際には Blob ごとに処理するのではなく、Blob ごとの KZG コミットメント・証明データを結合しまとめて検証する）
• 全データの検証が完了すれば、attestation（ブロックへの投票）を行う
• クライアントによっては(例: Prysm)、全 128 Subnet のうち 50%(64 Subnet)のデータが集まれば、ピアのデータを待たず、残りの Subnet データを再生成する

ブロックデータ生成・送信フェーズでは、ブロック・Blob データの送信も含めて 4 秒内に収めなければ有効なブロック提案とみなされません。そのため、Blob 数が増えれば増えるほど、必要となるリソース（特に帯域幅）が増大します。

例えば、2026/1/7 の BPO2 で、Blob の最大数は 21 に到達しました。符号化後の 1 Blob は 128 セル × 2kB = 256kB です。

4 秒のうち送信に使える時間を 3 秒と置くと、単独のピアに全データを送るだけで 21(blob) × 256(kB/blob) ÷ 3(s) = 1792(kB/s) = 14Mbps が最低限必要 です。当然、単独のピアだけではなく複数のピアにデータを送信するでしょうから、100Mbps 程度は Blob データのみで消費されることになります。

保有・検証するデータについては、PeerDAS のおかげで、従来の実装に比べ少なくなりましたが、帯域幅については従来の実装より増加していることに留意が必要です。

下図は、ブロックプロポーザーが 3 秒以内に 8 つのピアへ Blob データを送信すると想定した場合の、Blob 数ごとに必要となる帯域幅を示しています。

出典: Fusaka bandwidth estimation by ethPandaOps

その他の重要なEIPの詳細

Blob容量上限の上昇・段階的なBlobアップデート（EIP-7892）

Pectra の実装(2025/5/7)以降、Blob のターゲット数（最低手数料で利用できる数）は 6 つです。直近では相場の急変動もあり、利用率は 90% 以上に達しています。追加の手数料を払うことで、最大 9 個までの Blob を同一ブロックに格納できます。

とはいえ、さらに L2 が活発に利用されることを念頭に置けば、Blob の上限数・ターゲット数を継続的に増加させる必要があります。

下の図は、2025 年 4 月 14 日以降の日次での Blob 利用状況を示したものです。赤線を入れた 42K は、Blob のターゲット数（6）に 1 日の Ethereum ブロック数（約 7,100）を掛けた、1 日あたりのターゲット Blob 数のおおよその水準です。日次の利用数が徐々にこのラインに近づいてきているのが見て取れます。

出典: Daily Blobs by blobscan

そこで今回実装されたのが、Blob のパラメータのみを更新する新たな種類のフォーク、Blob Parameter Only Hardforks（以下、BPO）です。BPO により、Blob のターゲット・最大値等のパラメータは段階的に引き上げられます。

通常のハードフォークより短い間隔で更新できるため、Fusaka アップデートや BPO 自体の影響をモニタしながら、市場の拡大に合わせてパラメータを上げていけます。PeerDAS の実装に伴って Blob のターゲット・最大値を大きくしやすくなったことから、Fusaka アップデートに組み込まれました。

パラメータは、次のスケジュールで段階的に更新されました。

出典: Fusaka Mainnet Announcement (Ethereum Foundation Blog)

ブロックガス上限の上昇/トランザクションガス制限（EIP-7935 & EIP-7825）

Ethereum のブロックガス上限は、2025 年 7 月 21 日に 45M まで引き上げられたばかりです。直近の平均ガス利用率は下図の通り 50% ほどで、トランザクション処理には余裕があります。

出典: Average gas limit by Blockscout

しかしながら、ブロックによっては利用率が 90% を超え、下図の 6 か月間の平均ガス価格にも表れているように、ガス代への影響は残っています。そのため、ガス上限の引き上げは継続した取り組みになっています。

出典: Average gas price by Blockscout

Fusaka アップデートでは、ブロックガス上限を 60M に引き上げます(EIP-7935)。この引き上げにより、スループットの向上とガス価格の安定化が見込まれます。

このアップデートに組み合わせ、トランザクションごとにガス制限を適用する(EIP-7825) ことで、ブロックガス上限の緩和効果を最大化しようとしています。単一のトランザクションが消費できるガスは、プロトコルのルールとして約 17M ガス（2^24 ガス。現行のブロックガス上限の 1/3 強）までに制限されます。

一つの TX がブロックの大部分を占有して検証負荷を集中させる事態を防げるため、ガス上限を安全に引き上げられます。

この制限を超えるトランザクションを想定している場合は、コントラクトの再設計が必要です。

ブロックプロポーザーの事前決定（EIP-7917）

従来、次エポック(1 エポック=32block ~ 6.4 分)におけるプロポーザーは必ずしも確定していませんでした。そのため、近年話題になっている Preconfirmation（指定のトランザクションを指定のタイミングで取り込むことを事前に約束する技術）においても、この点が障害になると考えられていました。

Fusaka アップデートでは 次エポックのプロポーザーを事前に確定する ため、この障害は解消します。

こちらは、すぐに効果が出るのではなく、将来的な UX 改善に向けた対応です。

バリデータ・フルノード運用者、L2・コントラクト開発者への影響とまとめ

バリデータ・フルノード運用者への影響

ノード運用者にとって影響が大きいのは、PeerDAS（EIP-7594）と、Blob 容量上限の上昇・段階的な Blob アップデート（EIP-7892）です。どちらも、ノードのストレージ利用量と通信の帯域幅消費に直結します。また、eth/69 のノード間通信の簡易化(EIP-7642)により不要なデータ(Bloom)を返さない仕様となり、帯域幅消費は縮小される見込みです。

ethPandaOps の試算では、PeerDAS の実装により、ステーク量の少ないバリデータの性能要件はむしろ緩和されます。逆に、多数のバリデータを運用する事業者や、ステーク量の大きいバリデータでは、帯域幅要件がより厳しくなる見込みです。

下図は、複数のステーク量タイプにおける、ストレージ利用(Blob 関連のみ)・ブロック提案時の帯域幅を示しています。担当 Subnet 数に換算すると、320ETH は 10 Subnet、1024ETH は 32 Subnet に相当します。

320ETH をステークしているバリデータの Blob 数ごとのストレージ利用量

1024ETH をステークしているバリデータの Blob 数ごとのストレージ利用量

320ETH をステークしているバリデータの Blob 数ごとのブロック提案時のデータ送信速度

1024ETH をステークしているバリデータの Blob 数ごとのブロック提案時のデータ送信速度

出典: Fusaka bandwidth estimation by ethPandaOps

320ETH までのステークでは、20 Blob を超えたとしても、ストレージ利用量は Fusaka アップデート前より依然として低く収まります。問題となるのは、ブロック提案時の帯域幅です。提案の機会は各バリデータに時折しか回ってきませんが、その瞬間には全 Blob データを集約し、署名のためピアに提供しなければならないため、Blob 数が増えるほど帯域幅が必要となります。

一部のクライアントには、実行レイヤー（EL）から Blob データを受信して処理する仕組みや、--max-blobs のような上限 Blob 数を規定するフラグが実装されている場合があります。帯域幅の制限が想定されるなら、クライアントの機能をご確認ください。

Layer2開発者への影響

Layer2 開発への影響の中心は、DA（データ可用性レイヤー。L2 がデータの保存先として使う領域）である Blob の容量・コストを直接動かす 2 本、PeerDAS（EIP-7594）と Blob 容量上限の上昇・段階的な Blob アップデート（EIP-7892）です。その他にも、EIP-7939 のような、ZK Rollup の構築者にとってメリットの大きい EIP が実装されました。

スマートコントラクト開発者への影響

スマートコントラクト開発で最も影響が大きいのは、ブロックガス上限の上昇とトランザクションガス制限（EIP-7935 & EIP-7825）です。多くのコントラクトには影響しませんが、単一 TX のガス消費が上限を超えるような複雑なコントラクトを構築している場合は、機能の分割等の対応が必要になります。

まとめ

Fusaka アップデートは、12 本の EIP を束ねた、スケーラビリティ中心の大型ハードフォークです。目玉としては PeerDAS がよく取り上げられますが、ノード運用者の帯域幅要件からコントラクトのガス制限まで、各ステークホルダーに関わる細かな変更も数多く含まれています。

TX 処理性能のさらなる拡大や Preconfirmation など、効果が出るのはこの先の変更と組み合わさってからという EIP が多い点も、本アップデートの特徴です。

Omakase は Ethereum ステーキングの運用代行事業者（SSP, Staking Service Provider）として、PeerDAS をはじめとする本アップデートのクライアント対応やノード運用要件の変化を継続的に追っています。