比特币脚本天生擅长锁定“一样”东西：一个哈希前像、一把钥匙、一个时间。可现实合约常常要绑定“一组”条件：这笔支付同时取决于金额、对象、时间窗和一个状态号，任何一项单独泄露都不致命，拼起来才构成完整的开锁条件。BIP-442 给脚本补一块专门做这件事的积木 OP_PAIRCOMMIT，一次哈希、恰好两个元素。起草人是 moonsettler 与 Brandon Black，2024 年 12 月 9 日立项，Draft，落点在 tapscript 叶子版本 0xc0 语境下的 OP_SUCCESS205（0xcd）成功位。
规则短得像一句口诀。栈顶两个元素，弹出，按“紧凑尺寸前缀加数据”的顺序拼进一个带标签的哈希——标签是 PairCommit，沿用 BIP-340 的 tagged hash 定义，也就是先把标签哈希两遍垫在底层。结果 32 字节推回栈。少于两个元素就失败。尺寸前缀不是礼节性设计：它保证元素长度本身被固定住，没有“同一段字节切成不同长度”的碰撞花招可做。两个元素还能再折进更大的结构：对三个元素 a、b、c 的承诺就是 PC(a, PC(b, c))，先折右边再折左边，几个原语叠出一棵二叉承诺树。
为什么要为“两个元素”专门加一条操作码？效率是首要答案。SHA-256 以 64 字节为一轮，两个各三十二字节的元素加上尺寸前缀恰好一轮收完，标签的中态还能预先算好——典型场景一个操作码只花两轮压缩。若改用通用拼接方案，就得让脚本自己处理字节堆叠、长度注入和防碰撞检查，字节数与验证成本双双上去。BIP-442 的立场是：向量化承诺不必是一整套大机制，一块小原语加上栈操作就够了。
动机章节给了两类用例。一类是哈希锁合约的升级：把许多候选前像组织成承诺树藏进锁里，开锁时只需揭示其中一条路径，其余保持沉默，等于把“一把钥匙开一把锁”扩成“N 选一把而不露其余”。另一类更有分量：闪电对称合约。这类通道协议要在链上争议关闭时证明“对方手里那个状态确实存在”，做法是把每个状态的结算交易承诺进后续状态；如果只靠 CTV 哈希整笔结算交易，见证里就得塞下完整交易，通道状态历史越长负担越重。有了配对承诺，双方对“结算哈希”与“状态编号”做一个轻量组合承诺，恢复数据能瘦成必要的一小截。过去用纯现成脚本干同样的事要靠键梯——让一串公钥依次对各元素签名来钉住数据，字节数与签名操作数双双失控，这正是配对承诺想替掉的旧路。
它不做什么同样清楚：不引入新哈希函数、不自动构树、不带证明路径的验证逻辑（那些交给通用操作码），也不改签名语义。它就是一块负责“绑两个”的砖。
常见误区。一，以为它是 OP_SHA256 的复用场景：直接双元素拼接会引入可延展碰撞（长度歧义是哈希拼接的经典坑），标签加尺寸前缀正是为了堵这个坑。二，把它与 CTV 定位重叠：CTV 固定整笔交易模板，PAIRCOMMIT 固定任二元组，一个管形状一个管内容。三，以为闪电对称合约已经部署：该场景是提案引用的动机案例，实现进度另论。
快速问答。问：为什么恰好两个元素？答：两个是能把哈希塞进单轮又保留组合完备性的最小数字；三个以上交给嵌套。问：栈上不满足两个元素怎么办？答：脚本失败，没有静默跳过。问：对普通用户有感知吗？答：暂时没有，它尚未进入任何钱包或节点的激活计划。
最后给一个尺子：两笔 32 字节数据用朴素 SHA256 加拼接大约要处理一两个额外块并自担防碰撞责任，而 OP_PAIRCOMMIT 用单个操作码把长度、域分离、承诺三件事一次做完——省下的不仅是字节，是审读脚本时的心智负担。
风险提示：本文讨论未激活脚本提案，不构成投资建议或任何协议采用建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。