トップ > Ethereum > Ethereum Fusaka Upgrade 解説

Ethereum Fusaka Upgrade 解説

Ethereum Web3 ブロックチェーン

この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー5日目の記事です。 qiita.com

はじめに

みなさん、こんにちはこんばんは！

コインチェックのプロダクトエンジニアリング部のリスティング＆プロトコル GでエンジニアをしているYotaです。

今回のアドベントカレンダー2度目の登場となります。

前回はプルリクエスト作成を自動化した話を書きましたので、是非ご覧ください。

tech.coincheck.blog

今回は12/4に実施されたEthereumのFusaka Upgradeの解説記事です。 アップグレードの概要と各EIPについて解説します。

ちょこっと宣伝です。 12/12に弊社オフィスでステーキングのLT会をNext Finance Tech社さんと共催しますので、気になる方は是非いらして下さい！ coincheck.connpass.com

概要

Fusakaは日本時間で2025-12-04 06:49（slot: 13,164,544）からメインネットに適用されました。 Fusakaという名称は、実行レイヤーのアップグレードである「Fulu star」と、コンセンサスレイヤーのアップグレードである「Osaka」を統合した呼称です。 このアップグレードにより、両レイヤー共にスケーラビリティ、セキュリティ、そしてユーザーエクスペリエンスの向上を見込んでいます。

今回のアップグレードの目玉はPeerDASです。

Peer DASとは、チェーンを構成する各ノードが全てのデータを保持しておらずとも、サンプルを取得するだけでデータを検証可能にする仕組みです。 これにより、ハードウェア要件の緩和によるノードの分散性向上や、L1のデータ可用性領域が増えることによるL2のスループット向上/ガス代減少等のL2に対して特に大きな恩恵があります。

Fusakaに含まれるEIP一覧

EIP-7607に記載されているEIPを解説します。

Core EIPs

  • EIP-7594: PeerDAS - Peer Data Availability Sampling
  • EIP-7823: Set upper bounds for MODEXP
  • EIP-7825: Transaction Gas Limit Cap
  • EIP-7883: ModExp Gas Cost Increase
  • EIP-7917: Deterministic proposer lookahead
  • EIP-7918: Blob base fee bounded by execution cost
  • EIP-7934: RLP Execution Block Size Limit
  • EIP-7939: Count leading zeros (CLZ) opcode
  • EIP-7951: Precompile for secp256r1 Curve Support

Other EIPs

ここからは各EIPの詳細解説に入ります。

Core EIPs

EIP-7594: PeerDAS（Peer Data Availability Sampling）

今回の目玉のPeerDASに関するEIPです。 DAS（Data Availability Sampling）と呼ばれる、データ可用性をノードのピア通信を用いて実現する方法になります。

Dencunアップグレードで導入されたEIP-4844（Proto-Danksharding）では、トランザクションとは別に一時的に大容量のデータを添付できる「Blob」を導入し、L2のデータコストを大幅に削減しました。しかし、EIP-4844の時点では、ネットワーク内の検証ノードは、依然としてすべてのBlob dataをダウンロードし、「データが公開されていること」（データ可用性）を確認する必要がありました。

データ容量をさらに拡大しようとすると、このデータを全てダウンロードしなければならない要件がノードの帯域幅とストレージ要件を際限なく増加させる要因となります。その結果、フルノードを運用する敷居が高くなり、中央集権化を招く懸念があります。

PeerDASでは、リード・ソロモン符号（Reed-Solomon code）を用いたerasure coding（消失訂正符号）という手法を用いて、この問題を解決します。

具体的には、Blob dataを128個のcolumn（カラム）という単位に分割し、ゴシッププロトコルを用いてノードに分散して保存します。 ネットワーク上の各ノードはランダムに選択された最低8つのcolumn subnetに参加します。これは従来の1/16のデータのみを各ノードが受け取ることを意味しています。 リード・ソロモン符号では冗長性のため、元の多項式に元データと同じサイズのパリティを追加しておりデータ量が2倍になるため、保存している実質的なデータ量はFusaka前の1/8に軽減されます。 また、リード・ソロモン符号は50%以上のデータがあれば、ほぼ確実に元データを復元可能な特性があることから、データ可用性を保証していると言えます。 ここで復元しているデータはあくまでBlob dataのため、最終的な復元結果はEthereum側のステートではなく、L2のステートをサンプリングデータで復元可能になるということになります。

EIP7594はDanksharding実現までの段階的なアップグレードの一部であり、Blob dataの分割をcolumnという一次元的な分割をしていますが、Dankshardingが実現すると、分割方法がcolumn（列）に加えて、columnをさらにリード・ソロモン符号をかけて２次元的に分割したrow（行）が加わります。 これにより、columnの分割と復元も可能になり、より分散化やスケーラビリティが向上します。

EIP-7823: Set upper bounds for MODEXP

入力長無制限かつ複雑な価格計算法を持ち、多数のコンセンサスバグの原因となっていた、MODEXPプリコンパイル（モジュラ指数演算）の入力値に上限を設けます。

上限を超えた場合は全てのgasを消費してプリコンパイルを停止します。 この上限がない場合、意図的に巨大な入力を送りつけることでノードをクラッシュする可能性があるため、この防止にもなります。

なお、この変更の影響を受けるトランザクションは2025年1月4日までには確認されていないため、ほとんど影響はありません。

EIP-7825: Transaction Gas Limit Cap

プロトコルレベルで、1つのトランザクションで消費可能なgas上限を16,777,216 (224)に設定します。

gasを大量に消費するようなトランザクションが大量に発行されることによるDoS対策です。

EIP-7883: ModExp Gas Cost Increase

MODEXPプリコンパイルのgasコストが上昇します。

一部のMODEXPプリコンパイルのgasコストが過小評価されていたため、適正化することが目的の対応です。

EIP-7917: Deterministic proposer lookahead

ビーコンチェーンのproposer選出スケジュールを決定論的に確定するための変更です。 これまではget_beacon_proposer_indexにおいて、各epochのproposerをオンデマンドで計算していましたが、本EIPにより追加された、事前計算されたproposer_lookaheadを利用するように変更することで、2 epoch先のproposerが事前に判明します。

これまでは、特定のケースでepoch Nにおいて、epoch N+1のproposer選出に利用されるバリデータのEffective Balanceが変動する可能性があったことから、今後のepochのproposerを事前予測が正確にできませんでした。 本EIPの変更以降、epoch Nの処理において、epoch N のeffective balanceを用いてepoch N+1とepoch N+2のproposerを計算しておき、proposer_lookaheadに保存することで、先のepochのproposerを取得することが可能になります。 これによりL2のBased RollupやPreconfirmationにも恩恵があります。

EIP-7918: Blob base fee bounded by execution cost

blob領域の消費量に応じて変動するbase fee per blob gasに下限値を設けます。

実行コストが増大したときに、blob手数料が不当に低くなることを防ぐための変更です。 blobが極端に安価になることを抑制することで、スパム的な利用の抑制や安価なblobでノードに負荷をかけるような攻撃を予防する意図があります。

EIP-7934: RLP Execution Block Size Limit

executionレイヤーのブロックのRLPエンコード長のサイズ上限を 10MB に制限します。 なお、2MBの安全マージンを含んだ値に設定されています。 過度に大きなブロックは伝播速度の低下やfork, reorg, DoSリスクを高めます。 10 MiBを超えるブロックはconsensus layerのゴシッププロトコルでは伝播されないため、ネットワークの断片化を引き起こす原因にもなり得ます。 これらを防ぐための制限です。

過去にこのサイズを超えたブロックは存在しないため、実質影響はありません。

EIP-7939: Count leading zeros (CLZ) opcode

ゼロ知識証明の計算コスト減少に効果がある、新たなオペコードCLZ(x)を追加します。

スタックからxポップし、最上位ビットを256として、最上位ビットから連続する0の数をプッシュするような動作をします。

EIP-7951: Precompile for secp256r1 Curve Support

適切なセキュリティチェックを伴った、secp256r1楕円曲線上のECDSA検証用プリコンパイルコントラクトを追加します。

Other EIPs

EIP-7892: Blob Parameter Only Hardforks

Blobパラメータ変更のみのハードフォークを導入します。 設定変更可能なパラメータは下記です。

  • target: ブロックあたりの目標blob個数
  • max: ブロックあたりの最大blob数
  • baseFeeUpdateFraction: ブロックあたりのblobのbase feeの調整係数

現在のEthereumのハードフォークは低頻度で実施されているため、Blobの設定変更をする場合でもハードフォークを待たなければなりませんでした。 Fusaka後は段階的にblob targetとmaxを引き上げる想定がされていますが、現在のハードフォーク頻度よりも高頻度での変更が予想されるため、blob用のパラメータのみのハードフォークをできるようにします。

EIP-7642: eth/69 - Drop pre-merge fields

p2pプロトコルの修正とPoW時代の古い情報が削除されます。 p2p通信時にピアがThe merge以前の古い履歴を持っているかどうかを知ることができます。 これによりフルノード同期時のデータを530GB減ることが予想されます。

EIP-7910: eth_config JSON-RPC Method

eth_config JSON-RPC Method クライアントのハードフォーク設定を返す新たなJSON-RPCメソッドの追加です。 current, known, lastを返します。 現在EthereumのテストネットとしてHoodiがありますが、この移行に至った原因はHoleškyテストネットで、6個中4つのクライアントがdeposit contractの設定を間違っており、その影響で誤ったチェーンが正当化されてたことに起因します。 blog.ethereum.org

この対策として、クライアントがどのハードフォーク設定を適用しているかを知るためのメソッドが追加されました。

EIP-7935: Set default gas limit to 60M

Execution Layerクライアントのデフォルトgas limitの設定を60Mに引き上げます。

おわりに

今回のハードフォークでは、L2への恩恵が多い内容でした。 着々とDankshardingの実現ステップを踏んでおり、個人的にはとても嬉しい内容でした。 また、ノード運用負荷の軽減につながる内容をはじめとした、暗号資産関連の事業者にとってもメリットの多い更新だったといえます。

今後もFull Dankshardingへの道のりや、Verkle Treeの本格化、Single Slot Finality（SSF）、Proposer Builder Separation（PBS）など、楽しみにしているアップグレードが控えています。

引き続きCore Devを追っていきたいと思います。

ここまでお読んでくださり、ありがとうございました。

この記事が皆様の手助けになれば幸いです。