一、这份半成品答卷是什么
比特币出块的本质，是给一个 80 字节的区块头找一个让双重 SHA-256 结果落进目标范围的随机数。听起来简单，但区块头里的前一区块哈希、默克尔根、时间戳、难度位、版本字段每一个都有共识含义，组块软件必须清楚地知道自己能动什么、不能动什么。getblocktemplate 就是节点对外递出的半张答卷：它把架链点、难度目标、合法时间窗、候选交易集合与资源上限统统填好，交给矿工或矿池代理，让后者在明确边界内自行组装区块。BIP22 为这个方法定下基础语义，Bitcoin Core 29.0 导出的 RPC 文档给出当前的字段清单。
二、一个字节都不能碰的骨架
previousblockhash 锁定这块矿架在哪个区块之上；bits 与 target 是难度目标的压缩写法与完整写法，改一个字符，整个搜索结果就全部作废；height 是待出区块的高度，而 coinbase 交易的 scriptSig 必须写入区块高度，这是 BIP34 生效以来组块的硬要求。时间维度上，mintime 给出下一个区块时间戳的下限，curtime 是节点建议使用的当前时间，29.0 版文档还特别注明这两个时间戳已按 BIP94 提案的防时间扭曲规则做了调整。版本空间由 version、vbavailable 与 vbrequired 三个字段圈定：哪些版本位区间正在被软分叉部署征用、提交时又必须置起哪几位，模板都替矿工查好了。coinbasevalue 则划出 coinbase 交易允许的收入上限——区块补贴加上本块打包手续费的总和，多要一分钱，区块就无效。
三、mutable 数组的明示授权
模板里的 mutable 数组列出了官方许可的改动维度，比特币核心常见的取值是 time、transactions 与 prevblock：时间戳可以在合法窗口内向前推以持续刷新搜索空间；交易集合可以按打包策略重排取舍；前块哈希可以在新区块到达后刷新重架。没有写进这份清单的自由，协议层面一直在收窄——历史上围绕版本位乱填来扩大搜索空间的组块优化引发过专门讨论，此后软分叉对可部署版本区间的征用，本质上就是在压缩模板之外的自留地。
四、交易清单连着家底一起端出来
transactions 数组把候选交易连同它们的上下文一起交给组块方：每笔交易的原始十六进制、手续费、签名操作数，以及一份 depends 依赖表——哪笔父交易也在这份清单里、必须排在子交易之前，写得明明白白。父交易排在子交易之后不是可选的风格问题，而是节点组装与验证时的默认排序约定。资源红线 sigoplimit、sizelimit 与 weightlimit 也一并写在模板里，组块过程中的每一次增删都应当拿这三条线做增量校验。
五、不同角色该盯哪几个字段
矿池把模板转译成 Stratum 作业下发给矿机时，通常只开放时间戳与额外随机数的滚动，组块自由度留在池端；自己跑节点独立挖矿的人则要亲手处理 prevblock 刷新与交易集重排，模板读得好不好直接决定无效块率。即便完全不挖矿，getblocktemplate 也是个顺手的体检工具：它能告诉你这台节点此刻认定的合法时间窗、资源上限与正在激活的软分叉部署状态，排障时比翻日志直观得多。
本文只做节点接口与出块机制的科普，不构成任何投资建议；自建挖矿涉及电力、设备与噪声等现实成本，请自行评估。
六、把模板落进排查清单
理解这份答卷之后，一份矿工视角的自检表就能列出来。先问版本：模板里有没有把某个版本位区间标成正在部署的软分叉，自己有没有把这几位按 vbrequired 的要求填进去，填错等于把整段搜索结果作废。再问时间：mintime 与 curtime 是不是都读到了，本机时钟如果漂移太多，组出的块会被判时间无效，这是掉线半天后再开工最常见的翻车点。然后问家底：coinbasevalue 与自己的输出地址、BIP34 要求的高度编码是否一致，多出一分或少写一字节，验证节点都会把成果当废纸。最后问资源：weightlimit 与 sigoplimit 的余量有没有在增删交易时同步维护，只看字节数不看权重的组块软件早就跟不上现代区块的账本单位了。这份清单的价值不在于逐条打勾，而在于让每一次无效块都能被归因到某个字段上。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。