本記事の概要
本年 12 月 3 日に Ethereum メインネットへのリリースが予定されている、"Fusaka"アップデートについて、バリデータ・フルノードの運用に携わる方、または L2 及びスマートコントラクトの開発者に向けて本アップデートの技術的詳細と実務的影響を解説します。
(※"Fusaka"は、Consensus Layer(CL)側のアップデートが"Fulu"、Execution Layer(EL)側のアップデートが"Osaka"とされていることから作られた造語)
Fusaka アップデートの概要とタイムライン
目的と打ち手
本アップデートは、2025 年 5 月の Pectra に続く大型アップデートで、次を達成することを目標に開発されています。
- レイヤー2 におけるデータ可用性のスケーリング
- PeerDAS を導入することで、Blob 数の上限を最大 8 倍まで拡大（理論値）
- L2 のトランザクション(TX)手数料を削減
- レイヤー1 の TX 処理性能の改善
- ブロックのデフォルトガスリミットを 45M から 60M へ上昇
- 多数の TX を発出するような DoS 攻撃の防止のため、TX 単位でガス消費に上限を導入
- ノードの運用コスト削減
- PeerDAS によるストレージ要求性能の低減
- UX と開発者体験の向上
- 新規オペコードの追加による、ZKP 等特定ユースケースでの実装・ガスコスト削減
- スマートコントラクトの容量上限を 2 倍(48kB)に緩和
- セキュリティと将来性の担保
- Blob Parameter Only フォーク(BPO フォーク)により、段階的な Blob のスケーリング実現
- ブロックプロポーザーを前エポックで確定
Ethereum で掲げられている、 Lean Ethereum ロードマップにも整合しており、将来的な変更の下準備としての側面が大きいです。
対象となるEIPの一覧
本アップデートは、以下表の 12 本の EIP によって構成されます。
| 種類 | EIP番号 | 名称 | 主な機能 |
|---|---|---|---|
| スケーラビリティ関連 | EIP-7594 | PeerDAS | P2Pのデータ可用性サンプリング機能。ノードはBlobデータのうち1/8のみを取得し、符号化により8倍のBlobスケーリングを可能にする |
| スケーラビリティ関連 | EIP-7892 | Blob Parameter Only ハードフォーク | Blob関連の設定のみを修正可能とする、軽量版のハードフォーク機能(6/9から10/15、14/21へと段階的に増加） |
| 容量・セキュリティ関連 | EIP-7935 | デフォルトガスリミットを60Mに設定 | デフォルトガスリミットを45Mから60Mへ引き上げ |
| 容量・セキュリティ関連 | EIP-7825 | トランザクションごとのガスリミット上限 | 単一トランザクションを16,777,216ガス（=2^24ガス）に制限してDoS防止 |
| 容量・セキュリティ関連 | EIP-7934 | ブロックへのバイト単位サイズ上限の設定 | CLのブロック伝搬プロトコルの制限に合わせ、ブロックの容量を最大10MiBに制限 |
| オペレーション最適化 | EIP-7823 | MODEXPへの入力値のサイズ上限設定 | MODEXPのプレコンパイルコントラクトに1024バイトの入力値制限をつけ、バグ等の低減 |
| オペレーション最適化 | EIP-7883 | MODEXPのガスコスト増加 | MODEXPのプレコンパイルコントラクトについて、ベースコストを引き上げ、実際のリソース利用に応じた価格設定に修正 |
| オペレーション最適化 | EIP-7918 | ブロックのベースガス料金とBlobベース料金を連動 | Blobのベース料金を当該ブロックのベースガス料金に比例させ、実際のその時点でのリソース利用に応じた価格設定に修正 |
| オペレーション最適化 | EIP-7917 | ブロックプロポーザーの事前決定 | 次エポックのブロックプロポーザーを事前に確定し、信頼性の高いスケジューリングを実現 |
| 開発者ツール | EIP-7939 | CLZオペコードの追加 | CLZ(先頭からゼロをカウントする)命令を追加し、SP1/RiscZeroのようなゼロ知識証明の計算コストを低減 |
| 開発者ツール | EIP-7951 | secp256r1のプレコンパイルコントラクトの追加 | 既存のRIP-7212における P-256曲線のネイティブサポート（コントラクトアドレス0x100）のセキュリティバグ修正を行い・ガスコストを最適化 |
| データ管理 | EIP-7642 | eth/69にブロック範囲記載の追加、不要なデータ項目の削除 | eth/69でのノード間通信において、ノードが提供できるブロック範囲を記載し、基本使われていなかったデータ項目(Bloom)を削除し、帯域幅利用を削減 |
| サポート/情報提供EIP | EIP-7910 | eth_config JSON-RPC メソッド | フォーク状況の確認・ノードのアップデート状況の確認を容易化 |
| サポート/情報提供EIP | EIP-7607 | FusakaスコープのメタEIP | Fusakaアップデートで扱う範囲・対象を定義 |
Fusaka アップデートにおける一番の目玉機能とされている、PeerDAS がどのような技術なのか、概要から説明します。
新技術 PeerDAS
PeerDASの概要
EIP-7594: PeerDAS（データ可用性サンプリング） は、P2P ネットワーク層に DAS(データ可用性サンプリング)機能を統合する提案です。Pectra に含まれていた、EIP-4844（Proto-Danksharding）で導入された Blob データ(128 KB)の検証をしやすくすることを目的としています。ノード間で Blob 保管責任を分散させ、全ノードに全データをダウンロードさせることをコンセンサスルールとせず、確率的にデータ可用性を検証できるようにします。下図は、PeerDAS が実装されたのち、Blob ごとにどのようにノードが処理することになるかを示した概略図です。
技術的詳細
以下の前提に応じて、ノードの処理とコンセンサスモデルを説明します。
前提は次の通りです。
- 1 ブロック内には最大 48 個の Blob データが存在する
- 1Blob(最大 128kB)を 64 に分割し、セル(最大 2kB)と呼ぶ
- Blob あたりのデータを符号化し、128 セルのデータに変換
※ 符号化とは、多項式化を指します。ここでは、Blob の 64 セルごとのデータ([m_0, m_1, ..., m_{63}]
f(x) = m_0 + m_1 x + m_2 x^2 + ... m_{63} x^{63} = \sum_{i=0}^{63} m_i x^i
128 セルのデータへの変換は、[f(0), f(1), ... , f(127)] m_0 f(x)
符号化を行うことにより、元々は 64 セルのデータを逃さず取得しなければ Blob を復元できなかったことに対し、 64/128 だけ取得できれば、 Blob を復元できるようになりました。
PeerDAS について、処理を以下の流れで説明します。
- Blob の分割とノードへの割り当て
- コンセンサスのステップに従ったノードの PeerDAS 処理
Blobの分割とノードへの割り当て
1Blob あたり、2kB を 1 セルとして分割したのち、符号化することで、1Blob を 128 セル(2kB)に分割します。
例えば、6Blob がある場合は、全体を 6 行 128 列の行列として解釈されます。
それぞれの列を Subnet と呼称し、 担当 Subnet 数 = ノードの合計ステークETH / 32 ETH で計算される担当 Subnet 数の Subnet だけ、 Blob データのダウンロード・検証・保管・P2P での発出が必要となります。また、NodeID からそのノードが処理する Subnet がリスト形式で一意に生成できる([1,2,3,...,128] のようなリスト。最初の要素から用いる)ため、 NodeID と担当 Subnet 数がわかれば、そのノードがどの Subnet を処理する必要があるか、特定できます。
わかりやすくするため、いくつかの合計ステーク ETH の段階に分けて、担当 Subnet 数を計算すると、以下のようになります。
- フルノード(ステーク 0ETH)：4 Subnet
- ソロバリデータ(ステーク 32ETH)：8 Subnet
- 中型バリデータ(ステーク 2048ETH)：64 Subnet
- 大型バリデータ(ステーク 4096ETH = 2048ETH のバリデータ x 2 台)：128 Subnet(全 Subnet )
全ての Subnet のデータを提供するノードを、Supernode と呼びます。また中型バリデータは 64 Subnet となっており、前提で述べたように、符号化されているため、中型バリデータ以上は全 Subnet データを復元できます。
コンセンサスのステップに従ったノードのPeerDAS処理
PeerDAS は、ビーコンチェーンで次のように処理される。フェーズには、ターゲットタイムが指定されており、ブロック提案フェーズは 4 秒、ブロックデータの受信・署名フェーズも 4 秒、残り 4 秒は署名の集約フェーズとなります（署名集約に関しては PeerDAS は関係ないため、記載しません）。
- ブロックデータ生成・送信フェーズ(0~4 秒)
ブロックプロポーザーは全ての Blob データを集約し、ブロックデータを生成します。その後、Gossip プロトコルでピアに共有します。ブロックプロポーザーが実際に行う作業は、以下の通りです。- Blob データを符号化し、 blob 数の行×128 列の行列に変換する
- Blob ごとに KZG コミットメント・KZG 証明を発行する
- ブロックデータ・Blob データをピアに送信する
- ブロックデータの受信・署名フェーズ(4~8 秒)
各ノードはブロックデータ及び Blob データを Gossip プロトコルでピアから受信します。次のような作業を各ノードが行います。- 自分のノード ID といくつの Subnet を保有しているかを共有する
- 必要な Subnet に応じて、Gossip プロトコルで他のピアから Subnet のデータを送受信する
- Blob ごとの KZG コミットメント・KZG 証明を用いて、取得した Subnet データが確かにその Blob に含まれていることを検証する
※実際には Blob ごとに処理するのではなく、Blob ごとの KZG コミットメント・証明データを結合しまとめて検証する - 全データの検証が完了すれば、attestation を行う
- クライアントによっては(ex. prysm)、必要な Subnet データのうち 50%(64 Subnet )が集まれば、ピアのデータを待たず、残りの Subnet データを再生成する
1 においては、ブロック・Blob データの送信も含めて 4 秒内に収めなければ有効なブロック提案とみなされないことから、Blob 数が増えれば増えるほど、必要となるリソース（特に帯域幅）が増大します。例えば、現在のスケジュールにおいては、2026/1/7 に Blob の最大数は 21 に到達します。このとき 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 の上限数・ターゲット数を継続的に増加させる必要があります。下の図は、4 月 14 日以降の日次での Blob 利用状況を示したものです。42K に赤線を入れているのは、blob のターゲット数×1 日の ethereum ブロック数での、1 日のターゲット blob 数を示すためです。徐々に日次でのターゲット blob 数には近づいてきているのが見て取れます。
出典: Daily Blobs by blobscan
そこで今回実装されるのが、Blob のパラメータのみを更新する新たな種類のフォーク Blob Parameter Only Hardforks(BPO と呼ぶ)です。BPO により、以下のスケジュールで Blob のターゲット・最大値等のパラメータは段階的に上げられることになります。従来のハードフォークタイミングよりも高速にパラメータを上げていくことで、市場の拡大にも耐えつつ Fusaka アップデート・BPO の影響をモニタしながら、パラメータを上げていくためです。PeerDAS の実装に伴い、より Blob のターゲット・最大値を大きくできるようになったので、Fusaka アップデートに組み込まれています。
現時点では、次のスケジュールで、パラメータを更新していく予定です。
| アップデート名 | タイムスタンプ (JST) | ターゲット | 最大値 |
|---|---|---|---|
| Cancun | - | 3 | 6 |
| Prague | - | 6 | 9 |
| Fusaka | 2025-12-04 06:49 (JST) | 6 | 9 |
| BPO1 | 2025-12-18 22:29 (JST) | 10 | 15 |
| BPO2 | 2026-01-07 10:01 (JST) | 14 | 21 |
ブロックガス上限の上昇/トランザクションガス制限（EIP-7935 & EIP-7825）
Ethereum のブロックガス上限は、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 以上に相当)以上消費できないことをプロトコルのルールにすることで適用されます。
コントラクト開発者においては、もしこの制限を超えるようなトランザクションを想定している場合は、コントラクトの再設計が必要となるので、注意してください。
そのほか特記するべき、将来につながるアップデート項目
EIP-7917 ブロックプロポーザーの事前決定
従来、次エポック(1 エポック=32block ~ 6.4 分)におけるプロポーザーは必ずしも確定していませんでした。そのため、近年話題になっている Preconfirmation（指定のトランザクションを指定のタイミングに確実に通すことを確証する技術）においても、この点が障害になると考えられていましたが、Fusaka アップデートにおいて次エポックでのプロポーザーを事前に確定するため、この障害は解決します。
こちらは、すぐに効果が出るのではなく、将来的な UX 改善に向けた対応となります。
バリデータ・フルノード運用者、L2・コントラクト開発者への影響とまとめ
バリデータ・フルノード運用者への影響
Fusaka アップデートにより、以下のノード運用者に影響のある EIP が実装されます。特に、PeerDAS（EIP-7935 & EIP-7825）及び Blob 容量上限の上昇・段階的な Blob アップデート（EIP-7892）は、ノードのストレージ利用量・通信における帯域幅消費に影響します。また、eth/69 のレシートデータの簡易化(EIP-7642)によって、不要なデータを返さない仕様となっており、帯域幅消費が縮小される見込です。
PeerDAS の実装により、Fusaka アップデート後では、ステーク量の少ないバリデータにとって性能要件が緩和されると考えられています。逆に、多数のバリデータもしくは多数の ETH をステークするバリデータについては、例えば帯域幅要件がより厳しくなる見込です。
下図は、複数のステーク量タイプにおける、ストレージ利用(Blob 関連のみ)・ブロック提案時の帯域幅を示しています。
320ETH をステークしているバリデータの Blob 数ごとのストレージ利用量
1024ETH をステークしているバリデータの Blob 数ごとのストレージ利用量
320ETH をステークしているバリデータの Blob 数ごとのブロック提案時のデータ送信速度
1024ETH をステークしているバリデータの Blob 数ごとのブロック提案時のデータ送信速度
出典: Fusaka bandwidth estimation by ethPandaOps
~320ETH までのステークにおいては、20Blob を超えたとしても、ストレージ利用量は Fusaka アップデートより依然として低くなっています。問題となるのは、ブロック提案時の帯域幅です。ブロック提案においては、全 Blob データを集約し、署名のためピアに提供しなければならないため、Blob 数が増えるほど帯域幅が必要となります。一部のクライアントにおいては、EL から Blob データを受信して処理するなどの仕組みが実装されていたり、--max-blobs のような上限 blob 数を既定するフラグを実装している場合があるため、帯域幅の制限が想定される場合は、クライアントの機能をよく確認されることをお勧めします。
Layer2開発者への影響
Fusaka アップデートにより、以下の Layer2 開発に影響のある EIP が実装されます。特に、PeerDAS（EIP-7935 & EIP-7825）及び Blob 容量上限の上昇・段階的な Blob アップデート（EIP-7892）は、Layer2 において DA の役割を果たす blob の容量・コストに直結するため、Layer2 のコスト・スループットに影響します。その他、EIP-7939 のような、ZK Rollup の構築者にとっては利点の高い EIP が実装されます。
| EIP | 機能 | 開発者への影響 |
|---|---|---|
| EIP-7939 | CLZオペコードの追加 | ZK Rollup等、特定のユースケースに対して、実装・ガスコストが効率化 |
| EIP-7951 | secp256r1のプレコンパイルコントラクトの追加 | UXの変更なしに、既存のSecp256r1プリコンパイルコントラクトが修正される |
| EIP-7883 | MODEXPのガスコスト増加 | RSA/ZK暗号化オペレーションのガスコスト削減 |
| EIP-7594 | PeerDAS | 現行のUXを変更せず、Blobのスケーリングが可能に |
| EIP-7892 | Blob Parameter Only ハードフォーク | 現行のハードフォークよりも高速に、Blobのターゲット・最大値が変更可能に |
| EIP-7918 | ブロックのベースガス料金とBlobベース料金を連動 | Blobのベース料金がブロックのベースガス料金により変動 |
| EIP-7917 | ブロックプロポーザーの事前決定 | 次エポックのブロックプロポーザーが事前に確定できるため、Preconfirmationに寄与 |
スマートコントラクト開発者への影響
Fusaka アップデートにより、以下のスマートコントラクト開発に影響のある EIP が実装されます。特に、ブロックガス上限の上昇/トランザクションガス制限（EIP-7935 & EIP-7825 が実装されます。多くのコントラクトに影響はありませんが、もし非常に複雑なコントラクトを構築していて、トランザクションごとのガスリミットを超えてしまうような場合は、機能の分割等の影響が見込まれます。
| EIP番号 | 名称 | 開発者への影響 |
|---|---|---|
| EIP-7935 | デフォルトガスリミットを60Mに設定 | より多くのトランザクションを同一ブロックに投入できる可能性が高まる |
| EIP-7825 | トランザクションごとのガスリミット上限 | もし非常に複雑なコントラクトを構築しており、単一トランザクションのガス消費が16,777,216ガスを上回る場合、分割する必要あり |
| EIP-7823 | MODEXPへの入力値のサイズ上限設定 | MODEXPのプリコンパイルコントラクトに入力値制限(1024バイト)が設定 |
| EIP-7883 | MODEXPのガスコスト増加 | MODEXPに関するガスコストが引き上げ・修正 |
| EIP-7939 | CLZオペコードの追加 | CLZオペコードを追加し、ゼロ知識証明等の実装・計算コストを低減 |
まとめ
Fusaka アップグレードは、Ethereum のスケーラビリティにおいて非常に大きなハードフォークです。特に大きなものとして、 PeerDAS がよく取り上げられますが、上で各ステークホルダーへの影響を記載したように、細かな UX 改善も数多く含まれています。また、将来的な TPS 拡大、Preconfirmation 等を通した利用者にとっての UX の改善など、未来を見据えた改善も数多く含まれています。
参考文献
本稿は、以下の参考資料を元に作成しています。詳しく理解したいほうは、こちらをご確認ください。
- Emmanuel Nalepa（HackMD）「PeerDAS」https://hackmd.io/@manunalepa/peerDAS（参照日：2025 年 10 月 20 日）
- Ethereum Foundation（ethereum.org）「PeerDAS」https://ethereum.org/ja/roadmap/fusaka/peerdas/#peer-das（参照日：2025 年 10 月 20 日）
- Sigma Prime（Sigma Prime Blog）「Scaling Ethereum with PeerDAS and Distributed Blob Building」https://blog.sigmaprime.io/peerdas-distributed-blob-building.html（参照日：2025 年 10 月 20 日）
- EthPandaOps（EthPandaOps Blog）「Fusaka bandwidth estimation」https://ethpandaops.io/posts/fusaka-bandwidth-estimation（参照日：2025 年 10 月 20 日）
- EthPandaOps（EthPandaOps Blog）「Fusaka devnet-5 BPO analysis」https://ethpandaops.io/posts/fusaka-devnet-5-bpo-analysis（参照日：2025 年 10 月 20 日）
- Gaudiy Web3 Lab（Medium）「PeerDAS: Solving Ethereum’s Data Availability Problem」https://medium.com/gaudiy-web3-lab/3ace46a3a9af（参照日：2025 年 10 月 20 日）
- Paradigm（Paradigm Blog）「Time, slots, and the ordering of events in Ethereum Proof-of-Stake」https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus（参照日：2025 年 10 月 20 日）
Discussion