Ethereum Fusaka アップデート
この記事の内容は2025年11月7日時点の情報に基づいて作成しました。
0. 技術的観点まとめ（要約）
- Fusakaは、execution層「Osaka」とconsensus層「Fulu」からなる統合アップデート。
- データの可用性を向上させる技術「PeerDAS」により、ノードの分散検証を実現。
- L2（Layer 2）のBlobデータ処理を動的・安定的に管理し、L2手数料を最適化。
- ガスモデルの再設計により、トランザクション上限やブロックサイズを明確化（過負荷防止）。
- EVM（Ethereum Virtual Machine）を拡張し、CLZ命令とsecp256r1暗号曲線を追加。
- MODEXP演算の制限や動的ガス計算で、DoS攻撃耐性を強化。
- FusakaはDanksharding実装に向けた「中間段階」として、ネットワーク負荷を根本から最適化。
1. 概要
- Fusakaは、Ethereumの次期大型アップデートであり、
execution層アップデート「Osaka」とconsensus層アップデート「Fulu」を統合したもの。 - 2025年5月のPectraに続く大型アップデート
- 10月上旬にHoleskyとSepoliaでのテストを終え、10/29にHoodiでのテストも完了している。
12/3（水）メインネットへ適用予定。
主な目的は以下の4点
- スケーラビリティ向上（特にL2連携強化）
- ネットワーク負荷軽減とノード運用効率化
- ガスモデル・ブロック構造の最適化
- 開発者向けEVM機能拡張とセキュリティ改善
2. 技術的要点
| 項目 | EIP | 内容 | 目的・狙い |
|---|---|---|---|
| PeerDAS導入 | EIP-7594 | ノードごとの分散データ検証 | ストレージ・帯域負荷軽減 |
| L2強化 | EIP-7892 / EIP-7918 | Blobデータ手数料と管理の見直し | L2手数料安定化 |
| ガスモデル最適化 | EIP-7825 / EIP-7934 / EIP-7935 | ブロック・トランザクション上限見直し | 過負荷防止と性能向上 |
| セキュリティ改善 | EIP-7823 / EIP-7883 | MODEXP演算制限とガス再設計 | DoS攻撃耐性強化 |
| EVM拡張 | EIP-7939 / EIP-7951 | 新命令・新暗号曲線サポート | 開発柔軟性と相互運用性 |
3. 各EIPの技術詳細
3-1. データ効率化：EIP-7594（PeerDAS）
概要
- ノードがブロックデータ全体を保持せず、一部をランダム検証してもデータの可用性を保証できる仕組み。
- 「Data Availability Sampling（DAS）」をP2Pネットワーク層で実装。
背景と変更点
| 観点 | 変更前 | Fusaka後 |
|---|---|---|
| データ保持 | 全ノードが全データを保持 | 各ノードが分散的に保持・検証 |
| 検証方法 | フルダウンロード＋整合性確認 | サンプリング＋整合性証明 |
| 効果 | 同期・検証に時間とストレージ負荷 | ネットワーク軽量化・高速化 |
検証の流れ
-
ブロックデータを多数の小片（チャンク）に分割する
• 例：1MBのブロックを1KB単位に分割 → 約1000チャンク -
Erasure Coding（誤り訂正符号） による冗長化
Erasure Coding：データを細かく分割し、元のデータに加えて「パリティ」と呼ばれる冗長なデータ（データブロック）を作成し、これらを分散して保存することで、データが一部失われても元データを復元できる耐障害性を高める技術
参考：https://note.com/standenglish/n/n57cb448b19d6
• 元の1000チャンクから1500チャンクに符号化し、一部が欠けても再構成可能にする。 -
チャンクの分散配布
• 生成されたチャンクは、EthereumのP2Pネットワーク上に分散される。
• 各ノードは、全チャンクではなく一部のみを保持する。
• 1台のノードではブロック全体を復元できないが、ネットワーク全体で見れば完全なデータが存在している。 -
データ可用性サンプリング（DAS）の検証フロー
① 各ノードは、自分の接続しているピア（他ノード）に対して
ランダムにチャンクをリクエストする。
• 例：1500チャンク中ランダムに20個を取得
② 取得したチャンクをErasure Codingの符号情報に基づいて検証する。
• 各チャンクが正しい形式で生成されたものかを確認。
• 不整合なデータは即座に破棄。
③ ノードが複数のピアからサンプルを取得し、
すべてのサンプルが正常であれば「データが利用可能」 と判断する。
④ 多数のノードが独立してサンプリングを行うため、
攻撃者がデータを一部隠そうとしても、高確率で他ノードが検出できる仕組みになっている。
「攻撃者がデータを隠す」とは？
例：1000個のデータがあるとして、攻撃者がそのうち10個を隠したとする。
それを1000人のノードがそれぞれランダムに10個ずつチェックする。
すると、確率的にみて：
• 誰か1人でも隠されたチャンクに当たる確率はほぼ100％。
• 見つかった瞬間に「このブロックは欠損している」と全ネットワークに共有される。
結果的に、そのブロックは無効化されて採用されない。
効果
- ノード運用の負荷軽減
- ネットワーク帯域の最適化（全体の通信量の減少）
- ブロック検証の最適化（ブロック確定までの時間の短縮）
- 安全性・信頼性の向上
- Danksharding 導入への準備
Danksharding：Ethereumが将来的に目指す大規模なスケーリングソリューション
参考：https://ethereum.org/ja/roadmap/danksharding
3-2. L2連携強化：EIP-7892 / EIP-7918
Blob とは
- EIP-4844（Proto-Danksharding）で導入された新しいデータ構造
- ブロックに一時的にくっつけるデータのかたまり（データパケット）のこと
- 以前は永久にデータが保存される
calldataを使用していた -
Blobは一定期間後に削除されるので、ブロックチェーンを永久に圧迫しない。
参考：https://zenn.dev/qope/articles/b8d09ae260f1aa
EIP-7892：Blobパラメータ管理
- Blob の上限値（もともと1ブロック当たり6個まで）や料金（Blob手数料）計算をネットワーク状況に応じて動的に更新可能に。
- 大規模なアップデートを待つことなく、ノードが合意できればBlob数の上限を随時引き上げられる（＝小規模なフォークが可能に）
- オンチェーンでの手数料最適化が進む。
EIP-7918：Blob手数料安定化
- Blob feeの過剰変動を防止し、L2の手数料が急上昇しないよう調整。
背景と変更点
| 観点 | 変更前 | Fusaka後 |
|---|---|---|
| Blob fee計算 | 定数ベースで変動が大きい | 需要に応じた動的調整 |
| L2投稿コスト | 需要集中時に高騰 | 安定化し予測可能に |
効果
- L2利用コストの予測性が向上
- L2→L1データ投稿が安定化
3-3. ガスモデル・ブロック構造の最適化：EIP-7825 / EIP-7934 / EIP-7935
目的
- トランザクション処理の上限とブロックサイズを再設計し、リソース利用を最適化する。
背景と変更点
| 項目 | 変更前 | Fusaka後 |
|---|---|---|
| 1トランザクションあたり最大ガス量 | 約30M（理論値）だが現実的には制限なし | 約16.78Mに明確化（EIP-7825） |
| ブロックサイズ上限 | 約30MiB(メビバイト)程度まで膨張可能（実測） | 最大10MiB(メビバイト)に制限（EIP-7934） |
| ブロックあたりガス上限 | 約30M（可変） | 今後段階的に引き上げ検証（EIP-7935） |
効果
- 過剰なトランザクション詰め込みを防止し、リソース使用を均一化
- ブロック伝搬時間の短縮
- ノード間の同期安定性が向上
- ネットワーク分岐（フォーク）リスクの低減
⇒ブロックを太らせすぎないようにするアップデート
3-4. セキュリティ強化：EIP-7823 / EIP-7883
概要
- Ethereum EVMの演算命令「MODEXP（モジュラー指数）」（暗号計算などに使う重い演算命令）の仕様を見直し。
- 計算負荷を制限することでDoS攻撃耐性を強化。
背景と変更点
| 観点 | 変更前 | Fusaka後 |
|---|---|---|
| MODEXP入力長 | 無制限（理論上） | 最大8192bit（EIP-7823） |
| ガス計算式 | 固定コスト | 入力サイズ比例の動的ガス（EIP-7883） |
効果
- 一般的なニーズには対応しつつ、極端なケースを除外できる
- 大規模計算を悪用したノード停止攻撃を防止
- 公平なリソース利用を促進
3-5. EVM拡張：EIP-7939 / EIP-7951
EIP-7939：CLZ（Count Leading Zeros）命令追加
- ビット列の先頭ゼロ数をカウントする命令を新設。
- 暗号演算や圧縮処理などに利用可能。
EIP-7951：secp256r1（P-256）楕円曲線対応
- これまでEthereumが標準対応していたのは
secp256k1（Bitcoin系）。 - 今回、企業システムやモバイルで主流の
secp256r1にも対応。
背景と変更点
| 項目 | 変更前 | Fusaka後 |
|---|---|---|
| EVM命令 | CLZなし | CLZ追加により演算高速化 |
| 利用可能暗号曲線 | secp256k1のみ | secp256k1 + secp256r1 |
効果
- 高精度暗号計算のガス効率向上
- 外部APIやハードウェア署名機構との互換性向上
- Web2とWeb3の連携がスムーズに
4. Fusakaの位置づけと今後の展開
| フェーズ | 名称 | 主な目的 |
|---|---|---|
| 完了済 | Merge | PoS移行 |
| 完了済 | Dencun | Blobデータ導入・L2手数料削減 |
| 現在 | Fusaka | PeerDAS導入・ネットワーク最適化 |
| 将来 | 未定 | Verkle Trees / Danksharding 完全シャーディング実装による拡張性強化 |
補足
- FusakaでのPeerDASは「部分的なデータ可用性シャーディング」。
- 将来的には、Verkle Trees で状態データの圧縮を行い、 Danksharding で完全な並列処理を目指す流れ。
5. 全体まとめ
| 観点 | 改善内容 | 変更前 | Fusaka後 | 効果 |
|---|---|---|---|---|
| データ保持 | データ可用性の改善 | 全ノードで全データ保持 | 分散的保持（PeerDAS導入） | 各ノードの負荷を軽減し、スケーラビリティと可用性を両立 |
| トランザクション手数料 | 上限の明確化 | 明確な制限なし | 約16.78Mに固定 | ネットワーク混雑時の過負荷を防止し、安定稼働を実現 |
| ブロックサイズ | サイズ制限の最適化 | 約30MiB上限（実測） | 10MiBに制限 | ブロック伝播が安定し、同期遅延やフォークの発生を抑制 |
| MODEXP仕様 | 演算処理の制限 | 無制限入力・固定ガス | 8192bit上限・動的ガス | 大量演算によるDoS攻撃リスクを軽減し、計算コストを公平化 |
| 暗号曲線 | 対応曲線の拡張 | secp256k1 | secp256r1追加 | Web2のTLS・証明書との互換性を強化し、企業・外部連携が容易に |
⇒ Ethereumがより軽く、安全に、外と繋がるためのアップデート