翻开任何一笔近期比特币区块的 coinbase 交易，几乎总能在它的输出里看到一段奇怪的字节：以 6a 24 aa 21 a9 ed 开头，后面跟三十二个看似随机的字节。很多区块浏览器把它标成“OP_RETURN 数据”就带过了。实际上它是隔离见证的一条共识规则——见证承诺，作用是让区块结构对见证数据也负责。这一篇把它逐字节拆开。
先把问题摆清楚
隔离见证把签名等见证数据从交易的主哈希计算中挪了出去，于是同一笔交易有了两个编号：不含见证的 txid 和含见证的 wtxid。区块头里原有的默克尔根只覆盖 txid，等于对见证内容完全无感。问题来了：如果区块不承诺见证数据，旧节点看到的区块和新节点看到的区块就不是同一份数据，恶意中继可以在传输途中偷换见证而不被区块结构察觉。共识需要一个办法，把“这个区块的见证内容长这样”钉死在区块自身里。
BIP 141 选的办法简单粗暴：矿工的 coinbase 交易里必须记录一条承诺，其哈希输入是全区块交易的 wtxid 构建出的默克尔树根。注意 coinbase 自身的 wtxid 被规定视为全零，避免自己承诺自己的循环。
逐字节读这条承诺
规范要求承诺写进 coinbase 的某个输出，至少三十八字节：一字节 OP_RETURN（0x6a），一字节 0x24 表示后面推三十四至三十八字节里的三十六字节数据段，紧接着四字节固定前缀 aa21a9ed，之后是三十二字节的承诺哈希，其算法是双重 SHA256，输入为见证默克尔根拼接一个三十二字节的保留值。第三十九字节起还允许附带可选数据，没有任何共识含义。如果区块里有多个输出匹配这个模式，取输出编号最大的那条。一个干净规则：全区块都不含见证数据时，承诺可以不写。
coinbase 还有一条配套要求：其输入的见证字段必须恰好是一个三十二字节数组，填的就是那个保留值。当前它被约定为一个随机数，没有共识含义，但它在承诺哈希里的位置是为未来预留的插槽。
那个保留值到底是干什么的
规范明确禁止合并挖矿之类的非共识用途占用这个保留值。它的存在是为了未来软分叉：假如哪天需要承诺一个新东西，比如手续费总和，新规则会把“新承诺|旧保留值”做哈希放进 coinbase 见证，旧节点看到的仍然只是一串无意义字节，兼容照常。承诺后面的可选数据空间同理，只能用于未来软分叉的元数据。换句话说，这条 38 字节的记录同时是账本校验项和协议升级的挂钩。
从运维视角看这串字节
矿工软件自动维护承诺，普通节点在校验区块时重算默克尔根并比对。它进入日常视野的另一种方式是钱包隐私：coinbase由矿池生成，承诺里的随机保留值让同一矿池的相邻区块承诺互不相同，观察者无法从承诺串直接归并“这是同一台机器连开的十个块”这类指纹。链上分析的矿工识别转而依赖其他特征，这条设计不在共识清单里，却确实是随机数当前承担的实际副产品。
快速问答
问：不写见证承诺的区块会怎样？
答：只要区块里有任何一笔带见证的交易，缺承诺就是无效区块，所有升级后的节点都会拒绝它。
问：普通用户需要关心这串字节吗？
答：验证资金安全不需要，它由全节点自动校验。它进入大众视野通常是某笔交易的 OP_RETURN 被判为“烧币”或“铭文”时——承诺输出长得像，但两者毫无关系，认前缀 aa21a9ed 就不会误判。
常见误区
一是把这串字节当烧币输出或数据刻写，它由节点自动生成，不承载用户数据。二是以为承诺保护的是签名安全，它保护的是区块数据完整性，防止中间人篡改见证。三是把 witness reserved value 当_nonce_或随机数功能理解，当前它确实填随机数，但规范里它唯一的身份是升级插槽。
风险提示：本文为协议机制科普，不构成任何投资建议；链上数据判读请结合多个区块浏览器与官方规范交叉验证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。