验证者绕不开的一道难题
跑一个以太坊验证者，节点软件每一轮都要做两件事：给提议的区块签名、给看到的区块签投票。这两件事用的都是信标链的 BLS 私钥，而且不能停机：错过一个时段就少赚一个时段的奖励。问题就在这里——干活的机器必须全天候联网、跑着暴露给网络的客户端，而私钥就躺在这台机器的某个目录里。运维者的直觉很朴素：签名这个动作能不能挪到另一台根本不通外网的机器上去做？2020 年 9 月 30 日，以太坊基金会的 Herman Junge 把这件事的接口写成正式提案 EIP-3030，标题就叫 BLS Remote Signer HTTP API。它在 EIP 仓库里的状态是 Stagnant（停滞），从未被任何客户端当作必须实现的规范，但它描述的架构活了下来，今天多家签名服务和托管方案里都能认出它的形状。
三个端点的极简 API
3030 的规范部分短得罕见：整套 API 只有三个 HTTP 端点。第一个是 GET /upcheck，签名器活着就回 200 和 {"status": "OK"}，验证者客户端用它做健康检查。第二个是 GET /keys，返回这把签名器上可用的钥匙标识列表。第三个是 POST /sign/:identifier，URL 里的 identifier 是不带 0x 前缀的公钥十六进制串；请求体带四个必填字段——bls_domain（取 beacon_proposer、beacon_attester、randao 之一，对应提议、投票、随机数三种签名域）、data（要签的数据本体）、fork（含前后两个版本号的 Fork 对象）、genesis_validators_root（域分离与链版本化用的 32 字节哈希）。签名成功回 200 和十六进制编码的签名字符串；找不到那把钥匙回 404 带 Key not found；请求不合法回 400。规范特别写明：请求体里的其他字段一律被签名器忽略。
为什么签名要带这么多上下文
新手常问：签个数据不就是把哈希送过去吗，为什么要连 fork 版本和创世根一起送？这正是远程签名的安全要害。BLS 签名在信标链里必须绑定域：同一个私钥，给提议区块签和给投票签，出来的东西必须互不能冒充，这就是 bls_domain 字段的作用；而 fork 版本与 genesis_validators_root 保证主网、测试网、分叉链上的签名互不通用。一个只会对裸哈希签名的签名器是危险的——攻击者若能让它签任意哈希，等于拿到了任意签名。把语义结构留在签名器这一侧，签名器就能先检查数据合不合法、域对不对，再决定签不签。这与硬件钱包拒绝显示不明白的东西是同一个思路：掌钥匙的一方必须理解自己在签什么。
它故意没规定什么
3030 在理由一节把自己的 Unix 哲学讲得很坦白：规范刻意不含认证、密钥管理和传输加密这三块。作者的建议是用外部机制补齐——认证可以走 HTTP 请求头里的令牌，但必须和传输加密一起用才有效；也可以在验证者与签名器之间的网络上做访问控制列表，把攻击面压到必须与验证者同网段才能触达签名器；密钥存储则完全抽象掉，硬件安全模块、密管应用、云存储的私有网络策略、甚至一个目录里的裸文件都可以，增删钥匙的流程应当建在这套接口之外。换句话说，这份 API 是一根管道，安全边界靠部署者在管道外面自行砌墙。读这类接口规范时要养成这个眼光：没写的部分不是可有可无，往往正是留给工程判断的部分。
这份停滞提案的现实回声
3030 为什么停在 Stagnant？签名服务是个生态位而非协议层：验证者客户端普遍把远程签名做成可插拔特性，各家签名工具在自己的文档里约定细节，标准化反而不如快速迭代吃香，协议评审带宽也轮不到运维侧接口。但正因为它解决的是钥匙离手但不离岗这个通用问题，类似的三分法端点——健康检查、列钥匙、要签名——在多家实现里都留下了痕迹。把它当作一份架构切片来读，比当作一份将生效的规范更准确。
普通用户能学到什么
你大概不会自己跑验证者，但 3030 的思路对保管资产的人有普适价值：第一，能不干活的机器就别放钥匙，让签名集中到少数刻意保持孤立的环节；第二，签名器必须校验签名的语义上下文，只会盲签哈希的组件等于把钥匙外包给请求方；第三，接口规范承诺不了安全，认证、加密、访问控制要在部署层补齐——任何宣称上了远程签名就安全的说法，都该追问一句：认证谁做的，密钥谁管的，传输加密了吗。
风险提示：本文涉及的密钥管理仅供安全参考，不构成投资建议；请勿将真实助记词、私钥或签名密钥输入任何第三方网站或非官方软件。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。