协议演进 / BIP/比特币改进提案 / BIP-23

BIP-23 getblocktemplate——矿池挖矿

BIP-22 的矿池扩展篇,全是可选增补:让矿工能先把组装好的区块提议给矿池校验、能在清单许可内改动模板、能缩略提交份额,还能把一组服务器当成一个逻辑服务来用。本 BIP 目前处于已部署状态。

一、档案卡

档案卡
编号BIP-23
标题getblocktemplate - Pooled Mining
作者Luke Dashjr <[email protected]>
指定日期2012-02-28
层级API/RPC(接口)
类型Specification(规范类)
状态Deployed(已部署)
阅读版https://bips.dev/23
官方原文https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki

二、放在哪一族

挖矿接口族的扩展篇,是 BIP-22 的下篇:

它给矿池场景补了五组东西:基础矿池字段、区块提议(先验货再开工)、可变项清单(矿工到底能改模板的哪些地方)、提交缩略(少传字节的份额提交方式)、逻辑服务(把多台服务器当成一个服务来调度)。此外还划了支持等级:Level 1 要求实现 BIP-22 非可选部分与长轮询、本页基础扩展、以及 “coinbase/append”、“submit/coinbase”、“time/increment”(仅服务器)等条目;Level 2 再加 “transactions/add” 与区块提议。读实现声称的“支持 BIP-23”时,先对到这两档。

三、它要解决什么

动机直指矿池的权力结构:原文说,当时对挖矿过度集中于矿池、以及矿池握有的控制权,存在合理担忧。

老式的集中取活方式下,矿工拿到的只是待哈希的材料,区块里到底装了什么、coinbase 把钱付给谁,矿工无从过目。getblocktemplate 已经把整个区块结构暴露给矿工(见 BIP-22);本页进一步要让矿工能在开哈希之前审查区块、并有可能动手修改它——审查与修改的权利,就是从矿池手里分回给矿工个体的部分。

同时,为鼓励普及,本页以“做既有集中式 getwork 协议的完整超集”为设计目标:矿池不必大动干戈就能采纳,矿工审计能力是增量加上去的,而不是另起炉灶逼全行业换接口。

四、规则本身

4.1 基础矿池扩展

请求可带 target(期望的目标值,服务器可忽略);模板新增 expires(本工作自服务器发响应起最多有效的秒数)与 target(有效结果必须小于的数,大端十六进制)。目标值不可省略的原因写在 Rationale 里:有些矿池用更低的目标运转,不应浪费带宽去收注定不合格的份额;高算力下矿工也需要向矿池要更低目标来管理自己的带宽。

4.2 区块提议(Block Proposal)

服务器在模板的 capabilities 中带上 “proposal” 即表示支持。矿工可在工作过期前的任意时点,把自己组装的区块提议给服务器做一般校验:以 mode: "proposal" 调用 getblocktemplate,附十六进制区块数据 data,有 workid 时一并带上。

服务器须按平常的接受规则(除工作量证明那项检查外)验这块数据,结果三选一:合规则返回 null(并保持同一 workid,且不应因此使旧模板失效);不合规则返回拒收理由字符串(词表见 BIP-22 附录);或返回一个“增量模板”,指出要改什么——缺失的键按提议区块、再按原模板的取值理解,增量模板还可带 reject-reason。只为登记备案的服务器,原文推荐简单返回 {"workid":"new workid"} 这样的对象。客户端可假设:提议过的区块只要改动限于自己提供的那段 coinbase scriptSig 与时间头,就仍然有效,服务器无正当理由不应推翻这一假设。

4.3 可变项(Mutations)

模板中若有 mutable 数组,就逐项列明服务器允许矿工改动的地方,主要有:

模板还可带 noncerange(矿工可扫的 nonce 范围,两个大端十六进制的 32 位整数)与请求侧的 nonces(矿工需要的 nonce 范围大小,未给时服务器应按 2^32 假设)。服务器可以收紧 coinbase 与 nonce 范围,Rationale 的解释是:这是做 getwork 完整超集的必要代价,矿池才能在不显著增加份额校验复杂度与挖矿策略的前提下开放审计。

4.4 提交缩略(Submission Abbreviation)

若模板的 mutable 含缩略项,提交时可少传数据(模板另有 fulltarget,区分“完整区块”与“份额”的门槛):

share/merkle 的数据格式被精确规定:80 字节区块头 + 以比特币变长整数编码的交易总数 + coinbase 交易 + 把 coinbase 连到默克尔根的那条链上各环节的小端 SHA256 哈希。

4.5 逻辑服务(Logical Services)

客户端在 capabilities 中带 “serverlist” 时,服务器可在模板中给出 serverlist:一组可视为同一个逻辑服务的主机。每台主机对象含 uri、avoid(避用秒数)、priority(整数优先级,默认 0)、sticky(黏性秒数)、update(可否更新服务器列表,默认 true)、weight(同优先级内的相对权重,默认 1)。

选择规则:必须按 priority 从小到大依次尝试;同优先级内按 weight 加权随机。提议与提交必须发回发活的那台服务器,只有原服务器联系不上时才可改投别家;想跨服务器交份额,应改用 DNS 的等效机制。服务器列表只能由原服务器、或 update 缺失或为 true 的服务器更新;至少一台有 update 权限的服务器每天至少要尝试访问一次。永久换址与临时 5 分钟的委派,都可用 serverlist 参数表达。

五、谁必须动

矿池(服务器端):决定开放哪些扩展:在 capabilities 与 mutable 里逐项声明允许的提议、改动与缩略方式,按规则回提议的校验结果;给出 expires、target、fulltarget、serverlist 等字段时须保证其语义与本规范一致。

独立矿工(客户端):在服务器许可的清单内审查与修改区块——能改什么以 mutable 为准,不能自行假定;提议与提交必须回到发活的服务器;按 priority/weight 规则选服务器,不得无视 avoid 与 sticky。

普通持币人:无直接关系。这是矿池与矿工之间的接口约定。

共识层:不受影响。提议校验明确“按服务器平常接受规则验、只豁免工作量证明一项”,缩略的只是传输形式;上链的仍是普通完整区块。

六、现在算不算数,以及一个常见误读

状态为 Deployed(已部署)。它与 BIP-22 合起来是矿池挖矿接口的通行规范,原文列出的参考实现有 libblkmaker、Eloipool 与 bitcoind。

但“已部署”要按它的结构来读:整篇都是可选扩展,实现之间支持程度可以差很远,所以原文才划了 Level 1 / Level 2 两档支持等级。判断某个矿池或挖矿软件“支持 BIP-23 到什么程度”,正确问法是它实现了哪一档、开放了哪些 mutable 与缩略项,而不是有没有一个笼统的是/否。

常见误读:

“用了 getblocktemplate,矿工就能随意改区块里的交易和 coinbase。”

不对。矿工能动的地方以服务器在 mutable 中逐项授予的为准:追加 coinbase、增删交易、改时间头、换父区块,每一项都是单独授权;服务器完全可以只给最窄的权限。本页的设计恰恰是把“矿工的审查与修改权”做成一份可谈判、可审计的清单,而不是无限制放行——这与其缓解矿池权力集中的动机是同一件事的两面。

七、延伸

本页内容整理自 bitcoin/bips 仓库与 bips.dev,事实已与仓库核对;解读仅供学习参考。