以太坊验证者页面中的提款凭证以 0x00、0x01 或 0x02 开头。它不是普通钱包地址，也不是验证者每天签名用的密钥。对 Pectra 后的验证者来说，最常见选择是 0x01 与 0x02：0x01 会把超过 32 ETH 的余额自动划转到执行层地址；0x02 允许余额在验证者中复利，最高有效余额可到 2048 ETH，并支持主动部分提款。
三类凭证先放在一张图里
0x00 是早期 BLS 提款凭证，没有登记执行层提款地址，不能直接接收提款。0x01 指向执行层地址，是 Shapella 后的传统提款方式。0x02 是 Pectra 引入的复利型凭证。
| 项目 | 0x01 传统凭证 | 0x02 复利凭证 |
|---|---|---|
| 有效余额上限 | 通常 32 ETH | 最高 2048 ETH |
| 超额奖励 | 扫描时自动划转 | 在上限内继续复利 |
| 部分提款 | 自动余额划转 | 主动发起请求 |
| 验证者合并 | 不支持 MaxEB 合并目标 | 支持相关合并流程 |
自动划转不等于退出
0x01 验证者余额超过 32 ETH 时，符合条件的部分会在共识层扫描中推送到提款地址。验证者仍保持活跃，不需要重新激活。完整退出则要先离开验证者集合，并经过退出、可提款和扫描等阶段。
验证者在队列期间仍要保持在线并履行职责。离线与罚没的差别可阅读 验证者离线和Slashing有何区别。
0x02 为什么叫复利验证者
EIP-7251 提高最大有效余额，使一个验证者可以承载高于 32 ETH 的有效质押。0x02 凭证把奖励留在验证者内，按 1 ETH 增量增加有效余额，直到协议上限。自动扫描只处理超过更高上限的余额；低于上限的部分提款需要从执行层主动请求。
这提高了管理效率，但不是收益承诺。奖励仍取决于网络职责、在线率、总质押量和协议规则，集中更高余额也会提高单个验证者操作失误的影响。
三种密钥不要混淆
验证者签名密钥负责提议和证明，暴露后可能导致 Slashing。提款凭证控制资金提款方向。fee recipient 接收执行层交易费，可以和提款地址相同，也可以不同。把 fee recipient 改成某地址，不会改变提款凭证；反过来也一样。
以太坊最终性与验证者职责可参考 以太坊最终性是什么，但凭证转换仍应以 Launchpad 和当前客户端文档为准。
转换前必须知道的限制
0x00 需要先登记执行层提款地址。0x01 可以转换为 0x02，但官方资料明确提示这一转换不可逆。提款地址一旦设置也不能随意更换。任何转换都应在离线、安全环境中核对 validator index、pubkey、目标地址和签名材料。
不要根据社群脚本直接输入助记词。优先使用 Ethereum Staking Launchpad 列出的官方工具，核对下载来源和版本，并在广播后用多个浏览器确认凭证前缀与目标地址。
一套可复核的操作顺序
- 用验证者索引和 pubkey 确认当前凭证类型。
- 确认提款地址由自己或既定托管流程控制。
- 判断目标是自动领取奖励、复利、合并还是部分提款。
- 阅读当前 Launchpad、EIP 和客户端版本说明。
- 离线生成必要签名，在线设备只负责广播与查询。
- 等待链上处理并复核凭证、队列和余额变化。
区块确认和钱包显示不是提款完成的唯一证据，可结合 区块确认数与到账核验 读取执行层记录，同时保留共识层验证者状态。
本文仅用于以太坊质押机制与安全教育，不构成质押、收益或投资建议。验证者可能遭遇离线惩罚、Slashing、客户端故障、密钥泄露和规则变化，可能损失本金。转换不可逆，操作前应独立核验当前官方文档。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。