比特币,btc" data-link="btc" data-logo="//img.jbzj.com/coins/images/logo/bitcoin.png" data-name="bitcoin" data-style="0">
《比特币契约》第一部分主要讨论的是：比特币网络能否在支付条件设计上变得更灵活。和传统较为单一的转账方式相比，契约更关注“这笔钱在什么条件下才能被花出去”。例如，支付是否要等到某个时间点、是否要满足某个事件，或者是否要同时满足多项条件。对于刚接触这一概念的读者来说，理解“比特币契约是什么”以及“比特币脚本如何限制资金流向”，就是进入这个话题最重要的起点。这类机制也让比特币在链上支付、金融基础设施以及更广义的智能合约场景中，拥有更多可探索的空间。
近段时间，随着比特币开发和协议层讨论再次升温，“契约”又重新成为行业内的热门话题。它之所以受到关注，是因为它可能服务于多个方向，比如更可扩展、无需依赖信任的第二层网络，更复杂支出规则下的完全非托管保险库，以及效率更高的支付通道机制。不过，从现有技术路径来看，多数契约方案仍需要通过比特币共识规则的软分叉升级来实现。而软分叉本身往往需要较高的社区协调成本，因此相关讨论通常不容易快速形成统一意见。
与此同时，随着共识客户端进一步分化为 Core 节点和 Knots 节点，围绕协议变更达成共识的难度也在增加。虽然 Knots 方面近期推动了一项名为 BIP-110 的软分叉提案，但其整体立场更偏向协议固化，看起来也并不积极支持在基础层推进扩容。无论是技术路线上的差异，还是治理判断上的分歧，近期比特币核心生态中的这些争议，都在一定程度上降低了契约机制在短期内落地的可能性。
此外，包括迈克尔·塞勒在内的一些知名人士，也曾公开支持协议固化，并将那些资源充足、推动意愿较强的开发者视为可能影响协议稳定性的风险因素。即便如此，某种最低限度的契约实现，仍可能成为推动信任最小化第二层方案的相对稳妥路径之一，同时也有机会提升自我托管工具在更大用户群体中的可用性。如果未来主网手续费再次上升，且围绕垃圾交易的争论逐步缓和，那么相关提案的讨论热度仍有可能回升。本文的重点，是先帮助读者搭建一套理解比特币契约的基础框架，后续再逐步拆解不同提案的具体差异。
比特币契约是什么：先看懂比特币脚本如何验证交易
想理解比特币契约，首先要知道比特币交易是怎么被验证的。比特币用一套基于栈、且非图灵完备的语言来写“资金锁定规则”，这套语言就是比特币脚本。简单理解，发送方在创建交易时，会通过锁定脚本（scriptPubKey）写明这笔资金未来要满足什么条件才能被花费；而接收方在之后想使用这笔资金时，就需要提供对应的解锁脚本（scriptSig）来证明自己满足条件。
从功能上看，比特币脚本并不只是做签名验证，它还可以表达多种支付规则，例如公钥签名校验、时间锁、哈希原像验证，以及多个条件组合后的支付逻辑。也就是说，只要解锁脚本是正确的，资金就可以被转移到任意新的地址，也就是附加任意新的 scriptPubKey。问题在于，一旦签名已经通过验证，现有机制通常很难继续规定这笔钱下一步必须流向哪里。
而契约机制的作用，正是补上这一层能力。它试图让用户不仅能控制“谁能花这笔钱”，还可以进一步限制“这笔钱之后怎么花”。这一概念最早可以追溯到 2013 年，由格雷戈里·麦克斯韦提出，目标是提升比特币的灵活性与可扩展性；到了 2016 年，莫泽尔、埃亚尔和西雷尔又进一步推广了这一方向。麦克斯韦最早提出的思路，是利用 zk-SNARKs 来实现支出限制。此后，围绕契约出现了许多不同设计，其中也有一些方案尝试在不依赖软分叉的情况下实现类似效果。
基本契约和通用契约有什么区别：它们如何限制后续支出
在比特币契约的讨论中，一个很重要的分类是：基本型（或预计算型）契约，以及通用型（或递归型）契约。对新手来说，可以先把它理解成“限制一笔”与“持续限制多笔”的区别。
基本型契约通常只会对下一笔尚未发生的交易设置限制。不过，如果把多个受限地址或多条受限支出路径提前串联起来，基本型契约也可以预先定义出一段有限的交易流程。这个流程可以很长，也可以设计得比较复杂，但前提是：所有可能允许的支出路径，都需要事先明确写出来。
通用契约则更进一步。它可以在比特币脚本中表达递归式规则，也就是某一项限制可以被持续继承和重复应用。比如，Alice 向 Bob 转出 1 个 BTC。若使用基础契约，这笔钱也许只能被转往某个指定地址，或者必须按既定步骤完成支出。而在通用契约模型下，当 Bob 再把这个价值 1 个比特币的 UTXO 转给 Steve 时，这个 UTXO 仍然会带着原来的限制；之后 Steve 再继续转出，这个限制依旧生效，而且不需要事先设定最终终点。
也正因为如此，通用契约在灵活性上更强，但技术门槛也更高，社区审视会更严格。通常这类方案还需要更大范围的协议升级，因此始终是比特币开发讨论中的敏感议题之一。对于想了解“比特币契约安全吗”或“比特币协议升级难不难”的读者来说，这正是争议的核心来源之一。需要说明的是，相关机制目前仍处于持续讨论阶段，技术上的可行性并不等于最终一定落地，任何协议升级都存在不确定性和实施风险。
比特币契约提案有哪些：当前常见的实现方向
随着不同方案不断被讨论，市场也在逐步形成对“比特币契约如何增强协议能力”的整体认知。为了便于理解，目前可以大致把相关提案分成以下四类：
- 可直接实现契约功能的指令：这类方案可以直接对比特币交易增加支出限制。代表性提案包括 OP_CHECKTEMPLATEVERIFY 和 SIGHASH_ANYPREVOUT。
- 作为辅助工具的操作码：这类操作码主要用于增强比特币脚本的表达能力或数据处理能力，本身通常不足以单独完成契约，但可以和其他操作码配合使用。常见代表包括 OP_CHECKSIGFROMSTACK 和 OP_CAT。
- 面向专用场景的指令码：这类方案更偏向某些特定用途，比如资金安全管理或资产控制。常见方向包括 OP_VAULT、OP_UNVAULT 和 OP_EVICT。
- 无需软分叉也能实现类似契约行为的提案：这类方案不依赖新增操作码，而是利用现有共识规则下的密码学结构或信任最小化基础设施来实现类似效果。相关方向包括 ColliderScript、Bitcoin PIPE 以及基于 FE 的契约。
后续讨论通常会从 OP_CHECKTEMPLATEVERIFY 展开，因为它是目前热度较高、关注度也相对集中的方案之一。不过需要提醒的是，这些提案依然处在评估和讨论过程中，未来能否推进、推进到什么程度，仍取决于社区共识、技术可行性以及协议升级环境等多方面因素。对于普通读者而言，先理解这些方案解决的到底是什么问题，比急于判断结果更重要。
