EIP-8310 详解：面向状态型密钥的后量子 Keystore 格式（Post-Quantum Keystore for Stateful Keys）-北京尧图网络

EIP-8310 详解面向状态型密钥的后量子 Keystore 格式Post-Quantum Keystore for Stateful Keys【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本指南围绕 EIP-8310DraftStandards Track / Interface2026-06-19 创建展开讲解以太坊 Lean 共识层Lean Ethereum为 XMSS 等可消耗签名密钥consumable keys设计的 keystore 格式。你将掌握 v5 keystore 的完整 JSON 结构scheme参数块、非权威state快照、权威签名状态的归属规则、commit-before-sign 持久化顺序、保留叶子区间机制以及安全导入/导出/恢复的规范语义理解为什么叶子索引不可重用会彻底改变密钥存储的管理模型。一、背景从 BLS 到 XMSS问题不在加密而在状态ERC-2335 定义了以太坊验证者 BLS 密钥的 keystore 格式一个加密信封内含 32 字节的 BLS 标量。Lean Ethereum 计划用后量子安全的 XMSSeXtended Merkle Signature Scheme替换 BLS 验证者密钥。由于 XMSS 的私钥同样可以约简为一个小种子keystore 这个容器本身只需适度修改即可承载它——真正的危险在别处。仓库中与之配套的 EIP 可以佐证这一迁移背景EIP-8292 说明 PQ 共识签名方案是 XMSS 的状态型变体签名体积远大于 BLS当前 leanVM 聚合引擎所用实例约 1.17 KiB且无法像 BLS 那样廉价聚合EIP-8321 指出共识层规划的哈希签名方案通用化 XMSS即 leanSig因包含 salt 分量而可被 grindRANDAO 需要独立的哈希链方案来规避——这进一步说明 XMSS 相关设施正在被系统性引入共识层。XMSS 的安全性核心在于每次签名会消耗一个一次性的 WOTS 叶子leaf该叶子由索引标识且该索引绝不能重复使用。跨两条不同消息重用同一个叶子会直接导致伪造从而摧毁整个密钥。这一特性恰恰击穿了现有 keystore 模型的三条隐含假设假设BLSv4 keystore下成立XMSSv5 keystore下不可变性Immutabilitykeystore 创建后永不改变每次签名都会推进密钥状态自由复制Free copying同一 keystore 可在两台机器上并行运行两份独立签名的副本必然重用叶子恢复安全Restore-safety从任意备份恢复都安全恢复陈旧的 XMSS 状态会回滚高水位high-water mark诱发重用验证者生态其实已经为 BLS 解决过同构问题EIP-3076 的 slashing protection 强制同一个 slot 绝不签两条不同消息。对于同步型 XMSS 变体一个叶子绑定一个 epoch/slot绝不重用叶子与绝不对同一 slot 双重签名是同一个不变量。EIP-8310 的使命就是把这种耦合从巧合升级为规范并覆盖 slashing-protection 数据库之外的剩余场景如 builder-bid 这类协议外签名。二、核心术语可消耗密钥的语言EIP-8310 首先建立一套术语后续所有规范都建立在这些概念之上Consumable key可消耗密钥安全性依赖于索引绝不重用的签名密钥如 XMSS、LMS。与reusable密钥ECDSA、BLS相对。Leaf index叶子索引一次签名所消耗的一次性密钥在 Merkle 树中的位置。High-water mark高水位已被消耗或已保留为消耗的最高叶子索引。签名只允许严格高于它进行。Authoritative state权威状态签名者查询并推进的高水位唯一事实来源。它不是 keystore 文件本身。Synchronized mode同步模式叶子索引是共识位置的确定性函数leaf f(epoch)或f(slot)状态权威是 slashing-protection 数据库。Counter mode计数器模式叶子索引是与共识位置无关的自由计数器如协议外签名状态权威是专用的原子更新存储。三、v5 文件格式规范EIP-8310 定义 keystoreversion5。v5 keystore 是在 v4 keystore 基础上叠加下述变更而成规范关键词按 RFC 2119 / RFC 8174 解释MUST / MUST NOT / REQUIRED / SHOULD / SHOULD NOT / MAY。3.1 加密算法与 KDF 升级crypto.cipher.function必须是 AEAD 或 256 位构造。推荐aes-256-gcmv5 中禁止使用aes-128-ctr。crypto.kdf.function在 v4 的scrypt、pbkdf2之外可以MAY使用argon2id。参数必须符合当前内存困难性memory-hardness指引。需要强调这些是防御 Grover 加速口令搜索的预防性升级不影响下文的可消耗密钥语义。3.2 加密内容种子而非私钥crypto.cipher.message加密的是 XMSS种子seed而非展开后的私钥。种子长度由 scheme 参数决定。keystore 只存储恢复密钥所需的材料见 §6不存储实时签名状态。3.3 新增scheme对象显式的方案参数块这是 v5 的核心新增字段完整示例scheme: { name: leanxmss, params: { hash: hash identifier, tree_height: 32, hypertree_layers: 1, encoding: target_sum, winternitz_w: 8, dimension: 46, target_sum: 200, index_mode: synchronized, activation_epoch: 0, lifetime_leaves: 4294967296 } }参数语义逐项说明scheme.name必须标识签名方案。读取方若不识别scheme.name必须拒绝使用该 keystore。scheme.params必须包含确定性重建公钥、验证签名所需的全部参数。这些字段不可变——创建后写入方不得修改。hash标识可调整哈希函数tweakable hash及其底层域。本规范是**哈希无关hash-agnostic**的任何满足签名方案安全要求的哈希都可用hash字段记录具体选择以便验证者复现。Poseidon1例如基于 KoalaBear 域仍在评估中尚未定为推荐实例。tree_height单个 Merkle 树的高度与hypertree_layers共同决定lifetime_leaves 2^(tree_height × hypertree_layers)。hypertree_layers堆叠 Merkle 树的数量。leanxmss是单树通用化 XMSS因此必须为1。encoding标识不可比编码incomparable encoding。leanxmss使用target_sum。winternitz_w每条哈希链的基数leanSig 中的BASE。dimension哈希链数量超立方体维度。与winternitz_w、target_sum共同完整定义 target-sum 编码是重建公钥与验证签名所必需。target_sumtarget-sum 编码的目标和。index_mode按 §1 定义必须为synchronized或counter。上述非哈希值即推荐的 2^32 密钥生命周期生产参数集对应 leanSig 的SIGAbortingTargetSumLifetime32Dim46Base8实例LOG_LIFETIME 32、DIMENSION 46、BASE 8、TARGET_SUM 200。3.4 新增state快照对象非权威的容量视图state: { authoritative: false, authority: slashing-protection, reference: opaque locator, optional, capacity: { total: 4294967296, consumed: 12345, remaining: 4294954951 }, high_water: 12345, reserved_ranges: [] }关键规则state.authoritative在任何 keystore 文件中必须为false。文件只是面向运营者可见性的快照签名时绝不能把它当作高水位来查询。state.authority必须是slashing-protection、external、embedded三者之一且必须与scheme.params.index_mode一致synchronized⇒slashing-protectioncounter⇒external专用的状态存储embedded为保留值不建议用于生产验证者密钥仅供自包含的单签名者工具使用且一旦使用文件将失去不可变性。capacity与high_water仅作信息参考。消费者必须以权威存储而非这些字段为准。四、状态权威签名者向谁查询高水位一个签名者在产生签名时必须查询并推进唯一的权威状态同步模式下权威状态是 EIP-3076 的 slashing-protection 数据库。签名消耗的叶子是f(epoch)或f(slot)拒绝双重签名某个 slot 与拒绝重用叶子是同一件事。实现必须将 XMSS 密钥与其 slashing-protection 历史绑定为不可分割的整体任何移动、导入、导出密钥的操作都必须原子地一并移动、导入、导出对应历史。计数器模式下权威状态是以 keystoreuuid为键的专用存储保存当前计数器。它必须提供与 §5 相同的持久性与原子性保证。设计理由Rationale值得注意为什么耦合 3076 而不是自造状态机制——同步模式下 slashing-protection 不变量与叶子唯一性不变量是同一的另行定义平行状态机制会产生两个可能相互冲突的事实来源这对可消耗密钥是最坏结果。让 slashing 数据库成为权威等于给密钥装上一个久经考验的护栏。五、Commit-before-sign 顺序防止崩溃诱发重用对于每一次签名实现必须按顺序执行确定候选叶子索引验证该索引严格大于权威高水位同步模式下验证该 slot/epoch 尚未被签名持久化推进高水位——写入、刷新fsync或平台等价物、并通过原子重命名或等价原子事务提交且必须在步骤 5之前完成计算签名将签名释放给调用方。在状态推进持久化之前释放签名即违规崩溃发生在释放与持久化之间时重启后会导致索引重用。步骤 3 必须在步骤 5 之前完成步骤 3 与步骤 4 可相对重排但两者都不得先于步骤 2。EIP-8310 明确将此规则定为规范性normative而非建议性advisory它是防止崩溃诱发重用的唯一排序规则规范中其他一切细节都是围绕它的簿记。六、保留叶子区间并发签名者的分区机制为了支持并发或高吞吐签名者如 builder-bid 签名而不必在单个锁上串行化每次签名keystore 可以MAY将叶子空间划分为互不相交的保留区间reserved rangesreserved_ranges: [ { id: signer-a, start: 0, end: 524287, high_water: 410022 }, { id: signer-b, start: 524288, end: 1048575, high_water: 524288 } ]约束区间必须互不相交。被分配区间的签名者只能消耗[start, end]内的索引且必须按 §5 的顺序维护该区间自己的权威高水位。同一区间不得同时分配给多个签名者实例。区间耗尽时签名者必须拒绝签名而非回绕wrap或借用其他区间的索引。这是针对 builder-bid 耗尽场景推荐机制单一全局计数器在该场景下争用过于激烈。七、导入、导出、恢复、续签两个被传统工具混为一谈的操作EIP-8310 将传统工具混淆的两个操作明确区分Recover恢复从加密种子重建密钥重建 hypertree、派生公钥。这始终安全且只需 keystore 文件。Resume signing续签开始产生签名。这需要最新的权威状态仅凭 keystore 文件是不安全的。由此导出硬性规则实现不得从缺少权威状态的 keystore 开始签名。以空/全新状态导入对可消耗密钥必须是硬错误而非警告。导出可消耗密钥必须附带或引用其权威状态。裸 keystore 文件可以MAY仅用于恢复与验证而导出若如此必须标记为任何消费者不得据此签名。用陈旧状态快照恢复 keystore 是灾难性情形。实现必须检测高水位回退regression并在与最新权威状态对账之前拒绝签名。八、向后兼容性v5 与 v4 消费者不向后兼容——v4 消费者假定可重用的 32 字节密钥且没有状态权威的概念。v4 与 v5 keystore 通过version字段及是否存在scheme对象区分。v5 感知的客户端必须拒绝把可消耗密钥当作 v4 可重用密钥操作。v4 BLS keystore 在其自身标准下依然有效不在本 EIP 范围内。九、安全考虑重用是灾难性的且是静默的叶子重用灾难性且静默与 slashing 事件不同重用可能不产生即时的链上惩罚却会完全攻破密钥。§5 的顺序与 §7 的导入规则是主要防线不得为性能而放松。陈旧恢复是首要运营风险备份保护的是种子而非状态。运营者应被引导至先恢复、再对账绝不恢复即签名。高水位回退检测§7是必需的。跨主机克隆在无不相交保留区间的情况下于两台主机运行同一密钥必然导致重用。区间分配§6必须互斥。状态存储完整性能回滚权威状态的攻击者可诱发重用。状态存储应具备与 keystore 本身相称的完整性保护。加密强度AES-256 与内存困难 KDF 用于缓解 Grover 加速的口令搜索它们无需也不会保护签名方案本身——签名方案按构造即为后量子安全的。容量耗尽即可用性风险叶子耗尽的密钥将无法再签名。容量监控§2.4 的capacity与保守的lifetime_leaves选择是运营要求而非可选优化。十、状态与测试现状截至本仓库快照EIP-8310 处于Draft状态其 Test Cases 与 Reference Implementation 均标注 To be added 。计划中的最小测试集包括leanxmss种子的加密/解密往返高水位回退时拒绝签名在签名计算与状态持久化之间注入崩溃验证重启后无重用保留区间的互不相交性与独占分配检查。延伸阅读仓库内佐证EIP-3076slashing protection 互换格式——v5 同步模式下的权威状态载体本文档规定密钥与其历史必须原子捆绑。EIP-8292PQ 认证聚合器——交代 leanxmss 签名约 1.17 KiB在 PQ 共识中的使用背景以及 leanSig/leanVM 基准套件。EIP-8321哈希链 RANDAO——说明 leanSig/XMSS 因 salt 分量可被 grind从另一角度佐证可消耗密钥管理的必要性。EIP-8288Lean Ethereum 工具链在后量子签名聚合中的复用情况。版权本文内容对应 EIP-8310 原文版权与相关权利依据 CC0 放弃。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

EIP-8310 详解：面向状态型密钥的后量子 Keystore 格式（Post-Quantum Keystore for Stateful Keys）

相关推荐

基于51单片机的环境监测系统设计与Proteus仿真调试

Mac Mouse Fix 鼠标手势指南：免费三步给普通鼠标装上平滑滚动

Nextcloud AIO 部署实战：一条命令搭好私有云

更多资讯

Audacity 免费开源多轨音频编辑器：录音、剪辑与效果处理完整指南

COMSOL 6.1激光超声Lamb波仿真技术详解

深入解析 go-openapi/jsonreference：BuildKit 内 JSON Reference 的 Go 实现与解析原理

InvenTree 附件机制详解：Attachment 数据模型、自动缩略图生成与重命名实现

OpenProject 4.1.2 版本发布说明：核心与插件关键缺陷修复详解

电力负荷时空预测实战：从GEFCom与UCI数据集到LightGBM/LSTM模型

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？