残り1ヶ月！Ethereum Fusakaアップグレードにおける注目の9つの提案を解説。

著者: Ethereumインターン

編集：ティム、PANews

Fusaka は、Ethereum ネットワークの最新の技術アップグレードであり、2025 年 12 月 3 日 21:49:11 に実行されます。

このアップグレードはイーサリアムにどのような影響を与えるのでしょうか？メインネットでは具体的にどのような変化が起こるのでしょうか？早速見ていきましょう！

他のアップグレードと同様に、Fusakaには様々なEIP（イーサリアム改善提案）が含まれており、これらが組み合わさってアップグレードの内容を構成しています。それぞれのEIPを人気順に紹介していきます（これは完全に私の主観的なランキングです！）。

1. EIP7594

1 つ目は PeerDAS です。これは、Ethereum のデータ可用性における大きな変更であり、重要なパフォーマンスの向上です。

データの可用性に関して誤解されていることが多いので、まずそれについて説明しましょう。

Ethereum での最終決済を完了するために、Rollup は新しい状態に必要なすべてのデータを BLOB 形式で公開します。これらのデータは Ethereum ノードによって一時的に保存されます。

完全な状態にアクセスできない場合、ユーザーは必要な証明を生成できないため、強制的に出金を行うことができません。つまり、悪意のあるソートツールによってユーザーの資金が差し押さえられたり、悪意を持って妨害されたりする可能性があるということです。

したがって、データの可用性は、イーサリアムがBLOBの可用性を確保するために用いる保証です。例えば、L1およびL2ブリッジコントラクトなどのスマートコントラクトは、BLOBの存在を確認し、その内容を検証することができます。

現在、Proto-Danksharding（EIP-4844）方式を用いて、BLOBはネットワークノード全体に複製されています。しかし、この現在のアプローチでは、目標スループットがわずか31KB/秒であるため、持続的なサービス提供に必要なスケーラビリティが不足しています。

新たにリリースされたPeerDASシステムは、データシャーディング技術を採用しています。これは、データブロックが複数のノードに分散・保存されるため、単一のノードがすべてのデータを保存する必要がないことを意味します。

しかし、単純なシャーディングではデータの可用性にリスクが生じる可能性があります。この問題にはどのように対処すればよいでしょうか？

まず、BLOBは現在、消失訂正符号を使用しています。BLOBは8つのセルに分割されており、4つのセルは元のBLOBデータを保存するために使用され、残りの4つのセルは再構成可能なデータの追加情報を保存するために使用されます（この技術はリード・ソロモン消失訂正符号と呼ばれます）。

たった4つのセルがあれば、ブロブ全体を再構築できます。たとえ元のデータセット2つが失われたとしても、追加のランダムなブロブを2つ取得できれば、すべてのデータを復元できます。

消失訂正符号化後、BLOBは均等に分散され、「サブネット」と呼ばれるノードグループに保存されます。各サブネットは各BLOBの1/8を保存し、要求元のノードに配布します。

PeerDASは当初、ブロックあたり10個のBLOBの処理を目指していますが、BLOB数パラメータのみを調整するハードフォークを通じて、段階的に14個、そして最終的には48個まで処理能力を増やす予定です。これはネットワークの過負荷を回避するためです。具体的な実装については、後の章で詳しく説明します。

ノードは、各時間間隔ごとに他のノードにデータユニットと決定論的証明をランダムに要求することにより、DA層の要件を実行します。協力を拒否したノードは、他のノードによる共同裁定の対象となり、厳しいペナルティを受ける可能性があります。

つまり、データの提供を継続的に拒否するノードはブラックリストに登録され、他のノードによって信頼できないものとしてマークされます。これは、実質的にそれらのノードをネットワークから排除することと同じです。

さらに、ノードは、ブロックを受け入れる前に、新しいブロックの BLOB が利用可能かどうかを確認する必要があります。つまり、BLOB がない新しいブロックは直接拒否されます。

バリデータは通常のノードよりも多くのBLOBを保存・送信する必要があり、ステーク量が4096ETHの上限に達した場合、すべてのデータを処理する必要があります。この要件はP2Pネットワーク層によって強制されており、このルールに従わない場合、ネットワークはバリデータとの通信を停止します。

2. EIP-7951

さて、PeerDASについてはかなり詳しく説明しました。次は、新機能であるsecp256r1曲線（EIP-7951とも呼ばれます）のプリコンパイルについて説明します。

ビットコインと同様に、イーサリアムはsecp256k1と呼ばれる曲線を用いた楕円曲線デジタル署名アルゴリズム（ECDSA）を使用しています。この曲線はデジタル署名専用に設計されており、署名から秘密鍵を推測することが不可能であることを保証します。

ただし、ほとんどの安全なコンポーネント (つまり、暗号化操作を実行する分離された改ざん防止ハードウェアチップ) は、キーを保護しながら暗号化操作を実行できる secp256k1 曲線をサポートしていません。

コンピューターや携帯電話に組み込まれたハードウェアウォレットと考えることができます。

secp256r1曲線は、セキュアエレメントで広くサポートされている曲線です。これをプリコンパイル済みコントラクトとして設定することで、スマートウォレットはデバイスネイティブ署名や多要素認証などのセキュリティ機能をより簡単に実装できるようになります。

3.EIP7917

次の EIP は提案 7917 で、ビーコンチェーンの設計上の欠陥と呼ばれるものを修正することを目的としています。

ブロックプロデューサーは、RANDAO乱数シードを用いて選択されます。乱数シードは2つの時間間隔前に計算されます。したがって、次の時間間隔のブロックプロデューサーを予測できるはずです。

ブロックプロデューサーは、すべてのバリデーターからランダムに選択され、ステーク量に応じて重み付けされます。ただし、バリデーターのステーク量が1ETH以上変化した場合（デポジットやペナルティなどにより）、ブロックプロデューサーの配置全体が再生成されます。

EIP-7917 は、ブロックプロデューサーがブロックを状態に保存することを選択し、RANDAO と同様に 2 つの時間間隔を事前に設定していることを意味します。

これにより、スマートコントラクトがビーコンステートルートを介してマークル証明を検証できるようになり、オンチェーンコントラクトによるブロックプロデューサーのネットワークブロードキャストの検証も容易になります。この改善は、事前承認プロトコルに基づくアプリケーションにとって大きな実用的価値をもたらします。

4. EIP7939

次はEIP-7939、Count Leading Zero (CLZ) オペコードです。これはおそらくoptimizorが最も好むEIPスキームでしょう。なぜなら、現在の最良のYul実装と比較して179ガスを節約できるからです。

CLZ命令は、256ビットEVMワードの先頭のゼロの数を計算するために使用され、幅広い用途があります。言うまでもありませんが、将来的にはより効率的な暗号演算や数学演算を可能にすることが期待されます。

5. EIP7825

EIP-7825 (単一トランザクションのガス上限を設定する提案) では、ガス上限を 2^24 (約 1600 万ガス) に設定しています。これは、単一ブロックの容量の 3 分の 1 をわずかに上回る値です。

単一トランザクションのガス料金に上限を設定することは、主にDDoS攻撃対策として機能します。この対策により、ネットワークノード間の負荷の不均衡を回避できるだけでなく、最悪のケースにおける検証オーバーヘッドを削減し、ステート肥大化を緩和します。

6.EIP7918

次に提案EIP-7918があります。これは、BLOBのガス料金基準を定めることでBLOB市場の改善を目指しています。トランザクションあたり21,000ガスの基本料金と同様に、各BLOBの最小ガス消費基準は8,192ガスとなります。

ご存知の通り、DAレイヤーと実行レイヤーはデュアルトラック課金メカニズムを採用しています。データ利用可能性の価格が急騰した場合でも（例えば、レイヤー2でのNFTキャスティング活動などにより）、メインネットのガス価格は安定を維持します。

しかし、これによって新たな経済問題がいくつか生じました。

ロールアップのコストが主にメインネットのガス料金で構成される場合、BLOBの価格シグナリングメカニズムが機能不全に陥り、システムはBLOB料金を繰り返し引き下げることになります。これがまさに、BLOB料金が1 weiまで急落した後すぐに回復するという、劇的な変動が頻繁に見られる理由です。

したがって、BLOBトランザクション手数料を標準的なガス市場にわずかにリンクさせることで、BLOBスペース手数料の過小評価を防ぐことができます。さらに、これにより、KZG証明を検証する際にノードが実際に消費する計算能力がコストに反映されることが保証されます。

7.EIP7883

今後予定しているEIP-7883提案では、剰余乗算用のプリコンパイル済みコントラクトのコストを引き上げ、特定のユースケースにおいてより正確な価格設定を可能にします。この調整は、この機能の実際の計算リソース消費量をコストに反映させることを目的としています。この機能はこれまで高額でしたが、現在は割安になっています。

この手数料調整により、最小ガスコストが 200 から 500 に上がり、指数が 32 バイトを超える場合の乗数が 2 倍になり、基数または係数が 32 バイトを超える場合の複雑性コストが 2 倍になります。

潜在的なDDoS攻撃を防ぐには、正確な価格設定が不可欠です。ガス料金はノードが消費するリソース量に比例する必要があり、これにより攻撃者が最小限のコストでネットワークノードを麻痺させることを防止できます。

8.EIP7823

EIP-7823は、モジュラー指数演算のためのプリコンパイル済みコントラクトに影響を与える別の提案です。モジュラー指数演算機能は、これまで何度もコンセンサス脆弱性の原因となってきたため、各入力パラメータの長さを1024バイト（8192ビット）に制限しています。

コンセンサス脆弱性は、多数のバリデータが無効な状態遷移を実行した場合に発生します。この状況は、特にプルーフ・オブ・ステークのメカニズムにおいて非常に危険です。最終的に無効なチェーンが特定され、壊滅的な結果につながる可能性があるためです。

モジュラー指数演算は複雑なプリコンパイル関数であるため、実行層クライアントによって実装が極めて微妙に異なる可能性があります。現在、モジュラー指数演算のテストケースは多数存在しますが、入力長がテストカバレッジを超えると、脆弱性のリスクが大幅に高まります。

8192 ビットの長さ制限は、最大 8192 ビットのキーを使用した RSA 検証 (現在は 1024/2048/4096 ビットのキーが一般的に使用されています) のサポートや、通常 384 ビット以下を使用する楕円曲線暗号化アプリケーションなど、すべての実用的なアプリケーションシナリオを満たすことができます。

Ethereum の完全な履歴データの分析に基づくと、正常に実行されたトランザクションの最大入力長は 513 バイト未満であったため、この変更は過去のトランザクションに影響を与えません。

この制限により、将来的には EVMMAX などの新しいソリューションと組み合わせてモジュラー指数演算の事前コンパイルを再構築することも容易になります。

9.EIP7934

EIP-7934では、実行層のブロックサイズ上限を8MiBとすることが提案されています。現在、Ethereumにはブロックサイズ制限はありませんが、P2Pネットワークでは10MiBを超えるブロックを効率的に伝播させることは事実上不可能です。

8 MiB の容量は実際のトランザクションデータ専用となり、2 MiB のバッファはコンセンサスレイヤーのオーバーヘッド用に予約されます。

この制限により、最悪のケースのブロックサイズが現時点ではこの制限をはるかに下回っているにもかかわらず、将来的に極端に大きなブロックが関与するネットワーク攻撃のリスクが最小限に抑えられます。

さて、コア EIP はすべて説明しました。現在は、EIP-7892、EIP-7642、EIP-7910、EIP-7935 といういくつかのマイナーな提案があります。

EIP-7892は、BLOBの目標値、上限、価格設定メカニズムのみを変更する、より頻繁な変更を可能にする新しいタイプのハードフォークを定義します。各BPOフォークでは、設定の変更のみが必要で、コードの変更は不要です。

EIP-7642 は、マージ前に p2p プロトコルからレガシーデータを削除し、p2p の Bloom フィールドを削除して (約 530 GB の同期帯域幅を節約)、ブロック更新機能を追加し、ノードが提供できるブロックの範囲を認識できるようにしました。

EIP-7910では、現在および計画中のハードフォークの設定情報を記述するための新しいJSON-RPCメソッド「eth_config」が導入されました。この機能は、ノードオペレーターやネットワーク監視ツールがクライアントの準備状況を確認できるようにすることを目的としています。

最後に、EIP-7935 はバリデーター設定のデフォルトのブロック GAS 制限を 6,000 万に設定し、ブロックあたり 4,500 万 GAS という現在の標準から増加しました。