限制条款与 “多人共享的 UTXO” #1
editor-Ajian
started this conversation in
提议
Replies: 1 comment
-
|
修订：
更新：
最后：
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
我注意到，最近，限制条款（covenant）得到了更多的讨论；同时，人们也在关注如何获得（比闪电网络）更大的可扩展性。这两类讨论往往相互关联，最终指向同一种资金保管形式：多人共享同一个 UTXO。如果多个人（比如，超过两个人）可以共享同一个 UTXO，则显然它的可扩展性更好；同时，为了让多人能够共享同一个 UTXO，使用现有的操作码和承诺交易可能难以令人满意，我们需要限制条款来帮助我们。
也正因此，这样 “多人共享的 UTXO”，不论在具体场景中叫什么名字，一直是限制条款提议支持者认为限制条款可以给比特币带来的新的用途。
本文正想通过对 “多人共享的 UTXO” 这种形式的研究，来探讨限制条款的用途和局限性。
限制条款
在本文中，我们可能会接触到以下几种限制条款（它们全都仍然处于提议阶段）：
BIP-119 OP_CHECKTEMPLEVERIFY（CTV）。这种操作码可以在脚本中放置一个哈希值，使得该脚本只能被该哈希值所承诺的交易花费 [1] 。这样的哈希值并不等同于 txID，因为它不承诺输入，所以，你可以认为它所承诺的是资金的流向（会产生什么样的输出）。此外，还可以承诺一些比如交易级时间锁、输入数量这样的属性。
BIP-118 SIGHASH_ANYPREVOUT（APO）。使用该签名模式可以生成一种签名，该签名不承诺要花费哪一个 UTXO，因此，所有使用相同公钥的输入（交易），都可以使用这样的签名。因此，如果我们有一串交易，每一个交易所用的输入都具有相同的脚本，并将资金转移到相同的脚本输出内，那么，对这串交易中的任何一个交易的 APO 签名，也将可以用于所有其它交易。
此外，本文还会涉及的技术概念有：
下面，我们先通过一些外围的概念，以逐步接近我们想要探讨的概念。
闪电通道
没错，闪电通道也是一种形式的 “多人共享的 UTXO”，它是一个 2-of-2 的多签名输出，一般来说参与者有两个人。在闪电通道中，双方通过签名新的承诺交易来表达新的通道内状态，从而实现支付。而为了确保较旧的承诺交易不会被发到链上，承诺交易的一个输出中带有精心设置的脚本；当某一方将较旧的承诺交易发到链上，该交易为 TA 分配的资金会被对方全部拿走。这种惩罚机制（叫做 “LN-Penalty”）阻止了通道的参与者将旧状态发布到链上。
承诺交易和 LN-Penalty 保证了通道的免信任性：任何一方都可以随时以通道的最新状态退出通道。当某一方强制关闭通道时，另一方的资金会退出到链上，不会有损失。
在这里，CTV 能够提供的提升是非常有限的。CTV 可以用来预先承诺交易，但对通道来说，双方会不断更新状态。CTV 并不能提供超过 LN-Penalty 和承诺交易的保护作用，也不能简化它们 —— LN-Penalty 已经很紧凑了。
不过，APO 倒是能提供明显的提升。如前所述，APO 让用户可以只保留最新的承诺交易和签名，而无需保留旧的承诺交易和签名，这大大节约了硬盘，也让通道用户的交互以及交易的输出都变得更加简单。值得一提的是，更新状态依然需要双方都在线、签名。
（联盟）侧链
侧链也是一种 “多人共享的 UTXO”。在当前的比特币上，包括 Liquid Network 和 RSK 在内的双向侧链都使用了多签名输出（例如，11-of-15 的联盟）来保管资金。这样的输出保管的是不止一个用户的钱。当用户要进入侧链时，就要把资金存入这样的多签名输出；在这些输出被合并之前，用户有专属于自己的输出，但在资金合并之后，一个输出就将掌控许多个用户的钱。当用户要退出侧链时，也需要从这样的输出中取出资金 —— 这需要联盟成员的帮助才可以做到。
没错，在这里，侧链是一种需要信任的结构。用户需要信任这 15 个成员中不会有 11 个人串通起来盗走资金，也不会有 6 个以上的人串谋让侧链停机。而用户获得的好处是，他们可以在侧链上更新状态而无需支付主链的手续费；同时，侧链可以提供主链所没有的功能。那么侧链内部如何更新状态呢？在联盟成员间运行一套共识算法，以得出各个用户的最新状态。
也许，正是侧链这种需要信任的属性，推动人们思考有无更好的形式，比如，一种免信任的结构，让每一个用户都能不需要他人配合就能随时取款。
Fedimint
Fedimint 跟联盟侧链一样，也使用多签名输出来托管资金。有区别的地方在于，它并不使用共识算法来更新 Fedimint 内部的状态，它使用的是联盟成员的盲签名 —— 用户存入资金之后，就可以获得联盟签发的盲签名票据，这些票据允许用户们相互支付，也可以用来兑现主网的资金。但是，fedimint 依然是一种需要信任的结构。
下面我们进入一种追求免信任性的 “多人共享 UTXO” 构造。
Payment Pool / 拥堵控制
Payment Pool（“支付池”）所追求的 [3]，正是让多人共享的 UTXO 变成免信任的：最起码，这意味着，在这样的 UTXO 中的人，知道自己一定能够无需他人的协助就从中取出属于自己的资金。
我们先看看承诺交易如何做到这一点。假设 Alice、Bob 和 Carol 三人要将资金汇成同一个 UTXO，这个 UTXO 是一个 3-of-3 的多签名输出，以 “UXTO #1” 标记；承诺交易记为 CT，其作用是让某个用户的资金退出。
如上所示，只需在建立 UTXO #1 之前，签名 6 笔承诺交易，我们就能保证它的免信任性。不论 Alice、Bob、Carol 哪一个先取出资金，承诺交易的存在都让他们一定能取出资金。这个特性，也被 [3] 的作者归结为 “非交互式任意顺序取款” —— 不论之前发生了什么事，支付池中的用户都应能够无需他人协助就取出资金。（换言之：在任意状态下任意用户取款所造成的状态转换，都被考虑进去了。）
那么，限制条款可以提供哪些帮助呢？它可以减少签名的数量。在上面这个例子中， CT #A/#B/#C 都需要所有三位参与者的签名；CT #BC 这样的交易需要 Bob 和 Carol 的签名。假如我们有 CTV，我们就可以给 UTXO #1 增加三条 CTV 花费路径：这三条花费路径分别承诺了 CT #A/#B/#C，但是，它们分别只需要得到 Alice、Bob、Carol 的签名，就可以生效。在这里，无论哪一个人，都无法任意花费 UTXO #1；但是，每一个人想要拿走属于自己的资金时，都不再要其他人的签名。因为 CTV 的特性，对每一位参与者来说，它所允许的状态转换都是可以验证的。而使用了 CTV 之后，需要签名的数量就减少了。实际上，它也简化了交互的流程：参与者们只需传输这些承诺交易，而无需实际签名！当参与者数量增加时，这种带宽、交互复杂度和存储空间的节约，是非常明显的。
实际上，这种支付池模型，跟 CTV 提出者 Jeremy Rubin 所提出的 “拥堵控制” 应用 [4] ，是一模一样的：当用户需要从托管式交易所取款时，交易所不需要为 n 个取款用户生成 n 个输出，只需形成 1 个输出，并在这个输出中使用 n 个 CTV 花费条件，将每一位用户的取款额度（或者说取款交易）都承诺进去。在手续费高涨的时期，这可以节约大量手续费；每一个用户都可以在手续费率回落到自己愿意接受的水平时从中取出资金。
在这里，我们似乎是证明了，支付池这个概念，是有可能成立的 —— 多人共有的 UTXO 可以是免信任的。但是，我们尚未证明它是有用的 —— 我们尚未搞清楚，它使用起来是否便利；为了获得这些便利，有哪些条件。
按上述描述，稍加思考就会立即发现一个难题：上述承诺交易（以及 CTV 锁）都预设了一次只有一位用户取款；换言之，用户是排着队退出的；如果同时有多位用户希望退出，那该怎么办？
状态争用（race condition）
上述问题有一个专门的术语：“状态争用”：当多位用户共同享有一个状态，他们就有可能因为都希望更改状态而产生冲突。这种情况在比特币世界里，还算是新鲜事。
一种简单但很可能无用的解决方案是：因为交易池输出本身带有 n-of-n 多签名花费路径，所以，可以由这 n 位用户一同签名一笔交易，让某几位用户同时退出。但是，这种方案意味着，要解决这里的状态争用问题，n 位用户必须同时在线 —— 这是一个完全不现实的条件。
幸运的是，如果我们有 CTV，它又可以派上用场：可以预先为每一种 m 位用户（1 < m < n）同时退出资金池的交易安排一个 CTV 花费条件，并且只需要涉及其中的用户的签名，就可以花费这样的分支。例如，在一个 5 位用户的支付池中，为 Bob 和 Carol 同时退出的交易安排一个 CTV 花费条件，并且只需要提供 Bob 和 Carol 的签名（无需其他人的签名）就可以使用这个花费条件。—— 其实，它只是上一章的 CTV 用法的延伸。
在这里，CTV 算是比较好地解决了这个用户退出时候的状态争用问题。但是，它依然预设了：同时希望退出支付池的用户有办法联络到彼此，否则他们就不能一起签名从而使用这个更经济的分支，只能排队。
又或者，如果有一种技术，能够让花费同一个输入但形成不同输出的交易在交易池中非交互式地聚合，即，当 Bob 发起退出支付池的交易后，观察交易池的 Carol 能够直接使用 Bob 的签名、将 Bob 的交易 “升级” 成 Bob 与 Carol 一起退出的交易，那就无需要求用户知晓彼此的即时通讯方式。
下面，我们要继续探讨支付池的有用性。
状态更新
显然，如果支付池仅仅是用户资金的中转站，资金放在里面只是等待退出，其有用性是值得怀疑的。那么，支付池必须便利地实现下述功能：
实际上，所有三者功能的实现，都需要更新支付池的内部状态 —— 用户们在支付池内的余额改变了。然而，对一个支付池来说，当且仅当一组 CTV 交易与这样的状态相匹配，我们才能保留它的免信任性。因此，每当状态更新，我们都需要更新这组 CTV 交易。
但内部支付与加入支付池、外部支付有所区别的地方在于：后面两者一定要得到区块的确认，否则对接收资金的用户来说是不安全的（或者说，是需要信任的）。而前者则不必然。
在这里，我们将撞上 CTV 的局限性：CTV 只能确定性地预先承诺交易，但上述支付功能的支付对象、支付数额都是不确定的，我们不可能用 CTV 来承诺这不可计数的可能性（即使技术上可以做得到，通信开销也会令人望而却步，并让交易池变成完全不实用的东西）。
因此，不论是资金加入支付池还是离开支付池，我们都必须要求支付池的所有用户在线，通过 n-of-n 多签名路径花费支付池输出、形成新的支付池。这是支付池的重大局限 —— 它要求所有用户在线。实际上，[3] 的作者们对此心知肚明，他们说：
如果说资金离开支付池并不绝对需要所有参与者在线 —— 想要退出的用户可以先退出到自己的地址，再支付给他人，这样做需要支付更多手续费，并且需要等待更多的区块确认，但并不是完全不能做到；优化这个过程的一个办法是用户在 CTV 退出交易中使用带有复杂结构的地址，例如 “Swap in potentiam” 构造，进入这样的输出的资金可以立即置换成闪电通道内的资金并发起闪电支付 —— 的话，资金进入支付池就必须让所有人都在线了：如果进入操作得不到区块确认，接收者的资金就不安全；但要发起这样的操作，又必须得到所有人的签名，没有别的办法。
但是，这里还剩下一个拥有设计空间的东西：内部支付（状态更新）。因为三种功能都离不开状态更新，所以，它才是核心。假设我们有一个状态更新协议，就可以在它之上附加跟底层链的互动，从而实现资金进入和离开支付池的功能。
如果我们没有限制条款，我们就只能依赖于承诺交易，并且需要在支付池内实现一个类似于 “LN-Penalty” 的东西。但如果我们有 APO，事情就简单很多了。我们可以为支付池实现一个 Eltoo 协议：
当需要处理资金进出支付池的操作时，我们就让状态更新交易携带额外的输入或输出，而结算交易的输出就可以表示新状态。在这里，我们需要使用 “通道拼接 [6]” 这样的技术，来保证资金进入和退出支付池的同时，支付池可以保持内部支付功能而不必中断 —— 就像通道拼接让一条闪电通道无需中断运行就可以注入或抽出资金一样。
在这里，我们得到了一种支付池的状态变更协议，但是，它依然要求所有参与者都在线。能够无需所有参与者在线吗？这个问题实际上是问：是否存在一种无需所有参与者在场，但依然能保证内部支付安全性的协议？
答案是不存在。除非所有人都在线，否则无法杜绝重复花费 —— 当我在池内得到一笔支付时，我怎么知道这笔钱没有支付给其他人呢？只有通过要求每一个人都签名，来确保一笔钱不会支付给两个人。
一种放松在线要求的办法是使用支付池内的资金形成闪电通道。比如，Alice 和 Bob 在一次支付池状态更新中形成一条闪电通道，那么，他们在通道内相互支付时，就无需他人在场。但是，当这个通道要关闭、双方的资金要回到支付池中时，依然需要所有参与者在场。
通道工厂/批量通道
通道工厂/批量通道 [7] 可以认为是上述思想的延伸。假定一个支付池有 10 位用户，但 CTV 交易承诺的是他们之间的一对一通道，而不是个人的单签名输出，那么这就成了一个通道工厂。
在通道工厂中，每两位用户之间都有一条通道，因此，任意两位用户之间都可以直接支付而无需得到其他参与者的确认，这样就最小化了参与者的在线要求。它的不便在于，给定用户的资金数量，这样做会使用户的资金更加分散、降低其支付能力；此外，通道无法摆脱 “入账容量” 和 “出账容量” 的概念，一名用户接收支付的能力将受制于自己的入账容量总量，一旦支付额超过了这个入账容量，支付就要失败。而如果要调整通道的大小，则又必须让所有参与者在场，以完成整个通道工厂的状态更新。
CTV 的提出者 Jeremy Rubin 将批量通道当成 CTV 的一个应用场景。但是，我们已经看到了，如果不使用 APO，通道工厂的状态更新就必须得到区块的确认（或者需要使用承诺交易以及一套类似于 “LN-Penalty” 的东西）。
除此之外，资金 进入/定制化退出 通道工厂的要求，跟上述支付池构造的要求是一样的。
结论
本文中，我们研究了一种免信任的 “多人共享的 UTXO” —— 支付池：它是如何得到实现的；为了执行其功能，它对用户提出了哪些要求。与此同时，我们也探究了当前被讨论最多的两种限制条款（CTV 和 APO）分别可以为支付池的构造提供哪些帮助，以及它们各自的特点。我认为，结论是明确的：
在本文的开头，我们将 “侧链” 也作为 “多人共享的 UTXO” 的例子。这绝不是一种偶然，在我看来，探讨支付池概念的限制条款研究者，就像在使用限制条款开发一种免信任的侧链一样。 而缺乏共识算法来解决重复花费问题的支付池，就只能要求所有用户都在线。这可能会成为支付池的可扩展性的瓶颈。
需要指出的是，支付池概念的提出者 [3] 并非不知道这样的局限性（毕竟，在当时，对限制条款的理解可能更少），他们曾指出：
但他们同时也认为：
我的意见是，经过限制条款优化的支付池应该可以突破上述的 “10”，但究竟能够达到什么样的效果，则需要进一步的基准测试。
在闪电通道中，一位用户只有一个对手方，这意味着如果需要更新状态，他们的交互负担会比较小；同时，跟主链交互（进入和退出）的需要也会少一些。但是，在支付池中，如果我们有 10 个用户，他们跟主链交互的需要可能会成倍增加，而只要一位用户离线，状态更新的流程就会卡住。当然，可以通过承诺 CTV 交易，将离线的用户逐出交易池，但是，这依然是一种糟糕的用户体验。
支付池概念的作者们认为，支付池可以强化用户的隐私性。这当然是对的。但假如用户是从自己的单签名地址加入一个支付池的，则只有在这个支付池发生足够多的内部更新之后，这种隐私性得益才是真实的。
To Be Build
请求评论
请检查我在这里是否有推理上的错误、设计上不完整之处以及事实错误。
[1] https://www.btcstudy.org/2022/09/19/covenants-ctv-bitcoin-custody/
[2] https://www.btcstudy.org/2022/01/27/breaking-down-the-bitcoin-lightning-network-eltoo/
[3] https://www.btcstudy.org/2022/06/15/coinpool-exploring-generic-payment-pools-for-fun-and-privacy/
[4] https://utxos.org/uses/scaling/
[5] https://www.btcstudy.org/2023/03/06/swap-in-potentiam-moving-onchain-funds-instantly-to-lightning/
[6] https://bitcoinops.org/en/topics/splicing/
[7] https://utxos.org/uses/batch-channels/
[8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021694.html
[9] https://www.btcstudy.org/2022/10/11/spookchains-drivechain-analog-with-trusted-setup-and-apo/
Beta Was this translation helpful? Give feedback.
All reactions