多方共享的 UTXO：形式与特性

作者：Anony

“多方共享的 UTXO（sharing UTXO）”（下文缩写为 “共享 UTXO”），顾名思义，就是让多个用户共享对一个 UTXO 的所有权、让他们的资金寄身于同一个 UTXO 中。这个概念的侧重点不是对权限的管理，而是对内部状态的表达和控制 —— 让多个用户的资金容身于一个 UTXO 中，但依然能保证自主保管，而不会被其它用户侵犯所有权。

对 “共享 UTXO” 这个概念的关注和开发由来已久。从最广义的角度看，任何超过一方控制 UTXO 的设计，都可算作此类。这个最广义的定义会将 “闪电通道” 这样的两方共享 UTXO 也包含在内。即使我们有意排除这样的两方共享 UTXO，只包含三方及以上共享 UTXO 的情形，那么，于 2018 年提出的 “通道工厂（channel factory）” ^[1] 概念也无疑是共享 UTXO 的一个子集。此外，于 2020 年提出的 “支付池（CoinPool）” ^[2] 概念，以及在讨论 “限制条款（covenant）” 提议时 “顺带” 提出的一些设计 ^[3]，都为这个主题增加了内容。

实际上，人们提出的设计是如此多样，已界临容易引起困惑和混淆的程度（至少对我自己来说是如此）。这些理解上的障碍，要求我们归纳这些设计的共性、确定一个基础概念，并基于这个基础概念以及配套的术语来解释这些设计。

值得一提的是，一些作者已明确开始这样做了（将看似不同的概念当成同一概念上的有区别设计） ^[4]；Optech 的主题界面，也将意义相近的 “payment pool” 和 “Coinpool” 都合并到了 “Joinpool” 的名下 ^[5]（但依旧未提出 “Joinpool” 和 “通道工厂” 的基础概念）。

在这些努力的启发下，本文尝试将 “共享 UTXO” 作为基础概念，讨论这个概念要面临的基础问题，并解释常见的一些设计（比如：通道工厂、Statechain、ARK）的形式和特性。

在此之前，我们要先解释一些更基础的概念。

基础概念

承诺交易

在合约式协议（contractual protocol）中，“承诺交易（commitment transaction）” 指的是得到了对手方的签名（因而有效、可用）、但默认不向外广播的交易。这些交易可以被当成对手方给出的 “可信承诺”，也是参与者确保自己可以单方面取回自己应得的资金的保证。

比如，在闪电通道中，通道初始化以及每次更新通道状态的时候，双方都要交给对手方一个承诺交易；这些承诺交易记录了两方在通道内的最新状态（余额），一旦被发送到链上确认，就会将通道资金分拆给双方。

这里要强调的是承诺交易表达一个合约内部状态的能力。一个闪电通道在链上仅仅表现为一个 UTXO，但它却能容纳两个用户的资金在里面，所依靠的，正是承诺交易的这种能力。

vTXO

在 “共享 UTXO” 的语境下，“vTXO（虚拟的 UTXO）” 指的是寄身于 UTXO 中的用户资金的 最基本单元 。提出这个术语是为了分析和表达上的便利。但同时，这样的称谓也有严格的事实基础：给定我们以承诺交易的输出（TXO）来表达用户的资金，这些资金的动作跟 UTXO 是没有分别的。

在这里，我将 vTXO 分成两种类型：（1）排他性占有的资金（就像常见的单签名 UTXO），可称为 “coin”；（2） 闪电通道 。这里之所以分成两种类型（而不是将闪电通道也当成一种共享 UTXO，从而当作只有前者一种类型），是因为：（1）闪电通道的交易输出中都留有为实现下文即将提到的 “链下更新机制” 而专门设计的装置，不能算作 coin；（2）排他性占有的资金与闪电通道在使用体验上有极大的不同：闪电通道允许发起即时支付（同时，闪电网络可以放大这种支付能力），而且支付的大小是可以调整的；但在排他性占有的资金中，这两者都是做不到的；（3）关于闪电通道的特性，我们已经积累了大量的知识，也有了可以描述这些特性的术语，没有必要将其表述为一种共享 UTXO、然后用共享 UTXO 的术语将这些特性重新表述一遍；将它当成一个基本的可分析的单元，会在理解上提供极大的便利。

这种分类，从字面上看当然是不完美的，但却是有用的。往后我们会看到，从形式上看，一些设计（比如：带有服务商的单向通道）似乎也符合闪电通道的分类理由，但其实际用法却更接近于 coin；这种情况下，我依然将其归类为 coin。

链下更新机制

仅仅拥有 “承诺交易”，还不足以构造出闪电通道。设想一下，如果我们只是能让两个用户的资金寄身于同一个 UTXO 中，但每次他们要相互支付时，都依然需要发起一笔链上交易，那么这种构造的实用性是很值得怀疑的。闪电通道的成功之处，就在于设计出了一种可用的、在链下更新承诺交易的机制（“LN-Panelty”），从而允许双方相互支付而无需发起链上交易。

在共享 UTXO 的语境下，链下更新机制指的是能在 vTXO 之间转移资金而不需要链上确认的机制。

共享 UTXO

在 CoinPool 一文 ^[2] 中，两位作者归纳了一种重要的特性：“ 非交互式任意顺序取款 ”，意思是，无论何时退出，用户总能取回自己应得的资金，并且取款过程不需要他人的帮助。我认为，这一属性是共享 UTXO 的根本属性，缺失了这一属性，就会沦为一种托管方案；不管这种托管方案内部有什么样的设计，都不能称为 “共享 UTXO”。

在技术上，这就意味着，我们需要让每一方（每一个 vTXO 的持有者），都能否决共享 UTXO 的状态变更，否则，就有可能出现多数参与者侵犯某个参与者资金所有权的事情。也即，所有可能发生的状态变更，都必须得到每一位参与者（预先或即时）的同意。

比如，如果有 3 个用户共享一个 UTXO，那么不论是甲动用其中的资金向外支付，还是甲希望给乙支付，只要交易以该共享 UTXO 为输入，都必须保证：没有丙的签名同意，这些交易就不能生效。否则，甲和乙就有可能串谋倾吞丙的资金。

技术上，这很容易解决，只需要求每一位用户都参与的多签名装置即可。

然而，在实用性上，这就构成了一种挑战：一旦某个用户离线，其它用户更新状态的能力就会受到影响（虽然取款能力不受影响）。（类似于在闪电通道中，对手方离线会使你无法操作通道中的资金）。

可以说，所有的共享 UTXO 的设计，都是在应对这个挑战。

接下来，我们会用一系列的例子，介绍在共享 UTXO 内部表达状态的形式以及 vTXO 的类型，如何决定离线用户对共享 UTXO 的影响，并相应影响共享 UTXO 的实用性和使用体验。

拥堵控制

先考虑一种最简单的多人共享 UTXO：n 方都在一个 UTXO 内拥有资金（vTXO），并且这些 vTXO 都是排他性控制的；这些 vTXO 都得到了同一笔承诺交易的承诺（每一方都持有同一笔承诺交易，并且都得到了其它所有人的签名）；一旦这样的承诺交易得到广播和区块确认，就会将这个共享 UTXO 完全分解，即内部状态完全曝光、每个人都拿回自己原本存放在共享 UTXO 中的资金。如下图所示：

这是一种最简单的设计：vTXO 使用了最简单的类型、没有链下更新机制（因此三人无法在链下发起内部支付）、任何一个人单方面退出都会导致全体退出。这样一种构造，到底有什么用呢？

Jeremy Rubin 根据其使用场景，将这种构造命名为 “拥堵控制（congestion control）”，其用途是：在手续费高涨的时候，将需要发生的许多支付 “存放” 在一个 UTXO 中，等待手续费降低到可接受的水平时，再将这些支付在链上展开。比如，在手续费高涨的时候，Alice 三人希望从托管式交易所取款，那么交易所可以协调三方初始化一个共享的 UTXO，将三人的资金先打到这个共享的 UTXO；等手续费退潮的时候，三人再合作或使用手中的承诺交易取出其中的资金。

如果能保证三人始终在线，那么这种构造的有用性会大大提高：三人可以进一步协调手续费；也可以不使用自己在承诺交易中使用的收款地址，而是直接向另一个人支付。但在用户随机的情况下，这是无法保证的。而在非合作退出的情形中，由于承诺交易已预先锁定了手续费，希望加速确认的用户只能使用子交易来追加手续费（即 “CPFP” ^[6]），而不能使用 “手续费替换（RBF）”。

与此相关的，另一个可能受到批评的地方在于其全体退出机制：在非合作情形下，如果某个用户比其他人更急着退出，而承诺交易预设的手续费率无法做到，那么 TA 将需要独自承担让所有这些 UTXO 都得到链上确认的额外手续费。这意味着，如果拥堵控制 UTXO 中的用户并不都具有相同的时间偏好和使用模式，其用户体验就会打折扣甚至变成灾难。

有没有办法，能够只弹出一个 vTXO，而不是让所有的 vTXO 都展开呢？显然是有的 —— 仅仅 “只是” 更深度地利用拥堵控制这种构造而已。

改进的拥堵控制

如下图所示，我们可以这样初始化一个拥堵控制 UTXO：当 Alice 想要单方取款时，她能够动用的承诺交易只会弹出属于她的 vTXO，而将剩余的资金交回给属于剩余参与者的另一个拥堵控制 UTXO（比如下图中的 “拥堵控制 UTXO-2”），该拥堵控制 UTXO 也被预先签名了承诺交易，能让 Bob 和 Carol 可以单方退出。其余情形也是同理，因此下图中的 “承诺交易 B” 和 “承诺交易 C” 没有进一步细化。

这种构造可以大大缓解前面提到的额外手续费问题，因为，用户无论什么时候取款，都只需多确认一个 UTXO 而已。

而且，假设 Alice 也会给大家分享自己对承诺交易 A 的签名，那么该交易也可被其他用户用作 “排除交易” —— 在 Alice 长时间无响应的时候，将她弹出这个共享的 UTXO，让剩余的用户能享受正常的共享 UTXO 可以给他们带来的好处。这也可以限制 Alice 的离线给其他用户带来的影响。

美中不足的是，这种构造只允许用户一个一个排队退出；如果有多个用户尝试同时退出，就会发生所谓的 “ 状态争用/竞争进入 （race condition）” 问题：这些用户将发起手续费竞赛，以争夺排队的次序（优先退出的资格）。因为我们并未安排允许多个用户同时退出的承诺交易 —— 如果有这样的承诺交易，就无需争用。例如，当观察到 Alice 要退出时，Bob 可以使用准备好的让三人同时退出的承诺交易，以 RBF 方法让这笔交易获得比 Alice 的交易更高的确认优先级（从经济性上来说可以做到比 Bob 单发一笔交易更好，但这需要在签名承诺交易时设计好）；当 Bob 的交易获得确认时，三人可以同步退出。

乍看起来，似乎毫无疑问应该增设这种允许多人同时退出的承诺交易。但与此同时，“共享 UTXO” 这个概念也将开始向我们展现它的峥嵘之处：与上述简单拥堵控制构造相比，改进后的构造在初始化时需要用户签名的承诺交易数量大大增加，也即用户间交互的需求大量增加；而且，它不是随用户的数量而线性增加的，而是会出现所谓的 “组合爆炸”；如果再增设这样的允许多人同时退出的承诺交易，退出的可能性会进一步爆炸（如果因为 3 人的数量太少而使这一点不明显，读者可以尝试画一个 5 人的共享 UTXO）。

用户要用哪种通信手段完成这么多的交互？（当然是互联网，问题是这些用户如何找寻彼此呢？）给定一个用户在初始化过程中失联就会导致初始化完全失败、必须从头再来的可能性，是否应使用某种抗女巫机制？这些都是需要考虑的问题。

那么，是否有某种中庸之道？

树形结构

考虑下图这样的共享 UTXO：当 Alice 想要退出（或其他人想要排除 Alice）时，Alice 无法直接从共享 UTXO 中弹出，而需要先广播 “承诺交易 01”，该交易会将原本的共享 UTXO 对半分拆成两个共享的 UTXO；然后，Alice 广播下一笔承诺交易，继续分拆自身所在的共享 UTXO；…… 如此，直至其 vTXO 完全退出。

（熟悉这个领域的读者想必会脱口而出：“这是一种树形结构！”没错，正是如此。）

在退出的公平性上，这种构造不如上一节所述的构造：视乎 Alice 退出的先后，她几乎总是需要额外确认多于 1 个 UTXO。在我们这个例子中，如果她最先退出的话，她需要额外确认 2 个 UTXO。如果是一个 8 人的共享 UTXO，则她需要额外确认 3 个 UTXO。

然而，只要仔细观察上图，就可以发现其巨大优点，尤其在参数者数量较多的时候：

（1）需要签名的承诺交易的数量大大减少（本构造在多出 1 位用户的前提下，需要签名的承诺交易数量还比上一种构造少）；这是因为，多个用户可以共用相同的承诺交易来退出；

（2）它也部分缓解了前述的状态争用问题，因为共享的 UTXO 每分裂一次，就多出一个允许访问的 UTXO，也即允许多一个原来位于不同分支的用户操作；假设 Alice 和 Carol 都要退出，那么，在让 “承诺交易 01” 得到确认之后，他们就可以互不影响地并行操作；

（3）它也让链下更新机制更容易运行（如果有的话）。假设 Alice 离线，在我们前面所述的简单拥堵控制构造中，链下更新机制也会停摆；而在上述改进型构造中，尽管其他人可以更新原本就不包含 Alice 的承诺交易，但需要更新的数量很大，也会给设计带来难度、增加分析的复杂性；而在本构造中，由于承诺交易的数量大大减少，且不包含 Alice 的承诺交易易于定位和分析，自然就更容易设计出链下更新机制。

综上所述，在这几节中，我们分析了共享 UTXO 内部的状态表达方式对其实用性和用户体验造成的影响。这三种表达方式可姑且称之为 “串珠结构”、“星月结构” 和 “树形结构”。这三种结构最初如何提出已不可考，但我想，肯定有许多开发者思考过这些结构。

我们也在这些分析中了解了共享的 UTXO 在其生命周期中可能遇到的诸多挑战。

接下来，我们进一步分析 vTXO 的类型所带来的影响。

Coin vs. 闪电通道

看看以下这种形式的共享 UTXO，在特性上，它会跟 “拥堵控制” 构造有什么区别？

没错，它跟拥堵控制使用了完全相同的状态表达结构，但正因为这些 vTXO 并不是排他式控制的 coin，而是闪电通道，那么，即使这种共享 UTXO 没有实现链下更新机制（不能允许资金在 vTXO 之间转移），也不影响这些用户可以相互支付，因为他们两两之间都开设了闪电通道！他们可以相互支付，也可以借助共享通道中的对手来发起闪电支付和接收闪电支付。唯一他们不能做的事情是调整他们位于这个共享 UTXO 中的通道的大小 —— 这需要发起链上交易，更新这个共享的 UTXO 才行。

这个例子说明了 vTXO 的类型对共享的 UTXO 的用户体验带来的影响；也说明了，即使不改变状态表达结构，也可能在其它方面改善用户的体验。当然，这也需要增加用户在初始化阶段需要签名的承诺交易的数量。

实际上，上图启发自一种著名的共享 UTXO 设计 —— 通道工厂。与通道工厂不同的是，我在这里假设了它不存在链下更新机制（而通道工厂有）。如果有这样的机制，那么，这三位用户就可以调整彼此之间的通道的大小而不需要发起链上交易 —— 有显而易见的用途。

多方的链下更新机制

链下更新机制可以大大增加共享 UTXO 的实用性：当 vTXO 是排他性控制的资金时，链下更新机制允许这些用户相互支付；当 vTXO 是闪电通道时，链下更新机制允许这些通道调节大小。

不过，即使是链下更新，也需要让被更改的状态会影响到的参与者都在场，才能动用（否则就不安全）。因此，合适的状态表达结构会有便利与其运作。

最后，尽管链下更新机制在某些条件下可以发挥跟闪电通道型 vTXO 相同的效果，但这并不代表我们划分 vTXO 的类型是多余的，也不代表将链下更新机制作为一个独立的元素是多余的。从分析的便利和完整性出发，都要求我们将它们识别为两个独立的元素。

接下来，我们要介绍几种多方链下更新机制。（如果你对技术细节不感兴趣，可以直接跳到下一个章节。）

在闪电通道中，链下的状态更新机制是通过在承诺交易的输出中安装特殊的装置来实现的：每当要更新状态、交换新的承诺交易时，双方就将自己用在上一笔承诺交易中的一个秘密值交给对方。这等于是把上一笔承诺交易中归属于自身的输出交给对方，一旦自己广播了旧的承诺交易，就将失去所有。这就实现了一种惩罚机制，使双方都不敢广播过时的承诺交易。

这样一种机制，是极难延伸成一种多方链下更新机制的。具体来说，当某一方提交过时状态时，该方的确可被惩罚，但其他方也被回退到了一种旧状态，而无法马上按照最新状态来分割资金。解决办法是让每一笔表示旧状态的承诺交易都可以在一个窗口期内被表示更新状态的承诺交易花费，以保证总是可以按照最新状态分割资金并应用惩罚。问题是，这会让单次更新需要签名的承诺交易数量随已发生的状态更新次数而增长，且需要保存的承诺交易数量会呈阶梯式增长。如下图：

在第 2 次更新状态时：

共享 UTXO --> 承诺交易#0 --> 承诺交易 #01 --> 承诺交易 #012
共享 UTXO                --> 承诺交易 #1 --> 承诺交易 #12
共享 UTXO                              --> 承诺交易 #2

注 1：承诺交易 #0 表达的是初始状态。
注 2：纵向同一位置的承诺交易表达的是相同的状态。

这样一来，虽然状态更新的安全性得到了保证，但参与者的交互和存储负担都很大，而且，一旦某个用户将旧的承诺交易广播上链，为使用最新状态结算通道，可能就需要在链上确认整个交易链条（例如，Alice 将承诺交易 #0 上链，那么其他人要继续广播 #01 和 #012 上链），这就没什么可扩展性可言了。

这就是我们想要 “eltoo” 的原因。这一想法在 2018 年提出 ^[7]，它提出了一种新的 SIGHASH 标签（即 ANYPREVOUT，现已被 BIP-118 ^[8]定义）；使用这种标签，签名可以仅指定交易的输出，而不指定输入，因此总可以用来花费相同的脚本；再加上递增承诺交易 nLocktime 字段的数值，就可以实现这样一种效果 ^[9]：交易链条中排在后面的交易可以直接花费自己的任意一个祖先交易，而不论两者在被签名的时候中间隔着多少笔交易，同时反之不能成立。也即，当 Alice 将 #0 上链的时候，其他人可以直接广播 #012，跳过中间的 #01（实际上，这时候已经不需要 #012，而只需要 #2 了）。这就大大缓解了参与者的交互和存储负担、挽救了可扩展性。

但是，eltoo 需要我们以软分叉激活 SIGHASH_ANYPREVOUT，所以这种机制，当前是不可用的。

2022 年，John Law 提出了另一种叫做 “可调整惩罚协议（Tunable-Panelty Protocol）” ^[10] 的链下更新机制。

在这种机制中，表示状态的承诺交易（CT）（带有相对时间锁）不仅以共享 UTXO 为输入，还有额外的一个小额的输入（Dust），来自某个参与者在共享 UTXO 之外的另一笔资金。当某一个参与者，比如 Alice，尝试发布一笔承诺交易的时候，必须先让这个小额输入先得到确认，也即需要发布 ST（“状态交易”）。而 ST 还有另一个输出，实际上是一份押金（Stake），因为在更新状态时，参与者必须给出这个押金的私钥。

最终的效果是，如果某个参与者尝试发布某个旧的承诺交易，必须先将一笔旧的 ST 上链，而这就会导致其押金被取走 —— 而此时，共享的 UTXO 还没有被花费，因此不影响所有用户使用最新状态的能力。相等于，TPP 为分割共享 UTXO 设计了一个准备阶段，使尝试欺诈（或者只是粗心）的用户无法直接操作共享 UTXO，因此避免了前面提到的需要重放交易链条的问题。

TPP 的一个重大优点是它无需变更比特币的底层，现在就可以实现。

实际上，还有一种相当相当简单的多方更新机制，是基于时间锁的承诺交易。它脱胎于对两方通道的研究 ^[11]。

在这种机制中，承诺交易本身带有交易层面的时间锁，而每次更新状态，参与者都签名一笔时间锁更短（因此更快可被发布、得到确认）的承诺交易。时间锁自身就防止了承诺交易冲突的问题，因此也无需进一步设计应对这种冲突可能性（某个用户发布表示旧状态的承诺交易）的机制。

这种机制是如此简单，易于实现，让上面两种机制的探讨似乎没有意义。但并非如此。这种机制有个致命的缺陷是，它具有明确的寿命 —— 更新达到一定的次数之后，就只能结算并重新建立一个新的共享 UTXO。尽管可以缓解（比如，缓解办法之一是在共享 UTXO 与最终表达状态的承诺交易之间插入多笔中间交易，以倍乘相对时间锁），但无法从根本上解决。

题外话：与共享 UTXO 相关的限制条款提议

虽然共享 UTXO 常常被关联起各种可以实现限制条款的软分叉提议来讨论，但到目前为止，我几乎没有提到它们。原因在于，虽然这些限制条款提议可被用于协助共享 UTXO 的运行，但它们并不决定共享 UTXO 的根本特征 —— 而唯有理解了共享 UTXO 的根本特性，我们才能理解这些限制条款在这个场景中到底派什么用场。

我们在这里简单地分析三种提议：OP_TLUV ^[12]、OP_CTV ^[13] 和 OP_EVICT ^[14]。

如前所述，在建构共享 UTXO 时，需要进行大量交互（签名大量的承诺交易以保证安全性），会阻碍其实用性和用户体验。对此，OP_TLUV 的解决思路是，利用 Taproot 的默克尔脚本树结构，将用户的状态承诺到脚本树的叶子中。在用户需要单方面退出时，可揭晓这个叶子，并以其中记录的资金数量退出；TLUV 会验证资金数量、确保剩余资金被转移到了一个新的 taproot 输出中，且该输出已不再允许该退出用户参与 —— 其公钥已从 taproot 内部公钥中删除，其脚本也已经从默克尔树上摘除。

由于默克尔脚本树本身可以承诺用户的资金状态，用户也就无需签名承诺交易，在初始化和交互过程中，只需完全验证 taproot 输出的内部公钥和脚本树构成即可。这就极大地降低了交互需求。

熟悉本领域其他协议设计的读者可能会说：这不就是状态模型下常见的 “状态树” 设计吗？没错，正是如此。但从我们前面的结构分类法来看， 这种设计 应该被归类为星月结构，而不是树形结构 —— 它允许单用户直接退出，并让其他用户不受影响，而不是每次都对半分拆共享 UTXO。相应地，我们也可以想象一种使用 OP_TLUV 的树形结构 —— 被脚本树承诺的是一半参与者的资金和聚合公钥。

无独有偶，OP_CTV 也可以用来支持这种设计。因为，OP_CTV 使得我们可以让一个脚本仅可以被具备某些特征的交易花费，这些特征包括输出的数额和脚本。因此，我们也可以将用户的取款交易承诺到默克尔脚本树的叶子中，允许用户单方面动用 —— 反正，动用的结果是其资金退出，而剩余的资金进入一个 UTXO，该 UTXO 也已被我们用合适的内部公钥和默克尔脚本树锁定，允许剩余的用户单方面退出。

与 OP_TLUV 相比，在 OP_CTV 的这种用法中，用户需要验证的东西更多（需要验证每一个取款步骤都会将剩余资金交给正确的脚本树），但同样不需要再签名承诺交易（验证的数量跟仅使用承诺交易时相同）。

而 OP_EVICT 的想法则是另辟蹊径。OP_EVICT 的作者 ZmnSCPxj 注意到，在使用 OP_TLUV 的星月结构中，退出交易需要揭晓自身叶子的默克尔树路径；而使用树形结构也需要揭晓类似于默克尔树路径的多笔交易。有无办法避免这种开销？

OP_EVICT 想法是，让用户直接签名一个输出（公钥与数额），并让这样的签名可被 OP_EVICT 操作码理解、用于验证当前的某个交易输出是否与被签名输出一致。在验证完这个签名和对应的输出之后，OP_EVICT 会从 taproot 内部公钥中减去这个签名公钥，并要求剩余公钥对交易的签名。如此一来，等于是 taproot 的内部公钥自身就承诺了参与者的构成，而参与者的资金也无需得到默克尔树的承诺，只需要公钥自身的签名（以及其他用户的输出签名）保护。

OP_EVICT 还有一个重大的优点：它允许多个用户同时退出。因此，它可以实现一种没有竞争进入问题的星月结构。（更准确来说，OP_EVICT 的思维模式有所不同，它假设了用户很少需要单方面退出，相反，难以处理的问题是某个（些）用户离线造成其他用户无法正常使用共享 UTXO 的功能。因此，需要的是一种能够高效将离线用户排除出去的工具，排除掉离线用户，剩余用户就可以通过合作来更新状态了。所以，用户自己退出，并不是这个操作码的 “正常” 用法。）

与前面两者相比，由于没有显式承诺状态的方法，它所要求的用户间交互也将更多，但也显著少于只使用承诺交易的情形。

综上，限制条款操作码在共享 UTXO 场景中的主要用处是减少交互需求，它可以降低某些状态表达结构的运行开销，但并不决定我们可以使用哪种结构。对结构的研究也不会因为限制条款的出现而失去意义。

共享 UTXO 设计案例

多方通道

如上图所示，这是一种具备链下更新机制的拥堵控制 UTXO（vTXO 为 coin、具备链下更新机制的串珠结构）。

有时候，下图这种结构也会被当成一种多方通道。

与分散的闪电通道（以及下文要介绍的分层通道）相比，多方通道的好处在于更少面临 “收款额度（入账流动性）” 的困扰。缺点在于，更难抵抗离线用户带来的影响。

分层通道

“分层通道（hierarchical channel）” 是 John Law 在 2023 年提出的想法 ^[15]。它使用树形结构，vTXO 是闪电通道。同时，作者提议使用 TPP 作为其链下更新机制。

通道工厂

通道工厂使用串珠结构，vTXO 为闪电通道（共享 UTXO 的每两个用户之间都有闪电通道），使用时间锁递减承诺交易作为链下更新机制。

Statechain

“Statechain”^[16] 的基本想法是，通过转移控制一个 UTXO 的私钥，就可以将这个 UTXO 完全转移，而不需要发生链上交易。为了协助这样的转移，两方（用户以及服务商）需要共同构造一个公钥（两方都只有该公钥背后的私钥的一半），并将资金存入这个公钥（为了保证免信任取款，还需要预先签名一笔带有时间锁的承诺交易）；在支付时，支付者 和/或 服务商先给接收者展示该 UTXO 链下所有权的流转历史，证明资金的真实性；然后，支付者交出自己的签名，表示支付的意愿；接收者跟服务商合作生成新的私钥碎片，并签名新的一笔带有更短时间锁的承诺交易，支付完成。

如果用共享 UTXO 的术语来表述，它是一种使用时间锁递减承诺交易来更新状态的串珠结构；只不过，这个共享 UTXO 只有一个 vTXO，而且 vTXO 的持有者不能分割自己的 vTXO，一旦支付，就必须把整个 vTXO 都转移过去 —— 任何时刻，vTXO 的合法持有者都只有一个；此外，为了能够引入新的用户而不使用链上交易，用户必须信任服务商不会与该 vTXO 的任何一个前任用户勾结（他们勾结，就可以生成共享 UTXO 私钥的有效签名，从而把钱转走） —— 这是它最大的缺点，也是为什么在接收支付时，用户需要执行额外的验证。

如果用户想启用更细粒度的支付，而不是只能一次性转移全部资金，那么可以将 vTXO 转移给一条闪电通道，在闪电通道内发送支付，这是可以做到的 ^[17]。

ARK 和 ARK v2

“ARK”^[18] 是一种没有链下更新机制的扁平结构。那么，它跟 “拥堵控制” 的区别在哪里？在于其 vTXO 并不是纯粹的 coin（但也不是闪电通道）。从脚本内容上来说，更像一种 “单向通道”。这种单向通道有两种花费路径，一是两个参与者的多签名；二是带有时间锁的某一用户单签名。后者可以用来表明这条单向通道的最终资金归属，也可以用来催促某一参与者行动。而前者，则可以在时间锁还未到期时，启用多签名装置可以支持的功能。在下文描述单向通道时，我会将可以使用时间锁分支的参与者写在前面。

用户在 ARK 中的 vTXO 为 ARK 服务商与用户的单向通道。 而用户的 vTXO 又通过一笔特殊的承诺交易（Redeem TX），为用户与 ARK 服务商的单向通道注入资金。

这套设计被用来支持一种 “非交互的原子化 coinjoin 支付”：当 Alice 尝试给 David 支付时，她可以用自己跟服务商的单向通道（Alice-Server Coin）表达一种可信承诺：当且仅当你给 David 支付，我这笔钱就属于你；但如果你没有在一定时间内做到，我就取走我这笔钱。这确实是可以做到的，因为，作为共享 UTXO，ARK 无法在 Alice 不同意的时候被花费。因此，如果服务商不提供服务，Alice 总可以发布 the CT 和 Redeem TX#A，然后将 Alice-Server coin 中的钱取走。

相应地，服务商也不担心 Alice 会赖账，因为一旦 TA 给 David 支付了，就总是可以让 Alice-Server coin 确认，然后用 Alice 给出的承诺交易将钱取走。

最终，理想情形是，双方会合作：服务商给 David 合作，Alice 同意跟服务商一起在链上变更 ARK 的状态。而在这个过程中，Alice 并没有直接给 David 支付；如果 David 在链上接收支付，那么对于外部观察者来说，也不知道是这个 ARK 中的谁给他支付的（只有 Alice 的同伴知道）；而如果 David 也使用另一个 ARK 来接收支付，那么，甚至连 Alice 在这个 ARK 中的同伴，也不知道钱交给了谁（只要这些同伴不是在两个 ARK 中都有参与）。

此外，这里的单向通道虽然理论上支持细粒度的支付，但 ARK 并不支持这个特性。跟 statechain 一样，资金是整个转移的。

ARK v2 基本上沿用了相同的构造 ^[19]，只是启用了一些让服务商能够更高效地回收资金的设计（也同样依托于 taproot 的默克尔脚本树）。但从共享 UTXO 的构造上来说，两个版本基本上是一样的。此外，ARK 可以不依赖于限制条款，但 ARK v2 明确依赖于限制条款。

对共享 UTXO 的赞赏和批评

CoinPool 一文很好地勾勒了研究共享 UTXO 的两个动机，也正是共享 UTXO 有望为人们带来的好处：

• 隐私性。当许多人共享一个 UTXO，就可以在链上隐匿支付的发起人；而如果接收者也使用共享的 UTXO，还可以隐匿接收者。ARK 就是拥抱这个方向的代表。

• 可扩展性。可以缩减链上 UTXO（链上状态）的数量、减少对区块空间的需求（比如，可以在共享 UTXO 内使用链下更新机制来相互支付）。这方面的代表应属通道工厂。

而对这个概念的批评主要从实用性角度出发，认为在用户数量增多时，全体用户都在线是非常罕见的，这意味着其状态可能经常卡住而无法更新，因此它是一种脆弱、可用性差的机制。还有一种批评则更加尖锐，来自 Peter Todd：我们假设了要使用这种机制来拓展比特币的处理能力，即用它来容纳经济条件差、无法负担得起在链上拥有属于自己的 UTXO 并加以使用的用户；然而，我们又假设了真的发生什么事的时候，用户会主动退出或者被动弹出到链上 —— 他们怎么又突然负担得起了呢？

这种批评显然需要更深入的分析，才能找出合理的回应。至少，在目前，出于一些好处，人们不会停止对共享 UTXO 的研究。并且，这些研究已经产生了价值，无论是理论上的（比如 TPP），还是实际上的（比如 statechain 的实现）。

总结

本文分析了共享 UTXO 的基本元素，并以此解释了当前多种共享 UTXO 的具体设计，将它们的特性归因到对特定基本元素的使用。

本文主要着眼于结构上的特点，对许多技术细节（例如相关脚本的设计以及配套的用户交互流程）则多有省略。该方向上的进一步研究可以帮助我们进一步评价不同设计的短长。

（正文完）

脚注

1.https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks.pdf ↩

2.https://www.btcstudy.org/2022/06/15/coinpool-exploring-generic-payment-pools-for-fun-and-privacy/ ↩

3.https://utxos.org/uses/scaling/ ↩

4.https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdateverify-by-zmnscpxj/ ↩

5.https://bitcoinops.org/en/topics/joinpools/ ↩

6.https://www.btcstudy.org/2022/03/17/introduction-to-fee-bumping-by-Bitcoin-Optech/#CPFP-%E7%AE%80%E4%BB%8B ↩

7.https://blockstream.com/eltoo.pdf ↩

8.https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki ↩

9.https://www.btcstudy.org/2020/09/01/en-eltoo-next-lightning/ ↩

10.https://bitcoinops.org/zh/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories ↩

11.https://www.btcstudy.org/2022/11/14/understanding-payment-channels/ ↩

12.https://www.btcstudy.org/2023/06/29/tapleaf-update-verify-covenant-opcode-introduction/ ↩

13.https://www.btcstudy.org/2022/02/07/what-is-bitcoin-checktemplateverify/ ↩

14.https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdateverify-by-zmnscpxj/ ↩

15.https://www.btcstudy.org/2023/04/17/resizing-lightning-channels-off-chain-with-hierarchical-channels/ ↩

16.https://www.btcstudy.org/2021/10/12/statechains-non-custodial-off-chain-bitcoin-transfer/ ↩

17.https://www.btcstudy.org/2023/01/12/statechain-lightning-combined-in-bitcoin/ ↩

18.https://www.btcstudy.org/2023/07/21/simplest-ark-explanation-by-ruben-somsen/ ↩

19.https://www.btcstudy.org/2024/06/12/introducing-ark-v2/ ↩