原文
EIP-8310: Post-Quantum Keystore for Stateful Keys — ch4r10t33r (2026-06-23)
このスレッドは、EIP（Ethereum 改善提案）-8310: ステートフルなハッシュベース署名鍵（Lean Ethereum コンセンサス層で使われるXMSS、leanxmssと呼ばれる）のためのキーストアフォーマットを定義する、標準トラック（コア）提案に関する議論のためのものです。
これはERC（Ethereum Request for Comments）-2335を拡張し、暗号化されたシークレットがXMSSシードになることを可能にし、消費可能な鍵が必要とするメカニズムを追加します。
動機
ERC（Ethereum Request for Comments）-2335は再利用可能な32バイトのBLSスカラーを保存します。Lean Ethereumは、ポスト量子 (PQ)セキュリティのためにBLS鍵をXMSSに置き換えます。XMSSシークレットは小さなシードに還元されるため、コンテナはわずかな変更で済みますが、セキュリティモデルはそうではありません。
各XMSS署名は、インデックスが決して再利用されてはならないワンタイムのウィンターニッツ・ワンタイム署名 (WOTS+)リーフを消費します。2つの異なるメッセージ間で再利用すると偽造が可能になり、鍵が破壊されます。この単一の特性が、今日のツールが当然と考える3つのことを壊します。
- 不変性: 2335キーストアは決して変更されません。XMSS鍵は署名ごとに状態を進めます。
- 自由なコピー: BLS鍵の2つのコピーは無害です。XMSS鍵の2つのコピーが独立して署名すると、リーフが再利用されます。
- 復元安全性: 古いXMSS状態を復元すると、ハイウォーターマークがロールバックされ、再利用を招きます。
同期されたバリアントの場合、「リーフを再利用しない」という原則とEIP（Ethereum 改善提案）-3076の「スロットを二重署名しない」という不変条件は同一であるため、このEIP（Ethereum 改善提案）はその結合を規範とし、スラッシング保護の対象外となるプロトコル外のケース（例: ビルダー入札署名）を特定します。
EIPが追加するもの
- 明示的で不変な
schemeパラメータブロック（公開鍵を再生成し、署名を検証するために必要なすべて）。 - オペレーターの可視性のための非権威的な容量スナップショット。
- 権威ある署名状態が存在する場所に関する規範的なルール（同期モードではスラッシング保護DB、カウンターモードでは専用ストア）。
- コミット・ビフォア・サインの耐久性順序付け（署名をリリースする前に、進んだハイウォーターマークを永続化する）。
- 並行/高スループットの署名者のための予約済みリーフ範囲。
- 鍵の署名位置を黙ってリセットすることを禁止するインポート/エクスポートのセマンティクス。回復と署名再開を明確に区別します。
- マイナーな暗号化アップグレード: AES-256 / AEAD暗号とオプションの
argon2idKDF。
議論のための未解決の質問
- ハッシュ関数。 フォーマットは意図的にハッシュ非依存であり、
scheme.params.hashが具体的な選択を記録します。Poseidon1（例: KoalaBear素体上）は現在、推奨されるインスタンス化として検討されています。ハッシュの選択、およびEIP（Ethereum 改善提案）が何を推奨すべきか、あるいはオープンにしておくべきかについてのフィードバックを歓迎します。 - スキームパラメータ。 例では、2^32の鍵寿命（
dimension = 46、winternitz_w/base= 8、target_sum = 200、ターゲットサムエンコーディング）に対するleanSigの推奨プロダクションセットを使用しています。これらは仕様に記載するのに適切なデフォルトでしょうか？ - パラメータ命名。
winternitz_wはチェーンごとのベースに使用されていますが、ハイパーキューブ/ターゲットサムの定式化に合わせてbaseと命名すべきでしょうか？ - カウンターモード状態ストア。 専用のカウンターモードストアに指定された耐久性/アトミック性の基準は、クライアント全体で十分であり、実装可能でしょうか？
- 予約済み範囲。 範囲ベースのパーティショニングは、ビルダー入札枯渇ケースに適したメカニズムでしょうか、それとも異なる並行性モデルが好ましいでしょうか？
ドラフトPRに関するフィードバック、異議、レビューはすべて歓迎します。
1投稿 - 1参加者