BLS 验证者的钥匙从哪来：ERC-2334 的四层派生路径

普通钱包地址背后是 secp256k1 密钥；而以太坊信标链的验证者签名用的是另一套适合聚合的 BLS 方案，跑在 BLS12-381 曲线上。验证者密钥从哪生成、备份了怎么恢复、多家托管会不会各推各的钥匙？ERC-2334 负责回答这些钥匙该长在哪棵树的哪根枝上。标准创建于 2019 年 9 月 30 日，仓库记录状态为 Review，作者是 Ethereum Foundation 的 Carl Beekhuizen，配套的派生算法在同族标准 ERC-2333 里。

路径的读法

路径形如 m / purpose / coin_type / account / use，主节点之外四层，层与层之间是父子序号，不支持 BIP32 式的硬化标记——派生用的密钥函数是 ERC-2333，和 secp256k1 那套完全不兼容，这也是必须另立路径的原因。purpose 固定为 12381，取自曲线名 BLS12-381，规范强调只有实现了 ERC-2333 才许用这个 purpose。account 层让同一用户把不同用途的密钥集分开；use 层在账户之下再分相关密钥，多数场景留零。信标链另有专属参数：它的 coin_type 是 3600，规范解释这个数特意取以太坊 secp256k1 币种编号 60 的平方，为的是把 BLS 密钥与账户密钥干净隔开。

提取密钥与签名密钥的父子关系

每个验证者有两把钥匙。提取与转账用的提取密钥路径是 m/12381/3600/i/0，i 表示第几组验证者密钥；日常履职的签名密钥路径是 m/12381/3600/i/0/0——换个说法，签名密钥就是该验证者提取密钥的第 0 个子密钥。分工源自安全等级的不同：签名密钥是发给验证者客户端的热密钥，最坏情况是被诱导签出可罚没消息、导致质押被强制退出；提取密钥不接触执行环境，却掌握该验证者的全部质押资金，应按冷密钥对待。让热钥匙做冷钥匙的子代，意味着妥当地保管提取密钥本身就足以重建签名密钥。规范的备注还承认托管质押等场景可以放宽：存款人按标准生成提取密钥即可，服务商怎么生成签名密钥不受本标准要求。

与普通读者的交集

把这份标准与日常钱包的路径对照一遍，差异立刻可见。BIP44 路径里撇号代表硬化派生，而这份路径明文不支持硬化，写了撇号就是非法；它的密钥函数不是 BIP32 而是 ERC-2333，从根上换掉了推导数学；purpose 用 12381 而不是任何数字，也是为了把这套树和 secp256k1 的树隔成两个宇宙，即便同一句助记词，两边各自推导、互不泄漏。对普通用户还有一层常被误读的点：验证者路径管的是信标链侧的 BLS 钥匙，和你钱包里那个 0x 地址的密钥不是同一把——导入验证者 keystore 时看到的路径以 12381/3600 开头，说明工具在按这份标准生成验证者身份；看到别的路径，要么工具自有约定，要么就该追问依据。把路径的层与数背下来没有意义，会问出上述这一句质疑就够了。

最后留一个防混淆的清单：信标链语境里同时存在三套钥匙体系——账户地址背后的 secp256k1 密钥、验证者的 BLS 提取密钥与签名密钥、以及提款凭证那一层，路径开头分别是各自体系的名字。工具让你导入或生成任何一把时，先确认它属于哪套体系再谈其他，一份 12381/3600 打头的 keystore 被误当成普通钱包助记词导入的后果，与反过来把助记词填进验证者导入框同样严重。标准本身写得克制，但它划下的边界，恰好是每一次质押操作里最容易踩空的那一步。

多数人不亲自跑验证者，但两种场景会遇见这条标准：委托质押时工具要求导入验证者 keystore，或核对提取地址背后的身份体系。此时值得确认三件事：提取密钥是否按上述可验证路径生成、换服务商时能否用同一种子独立重建、以及被要求导入的是哪一层密钥——热钥匙的可读导出与冷钥匙的保管要求不该混为一谈。钥匙的规则看似枯燥，但它决定了你的质押身份在多大程度上属于你自己。本文为机制说明，不构成任何投资建议。