验证者存款一共写入三样东西：一热一冷两把密钥，再加 32 字节的提款凭据（withdrawal credentials）。前两样决定谁在签名，第三样决定钱最终能到谁的口袋——它在存款时写定，此后想改，规矩比想象中复杂。不少早期存款到今天仍未把凭据从 0x00 前缀迁移走，这部分质押余额的收益提取路径和 0x01 前缀完全不同，值得逐层拆开讲清楚。
32 字节字段里的两种前缀
按 phase0 规范的定义，提款凭据的第一个字节是前缀，决定后面 31 字节的语义。前缀 0x00 走 BLS 路线：后 31 字节等于提款公钥经 sha256 后去掉首字节，对应的提款密钥由存款助记词按固定派生路径生成，这把密钥平时根本不参与验证，可以离线封存。前缀 0x01 则直接内嵌一个执行层地址，规范注明该地址既可以是外部账户也可以是合约账户，所有提款统一打到这个地址。需要强调的边界是：凭据在存款时设定后本身不可更改——所谓升级，其实是通过一条特殊消息把 BLS 语义换成地址语义的一次性迁移，而不是随手改字段。
Capella 时代的一次性地址变更
信标链升级 Capella 时引入 BLS to Execution Change 消息，专门处理 0x00 凭据的迁移。规范里的处理函数写得很直白：校验目标验证者当前凭据前缀必须等于 BLS 前缀，然后把凭据重写为 0x01 前缀、十一字节的零、再加 20 字节执行层地址。消息需要用提款私钥签名——也就是那把来自主助记词派生的冷密钥，热密钥和节点上的任何进程都替代不了它。这条消息每个验证者只能被成功处理一次：0x01 凭据上再提交会被前缀断言拒绝。操作流程上通常经由staking CLI 在离线环境签名、再经信标节点广播，签名环境的安全假设与生成存款时一致。
执行层也能触发退出之后
EIP-7002 状态为 Final，它把触发退出的能力从共识层扩展到执行层：满足条件的验证者可以在执行层排队发起退出与提款请求，规范描述这些消息被追加进执行层区块、再由共识层处理。它设立了一个硬门槛——只有携带 0x01 前缀凭据的验证者才能走这条通道，因为执行层必须能证明请求出自提款私钥的持有者。换句话说，还停在 0x00 的存款享受不到这类便利：既不能用执行层消息触发退出，自动提款也要等凭据迁移完成后才顺畅。规范同时定义了退出后余额转为可提取状态需要等待至少 256 个纪元（约 27 小时量级）的最短延迟，具体到账时间还取决于提款队列的拥塞程度。
给质押者的核对清单
第一步是看清现状：任意信标链查询面板都能按验证者索引读到 withdrawal_credentials 字段，开头两位十六进制决定你属于哪一类。第二件事是提前备好冷环境：迁移需要提款私钥签名，等于把助记词暴露给一台干净设备，操作时序应与当年生成存款密钥同等谨慎。第三，动手前先确认目标地址控制无误——迁移消息一次成功、永久生效，地址写错没有回滚按钮。若验证者委托给了质押池或服务商，凭据由协议方管理，个人要核对的是服务条款而非自己签名。还有一条容易踩的时间坑：地址变更消息本身也要排队进块，在网络拥堵期可能迟迟不被打包，签名提交后应在查询面板确认凭据字段真的翻成了 0x01，而不是以为签了字就万事大吉；期间该验证者的自动提款照旧不会发生。最后留意 Electra 规范里还有 0x02 前缀的复合提款凭据（compounding withdrawal credential），语义与前两类不同，涉及升级路径时先查当期规范再动手。质押本金会波动，机制细节以当期官方规范为准；本文不构成投资建议，也不承诺任何提款时效。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。