比特币可编程性的新领域

作者：Anony

来源：<>

背景

在 2022 年，笔者曾撰文讨论过比特币的可编程性 1。在该文中，笔者介绍了比特币可编程性的基本模块，并以 “闪电通道” 和 “谨慎日志合约（DLC）” 为例，展示了这些基本模块可以编程出如何有用的电子合约：前者编程出了 “过期可撤销的合约（RSMC）” 和 “惩罚交易”，实现了双方可以几乎无限次相互支付的账户；后者则使用 “适配器签名” 实现了依赖于断言机（oracles）签名的隐私型条件式支付；两者都是免信任的。在文章末尾，笔者将比特币的编程总结为基于无状态（也可以理解成 “无记忆”）的比特币脚本（bitcoin script）来编程可信的承诺。

然而，该文的问题在于，它的视角过于狭窄：它几乎完全集中在基于单个比特币交易输出的脚本的编程可能性中 —— 不论是闪电通道还是谨慎日志合约，用于为双方提供可信承诺的交易都只有一个输入，要么是通道，要么是 DLC 。然而，仅凭该文对基本模块的介绍亦可知：比特币的交易可以使用多个输入和输出；难道，在这种使用多个输入的情形中，就不存在别的编程可能性吗？（事实上，在该文介绍 SIGHASH 的时候，已然暗示了这种可能性；而且可以说比特币开发者们对此也并不陌生。）

在该文出版之后，不到一年的时间里，比特币可编程性领域就出现了至少两个重大突破：“BitVM” 和 “Ark”，前者动摇了我们对比特币脚本可以编程的验证运算类型的理解，后者则基于对多输入的应用，为我们带来了一种新的 “链上-链下” 的原子化互换形式。这两种突破，使笔者在该文 “可编程性的限制” 一节中的总结成为彻底的一孔之见；如果说 BitVM 出乎所有人的意料之外，因此笔者可免于苛责，Ark 则是已被关注到的可能性上的突破，更能说明笔者的草率。

本文将介绍这两种突破以及它们的应用，还有一种受到较少关注但值得一提的方法。

比特值承诺与 BitVM：验证任意计算

BitVM 简介

BitVM 2 的核心洞见来自数字电路的基本原理：在数字电路中，我们通过连接一系列的 “逻辑门”，来实现 “计算”。这些门，会以两个比特值作为输入，输出一个比特（比特只能取值 0 或 1）。以 “与门（AND）” 为例，在面对不同比特值的输入时，它会产生这样的输出（结果）：

- 表 1. 与门（AND）的输入输出对应关系；仅在两个输入都是 1 时，才输出 1 -

恰巧，有一种门称为 “与非门（NAND）”，这种门等于是先运行 “与门”，再对结果取反（NOT）。理论上，仅仅使用这种逻辑门，通过将一个又一个的 NAND 连接起来，你就能实现任意计算。

- 表 2. 与非门（NAND）的输入输出对应关系；仅在两个输入都是 1 时，才输出 0 -

- 图 1. 转换自 BitVM 论文。圆形代表比特，方形代表 NAND 。使用 4 个比特值输入和 8 个 NAND 实现的一段计算 -

也就是说，如果在比特币的脚本中能够实现 NAND，那么比特币脚本就能够实现任意计算！那么真的能够吗？答案是可以。在比特币脚本中，我们有两个操作码 OP_BOOLAND 和 OP_NOT3，两者串联在一起恰好就能实现 NAND（没错，这两个操作码恰好分别是运行 AND 和取反）。

如果 BitVM 的发现仅限于此，那还算不上多么实用。毕竟，我们通常认为有用的计算，在转化成由 NAND 构成的电路时，体积都是非常庞大的，一方面，比特币区块不一定能容纳完整的一个电路，另一方面，交易的体积越大，交易手续费也就相应越高，从而经济性也就越差。该如何将这种 “新” 原语转化为实质可用的工具呢？

BitVM 的第二项洞见在于，可以基于上述原理，设计出一种 “挑战-应答” 游戏，从而让双方对任意计算的结果达成一致意见。这洞见听起来简单，实现起来，却用上了比特币脚本的多种特性：

1. 将双方尝试运行的计算打散成基于 NAND 的电路（就像图 1），然后将每一个 NAND 都转化为一个比特币脚本，并将这许许多多的比特币脚本作为叶子（tapleaf），放到一棵 taproot 脚本树上；也即，只需一个 P2TR 输出，就能承诺所有的 NAND；

2. 每个 NAND 由三个比特值组成：两个输入，一个输出；对于每一个比特，证明者（应答者）需要提前提供一对哈希值，分别对应该比特取值的 0 和 1（这被称为 “比特值承诺”）；当证明者要为一个比特设定一个具体的值时，就公开对应的哈希值的原像；

   • 需要注意的是，由于我们在脚本中实现了 NAND，所以，一旦为两个输入取了值，输出的值也就确定，证明者也就必须根据这个结果来公布对应的哈希值的原像；

3. 在脚本树上还有一类特殊的脚本：一旦验证者（挑战者）能为证明者的一对哈希值都提供原像，就能取走所有资金。没错，这就是一种 “惩罚分支”：一旦证明者在一个比特上前后使用了两个不同的值，那就意味着欺诈，验证者就能取走所有资金；

4. 脚本树还带有时间锁分支，如果一段时间内没有出现 挑战/应答，证明者/验证者 就能相应取走所有资金；

5. 最后，通过构造两种 taproot 脚本树（“挑战 taproot 输出” 和 “应答 taproot 输出”），验证者可以迫使证明者在一段时间内揭晓某个 NAND ；如果证明者应答成功，就回到原点（等待时间锁解锁），如果证明者作弊或不应答，则验证者取走所有资金；如下图：

-图 2. 作为 挑战-应答 游戏基础的 taproot 脚本树-

六边形表示一个脚本树叶子；“HS” 表示哈希锁，全都由验证者设定。在具体的一轮游戏中，验证者通过打开一个哈希锁，来迫使证明者揭晓某个 NAND ：比如，验证者通过揭晓 HS3 的原像来花费挑战输出，则证明者就必须用 “HS3 + NAND3” 这个脚本来花费应答输出（显然，这些哈希锁不能复用，否则会给予证明者使用已经揭晓的 NAND 来逃逸的选择，也即拖延游戏）。

至此，BitVM 的设计就完成了：一旦双方对要运行的计算达成了共识，并构造好了哈希锁和比特值承诺，资金存入了这样的合约，双方就必定能决出结果。在使用这种挑战游戏时，要么，验证者不再响应（也即认输），由对方取得资金；要么，证明者被抓住欺诈，由验证者取走所有资金。

重要的是，BitVM 论文并没忘记比特币合约式编程的精髓：这种链上的挑战游戏，只是双方博弈的基础，只要双方能对运算结果形成一致意见，他们可以不动用这种挑战游戏，使用多签名分支直接花费合约。

影响

尽管 BitVM 要求结为对手的双方在启动阶段生成和交换大量的数据资料，但由于它支持任意计算的验证，它在问世之后还是迅速引爆了开发者的想象力。许多项目都尝试用它来开发新型的侧链桥接合约：通过显式要求侧链的每一次状态转换（出块）都符合既定的规则，这种桥接合约有望提供比基于多签名联盟的侧链桥接合约更强的安全性。后来还出现了 BitVM 的一些改进或特化版本 4。

但是，对 BitVM 所带来的可能性的理解，却有不同看法。

有观点认为，BitVM 带来了 “富状态（stateful）的比特币脚本” 5。因为 BitVM 的 挑战-应答 游戏的开展过程是曝光的，而且，通过使用比特值承诺，即使作为执行基点的 UTXO 不断轮换（跨越了多笔交易），依然有一些状态（已被设定的比特的值）保持不变。笔者倒不同意这种看法，原因是：（1）在并未提出 “富状态性” 的新定义的前提下，BitVM 的特性依然与在其它密码货币语境下既有的 “富状态性” 定义有区别 6；（2）在 BitVM 中，比特值承诺可以说是专项使用的，一个比特值承诺之所以有意义，仅在于它存在于一个具体的 BitVM 实例中，这种状态即使暴露出来，对于另一个合约来说也没有复用的意义。

笔者认为，最优雅的描述来自于 Andrew Poelstra 的《从 Lamport 签名中获得脚本状态》一文 7，因此直接引用：

那么，有了抗模棱两可构造的 Lamport 签名，就有了将公钥映射成具体的、不可篡改的数值的效果。换句话来说，我们有了一个全局的 “键-值”对存储，是可以通过 Script 来访问的，而且它还有一个神奇的特性，这个全局表中的每一个条目都可以由一个具体的人（知道该公钥的原像的人）来设定，但永远只能设定一次。这个键值对存储对任何比特币交易（实际上，是对任何区块链上的交易）来说都是可以访问的，无论它是否连接到另一笔交易。

这个键值对存储有 2^256 个条目，其中的大部分都是不能访问的，因为没人知道这些键背后的原像，所以，虽然它是一个由每一种使用这种 Lamport 签名构造的程序共享的 “全局键值对存储”，但它不会被填满，也没有来自一个程序的数据意外破坏来自另一个程序的数据的风险，也没有理应由某一个用户设置的数值被另一个用户设定的风险。这个键值对存储也并不完整地存储在任何地方。

该文还指出，比特值承诺本身可以说是 “Lamport 签名” 这种基于哈希函数的一次性签名的应用，而这种阻止一个公钥签名多个数值的行为，在别的方面（比如断言机）也有重要应用。这可能才是 BitVM 给我们带来的编程能力和想象力的大突破：从此之后，我们知道了，在比特币世界里，表达状态不仅仅有使用比特币交易这一种办法，还可以使用 Lamport 签名，它能在一个全局的键-值对存储中长久地保留状态。

连接器输出与 Ark 协议：新的原子化互换形式

Ark 协议简介

“Ark 协议” 的发明来源于比特币世界的一个长期未解的问题：如何实现免信任的 “多方共享的 UTXO”，也就是让多个人的资金能共同居住在一个比特币交易的输出中。

可以想象，多方共享的 UTXO 在可扩展性和经济性上都很有好处：首先，多人的资金只占用一个 UTXO，则全节点需要保存的 UTXO 数量将较少，负担较小；其次，只要这样的 UTXO 带有内部状态的更新机制，处在同一个 UTXO（资金池）中的人们就能相互支付，而不使用区块链的交易确认机制，可扩展性更强，经济负担也更小。

在闪电通道出现之后，“使用链下交易来表达一个 UTXO 内部的状态” 已经不是什么理论难题；然而，为了保证免信任性，也就是每一位用户都不会被侵犯资金所有权，我们必须让可能受影响的用户的签名成为状态变更的必要条件，从而，共享 UTXO 的内部状态变更就成了一个要求许多用户在线协作的协调开销问题。

关于这一问题的完整描述以及解决思路，笔者曾专门撰文讨论 8，此处不再赘述。

Ark 协议的解决方案是，引入 “运营者/服务商” 的概念，并让共享的 UTXO 变成有保质期的，从而部分地绕过这个协调难题。由于共享的 UTXO 带有时间锁，在时间锁解锁之后就可以由 Ark 服务商以一个签名直接取走，这就避免了在移动这个链上的共享 UTXO 时需要所有用户协作的问题。

但是，在时间锁还没过期的时候，其中的用户也可能想动用自己的资金（比如发起链上支付，或退出资金池），该如何避免在这时候移动共享 UTXO 呢？

Ark 协议的想法是，将 “链上支付” 与 “移动共享 UTXO” 这两个动作分拆开来：用户把自己在共享 UTXO 中的钱币（称作 “vTXO”）交给服务商，服务商用另外的链上 UTXO 来发起支付，而避免花费共享的 UTXO 。那么问题来了，这两个动作怎么相互绑定，从而实现免信任性呢？

这就是 “连接器输出” 的作用了。

我们将实现用户支付意图的交易称为 “目标交易”。用户要签名一笔 “弃权交易”，花费自己的 vTXO 并支付给服务商。由于 vTXO 是共享 UTXO 的多笔连续花费交易的一个输出，因此它跟 UTXO 具有完全相同的形式，可以用来构造比特币。弃权交易的特殊之处在于，它还花费了目标交易的一个小额输出（也就是连接器输出），从而与目标交易形成了绑定 —— 如果目标交易不在区块链上得到确认，弃权交易就是一笔无效的交易（它花费的一个输入是不存在的），即如果服务商不支付，用户就不会失去自己的 vTXO ；而一旦目标交易得到了确认，服务商就有办法可以名正言顺地得到用户的资金。

- 图 3. 连接器的用法。方角矩形表示交易，圆角矩形表示输出。链下的弃权交易花费链上的目标交易的一个输出 -

这是一种不同于哈希时间锁合约的，新的原子化互换形式。

影响

有趣的是 Ark 协议的原创作者 Burak Keceli 在 bitcoin-dev 邮件组的最初一份邮件中的一番话 9，非常发人深省，大意是，Ark 所用的这种原子化互换方法，理论上，可以通过一种能在脚本中检查区块链上是否存在某个交易的操作码来实现，但他想出了连接器输出这个办法，可以实现相同的效果。

你可以想象一下，如果真的要实现这样的操作码，可以使用什么样的方法，以及它的资源开销如何。比如，实现它的其中一种方法是在脚本内实现 SPV 验证 —— 通过区块头来验证一笔交易存在于区块链上，但这不仅增加了比特币的交易验证引擎需要访问的数据，而且，为了通过这样的操作码，为交易提供的见证数据也是非常脆弱的，一旦发生区块链重组，可能交易就失效了。如果我们减少该操作码的功能范围，使其只能检查创建出现有 UTXO 集的交易，那么它的开销与连接器输出实际上是一样的；唯一区别在于不需要为目标交易安排连接器输出，即目标交易的体积稍微小一些。

笔者猜测，Burak 有过跟我们一样的困惑：当前的脚本设计使比特币的 UTXO 是一个独立的宇宙，它并不能将另一笔交易、另一个 UTXO 存在与否来作为自身的解锁条件，那该怎么实现这种条件呢？为脚本增加操作码吗？最终的答案是非常平实的：脚本通过与否不能依赖于另一个 脚本/UTXO/交易，一笔交易的有效性却能依赖于另一笔交易的存在性（只要让后者安排一个连接器输出），从而，只需让签名是对交易的签名，我们就能实现这样的控制。这再一次体现了比特币的编程模块的灵活性。

Ark 协议的设计初衷是实现一种异步的 coinjoin 协议：用户们将资金存入一个共享 UTXO，实际支付却在后续时间中使用其它 UTXO 来实现，这就成了一种 coinjoin。也正因此，它并未考虑变更一个共享 UTXO 内部状态的方法（它不考虑用户在内部相互支付）。

在该协议问世之后，后续的开发从未中断，例如，部分项目使用 statechain 的概念来实现 vTXO 的转移（也即 Ark 实例的内部状态变更）10，以及，许多新的变种都在考虑如何降低剩余的协调开销（存在于形构新的 Ark 实例的过程中） 11。这些开发可能会发现新的编程原语。

可调整惩罚协议（TPP）

TPP 由 John Law 提出，同样脱胎于对多方共享 UTXO 的研究。作为一种用于更新共享 UTXO 内部状态的机制，我们用一张图来说明它的原理：

- 图 4. 可调整惩罚协议。来自《 多方共享的 UTXO》 -

如图 4 所示，共享 UTXO 使用 “CT”（承诺交易）来表达内部状态，然而，承诺交易会花费来自某用户的 “ST”（状态交易）的一个 “Dust”（小额输出）；并且，ST 还有一个 “Stake”（押金输出），一旦共享 UTXO 需要更新状态（发布新的承诺交易），最新一个押金输出的私钥就要暴露。

也就是说，如果有人想发布旧的状态（比如这里的 “CT#A0”），就必须先发布旧的状态交易（如 “ST#A0”），然后把自己的押金烧掉。

显然，这也是一种用惩罚来劝阻参与者发布旧状态的机制，但它别出心裁的地方在于：（1）这种惩罚机制并不在表达共享 UTXO 内部状态的交易的输出中实现（想想看 “闪电通道”）；从而（2）惩罚的上限也不由参与者投入合约的资金价值决定，而可以另外指定。

这种设计，隔离了共享 UTXO 因为需要链下的状态更新机制而对表达状态的输出脚本造成的影响，后者可以专注于钱币的功能，而无需考虑共享 UTXO 层面的状态更新机制，也就大大简化了脚本的设计。

可以看出，TPP 的形式与 Ark 的连接器输出非常相似，只是用意不同。

到目前为止，还没有观察到 TPP 的应用。

结语

本文介绍的三种原语都出现于 2023 年，时间上先后是：TPP、Ark、BitVM。可以看出，这些新原语都从已经出现的编程原语中吸取了养分，比如惩罚机制，以及带有时间锁的结构；当然，也都创造了新事物，扩大了我们的想象力和编程能力。

时至今日，如果我们要基于同样的方法 —— 基于经验和总结 —— 来讨论比特币的可编程性，则势必要纳入这些新的案例。作为基础的比特币钱币模型（UTXO）、脚本系统和交易，在此期间并没有发生质的变化，然而，这些新案例说明了在曾经被我们忽视的领域，的确存在可用于编程出有用应用的可能性。

本文没有讨论近年来的热门概念 “限制条款（covenants）”，这个概念意味着你可以在脚本中限定该钱币要花费到哪里去。显然，如果某个软分叉成功增设了相关的操作码（比如 OP_CTV 12 或 OP_CCV 13），它必然会给比特币可编程性的研究增加新的篇章、迫使我们以更加精准的概念来描述比特币的可编程性。但笔者安然地止步于此。它们是已经浮现在地平线上的可能性，而笔者也不介意在它们真的升起时，使用一篇全新的文章来总结我们的新领域。

参考文献

1. https://learnblockchain.cn/article/18086/ ↩

2. https://learnblockchain.cn/article/6685 ↩

3. https://en.bitcoin.it/wiki/Script#Arithmetic ↩

4. https://bitvm.org/#resources ↩

5. https://learnblockchain.cn/article/23558/ ↩

6.“以太坊（Ethereum）” 是笔者所知最早以 “富状态性” 来描述自身可编程性特性的项目；而在该系统中，富状态性意味着一笔交易可以访问任意多个智能合约账户（它们是存储自定义状态的单元），仅受区块剩余可用资源的限制。 ↩

7. https://www.btcstudy.org/2024/07/15/script-state-from-lamport-signatures/ ↩

8. https://www.btcstudy.org/2024/08/30/on-sharing-utxo-forms-and-features/ ↩

9. https://learnblockchain.cn/article/18729/ ↩

10. https://learnblockchain.cn/article/19566/#%E6%94%AF%E5%87%BA%E5%9E%8B-VTXO ↩

11. https://learnblockchain.cn/article/21026/ ↩

12. https://learnblockchain.cn/article/18619/ ↩

13. https://learnblockchain.cn/article/23488/ ↩

（完）

• 本文转载自： btcstudy.org/2026/02/26/... , 如有侵权请联系管理员删除。