Block Template 是一组用于组装区块的数据,矿工随后针对其区块头寻找 proof of work。它关联前一区块、交易、coinbase 和挖矿限制,本身不能证明区块已经找到或被接受。
previousblockhash 和 height 字段确定候选区块在链上的位置,另有 version、bits 和时间信息。模板是组装区块的依据,不只是一个供人盲目重复相同计算的现成区块头。 [BIP 22 — Block template structure]
在 BIP 22 中,depends 使用从一开始的索引引用 transactions 列表中更早的交易;该列表不含 coinbase。如果子交易花费同一区块内父交易的输出,父交易必须排在前面。缺少 depends 表示依赖关系未知,并不表示没有依赖。 [BIP 22 — Block template structure]
Bitcoin Core v29.0 用该高度的区块补贴与所选交易的实际手续费构造 coinbase。删除交易后,不能自动把旧 coinbasevalue 保留为应得奖励。更改交易选择需要重新计算可用手续费。 [Bitcoin Core v29.0 — Block assembler]
根据 BIP 141,witness commitment 通过 wtxid 绑定 witness 数据。Bitcoin Core 29 提供适用于未修改模板的 default_witness_commitment。修改相关交易或顺序后,必须检查或重算承诺,并将最终 TXID 反映到区块头的 Merkle root 中。 [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]
Bitcoin Core v29.0 选择包含依赖关系的交易包,并遵守权重及 sigops 限制。blockmaxweight 和 blockmintxfee 设置影响组装。仅因该策略遗漏一笔交易,不能证明它违反共识;矿工配置也不能提高网络限制。 [Bitcoin Core v29.0 — Block assembler]
BIP 23 用 mutable 描述允许的修改,例如时间或交易。服务器许可不会取消共识要求:前一区块、时间、难度及交易仍须正确。能够获得模板,也不保证终端设备可以无限制地选择内容。 [BIP 23 — Mutations and proposals]
BIP 23 可通过 expires 限制工作期限,并指定修改 prevblock 的权限。链尖变化后,仅替换前一区块哈希并不能保证其余数据依然有效。高度、交易、奖励及其他上下文条件都需要重新评估。 [BIP 23 — Mutations and proposals]
BIP 23 的 proposal 模式检查候选区块时不要求有效的 proof of work。因此,肯定结果不表示区块已找到、已发布或已永久进入链中。完成的区块在提交时仍须经过相应验证。 [BIP 23 — Mutations and proposals]
要获得更完整的理解,请将本词条与以下词条结合阅读: Mining Pool, 区块头, Extranonce, Merkle树. 反向关联还来自: Coinbase交易, Stratum V1, Stratum V2, Extranonce.