提到 keystore，多数人想到的是以太坊网页钱包导出的一串加密 JSON。在验证者密钥的世界里，同一类容器还有一份专门的标准：ERC-2335（BLS12-381 Keystore），给跨链通用的 BLS 私钥定义加密文件格式。它的官方状态是 Review，2019 年 9 月 30 日提交，依赖同样已划入 ERC 系列的 ERC-2333（密钥派生）与 ERC-2334（助记词映射）。这份文件值得钱包用户读一遍，因为它把”加密文件到底防什么、靠什么防”讲得比多数产品界面清楚。
为什么要另起一个标准
规范在动机部分列了两条。其一，旧有的 Web3 Secret Storage 用 Keccak256 做校验和，而 BLS 签名、密钥派生与密钥存储被设计为对所有链中立的标准，Keccak 的中立性不够；其二，旧文件是逐步打补丁长出来的，缺乏模块抽象。于是新标准把整个容器拆成三个可替换的”模块”，每个模块固定三件套：function（用哪个密码学构造）、params（参数）、message（主输入）。哪天某个算法被攻破，换掉对应模块即可，不必推翻整个格式。
解密一条密码的三步流程
标准把”用密码打开文件”拆成三个子过程：先由密码经 KDF 派生出中间密钥（decryption key），再做密码验证，最后解密私钥。KDF 提供两个选项：pbkdf2（参数含迭代次数 c、密钥长度 dklen、盐值 salt）与 scrypt（参数含工作因子 N、并行度 p、块大小 r 等）。密码验证的算法在规范里写得很具体：取派生密钥第 16 到 32 字节，拼接密文 cipher.message，做 SHA256，与文件里 checksum.message 比对——对得上才继续解密。这就是为什么密码错了文件会立刻报错而不是解出一把废私钥：文件自带”密码对不对”的自证结构。
文件里还有什么值得看
字段层面，version 在这一版固定为 4，另有一个 description 说明密钥用途的标签；path 记录这个文件对应 ERC-2333 派生树上的哪条路径（也就是”这个文件是哪个账户的”），uuid 区分同路径下的多个文件，pubkey 存派生公钥方便导出后核对。对做冷备份的人来说，path 字段常被忽略却最实用：一抽屉 keystore 文件里，谁是谁全靠它。相关话题可以接着读keystore 文件是什么：加密私钥备份怎么看、怎么用（以太坊 keystore 的读法）与把助记词拆成几张卡片保管：SLIP-39 门限备份的规则怎么算（门限备份），三份文件构成密钥保管的三种容器形态。
拿到一个 keystore 文件的三分钟
假设你从验证者节点目录里拷回一份 keystore-*.json。第一分钟看 crypto 三个模块：kdf.function 是 scrypt 还是 pbkdf2，前者的 N 值与后者的 c 值直接决定离线爆破一次密码的硬件成本，参数低到像默认值没改过的文件，密码再多位也白搭。第二分钟看 path 与 pubkey：把公钥用配套工具重新派生一次，能对上路径上的序号，说明文件没被换过手脚。第三分钟做恢复演练：在隔离机器上完整走一遍”密码—校验—解密”，确认没有控制字符污染密码（规范专门讨论了剪贴板带入控制码的问题，并要求去掉首尾空白与不可见字符再比对）。演练通过，这份文件才算备份而不是摆设——这与助记词领域”备份必须实测”的纪律完全一致，物理介质的选择可参考助记词能用纸和钢板备份吗？物理备份、恢复演练与损坏补救。
和助记词、私钥的边界再核对一次
ERC-2335 装的是”一句话能读出来的一棵密钥树上的一片叶子”，密码只是这把锁的锁芯，密钥本身来自派生路径。所以导入一台新机器需要三样齐：助记词、口令（如启用了 2334 的 passphrase）、路径——少任何一样，导出的都是另一个地址。这个”同根不同枝”的道理在钱包侧的常见事故形态，见助记词和私钥不是一回事：一个是根，一个是枝，泄露的代价完全不同。
现状与使用建议
ERC-2335 停在 Review，没有升级为 Final，但它已是各验证者客户端事实上的交换格式；读第三方文档时以文件字段为准而不是产品截图为准。对个人，三条纪律直接可用：keystore 的密码强度决定文件寿命（离线不等于安全，文件可以被拖走慢慢爆破）；KDF 参数（scrypt 的 N 值）偏低的老文件迁移时应重新加密；path 与 uuid 抄进备份清单，恢复时少踩十个坑。本文为工具科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。