イーサリアムは3日以内にこれらの大きな変更を経験するでしょう。

原文： Sahil Sojitra

Odaily Planet Daily Golem ( @web3_golem )がまとめました

2025年12月3日に実施予定のFusakaハードフォークは、Pectraに続くイーサリアムのもう一つの主要なネットワークアップグレードであり、この暗号通貨大手にとってスケーリングに向けたもう一つの重要な一歩となる。

PectraのアップグレードされたEIPは、パフォーマンス、セキュリティ、開発者ツールの改善に重点を置いています。一方、FusakaのアップグレードされたEIPは、スケーリング、オペコードの更新、実行セキュリティに重点を置いています。

PeerDAS (EIP-7594) は、ノードがすべてのデータをダウンロードすることなくBLOBを検証できるようにすることで、データの可用性を向上させます。また、ModExpの制限 (EIP-7823)、トランザクションガス制限の制限 (EIP-7825)、ModExpガスコストの更新 (EIP-7883) など、いくつかのアップグレードにより実行セキュリティも強化されます。このFusakaアップグレードでは、決定論的なプロポーザ先読みメカニズム (EIP-7917) を通じてブロック生成を改善し、実行コストにリンクされた「予約価格」を設定することでBLOB手数料の安定性を維持します (EIP-7918)。

その他の機能強化には、RLP 形式のブロック サイズの制限 (EIP-7934)、ビット操作を高速化するための新しい CLZ オペコードの追加 (EIP-7939)、最新の暗号化およびハードウェア セキュリティ キーとの互換性を向上させるための secp256r1 プリコンパイルの導入 (EIP-7951) などがあります。

Fusakaは、Fulu（実行レイヤー）とOsaka（コンセンサスレイヤー）を組み合わせた名称です。これは、レイヤー2ロールアップをより低コストかつ高速に運用できる、高度にスケーラブルでデータ豊富な未来に向けた、イーサリアムの新たな一歩を象徴するものです。

この記事では、Fusaka ハードフォークの 9 つのコア EIP 提案を詳細に分析します。

EIP-7594: PeerDAS — ノードデータ可用性サンプリング

Ethereum がこの提案を必要とするのは、ネットワークがユーザー、特に Rollup ユーザーにさらに高いデータ可用性を提供したいと考えているためです。

しかし、現在のEIP-4844の設計では、各ノードは公開されているかどうかを確認するために、依然として大量のBLOBデータをダウンロードする必要があります。これはスケーラビリティの問題を引き起こします。すべてのノードがすべてのデータをダウンロードしなければならない場合、ネットワークの帯域幅とハードウェア要件が増加し、分散化の度合いが影響を受けるためです。この問題を解決するために、Ethereumは、ノードがすべてのデータをダウンロードすることなく、データの可用性を確認できる方法を必要としています。

データ可用性サンプリング (DAS) は、ノードが少量のランダム データのみを検査できるようにすることでこの問題に対処します。

しかし、イーサリアムには、既存のゴシップネットワークと互換性があり、ブロックプロデューサーに大きな計算負荷をかけないDAS方式も必要です。PeerDASは、これらのニーズを満たし、ノード要件を低く抑えながらBLOBスループットを安全に向上させるために開発されました。

PeerDASは、ノードがデータの小さな断片のみをダウンロードすることで、完全なデータが公開されているかどうかを確認できるネットワークシステムです。データ全体をダウンロードする代わりに、ノードは通常のゴシップネットワーク共有を利用して、どのノードがデータの特定の部分を保持しているかを検出し、必要な小さなサンプルのみを要求します。この基本的な考え方は、データ断片のランダムな小さな部分のみをダウンロードすることで、ノードが断片全体の存在を確信できるというものです。例えば、ノードは256KBの断片全体ではなく、データの約1/8のみをダウンロードする場合もありますが、多くのノードがさまざまな部分をサンプリングするため、欠落したデータはすぐに検出されます。

PeerDASは、サンプリングを実現するために、EIP-4844内の各データセグメントを拡張するために、基本的な消失訂正符号化方式を採用しています。消失訂正符号化とは、一部のデータセグメントが欠落していても元のデータを復元できるように冗長データを追加する技術です。これは、ピースが欠けていても組み立てられるジグソーパズルに似ています。

BLOBは、元のデータと、その後のデータ再構築を可能にするための追加のエンコードデータを含む「行」に変換されます。この行は、「セル」と呼ばれる小さな断片に分割されます。セルは、KZGコミットメントに関連付けられた最小の検証単位です。その後、すべての「行」は「列」に再編成され、各列にはすべての行で同じ位置にあるセルが含まれます。各列は特定のゴシップサブネットに割り当てられます。

各ノードは、ノードIDに基づいて特定の列を保存し、各タイムスロットでピアからいくつかの列をサンプリングする役割を担います。ノードが少なくとも50%の列を収集すれば、データを完全に再構築できます。50%未満の列を収集した場合、不足している列をピアに要求する必要があります。これにより、データが実際に公開されている場合、常に再構築できるようになります。つまり、合計64列の場合、ノードが完全なBLOBを再構築するために必要な列は約32列だけです。ノードは一部の列を自身で保持し、残りの列をピアからダウンロードします。ネットワークに列の半分が存在すれば、一部の列が欠落していても、ノードはすべてを再構築できます。

さらに、EIP-7594では重要なルールが導入されています。トランザクションは6個を超えるBLOBを含むことはできません。この制限は、トランザクションの検証、ゴシップの伝播、ブロックの作成、そしてブロックの処理中に必ず適用されます。これにより、単一のトランザクションがBLOBシステムに過負荷をかけるような極端なケースを軽減できます。

PeerDASに「セルKZG証明」と呼ばれる機能が追加されました。セルKZG証明は、KZGコミットメントがBLOB内の特定のセル（小さな単位）と一致することを証明します。これにより、ノードはサンプリングしたいセルのみをダウンロードできます。データの整合性を確保しながらBLOB全体を取得することは、データ可用性サンプリングにおいて非常に重要です。

しかし、これらすべてのユニット証明を生成するにはコストがかかります。ブロック生成者は多数のBLOBに対してこれらの証明を繰り返し計算する必要があり、これは非常に時間がかかります。しかし、証明の検証コストは非常に低いため、EIP-7594では、BLOBトランザクションの送信者がすべてのユニット証明を事前に生成し、トランザクションラッパーに含めることを義務付けています。

このため、トランザクション ゴシップ (PooledTransactions) では、変更されたラッパーが使用されるようになりました。

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

新しいラッパーでは、`cell_proofs` は各 BLOB の各セルのすべての証明を含むリストです（例: `[cell_proof_0, cell_proof_1, ...]`）。その他のフィールド `tx_payload_body`、`blobs`、`commitments` は EIP-4844 のものと同一です。違いは、元の単一の "proofs" フィールドが削除され、新しい `cell_proofs` リストに置き換えられ、現在使用されているラッパー形式を示す `wrapper_version` という新しいフィールドが追加されていることです。

PeerDAS により、Ethereum はノードのワークロードを増やすことなくデータの可用性を向上させることができます。現在、ノードは総データの約 1/8 しかサンプリングする必要がありません。将来的には、この割合は 1/16 または 1/32 にまで低下し、Ethereum のスケーラビリティが向上する可能性があります。このシステムは、各ノードが多数のピアを持つため、あるピアが必要なデータを提供できない場合でも、他のピアにデータを要求できるため、効率的に機能します。これにより、冗長性が自然に確立され、セキュリティが向上します。また、ノードは実際に必要な量よりも多くのデータを保存することも選択できるため、ネットワークセキュリティがさらに強化されます。

バリデータノードは、通常のフルノードよりも多くの責任を負います。バリデータノードはより強力なハードウェアで動作するため、PeerDASはバリデータノードの総数に基づいて、対応するデータホスティング負荷をバリデータノードに割り当てます。これにより、より多くのデータを保存・共有できる安定したノードグループが常に確保され、ネットワークの信頼性が向上します。つまり、バリデータノードが90万台ある場合、各バリデータノードには、保存とサービス提供のために総データ量のごく一部が割り当てられることになります。バリデータノードはより強力なマシンで動作するため、ネットワークはバリデータノードにデータの可用性を託すことができます。

PeerDASは行サンプリングではなく列サンプリングを採用しています。これは、データの再構築を大幅に簡素化するためです。ノードが行全体（BLOB全体）をサンプリングすると、元々存在しなかった「拡張BLOB」を余分に作成する必要があり、ブロック生成の速度が低下します。

列サンプリングでは、ノードが追加の行データを事前に準備することができ、必要な証明は（ブロック生成者ではなく）トランザクション送信者によって計算されます。これにより、ブロック生成の速度と効率が維持されます。例えば、BLOBが4x4のセルのグリッドであるとします。行サンプリングでは、1行から4つのセルをすべて取得しますが、一部の拡張行はまだ準備できていないため、ブロック生成者はそれらをその場で生成する必要があります。一方、列サンプリングでは、各行（各列）から1つのセルを抽出し、再構成に必要な追加のセルを事前に準備できるため、ノードはブロック生成の速度を低下させることなくデータを検証できます。

EIP-7594はEIP-4844と完全に互換性があるため、Ethereumの既存の機能に支障をきたすことはありません。すべてのテストと詳細なルールは、コンセンサスおよびエンフォースメント仕様に含まれています。

DASシステムにおける主要なセキュリティリスクは、「データ隠蔽攻撃」です。これは、ブロック生成者がデータが存在するように見せかけて、実際には一部を隠す攻撃です。PeerDASはランダムサンプリングを用いることでこれを防ぎます。ノードはデータのランダムな部分を検査します。サンプリングするノードの数が多いほど、攻撃者が不正行為をするのが難しくなります。EIP-7594では、ノードの総数（n）、サンプルの総数（m）、ノードあたりのサンプル数（k）に基づいて、このような攻撃が成功する可能性を計算する式も提供されています。約1万ノードのEthereumメインネットでは、攻撃が成功する可能性は極めて低いため、PeerDASは安全であると考えられています。

EIP-7823: MODEXPの最大サイズを1024バイトに設定します

この提案の必要性は、イーサリアムの現在のMODEXPプリコンパイルメカニズムが長年にわたり数多くのコンセンサス脆弱性を引き起こしてきたという事実にあります。これらの脆弱性は主に、MODEXPが極めて大規模かつ非現実的な量の入力データを許容し、クライアントに無数の例外処理を強いることに起因しています。

各ノードはトランザクションによって提供されるすべての入力を処理する必要があるため、上限がないことでMODEXPのテストが困難になり、エラーが発生しやすくなり、クライアントごとに動作が異なる可能性が高くなります。また、入力データが過度に大きいため、ガスコストの計算式を予測することが困難になります。データ量が無制限に増加すると価格設定が困難になるためです。これらの問題は、将来的にEVMMAXなどのツールを使用してMODEXPをEVMレベルのコードに置き換えることを困難にしています。なぜなら、固定された制約がないと、開発者は安全で最適化された実行パスを作成できないためです。

これらの問題を軽減し、Ethereum の安定性を向上させるために、EIP-7823 では MODEXP 入力データの量に厳格な上限が追加され、事前コンパイル プロセスがより安全になり、テストが容易になり、予測可能性が向上します。

EIP-7823 は、MODEXP で使用される 3 つの長さフィールド（基数、指数、係数）はすべて 8192 ビット（1024 バイト）以下でなければならないというシンプルなルールを導入しています。MODEXPの入力は、EIP-198 で定義されている形式（<len(基数)> <len(指数)> <len(係数)> <基数> <指数> <係数>）に従うため、この EIP は長さの値のみを制限します。長さが 1024 バイトを超える場合、前処理は直ちに停止し、エラーを返してすべてのガスを消費します。

例えば、誰かが2000バイトの基数を指定しようとすると、処理が開始される前に呼び出しは失敗します。これらの制限は、すべての実用的なアプリケーションシナリオを依然として満たしています。RSA検証では通常、1024ビット、2048ビット、または4096ビットの鍵長が使用されますが、これらはすべて新しい制限内に収まります。楕円曲線演算では、通常384ビット未満のより小さな入力サイズが使用されるため、影響を受けません。

これらの新しい制限は、将来のアップグレードにも役立ちます。将来、MODEXPがEVMMAXを用いたEVMコードとして書き換えられる場合、開発者は一般的な入力サイズ（256ビット、381ビット、2048ビットなど）に対して最適化されたパスを追加し、稀なケースに対しては低速のフォールバック方式を使用できます。最大入力サイズを固定することで、開発者は非常に一般的なモジュラスに対して特別な処理を追加することもできます。以前は、入力サイズが無制限だったため、これは不可能でした。その結果、設計空間が過度に大きくなり、安全に管理できない状態になっていました。

この変更が過去のトランザクションに支障をきたさないことを確認するため、著者らはブロック5,472,266（2018年4月20日）からブロック21,550,926（2025年1月4日）までのすべてのMODEXPの使用状況を分析しました。その結果、これまで正常に実行されたMODEXP呼び出しで、新しい1024バイトの制限を大きく下回る513バイトを超える入力が使用されたものはないことが示されました。実際の呼び出しのほとんどは、32バイト、128バイト、または256バイトといったより短い長さで実行されました。

空の入力、重複バイトで埋められた入力、非常に大きいが無効な入力など、無効または破損した呼び出しがいくつかあります。これらの呼び出しは、それ自体が無効であるため、新しい制限の下でも無効な動作をします。したがって、EIP-7823は重要な技術的変更ですが、過去のトランザクションの結果を実際に変更するものではありません。

セキュリティの観点から見ると、許容入力サイズを縮小しても新たなリスクは発生しません。むしろ、これまでエラーやクライアント間の不整合の原因となっていた不要な極端なケースを排除することになります。EIP-7823は、MODEXP入力を適切な範囲に制限することで、システムの予測可能性を高め、奇妙な極端なケースを減らし、異なる実装間でのエラー発生の可能性を低減します。これらの制限は、将来のアップグレード（EVMMAXなど）で最適化された実行パスが導入された場合のスムーズな移行にも役立ちます。

EIP-7825: 取引限度額1670万ガス

現時点では単一のトランザクションでブロックのガス制限全体をほぼ消費できるため、Ethereum には確かにこの提案が必要です。

これにより、いくつかの問題が発生します。単一のトランザクションがブロックのリソースの大部分を消費し、DoS 攻撃に似た低速の遅延が発生する可能性があります。また、ガスを大量に消費する操作によって Ethereum の状態更新が急速に増加し、ブロックの検証速度が低下して、ノードが対応するのが困難になります。

ユーザーがほぼすべてのガスを消費する大規模なトランザクション（例えば、4000万ガスのブロックで3800万ガスを消費するトランザクション）を送信した場合、他の通常のトランザクションはそのブロックに含めることができず、各ノードはブロックの検証に余分な時間を費やすことになります。これは、検証が遅くなると弱いノードが遅れをとることになり、ネットワークの安定性と分散性を脅かします。この問題に対処するため、イーサリアムは、単一のトランザクションが使用できるガスの量を制限する安全なガスキャップを必要としています。これにより、ブロックの負荷がより予測可能になり、DoS攻撃のリスクが軽減され、ノードへの負荷がより均等になります。

EIP-7825では、厳格なルールが導入されました。それは、いかなるトランザクションも16,777,216 (2²⁴) のガスを超えて消費してはならないというものです。これはプロトコルレベルの上限となり、すべての段階、つまりトランザクションを送信するユーザー、トランザクションをチェックするトランザクションプール、そしてトランザクションをブロックにパッケージ化するバリデーターに適用されます。誰かがこの上限を超えるガスを送信した場合、クライアントは直ちにトランザクションを拒否し、MAX_GAS_LIMIT_EXCEEDEDのようなエラーを返す必要があります。

この制限は、ブロックのガス制限とは完全に独立しています。例えば、ブロックのガス制限が4000万であっても、単一のトランザクションのガス消費量は1670万を超えてはなりません。これは、単一のトランザクションがブロック全体を占有するのではなく、各ブロックが複数のトランザクションを収容できるようにするためです。

これをより理解しやすくするために、ブロックが4000万ガスを保有できると仮定してみましょう。この制限がなければ、誰かが3500万～4000万ガスを消費するトランザクションを送信できてしまいます。このトランザクションはブロックを独占し、他のトランザクションのためのスペースを奪ってしまいます。まるで誰かがバスを貸し切って他の誰も乗車できないようにするようなものです。新しい1670万ガスの制限により、ブロックは複数のトランザクションを自然に収容できるようになり、このような不正使用を防ぐことができます。

この提案では、クライアントがトランザクションを検証する方法に関する具体的な要件も定められています。トランザクションのガスが16,777,216を超える場合、トランザクションプールはそれを拒否しなければなりません。つまり、そのようなトランザクションはキューに追加されません。ブロック検証において、ブロックに上限を超えるトランザクションが含まれている場合、ブロック自体を拒否しなければなりません。

16,777,216 (2²⁴) という数字が選ばれたのは、2のべき乗の境界を明確に表しており、実装が容易であると同時に、スマートコントラクトのデプロイメント、複雑なDeFiインタラクション、複数ステップのコントラクト呼び出しなど、現実世界のほとんどのトランザクションを処理するのに十分な大きさであるためです。この値は一般的なブロックサイズの約半分であり、最も複雑なトランザクションであってもこの制限内に容易に収めることができます。

このEIPは既存のガスメカニズムとの互換性も維持しています。既存のトランザクションのほぼすべてが1600万ガスをはるかに下回る消費量であるため、ほとんどのユーザーはこの変更に気付かないかもしれません。バリデータとブロック作成者は、各トランザクションが新しい上限を遵守している限り、合計ガス量が1670万ガスを超えるブロックを作成できます。

影響を受けるトランザクションは、以前に新しい制限を超えようとし、非常に大きなサイズになったトランザクションのみです。これらのトランザクションは、非常に大きなファイルのアップロードを2つの小さなファイルに分割するのと同様に、複数の小さな操作に分割する必要があります。技術的には、この変更はこれらのまれで極端なトランザクションとの下位互換性はありませんが、影響を受けるユーザーの数はごくわずかになると予想されます。

セキュリティの観点から見ると、ガスキャップの導入により、攻撃者がバリデーターに非常に大規模なトランザクションの処理を強制できなくなるため、イーサリアムはガスベースのDoS攻撃に対する耐性が向上します。また、ブロック検証時間の予測可能性が維持されるため、ノード間の同期が容易になります。極端な例としては、非常に大規模なコントラクトのデプロイメントがいくつかキャップ要件を満たせなくなり、再設計や複数のデプロイメントステップへの分割が必要になる場合があります。

全体として、EIP-7825 は、ネットワークの不正使用に対する保護を強化し、合理的なノード需要を維持し、ブロック スペースの使用の公平性を向上させ、ガス キャップが増加してもブロックチェーンが迅速かつ安定して動作できるようにすることを目的としています。

EIP-7883: ModExpガス料金の値上げ

Ethereum がこの提案を必要とするのは、事前コンパイルされた ModExp (モジュラー指数計算に使用) の価格が、実際に消費するリソースに比べて一貫して低いためです。

ModExp操作の計算負荷が、ユーザーが現在支払っている手数料をはるかに上回る場合があります。このミスマッチはリスクをもたらします。複雑なModExp呼び出しの料金が低すぎると、ボトルネックとなり、ネットワークが安全にガス制限を引き上げることが困難になる可能性があります。これは、ブロックプロデューサーが非常に高い負荷の演算を非常に低いコストで処理せざるを得なくなる可能性があるためです。

この問題に対処するため、EthereumはModExpの価格設定式を調整し、ガス消費量がクライアントが実際に実行した作業量を正確に反映するようにする必要がありました。そのため、 EIP-7883では、最小ガスコストと総ガスコストを引き上げ、入力データ量の多い演算（特に32バイトを超える累乗、基数、剰余演算）のコストを高くする新しいルールが導入され、ガス価格が実際の計算需要に一致するようになりました。

この提案はいくつかの重要な点でコストを増加させ、それによって EIP-2565 で最初に定義された ModExp 価格設定アルゴリズムを変更します。

まず、最小ガス消費量が200から500に増加し、総ガス消費量が3で割られなくなったため、実質的に総ガス消費量が3倍になりました。例えば、ModExp呼び出しで以前は1200ガスを消費していた場合、新しい計算式では約3600ガスを消費することになります。

次に、指数が 32 バイトを超える場合は乗数が 8 から 16 に増加するため、計算コストが 2 倍になります。たとえば、指数の長さが 40 バイトの場合、EIP-2565 では反復回数が 8 × (40 − 32) = 64 増加しますが、EIP-7883 では 16 × (40 − 32) = 128 となり、コストが 2 倍になります。

第三に、料金設定では基数/法の最小サイズを32バイトと想定するようになり、これらの値が32バイトを超えると計算コストが大幅に増加します。例えば、法が64バイトの場合、新しいルールでは、以前のより単純な計算式ではなく、2倍の計算量（2 × ワード数²）を適用することで、大規模な数値演算の実際のコストを反映します。これらの変更により、小規模なModExp演算には妥当な最低料金が支払われ、大規模で複雑な演算のコストはサイズに応じて適切に調整されます。

この提案では、新しいガス計算関数を定義し、計算量と反復回数のルールを更新します。乗算の計算量は、基数/法の長さが32バイト以下の場合はデフォルト値の16を使用し、それより大きい入力の場合はより複雑な式である2 × ワード²に切り替わります。ここで「ワード」は8バイトブロックの数を指します。反復回数も更新され、指数が32バイト以下の場合はビット長に基づいて計算量が決定され、指数が32バイトを超える場合はより大きなガスペナルティが発生します。

これにより、計算コストの高い非常に大きな指数のガスコストが、より高くなることが保証されます。重要なのは、返されるガスコストの最小値が以前の200から500に強制的に変更されたことです。これにより、最も単純なModExp呼び出しでさえも、より合理的なものになります。

これらの値上げは、ModExpの事前コンパイル済み価格が多くの場合で大幅に過小評価されていることを示すベンチマークテストの結果に基づいています。改訂された計算式では、小規模な操作ではガスコストが150%、一般的な操作では約200%増加します。また、大規模または不均衡な操作では、指数、基数、または係数の大きさに応じて、ガスコストが何倍も増加し、場合によっては80倍を超えることもあります。

この変更の目的は、ModExpの動作方法を変更することではなく、極端にリソースを消費する状況下でも、ネットワークの安定性を脅かしたり、ブロックのガスキャップの将来的な増加を妨げたりしないようにすることです。EIP-7883はModExpに必要なガス量を変更するため、下位互換性はありませんが、ガス価格のリプライシングはイーサリアムで複数回行われており、十分に理解されています。

テスト結果によると、ガスコストの大幅な増加が見られます。過去のModExp呼び出しの約99.69%で、500ガス（以前は200ガス）または以前の3倍のガスが必要になっています。しかし、一部の高負荷テストケースでは、ガスコストの増加はさらに大きくなります。例えば、「指数関数的に計算量が多い」テストでは、ガス消費量が215から16,624に急増し、約76倍に増加しました。これは、非常に高い指数に対する価格設定がより合理的になったためです。

セキュリティの観点から見ると、この提案は新たな攻撃ベクトルを導入するものではなく、計算コストを削減するものでもありません。むしろ、重大なリスクを軽減することに重点を置いています。ModExp演算の価格が過度に低い場合、攻撃者は極めて低いコストで、非常に計算負荷の高い計算でブロックを埋めてしまう可能性があります。唯一の潜在的な欠点は、一部のModExp演算の価格が高くなりすぎる可能性があることですが、これは現在の価格設定が過度に低いという問題よりもはるかに良いものです。この提案はインターフェースの変更や新機能を導入するものではないため、既存の算術動作とテストベクトルは引き続き有効です。

EIP-7917: 次の提案者を正確に予測する

イーサリアムがこの提案を必要とするのは、ネットワークの次のエポックにおける提案者のスケジュールを完全に予測できないためです。N+1番目のエポックのRANDAOシードがN番目のエポックで判明したとしても、N番目のエポックにおける実効残高（EB）の更新により、実際の提案者リストは変更される可能性があります。

これらのEBの変更は、スラッシング、ペナルティ、1ETHを超える報酬、バリデータ統合、あるいは新規デポジット（特にEIP-7251で最大有効残高が32ETH以上に増加した後）などに起因する可能性があります。この不確実性は、次の提案者を事前に把握する必要があるシステム（事前確認プロトコルなど）にとって問題となり、円滑に機能するためには安定的かつ予測可能なタイムラインが必要となります。バリデーターは、次のエポックの提案者に影響を与えるために、有効残高を「パンプ」したり操作したりしようとする可能性さえあります。

これらの問題のため、Ethereum では、直前の EB 更新によって変更されず、アプリケーション層から簡単にアクセスできるように、次の数エポックにわたってプロポーザーのタイムラインを完全に決定論的にする方法が必要です。

これを実現するために、EIP-7917では決定論的なプロポーザ先読みメカニズムが導入されました。このメカニズムは、各エポックの開始時に、次のMIN_SEED_LOOKAHEAD + 1エポック分のプロポーザスケジュールを事前に計算して保存します。簡単に言うと、ビーコンステートには「prosoperer_lookahead」と呼ばれるリストが含まれるようになり、これは常に2サイクル分（合計64スロット）のプロポーザをカバーします。

例えば、エポックNの開始時には、リストにはすでにエポックNとエポックN+1の各スロットのプロポーザが含まれています。その後、ネットワークがエポックN+1に入ると、リストは前方にシフトされます。エポックNのプロポーザエントリは削除され、エポックN+1のエントリはリストの先頭に移動され、エポックN+2の新しいプロポーザエントリがリストの末尾に追加されます。これにより、スケジューリングは固定され予測可能になり、クライアントは各スロットのプロポーザを再計算することなく、直接スケジューリングを読み取ることができます。

リストを最新の状態に保つため、各エポックの境界でリストは前進します。前のエポックのデータは削除され、次のエポックの新しいプロポーザインデックスセットが計算され、リストに追加されます。このプロセスでは、以前と同じシードと実効残高ルールが使用されますが、スケジューリングはより早く計算されるため、シード決定後の実効残高の変化による影響を回避できます。また、フォーク後の最初のブロックは、将来のすべてのエポックでスケジューリングが正しく初期化されるように、先読み範囲全体にデータを設定します。

単純化のため、エポックあたりのスロット数が32ではなく8であると仮定しましょう。このEIPがない場合、第5エポックでは、第6エポックのシード値が分かっていても、バリデータがペナルティを受けたり、第5エポック中に実質的な残高を変更するのに十分な報酬を受け取ったりすると、第6エポックのスロット2の実際の提案者が変わる可能性があります。EIP-7917では、Ethereumは第5エポックの開始時に第5、第6、第7エポックのすべての提案者を事前計算し、それらを順に「prosopers_lookahead」に格納します。したがって、第5エポックの後半で残高が変化したとしても、第6エポックの提案者リストは固定され、予測可能なままです。

EIP-7917は、ビーコンチェーン設計における長年の欠陥に対処します。この仕様は、前のエポックのRANDAOが利用可能になると、将来のエポックのバリデータの選択を変更できないことを保証します。また、バリデータがRANDAOを確認した後に残高を調整し、次のエポックの提案者リストに影響を与えようとする「実効残高スクランブル」も防止します。この決定論的な先読みメカニズムは、攻撃ベクトル全体を排除し、セキュリティ分析を大幅に簡素化します。また、コンセンサスクライアントは誰が今後のブロックを提案するかを事前に把握できるため、実装が容易になり、アプリケーション層はビーコンルートのMerkle証明を介して提案者のスケジュールを容易に検証できます。

この提案以前は、クライアントは現在のタイムスロットの提案者のみを計算していました。EIP-7917では、エポック遷移ごとに、次のエポックの全タイムスロットの提案者リストを一度に計算するようになりました。これにより若干の作業量が追加されますが、提案者インデックスの計算は非常に軽量で、主にシードを用いてバリデータリストをサンプリングするだけです。ただし、クライアントはベンチマークを実施し、この追加計算がパフォーマンス上の問題を引き起こさないことを確認する必要があります。

EIP-7918: Blob 基本手数料は実行コストによって制限されます。

イーサリアムがこの提案を必要とするのは、ガスがローリングの主なコストになると、現在の Blob 料金システム (EIP-4844 から派生) が機能しなくなるためです。

現在、ほとんどのロールアップで支払われる実行ガス（Blobトランザクションをブロックに含めるためのコスト）は、実際のBlob手数料よりもはるかに高くなっています。これが問題を引き起こします。Ethereumが基本Blob手数料を継続的に削減しても、最も高いコストは依然として実行ガスであるため、ロールアップの総コストは実際には変化しません。したがって、基本Blob手数料は絶対最小値（1 wei）に達するまで減少し続け、その時点でプロトコルはBlob手数料を使用して需要を制御できなくなります。その後、Blobの使用量が急増すると、Blob手数料が通常のレベルに戻るまでに多くのブロックが必要になります。これにより、価格が不安定になり、ユーザーにとって予測不可能になります。

例えば、Rollupがデータを公開する場合、実行ガスとして約25,000,000 gweiを支払う必要があります（約1,000,000ガスには25 gweiが必要です）。一方、Blob手数料は約200 gweiです。つまり、総コストは約25,000,200 gweiとなり、そのほとんどがBlob手数料ではなく実行ガスから発生します。EthereumがBlob手数料を、例えば200 gweiから50 gwei、10 gwei、そして最終的に1 gweiへと引き下げ続けたとしても、総コストはほとんど変わらず、25,000,000 gweiのままです。

EIP-7918 は、実行ベースコストに基づいて最小の「予約価格」を導入することでこの問題に対処し、Blob 価格が低くなりすぎるのを防ぎ、Rollup の Blob 価格設定をより安定して予測可能にします。

EIP-7918の核となる考え方はシンプルです。BLOBの価格は、実行ガスコスト（BLOB_BASE_COSTと呼ばれる）の一定額を下回ってはならない、というものです。calc_excess_blob_gas ()の値は2¹³に設定されており、このメカニズムはcalc_excess_blob_gas()関数に若干の修正を加えることで実装されています。

通常、この関数は、ブロックで使用されるBLOBガスが目標値を上回っているか下回っているかに基づいて、BLOB基本手数料を増減させます。この提案では、BLOBが実行ガスに対して「低すぎる」状態になった場合、この関数は目標BLOBガスの減額を停止します。これにより、BLOBガスの超過量がより急速に増加し、BLOB基本手数料のさらなる減少を抑制します。したがって、BLOB基本手数料の最小値は、 BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB となります。

なぜこれが必要なのかを理解するために、BLOBの需要を見てみましょう。ロールアップは、支払う総コスト、つまり実行コストとBLOBコストに焦点を当てています。実行ガスコストが非常に高い場合、例えば20gweiの場合、BLOBコストが2gweiから0.2gweiに下がっても、総コストはほぼ変わりません。つまり、BLOBの基本コストを下げても需要にはほとんど影響がないということです。経済学では、これを「コストの非弾力性」と呼びます。これにより、需要曲線がほぼ垂直になり、価格を下げても需要は増加しない状況が生まれます。

このシナリオでは、Blob基本手数料メカニズムは盲目的になり、需要が反応しない場合でも価格を下げ続けます。そのため、Blob基本手数料はしばしば1gweiまで下がります。その後、実際の需要が増加すると、プロトコルは手数料を妥当なレベルまで引き上げるために、ほぼ満杯のブロックが1時間以上必要になります。EIP-7918は、実行ガスにリンクされた最低価格を設定することでこの問題に対処し、実行コストが支配的になった場合でもBlob手数料が意味のある水準を維持できるようにします。

この予約価格を追加するもう一つの理由は、ノードがBLOBデータのKZG証明を検証するために多くの追加作業を行う必要があるためです。これらの証明は、BLOB内のデータがその約束と一致することを保証します。EIP-4844では、ノードはBLOBごとに1つの証明を検証するだけでよく、これは低コストです。しかし、EIP-7918では、ノードははるかに多くの証明を検証する必要があります。これは、EIP-7594（PeerDAS）ではBLOBがセルと呼ばれる多数の小さな部分に分割され、それぞれに独自の証明があるため、検証作業量が大幅に増加するためです。

長期的には、EIP-7918はイーサリアムの将来への準備にも役立ちます。技術の進歩に伴い、データの保存と共有にかかるコストは自然に低下し、イーサリアムは時間の経過とともにより多くのBlobデータの保存を可能にすると予想されます。Blobの容量が増加するにつれて、Blob手数料（ETH単位）は自然に低下します。この提案は、保持価格が固定値ではなく実行ガス価格に固定されているため、ネットワークの成長に合わせて調整できるため、この考え方を支持しています。

BLOB空間と実行ブロック空間が拡大するにつれて、両者の価格関係は均衡を保ちます。Ethereumが実行ガス容量を増やさずにBLOB容量を大幅に増加させるという稀なケースにおいてのみ、準備金価格が過度に高くなる可能性があります。このようなシナリオでは、BLOB手数料が最終的に実際の需要を上回る可能性があります。しかし、Ethereumはそのような拡張を計画しておらず、BLOB空間と実行ブロック空間は連動して拡大すると見込まれています。したがって、選択された値（BLOB_BASE_COST = 2¹³）は安全かつ均衡が取れていると考えられます。

実行ガス料金が突然急上昇した場合、注意すべき小さな詳細があります。BLOB の価格は基本実行コストに依存するため、実行コストが急上昇すると、一時的に BLOB 料金が実行コストによって支配される状態になる可能性があります。たとえば、実行ガス料金がブロック内で 20 gwei から 60 gwei に突然跳ね上がったとします。BLOB の価格はこの値に固定されているため、BLOB 料金は新しい高いレベルを下回ることはできません。BLOB がまだ使用されている場合、その料金は通常どおり増加し続けますが、プロトコルは、料金がより高い実行コストに見合うほど増加するまで料金を下げることを許可しません。つまり、数ブロック以内に、BLOB 料金の増加が実行コストよりも遅くなる可能性があります。この一時的な遅延は無害であり、実際には BLOB 価格の急激な変動を防ぎ、システムをよりスムーズにします。

著者らはまた、2024年11月から2025年3月までの実際のブロック取引活動について、準備金ルールを適用した実証分析を行った。実行手数料が高かった期間（平均約16gwei）には、準備金閾値により、従来のメカニズムと比較して基本ブロック手数料が大幅に増加した。実行手数料が低かった期間（平均約1.3gwei）には、算出された基本ブロック手数料が準備金ルールを下回らない限り、ブロック手数料はほぼ一定であった。著者らは数千のブロックを比較することで、新しいメカニズムは需要への自然な反応を維持しながら、より安定した価格設定を実現することを示している。4か月間のブロック手数料ヒストグラムは、準備金ルールがブロック手数料が1gweiまで急落するのを防ぎ、極端なボラティリティを低減していることを示す。

セキュリティの観点から、この変更はリスクをもたらしません。ベースブロック手数料は常に、ガス実行の単位コストであるBLOB_BASE_COSTと同等かそれ以上になります。このメカニズムは最低手数料のみを引き上げ、価格の下限を設定してもプロトコルの正確性に影響を与えないため、これは安全です。健全な経済運営を確保するだけです。

EIP-7934: RLPはブロックサイズの制限を強制します

EIP-7934以前、イーサリアムはRLPでエンコードされた実行ブロックのサイズに厳密な上限を設けていませんでした。理論上、ブロックに多数のトランザクションや非常に複雑なデータが含まれている場合、そのサイズは非常に大きくなる可能性がありました。これにより、ネットワークの不安定性とサービス拒否（DoS）攻撃のリスクという2つの大きな問題が発生しました。

ブロックが大きすぎると、ノードによるダウンロードと検証に時間がかかり、ブロックの伝播が遅くなり、一時的なブロックチェーンフォークの可能性が高まります。さらに悪いことに、攻撃者が意図的に非常に大きなブロックを作成してノードに過負荷をかけ、遅延を引き起こしたり、オフラインにしたりする可能性があります。これは典型的なサービス拒否攻撃です。さらに、イーサリアムのコンセンサスレイヤー（CL）のゴシッププロトコルは、10MBを超えるブロックの伝播を拒否します。つまり、過度に大きな実行ブロックはネットワークを伝播できず、オンチェーンの断片化やノード間の不一致を引き起こす可能性があります。これらのリスクを考慮すると、イーサリアムは過度に大きなブロックを防ぎ、ネットワークの安定性とセキュリティを維持するための明確なプロトコルレベルのルールを必要としています。

EIP-7934は、プロトコルレベルのRLPエンコーディングを導入し、ブロックサイズの上限を強制することでこの問題に対処しています。最大ブロックサイズ（MAX_BLOCK_SIZE）は10MiB（10,485,760バイト）に設定されていますが、ビーコンブロックも一定のスペース（SAFETY_MARGIN）を占有するため、Ethereumはこの制限に2MiB（2,097,152バイト）を追加します。

これは、RLPエンコードされたブロックの最大許容サイズがMAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGINであることを意味します。エンコードされたブロックがこの制限を超えた場合、無効とみなされ、ノードはそれを拒否しなければなりません。このルールでは、ブロック生成者は構築する各ブロックのエンコードされたサイズを確認し、バリデータはブロック検証時にこの制限を検証する必要があります。このサイズ上限はガス制限とは独立しており、ブロックが「ガス制限を下回っている」場合でも、エンコードされたサイズが大きすぎる場合は拒否されます。これにより、ガス使用量と実際のバイトサイズ制限の両方が満たされることが保証されます。

10MiBという上限は、コンセンサス層のゴシッププロトコルにおける既存の制限と整合させるため、意図的に設定されています。10MiBを超えるデータはネットワーク全体にブロードキャストされないため、このEIPによって実行層はコンセンサス層の制限と整合性を保つことができます。これにより、すべてのコンポーネント間の一貫性が確保され、CLが伝播を拒否することで有効な実行ブロックが「見えなくなる」ことを防ぎます。

この変更は、新しい制限を超えるブロックとの後方互換性がないため、マイナーとバリデータはクライアントを更新してこのルールに準拠する必要があります。ただし、ブロックサイズが大きすぎることは本質的に問題であり、実際には一般的ではないため、影響は最小限です。

セキュリティ面では、EIP-7934は、ネットワークを麻痺させるようなブロックを参加者が作成できないようにすることで、特定のブロックサイズを標的としたDoS攻撃に対するイーサリアムの耐性を大幅に強化します。要約すると、EIP-7934は重要なセキュリティ境界を追加し、安定性を向上させ、実行ロジック（EL）とCLの動作を標準化し、過大なブロックの作成と伝播に関連するさまざまな攻撃を防止します。

EIP-7939: 先頭ゼロの計算 (CLZ) オペコード

このEIP以前、イーサリアムには256ビットの数値の先頭のゼロの数を計算するための組み込みオペコードがありませんでした。開発者はSolidityを使用してCLZ関数を手動で実装する必要があり、多数のビット演算と比較が必要でした。

これは重大な問題です。カスタム実装は遅く、コストが高く、大量のバイトコードを消費し、ガス消費量を増加させるからです。ゼロ知識証明システムの場合、コストはさらに高くなります。右シフト演算の証明コストは非常に高いため、CLZのような演算はゼロ知識証明回路の速度を著しく低下させます。CLZは非常に一般的な低レベル関数であり、数学ライブラリ、圧縮アルゴリズム、ビットマップ、署名スキーム、そして多くの暗号化やデータ処理タスクで広く使用されているため、Ethereumにはより高速で経済的な計算手法が必要です。

EIP-7939では、CLZ (0x1e) という新しいオペコードを導入することでこの問題に対処しています。このオペコードはスタックから256ビットの値を読み取り、先頭のゼロの数を返します。入力値がゼロの場合、オペコードは256を返します。これは、256ビットのゼロには先頭に256個のゼロがあるためです。

これは、CLZ演算がネイティブにサポートされているARMやx86などの多くのCPUアーキテクチャにおけるCLZの動作と一致しています。CLZを追加することで、多くのアルゴリズムのオーバーヘッドを大幅に削減できます。lnWad、powWad、LambertWなどの演算、様々な数学関数、バイト文字列の比較、ビットマップスキャン、データ圧縮/解凍呼び出し、量子耐性署名スキームなどは、ゼロ先読み検出の高速化の恩恵を受けることができます。

CLZのガスコストはADDと同程度の5に設定されており、以前のMUL価格よりもわずかに高くなっています。これは、価格設定の低さによるサービス拒否（DoS）攻撃のリスクを回避するためです。ベンチマークでは、CLZの計算コストは​​ADDとほぼ同じであることが示されており、SP1 rv32im証明環境では、CLZの証明コストは実際にはADDよりも低く、ゼロ知識証明のコストが削減されています。

EIP-7939 は新しいオペコードを導入し、既存の動作を変更しないため、完全な下位互換性があります。

全体として、EIP-7939 は、最新の CPU ですでにサポートされているシンプルで効率的なプリミティブを追加することで、ガス料金の削減、バイトコード サイズの縮小、多くの一般的な操作のゼロ知識証明のコストの削減を実現し、Ethereum をより高速、安価、開発者にとって使いやすいものにします。

EIP-7951: 最新のハードウェアの署名をサポートします。

この EIP 以前は、Ethereum には secp256r1 (P-256) 曲線を使用して作成されたデジタル署名を検証するための安全でネイティブな方法がありませんでした。

この曲線は、Apple Secure Enclave、Android Keystore、HSM、TEE、FIDO2/WebAuthnセキュリティキーなどの最新デバイスで使用されている標準です。このサポートがなければ、アプリケーションやウォレットはデバイスレベルのハードウェアセキュリティを使用して署名を簡単に実行できません。以前の試み（RIP-7212）には、無限大点の処理と誤った署名比較に関連する2つの深刻なセキュリティ脆弱性がありました。これらの問題は、検証エラーやコンセンサス失敗につながる可能性がありました。EIP -7951はこれらのセキュリティ問題に対処し、安全なネイティブコンパイル済みプロトコルを導入することで、Ethereumが最新ハードウェアからの署名を安全かつ効率的にサポートできるようになりました。

EIP-7951は、アドレス0x100にP256VERIFYという新しいプリコンパイル済みコントラクトを追加します。このコントラクトは、secp256r1曲線を用いたECDSA署名検証を実行します。これにより、Solidityに直接アルゴリズムを実装する場合と比較して、署名検証が高速化され、コストも削減されます。

EIP-7951は、厳密な入力検証ルールも定義しています。無効なケースが存在する場合、プリコンパイルはロールバックせずに失敗を返し、成功した呼び出しと同じガスを消費します。検証アルゴリズムは標準ECDSAに準拠しています。s⁻¹ mod nを計算し、署名点R'を再構築し、R'が無限大にある場合はそれを拒否し、最後にR'のx座標がr (mod n)と一致するかどうかを確認します。これは、r'をまずnを法として単純化するのではなく、直接比較するRIP-7212のエラーを修正するものです。

このオペレーションのガス料金は6900ガスに設定されており、RIP-7212バージョンよりも高額ですが、secp256r1によって検証された実際のパフォーマンスベンチマークと一致しています。重要なのは、このインターフェースは既にRIP-7212を導入しているレイヤー2ネットワークと完全に互換性があることです（同じアドレス、同じ入出力形式）。そのため、既存のスマートコントラクトは変更を加えることなく正常に機能し続けます。唯一の違いは、変更された動作とガス料金の引き上げです。

セキュリティの観点から、EIP-7951はECDSAの正しい動作を復元し、プリコンパイルレベルでの可塑性の問題を排除し（オプションのチェックはアプリケーションに委ねる）、プリコンパイルでは定数時間の実行を必要としないことを明示的に規定しています。secp256r1曲線は128ビットのセキュリティを提供し、幅広い信頼と分析を獲得しているため、Ethereumで安全に使用できます。

つまり、EIP-7951 は、最新のハードウェア サポート認証を Ethereum に安全に導入し、以前の提案のセキュリティ問題を修正し、エコシステム全体で P-256 署名を検証するための信頼性の高い標準化された方法を提供することを目的としています。

要約

以下の表は、Fusaka EIPごとに変更が必要なEthereumクライアントをまとめたものです。「コンセンサスクライアント」のチェックマークは、EIPのコンセンサスレイヤークライアントを更新する必要があることを示し、「実行クライアント」のチェックマークは、アップグレードが実行レイヤークライアントに影響することを示します。EIPによっては、コンセンサスレイヤーと実行レイヤーの両方の更新が必要なものもありますが、どちらか一方の更新のみが必要なものもあります。

まとめると、これらがFusakaハードフォークに含まれる主要なEIPです。このアップグレードには、ガス調整やオペコードの更新から新しいプリコンパイルバージョンまで、コンセンサスクライアントと実行クライアントへのいくつかの改善が含まれていますが、このアップグレードの中核は依然としてPeerDASです。PeerDASはピアツーピアのデータ可用性サンプリングを導入し、ネットワーク全体でBlobデータをより効率的かつ分散的に処理することを可能にします。