最近，随着比特币开发和协议讨论的复兴，所谓契约的概念再次受到关注。契约可以实现广泛的应用，包括新的无需信任且可扩展的第 2 层解决方案、具有先进支出逻辑的完全非托管金库以及更高效的支付渠道。
然而，实现此功能的大多数途径都需要对比特币共识规则进行软分叉，这一过程可能会引发激烈的社区辩论。随着最近共识客户端多样化为 Core 和 Knots 节点，就这种变化达成一致的可能性变得越来越小。尽管 Knots 方面最近提倡自己的软分叉（BIP-110），但它倾向于支持协议僵化，并且似乎不太支持基础层扩展解决方案。
此外，最近围绕比特币核心的争议，无论是技术上的还是治理上的，都削弱了契约实施的近期前景。像 Michael Saylor 这样的知名人士公开主张协议僵化，将资金雄厚的开发者描绘成对网络稳定性的潜在威胁。
尽管如此，最低限度的契约实施可以提供一条通往信任最小化第 2 层的保守路径，有可能将自我托管特权扩展到数十亿用户。如果主网费用再次飙升并且交易垃圾邮件纠纷的解决方案出现，围绕这些提案的讨论可能会重新获得动力。
要理解契约，必须首先掌握比特币的基本交易验证流程。比特币锁定条件用比特币脚本表示——一种基于堆栈的非图灵完备语言。发送者通过锁定脚本（scriptPubKey）指定支出条件。当接收者稍后花费输出时，他们必须提供满足这些条件的解锁脚本（scriptSig）。
比特币脚本可以验证公钥签名、强制执行时间锁、验证哈希原像以及使用命题逻辑组合条件。然而，一旦提供了有效的解锁脚本，资金就可以发送到任何地方，而不会限制后续交易。契约旨在通过允许用户施加未来支出限制来改变这种情况。
该概念由 Gregory Maxwell 于 2013 年提出，旨在提高比特币的可扩展性和灵活性，后来由 Möser、Eyal 和 Sirer 在 2016 年推广。Maxwell 最初提出使用 zk-SNARK 来实施支出限制。从那时起，出现了许多提案，其中一些提案可能绕过了软分叉的需要。
基本契约与一般契约
一个关键的区别在于基本（预先计算）和一般（递归）契约之间。基本契约仅限制下一个交易，但可以链接起来定义有限的、预先指定的交易序列。然而，一般契约允许比特币脚本中的递归支出规则，从而使限制能够在没有预定义端点的交易中无限期地持续。
虽然一般契约提供了更大的多功能性，但它们面临着重大的技术障碍和社区怀疑，需要重大协议更新。
建议的实现和应用
契约提案可以分为四组：
- 实现完整契约功能的操作码：直接施加支出限制（例如 OP_CHECKTEMPLATEVERIFY、SIGHASH_ANYPREVOUT）。
- 支持操作码：扩展脚本表达能力或数据处理，但需要与其他操作码组合以实现约定功能（例如 OP_CHECKSIGFROMSTACK、OP_CAT）。
- 专用应用程序操作码：专为特定用例而设计（例如 OP_VAULT、OP_UNVAULT、OP_EVICT）。
- 避免软分叉的提案：使用现有共识规则或信任最小化基础设施（例如 ColliderScript、比特币 PIPE、基于 FE 的契约）来近似契约行为。
在接下来的文章中，我们将详细探讨这些类别，从 OP_CHECKTEMPLATEVERIFY 开始——迄今为止最受欢迎的契约提案之一。