Ethereum EIP-8479の解説：耐量子ペアダスと可変サイズのブロブ
もしEthereumが、レイヤー2ネットワークがトランザクションデータを公開する方法に対してより柔軟性を提供しながら、将来の量子コンピューターに対してデータ可用性インフラをより耐性のあるものにできるとしたら？2026年11月1日にEthereum財団の研究者Francesco Risitanoが導入した新しい提案は、まさにその可能性を検討しています。当初EIP-9999と番号付けされたこの草案は、PeerDAS内のKZGコミットメントをKeccak-256 MerkleコミットメントとLeanDA STARK証明で置き換えることを提案しています。また、2 KiBから512 KiBまでの可変サイズのブロブを導入し、ロールアップが自身のニーズにより密接したデータ容量を選択できるようにします。Ethereum Magiciansのディスカッションスレッドでは、この提案をEIP-8479と呼んでおり、提案を追跡する際には番号の区別が重要です。この設計はまだ初期レビュー段階ですが、ポスト量子暗号、データ可用性、レイヤー2のスケーラビリティというEthereum開発の三大優先事項を結びつけています。その潜在的な意義はプロトコルエンジニアリングを超えて、ロールアップのコスト、Ethereumのインフラ競争力、そしてETHの長期的なエコシステム価値に関する問いを提起しています。
-
新しいポスト量子プロポーザル：草案では、KZGベースのPeerDASコミットメントをKeccak-256 MerkleコミットメントとLeanDA STARK証明で置き換えることを検討しています。
-
可変サイズのブロブ：設計により、各ブロブの列数を128列に保ちながら、2 KiBから512 KiBまでの2のべき乗サイズを許可します。
-
レイヤー2への影響：ロールアップは、トランザクションバッチにより密接に合わせたデータ容量を選択できる可能性があり、データ利用効率の向上が期待されます。
-
暗号学的変更: Merkle認証パスがKZGセル証明に置き換えられ、STARK証明がReed-Solomonエンコーディングとコミットメント導出を検証します。
-
初期開発段階：この提案はドラフト段階にあり、証明システムのパラメータ、クライアント統合、パフォーマンスベンチマークの調整が必要です。
-
ETHの市場関連性：この提案はEthereumの長期的なインフラストラクチャーに関する物語を強化する可能性がありますが、ETH価格の即時の触媒を確立するものではなく、トランザクション手数料の低下を保証するものでもありません。
この提案は、Ethereumのデータ可用性レイヤーの長期的な暗号的安全性と、ロールアップのためのより柔軟なデータ容量の必要性という、関連する二つの課題に対処しています。元の仕様のタイトルはEIP-9999ですが、11月1日のディスカッションスレッドではEIP-8479というタイトルが使用されています。この提案はFrancesco Risitano、Thomas Coratger、Tom Wambsgansによって作成され、初期草案の日付は2026年10月26日です。この提案はCore、Standards TrackのEIPであり、現在はDraftステータスです。この提案はEIP-4844、EIP-7594、EIP-7892、EIP-8141、EIP-8288を含む複数の関連提案を参照しています。
既存のPeerDASには異なる暗号学的アプローチが必要な理由
PeerDAS（ピア・データ・可用性サンプリング）は、Ethereumノードがブロブ全体のすべてのバイトをダウンロードせずに、ブロブデータが利用可能であるかを確認できるようにします。このメカニズムは、データを列に分割し、ノードに保管責任を割り当て、参加者が選択された部分をサンプリングできるようにします。これにより、通常のバリデーターのデータ要件が削減されながら、データの可用性を確認する方法が維持されます。
現在の設計は、KZGコミットメントとセル証明を使用してサンプリングされたデータを認証しています。KZGは、楕円曲線ペアリング暗号に依存しており、理論的にはShorアルゴリズムを実行する十分な能力を持つ耐障害性量子コンピュータに対して脆弱です。現在のところ、Ethereumの暗号的仮定を破ることができる実用的な量子コンピュータは存在しませんが、プロトコル研究者は、そのような脅威が実用化される前に代替策を評価しています。したがって、EIP-8479の議論は、即時的な量子攻撃への対応ではなく、将来を見据えたセキュリティ戦略を反映しています。
Blobの柔軟性がEthereumに重要な理由
二つ目の動機は、ロールアップがデータ容量を購入し公開する方法に関するものです。固定サイズのデータ構造は、ロールアップのトランザクションバッチが利用可能な容量と一致しない場合、非効率を生む可能性があります。小さなバッチでは使用されていないスペースが残り、より大きなバッチを蓄積するまで待つと、さらに公開の遅延が発生します。
可変サイズのブロブは、ロールアップオペレーターがこのトレードオフに対してより多くの制御を可能にすることを目的としています。すべてのサブミッションを固定容量の単位として扱うのではなく、提案された設計では、対応するブロブサイズを2のべき乗で拡張できます。これにより、データ公開が異なるトランザクション量や運用要件により柔軟に対応できるようになります。
中央の暗号的変更は、KZGコミットメントとセル証明をKeccak-256 Merkleコミットメント、Merkle認証パス、およびLeanDA STARK証明で置き換えることです。この設計は、個々のデータサンプルの認証タスクと、ブロブ全体が正しくエンコードされコミットされたことを証明するタスクを分離しています。これは、楕円曲線ペアリングの仮定への依存を排除し、既存のKZG構成に必要な信頼設定を削除することを目的としています。
Keccak-256 Merkleコミットメント
メルクルツリーは、繰り返しのハッシュ処理を通じてデータを整理します。個々のデータ要素はまずリーフノードにハッシュされ、その後、ハッシュのペアが結合されてより上位のノードが生成されます。このプロセスは、単一のメルクルルートが基盤となるデータ構造を表すまで繰り返されます。
提案されたPeerDAS設計では、各blobにKeccak-256ベースのMerkleコミットメントが割り当てられます。ノードが特定のデータセルをサンプリングすると、対応するMerkle認証パスを受け取り、そのセルがコミットされたblobに属していることを独立して検証できます。これにより、KZGセル証明に依存せずにサンプリングされたデータを認証できるようになります。
Keccak-256は特に重要である。ハッシュベースの暗号構成は、楕円曲線離散対数に基づく方式よりもポスト量子セキュリティに適していると一般に考えられているからである。量子検索アルゴリズムは依然としてハッシュ関数の有効なセキュリティを低下させる可能性があるため、セキュリティパラメータと実装の詳細は引き続き重要である。したがって、この提案は、すべての将来の量子攻撃に対する保証ではなく、量子耐性のある暗号仮定への移行と理解すべきである。
LeanDA STARKは実際に何を検証しますか？
Merkle認証は、サンプリングされたセルが特定のコミットされたデータ構造に属することを確立しますが、プロトコルはまた、blobのデータエンコードおよびコミット生成が正しく行われていることを確立しなければなりません。ここにLeanDA STARKが重要になります。
提案されたSTARKは、二つの中心的な性質を証明します：blobがReed-Solomon符号化の関係を満たしていること、および関連するMerkleコミットメントが正しく導出されていることです。Reed-Solomon符号化は、十分な有効な部分が利用可能である場合に、欠落したデータ部分を再構成できるように冗長性を導入します。この証明により、ネットワークは関連する符号化およびコミットメントの関係を検証でき、すべての検証者がその計算を独立して繰り返す必要がなくなります。
この提案はまた、LeanDA証明をEIP-8288と結びつけており、EIP-8288はブロックレベルの再帰的STARK集約フレームワークを提供する。各証明を孤立した検証タスクとして扱うのではなく、この設計はデータ可用性依存フレームを導入し、その証明をより広範なブロックレベルの集約に統合できる。この統合は技術的に重要であり、証明生成、集約、検証のコストが、この設計がEthereumクライアントにとって実用的かどうかに影響を与えるからである。
この提案では、blobのサイズを2 KiBから512 KiBまでとし、サポートされるバイト長は2のべき乗に制限されます。各blobは128列を維持し、個々のデータユニットのバイト長は変化しますが、全体の列構造は一貫して保持されます。これは、Ethereumの既存のデータ可用性インフラで使用されている従来の固定サイズblobモデルとは大きな違いです。
固定容量から柔軟なデータ公開へ
提案された設計では、ロールアップは公開する必要のあるデータ量により近いサイズのブロブを選択できます。小さなトランザクションバッチは小さなブロブを使用し、大きなバッチはより大きな容量を選択できます。目的は不要なパディングを削減し、ロールアップがデータ可用性コストと公開頻度のバランスをより柔軟に取れるようにすることです。
以下の例は、提案された容量範囲を示しています：
-
2 KiB：容量が限られた小さなデータ提出。
-
8 KiB–64 KiB：比較的コンパクトなトランザクションバッチ用の中間サイズ。
-
128 KiB：従来のブロブ容量に対応するなじみのある基準値。
-
256 KiB–512 KiB：追加のデータ容量を必要とするより大きな提出物。
提案は、ブロブを含むトランザクションへの変更も明示しています。既存のバージョン済ハッシュ表現にのみ依存するのではなく、提案されたトランザクション構造はMerkleルートと明示的なバイト長フィールドを使用します。ブロブを含むトランザクションは、EIP-8141フレームトランザクションを用いて表され、新しいデータ構造を広範なトランザクション形式設計にリンクします。
可変サイズのブロブはガスコストにどのように影響しますか？
柔軟なblob容量はデータ利用効率を向上させる可能性がありますが、blobサイズと手数料の関係は、より小さなblobを選択すれば自動的に手数料が安くなるという単純なものではありません。この提案は、ネットワーク要件とガス会計も変更し、Merkle認証および新しい検証プロセスに関連するコストを含みます。
ロールアップオペレーターにとって、関連する計算には生データ容量以上の要素が含まれます。取引バッチサイズ、ブロブ公開頻度、証明生成コスト、ネットワーク伝播、およびブロブガスの市場価格を考慮する必要があります。あるワークロードには小さなブロブが効率的である一方、別のワークロードでは大きなサブミッションが好ましい場合があります。
したがって、この設計は普遍的な手数料削減を約束するのではなく、データ公開の最適化の機会をもたらします。実際の節約額は、実装のベンチマークと、この提案がさらに検討された後のロールアップ開発者がバッチ処理戦略をどのように調整するかに依存します。
この提案は、Layer 2ネットワーク、特にトランザクションデータをバッチで公開するロールアップのニーズに応じて、Ethereumのデータ可用性インフラをより柔軟にすることが可能になります。Arbitrum、Optimism、Baseは、効率的で予測可能なデータ公開に興味を持つ主要なEthereumスケーリングエコシステムの例です。ただし、EIP-8479はそれらの実行環境を直接変更するものではなく、ユーザーのトランザクション手数料の即時削減を保証するものでもありません。
ロールアップオペレーターへの潜在的なメリット
ラップアップは、トランザクションバッチの送信頻度とEthereumへのデータ公開コストのバランスを取る必要があります。固定容量のブロブは、実際のデータ要件と購入した容量との不一致を生む可能性があります。可変サイズのブロブであれば、オペレーターがバッチサイズや公開スケジュールを設計する際により多くの選択肢を得られます。
たとえば、比較的取引アクティビティが低いロールアップは、より大きな固定容量の構造を満たすためにデータを十分に蓄積するのを待たずに、小さなバッチを公開することを好むかもしれません。一方、高ボリュームのロールアップは、各サブミッションにより多くのデータを凝縮するために、より大きなブロブを使用できます。これらの選択肢は、運用の柔軟性を向上させ、データ可用性コストと取引遅延の関係を開発者が最適化するのに役立ちます。
利点はネットワークごとに必ずしも同じではありません。ロールアップはトランザクション量、圧縮技術、シーケンシングモデル、およびデータ公開戦略において異なります。したがって、開発者は追加の柔軟性が実装および証明生成コストを上回るかどうかを評価する必要があります。
Ethereumのレイヤー2競争への影響
Ethereumは、実行、トランザクション決済、データ可用性において異なるアプローチを提供する代替ブロックチェーンエコシステムと競合しています。ブロブインフラの効率を向上させることで、Ethereumはロールアップベースのアプリケーションの決済およびデータ可用性レイヤーとしての地位を強化できます。
ただし、ネットワークの競争力はブロブ容量だけでなく、トランザクション手数料、アプリケーションのパフォーマンス、流動性、相互運用性、セキュリティ、エコシステムのサポートにも依存します。EIP-8479は、ロールアップスケーリングの基盤となる暗号化およびデータ可用性インフラストラクチャという、この広範な方程式の重要な一部に対応しています。
したがって、その潜在的な貢献は、すでに実証された即時の競争優位性としてではなく、時間の経過とともにEthereumのLayer 2開発環境を強化するインフラ改善として評価するのが最適です。
EIP-8479は、Ethereumの広範な量子後研究アジェンダにおけるデータ可用性のコンポーネントを解決します。これはネットワークで使用されるすべての暗号プリミティブを置き換えるものではなく、Ethereumを完全に量子耐性にします。コンセンサス署名、口座認証、その他の暗号システムには、それぞれ独自の移行戦略が必要です。
暗号化の3つの分野に注意が必要
Ethereumの暗号アーキテクチャには、異なるセキュリティ仮定を備えた複数のコンポーネントが含まれています：
コンセンサス署名：Ethereumのバリデーターは、コンセンサスへの参加と確認の集約にBLS署名を使用します。BLSは楕円曲線ペアリング暗号に依存しているため、研究者たちは、より強力な量子耐性セキュリティ特性を提供できる代替署名システムを模索しています。
アカウント署名：標準的な外部所有アカウントはECDSA署名を使用します。十分な性能を持つ量子コンピュータは、関連する楕円曲線の前提条件下で、公開鍵から秘密鍵情報をショアのアルゴリズムを用いて導出することが理論的に可能です。アカウント抽象化および代替署名検証メカニズムは、将来的な移行を支援するアプローチの一つです。
データ可用性のコミットメント：KZGコミットメントは、本提案によって直接対象とされるコンポーネントです。これらをハッシュベースのMerkleコミットメントとSTARK証明で置き換えることで、プロトコルの暗号的露出の特定の部分に対処できます。
これらの領域は関連していますが、単一の変動幅ではアップグレードできません。Ethereumの量子耐性への移行には、コンセンサス、実行、ネットワーキング、アプリケーションインフラストラクチャ全体での調整された作業が必要です。
STARKベースのデザインが重要な理由
STARKシステムは、楕円曲線ペアリングと従来の信頼されたセットアップに依存するのではなく、ハッシュ関数と透明な証明構成を使用します。これらの特性により、STARKは量子後時代のアプリケーションに適していますが、証明サイズ、検証パフォーマンス、実装の複雑さ、およびハッシュセキュリティパラメータの評価が必要です。
EIP-8479は、暗号学的研究とプロトコルエンジニアリングを結びつける重要性を示しています。理論的に安全な証明システムだけでは不十分であり、Ethereumのブロックタイミング、帯域幅、バリデーターリソース、クライアント互換性の制約内で動作する必要があります。この提案がEIP-8288と統合されていることは、証明検証をより広いブロックレベルで考慮する必要性を反映しています。
2026年11月2日現在、この提案は承認されたEthereumネットワークアップグレードではなく、初期段階のドラフトです。11月1日の議論およびGitHubのプルリクエストは、ロールアップ開発者、コンセンサスおよび実行クライアントチーム、ネットワーキング貢献者、暗号学研究者からのフィードバックを呼びかけています。この仕様は、複数の未解決の課題を明確に特定しており、メインネットへのデプロイが検討される前に、大幅な設計および実装作業が残されています。
優れた技術的課題
最初の課題は、LeanDAゲストプログラムの完了とその検証キーのハッシュです。これらのコンポーネントは、証明される計算と、結果のSTARK証明を検証するために検証者が使用するパラメータを定義するため重要です。
二番目の課題はクライアントの実装です。この提案では、実行層、コンセンサス層、ネットワーキングコンポーネント全体で調整された変更が必要です。開発者は、異なるクライアントがブロブコミットメント、トランザクションフィールド、およびデータ認証プロシージャを一貫して解釈することを確保しなければなりません。
三番目の問題はパフォーマンスです。証明生成、再帰的集約、Merkle認証パス、およびPeerDAS帯域幅は、異なるノード構成でベンチマークされる必要があります。制御された研究環境で機能する設計は、広範なバリデーターネットワークに対しても実用的でなければなりません。
最後に、ロールアップオペレーターは、提案されたblobサイズの分布が実際の需要と一致しているかを確認する必要があります。好ましい容量に関するフィードバックは、可変サイズのblobがプロトコルの複雑性を増す以上の意味のある利点をもたらすかどうかを決定するのに役立ちます。
開発者と投資家は次に何に注目すべきですか？
最も重要な進展は、仕様の進展、作動するプロトタイプの公開、独立した暗号学的レビュー、およびパフォーマンス結果です。ロールアップチームからのフィードバックは、提案された容量範囲が実際のデータ公開ワークロードに有用であるかどうかを確認するのに役立ちます。
関連する提案の状況も重要です。EIP-8288はLeanDAが参照する再帰的証明集約フレームワークを提供し、EIP-8141は提案されたフレームトランザクション構造を提供します。それらの実装進捗は、新しい設計の統合パスに影響を与える可能性があります。
投資家にとって、研究提案とスケジュールされたアップグレードの違いは重要です。ドラフトEIPはEthereumの長期的な開発ナラティブに影響を与える可能性がありますが、特定の機能がメインネットに到達し、ETHの需要に測定可能な変動幅をもたらすという証拠としては扱わないでください。
EIP-8479はEthereumのインフラに長期的な影響を及ぼす可能性がありますが、ETHの評価への即時の影響は、ネットワーク経済への直接的な変更よりも、市場の期待によって左右される可能性が高いです。この提案はまだ実装されておらず、メインネットでの活性化スケジュールも確定していません。したがって、現在のところ、ロールアップ手数料の低下、blob利用率の向上、またはETHトランザクション需要の増加という測定可能な証拠は提供されていません。
短期的には、トレーダーやアナリストはETHの現物取引活動、デリバティブのポジション、ETFの資金流れ、およびより広い市場状況を注視する可能性が高いです。この提案に関するニュースはEthereumの技術的ロードマップへの関心を高める可能性がありますが、草案仕様だけでは持続的な価格の Catalyst を確立するには不十分です。
長期的には、成功した実装がEthereumを安全なデータ可用性および決済レイヤーとして支える可能性があります。より柔軟なblob容量はロールアップがデータ公開を管理するのを助け、ハッシュベースのコミットメントとSTARK証明はネットワークのポスト量子移行に貢献する可能性があります。これらの改善が実用的なパフォーマンス上の利点をもたらす場合、開発者の信頼とエコシステムへの参加を強化する可能性があります。
しかし、ETHの広範な評価は、ネットワークの活動、ステーキング、供給の動向、アプリケーションの採用、および他のブロックチェーンエコシステムとの競争に引き続き依存するでしょう。したがって、EIP-8479は、独立した投資理論ではなく、Ethereumの長期的なインフラ開発の一部として捉えるべきです。
Ethereumが提案する量子耐性PeerDASおよび可変サイズのblob設計は、ネットワークのデータ可用性インフラストラクチャにおける重要な研究方向性を示している。KZGコミットメントとセル証明をKeccak-256 MerkleコミットメントとLeanDA STARK検証で置き換えることで、この提案は長期的な量子耐性セキュリティ目標により適した暗号アーキテクチャを模索している。2 KiBから512 KiBまでの可変サイズblob設計は、異なる量のトランザクションデータを公開する必要があるロールアップに更大的な柔軟性をもたらす。
ただし、この提案はまだ初期のドラフト段階にあります。証明パラメータ、クライアント統合、ネットワーク変更、およびパフォーマンス要件は、技術的レビューと実装テストを通じて依然として解決される必要があります。Ethereumにとって、この開発の意義は、暗号学的耐性とLayer 2データ効率の組み合わせにあります。最終的にロールアップの経済性が改善されるか、ETHの採用に影響を与えるかは、成功した実装と測定可能なエコシステムの利点に依存します。現在のところ、EIP-8479はEthereumのより広範なスケーリングおよびポスト量子研究アジェンダにおける前向きなインフラストラクチャ提案と理解されるべきです。
EIPとERCの違いは何ですか？
Ethereum改善提案（EIP）は、Ethereumのプロトコル、標準、または開発プロセスに提案される変更を説明します。Ethereumコメント要求（ERC）は一般的に、トークンインターフェースやスマートコントラクトの規約などのアプリケーション層の標準を規定します。EIP-8479は、基本的なデータ可用性とプロトコルの動作に関係するため、コア提案です。
PeerDASとは何を意味しますか？
PeerDASはPeer Data Availability Samplingの略です。これは、Ethereumノードが分散されたblobデータのすべてのデータ要素をダウンロードするのではなく、その一部をサンプリングできる仕組みです。このアプローチにより、個々のノードのデータ要件を削減しつつ、データの可用性を検証する手段を維持できます。
リード・ソロモン符号化とは？
リード・ソロモン符号は、データに冗長性を追加するエラー訂正符号です。これにより、十分な有効な部分が残っていれば、欠損した部分を再構成できます。これはPeerDASに関連しています。分散型データ可用性は、ネットワークがサンプリングされ分散されたコンポーネントから元のデータを復元できる能力に依存しているからです。
暗号学における信頼できるセットアップとは？
信頼できるセットアップは、特定の暗号システムが公開パラメータを生成するために使用する初期化プロセスです。その秘密情報が適切に破棄されない場合、セキュリティリスクを生む可能性があります。KZGコミットメントは信頼できるセットアップに依存していますが、提案されたSTARKベースの設計は、透明な証明構築を通じてこの要件を回避することを目的としています。
ユーザーはどのようにEthereum改善提案の進捗を追跡できますか？
ユーザーはGitHub上のEthereum EIPsリポジトリをフォローし、Ethereum Magiciansでの技術的な議論を確認し、Ethereum開発者からのアップデートを監視できます。重要なマイルストーンには、仕様の改訂、独立したレビュー、プロトタイプ実装、クライアントテスト、および今後のネットワークアップグレードへの採用に関する公式な決定が含まれます。
免責事項: このページは、お客様の便宜のためにAI技術を使用して翻訳されています。最も正確な情報については、元の英語版を参照してください。