Bitcoin covenants 再受关注：或推动Layer 2与非托管金库，但软分叉与客户端分歧增大阻力

近期，随着Bitcoin开发与协议讨论复兴，“covenants（契约）”概念再度受到关注，可用于支持无需信任且可扩展的Layer 2、更复杂支出逻辑的全非托管金库，以及更高效的支付通道。据 Cointelegraph 报道，多数实现路径需要对Bitcoin共识规则进行软分叉，可能引发社区争论。

在共识客户端近期分化为Bitcoin Core与Knots节点后，就此类变更达成一致更不可能。尽管Knots阵营近期推动其软分叉提案BIP-110，但其更主张协议“固化”，对在基础层促进扩容方案的支持度较低；同时，Bitcoin Core近期在技术与治理层面的争议，也降低了短期内引入契约的可能性。

迈克尔·塞勒（Michael Saylor）等人也公开支持协议固化，并将激进且资金充足的开发者视为对协议的最大威胁。不过，文章认为，最小化的契约实现或是通往“最保守”的低信任Layer-2路径，有望将自托管优势带给下一批十亿用户；若未来主网费用再次飙升且垃圾交易之争得到解决，相关讨论可能重获动能。

文章解释，Bitcoin交易验证依赖非图灵完备的Bitcoin Script：发送方用锁定脚本scriptPubKey设定支出条件，接收方花费时提供解锁脚本scriptSig满足条件。现有机制下，满足scriptSig后资金可被转至任意scriptPubKey，但无法限制其后续转出目的地；契约旨在让用户对未来如何花费硬币施加限制。

该概念由格雷戈里·麦克斯韦（Gregory Maxwell）在2013年提出，后由莫泽（Möser）、埃亚尔（Eyal）与西勒（Sirer）在2016年推广。此后出现大量方案，部分尝试在不软分叉的前提下近似实现。

文章区分“基础/预计算契约”与“通用/递归契约”：前者主要限制下一笔交易，但可通过链式地址预先定义有限交易序列；后者可在脚本中表达递归规则，使限制可被无限次沿用，但技术门槛更高、社区更审慎，且需要重大协议更新。

文中将拟议改动分为四类：直接实现契约功能的操作码（如OP_CHECKTEMPLATEVERIFY、SIGHASH_ANYPREVOUT）；作为辅助工具的操作码（如OP_CHECKSIGFROMSTACK、OP_CAT）；面向特定应用的操作码（OP_VAULT、OP_UNVAULT、OP_EVICT）；以及无需软分叉、依赖现有共识规则或低信任基础设施的近似方案（ColliderScript、Bitcoin PIPE、FE-based covenants）。后续文章将从OP_CHECKTEMPLATEVERIFY展开讨论。