比特币契约（一）：探索比特币网络上复杂支出条件的新可能性

编译：陶朱，金色财经；作者：Kyrian Alex，CoinTelegraph

最近，随着比特币开发和协议讨论的复兴，所谓的“契约”（covenants）概念再次受到关注。契约可以实现并促进一系列应用，包括新型的无需信任且可扩展的二层网络、具有更复杂支出逻辑的完全非托管金库，以及更高效的支付通道。然而，实现此功能的大多数途径都需要对比特币的共识规则进行软分叉，而这一过程很可能在社区内引发争论。

随着共识客户端近期分化为Core节点和Knots节点，就此类变更达成一致的可能性变得更小。尽管Knots节点近期推动了他们自己的软分叉（即BIP-110），但他们倾向于协议僵化，并且似乎不太支持在底层实现扩展解决方案。比特币核心（Bitcoin Core）近期引发的争议，无论是在技术层面还是治理层面，都降低了比特币近期实现契约的可能性。

迈克尔·塞勒等知名人士也曾公开倡导协议僵化，将那些热情高涨、资金雄厚的开发者视为协议的最大威胁。尽管如此，一些最低限度的契约实施或许是实现信任最小化的二层网络最保守的途径，这能让下十亿用户享有数据自保的权利。如果未来主网费用再次飙升，并且垃圾邮件问题得到解决，那么围绕这些提案的讨论很可能会再次升温。本文将为读者理解契约奠定基础。后续文章将深入探讨各个提案。

要理解契约提案，首先需要掌握比特币交易的基本验证流程。比特币的锁定条件是用一种基于栈的非图灵完备语言——比特币脚本（Bitcoin Script）来表达的。比特币交易的发送者通过创建所谓的锁定脚本（也称为 scriptPubKey）来指定支出条件。当资金接收者之后想要花费这些比特币时，他们必须提供满足这些条件的相应解锁脚本（也称为 scriptSig）。比特币的脚本语言可以表达各种验证条件，例如验证公钥签名、强制执行时间锁、验证哈希原像，以及将支出条件与命题逻辑结合起来。拥有正确解锁脚本的实体可以将比特币转移到任意位置，即用任意 scriptPubKey 来绑定比特币。但是，在提供正确的 scriptSig 之后，它无法限制资金的去向。

契约旨在实现的正是这一功能。契约允许用户对未来如何使用比特币施加限制。该概念最早由 Gregory Maxwell 于 2013 年提出，旨在提升比特币的可扩展性和灵活性。随后，Möser、Eyal 和 Sirer 在 2016 年对其进行了推广。Maxwell 最初提议使用 zk-SNARKs 来限制支出。此后，相关讨论涌现出大量不同的提案，其中一些提案甚至可能绕过软分叉的必要性。

基本契约（或预计算契约）与一般契约（或递归契约）

契约提案的关键区别在于基本契约（或预计算契约）和通用契约（或递归契约）。原则上，基本契约仅对后续交易施加限制。然而，通过将受限地址链接起来，基本契约也可用于预先定义有限的交易序列。虽然此允许的交易序列可以任意长或复杂，但必须事先指定。

通用契约可以直接在比特币脚本中表达递归支出规则。这使得支出条件可以无限期地重复应用。例如，如果 Alice 向 Bob 发送 1 个比特币，基本契约可以确保 Bob 只能将资金发送到特定地址，或者将其受限一定次数。然而，在通用契约下，价值 1 个比特币的 UTXO 在 Bob 将其发送给 Steve 时，以及 Steve 将其进一步转账时，都将保持相同的支出限制，而无需任何预定义的终点。虽然通用契约能提供更大的灵活性，但它们面临着巨大的技术难题，并受到社区的批评。它们的实施还需要对协议进行重大更新。

拟议的公约实施方案及其应用

各种实施方案和讨论塑造了我们对契约如何增强比特币功能的理解。为了清晰地探讨这一主题，有必要将拟议的变更分为四类：

• 完全实现契约功能的操作码。它们直接对比特币交易施加支出限制。这包括 OP_CHECKTEMPLATEVERIFY 和 SIGHASH_ANYPREVOUT。

• 作为辅助工具的操作码。这些操作码扩展了比特币脚本或数据处理的表达能力，但除非与其他操作码结合使用，否则它们本身并不实现契约功能。我们将讨论 OP_CHECKSIGFROMSTACK 和 OP_CAT。

• 用于特定应用的操作码。我们将考虑 OP_VAULT、OP_UNVAULT 和 OP_EVICT。

• 无需软分叉即可近似实现契约行为的提案。这些提案依赖于现有共识规则或信任最小化基础设施中的密码学构造，而不是新的操作码。我们将讨论 ColliderScript、Bitcoin PIPE 和基于前端的契约。

在下一篇文章中，我们将开始讨论第一类契约提案，首先介绍 OP_CHECKTEMPLATEVERIFY——迄今为止最受欢迎的提案之一。