区块链/等级 IV · 深入协议/4.2 升级/课程 6
密码学前沿:见证加密与 PIPEs
当操作码迟迟不来,把密钥锁进证明之中
材料BIP-119和BIP-347的副本可访问具备脚本调试功能的区块浏览器用于跟踪提案状态的笔记本IACR ePrint 2026/186 的副本
好奇
- 为什么比特币能验证签名,却无法限制由此产生的币接下来流向何处?
- 在不泄露秘密本身的情况下,要证明自己知晓某个秘密需要付出什么代价?
- 当底层规则保持静态且不可更改时,协议是如何保障安全的?
探索
- 比特币脚本被刻意设计得很有限。它能够验证签名是否与公钥匹配,却无法检查币被花费后的去向。这种限制让脚本保持简单、可预测。然而,它也阻碍了某些花费条件取决于未来交易结构的设计。
- Jeremy Rubin 提出的 OP_CHECKTEMPLATEVERIFY(BIP-119)旨在填补这一空白。该操作码将允许脚本要求花费交易与一个预先承诺的模板相匹配,从而固定其输出和某些其他字段。这使得非递归契约成为可能:即规定币接下来可以流向何处的规则,例如将资金锁入保险库(vault)或限制赎回路径。该提案至今尚未激活,比特币社区仍在持续讨论。
- 另一项提案 OP_CAT(BIP-347)侧重于拼接栈上的数据,而不是直接施加去向限制,不过与 Schnorr 签名结合后,它同样可以实现契约。这一简单操作能够支撑复杂的密码学构造,包括能以紧凑方式表达超大规模多签策略的树签名。由于允许在脚本引擎内直接操作哈希值和数据,它还有助于实现抗量子的 Lamport 签名。
- 除了新的操作码,研究人员还在探索将见证加密作为实现可编程性的另一条路径。见证加密允许发送方锁定数据,只有能够证明自己掌握某个特定秘密(即“见证”)的人才能解锁。理论上,这可以让比特币密钥只在某个陈述被证明之后才被揭示,而无需网络直接验证该计算。
- 学术文献中已有一些早期的见证加密构造,但它们在比特币上部署仍不现实。针对一般陈述的实用构造尚不存在:已知方案规模极其庞大,且依赖于尚未被广泛信任的密码学假设。尽管理论基础是可靠的,但从概念验证到可投入生产的协议之间仍存在巨大的工程差距。
- 权衡很清楚:契约增强了表达能力,但会引入需要仔细审查的新共识规则;见证加密带来了隐私和灵活性,却会产生沉重的存储和计算成本。两种路径都试图在不放弃比特币核心安全模型——固定、可预测的发行和有限的脚本能力——的前提下,扩展比特币的能力。
- 上一课详细介绍的屏蔽比特币,在其自身的票据系统内处理私密转账。它将锚入和锚出排除在范围之外,即如何把价值从普通、透明的比特币转入屏蔽层,以及如何再转回来。这些桥接的设计方案依赖于一种名为见证加密的机制,具体来说是 Bitcoin PIPEs v2(IACR ePrint 2026/186,2026年2月)。
- 见证加密将数据锁定在一个数学陈述之后。在这里,比特币私钥被加密,只有当有人出示有效的见证(即证明该陈述成立的证据)时才能解密。密文在链下发布,任何无法提供相应见证的人都无法获取其中的密钥。
- 该机制将可编程性从共识层转移到密码学。无需新的操作码或软分叉来执行复杂的花费条件,相关逻辑完全存在于加密方案之中。任何出示有效见证(例如 SNARK 证明)的人都能恢复私钥,并使用普通的 Schnorr 签名花费这些币。在比特币的共识规则看来,这只是一笔标准交易;其复杂性是不可见的。
- 该方法无需修改协议即可模拟类似契约式的限制机制,例如 CheckTemplateVerify 或保险库机制。这些限制通过“除非见证信息满足特定条件否则无法解密密钥”的方式来实施。只要底层加密技术依然有效,它就能实现与比特币现有验证规则相兼容的更复杂的支出条件。
- 主要障碍在于规模。2026年2月的论文估计每份密文约为338太字节;作者后来的研究称约为10太字节,但依然难以存储和分发。目前尚无任何实现,因此这些都只是估算值,PIPEs 究竟能否部署仍是一个悬而未决的研究问题。
- 这仍处于研究阶段,而非已实现的功能。目前没有部署时间表,相互矛盾的规模数据也凸显了该领域的不确定性。在密文缩小到足够程度之前,见证加密只是比特币透明账本与复杂密码学承诺之间的一座理论桥梁,而不是供用户使用的实用工具。
部分 I密码学前沿:契约(Covenants)与见证加密
部分 II比特币的转入与转出:PIPEs 与见证加密
关键事实
- OP_CHECKTEMPLATEVERIFY(BIP-119)提出了一种契约机制,用于限制币未来的去向。
- OP_CAT(BIP-347)支持栈上数据拼接,可用于树签名和基于哈希的(Lamport)签名。
- 见证加密通过秘密见证的证明来锁定数据,同时不会泄露该秘密。
- 目前尚不存在针对一般陈述的实际可用的见证加密构造方法。
- 契约仍是需经共识讨论的未生效提案。
- 比特币脚本的固有限制从设计上就阻止了许多攻击方式的实现。
- Bitcoin PIPEs v2 使用见证加密,将私钥锁定在数学陈述之后。
- 恢复密钥需要出示有效的见证,例如 SNARK 证明。
- 恢复密钥后,即可通过普通的 Schnorr 签名进行花费。
- 该机制无需新的操作码或软分叉即可模拟契约功能。
- 估算的密文大小从约338 TB(论文)降至约10 TB(后续声称),仍不具备实用性。
- 屏蔽比特币的锚入和锚出方案依赖于这一见证加密基础设施。
练习 九、六、三、一
9收集列出比特币脚本的9项技术限制或特性,这些因素决定了它目前的功能与局限。
6归类按各自能实现或阻止什么,将这9项分为6组。
3提炼将这6组归纳为3个核心原因,说明尽管理论上的好处显而易见,扩展比特币脚本为何仍然困难。
1凝结用1句话写出:在去中心化系统中,增加可编程性与保持共识稳定性之间的根本张力。
事实核查
日期、数字及数据均依据下方列出的已发表资料进行核实。
- J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
- E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
- S. Garg, C. Gentry, A. Sahai & B. Waters, 'Witness Encryption and its Applications' (STOC 2013)
- bitcoin-dev mailing list archives
- Abdalla, Carmer, El Gebali, Kilinc Alper, Komarov et al., 'Bitcoin PIPEs v2' (IACR ePrint 2026/186, February 2026)
- Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 2026)
- S. Garg et al., 'Witness Encryption and its Applications' (2013)