作者：ademan

来源：https://delvingbitcoin.org/t/ctv-only-vault-concept-v0-1-0-release/2539

我很高兴能够宣布，MCCV —— 我的 “更复杂的 CTV保险柜” 概念 —— 的第一个版本发布；它是使用 BIP-119 OP_CHECKTEMPLATEVERIFY（OP_CTV）开发出来的。MCCV 证明了，一个功能非常全面的保险柜合约可以仅使用 OP_CHECKTEMPLATEVERIFY 就构造出来，无需依赖于更有表达能力的限制条款（covenant）操作码。虽然最终的设计有很大的计算负担，也不是很便利，但它成功提供了存入、延迟取款、复原、 取款速度控制以及重复的保险柜操作这些特性。

概要地说，资金从一个普通钱包以预先定义的增量存入保险柜；取款也是按预先定义的增量来取款，并且其所面临的时间锁会随着取款数量的增加而延长。这种相对时间锁提供了一种挑战窗口，在此期间，待完成的取款操作和保险柜中剩余的资金可以被清扫到一个复原密钥；复原密钥可以使用更安全的保管装置。

因为时间锁会随着取款数量的增加而线性延长，这种保险柜合约提供了由共识机制来强制执行的取款速度限制，可以减少潜在损失。

概述

注：这是实验性的概念验证软件，只应用在 signet（或 regtest）等测试网上。

当前的实现是一款可用的命令行界面软件，属于概念验证，是用 Rust 语言编写的，依赖于 BDK 和 rust-bitcoin。它使用 Bitcoin Inquisition v29 运行在 regtest 和 signet 上；Bitcoin Inquisition 提供了对 OP_CHECKTEMPLATEVERIFY、TRUC（确认前拓扑受限的交易）和 “临时锚点” 的支持。

本实现支持：

特性

防止未经许可的取款

与所有的保险柜构造一样，从这种保险柜取出的款项会进入一段挑战窗口：在这段时间内，用户可以将取出的款项和保险柜中剩余的资金都清扫给一个复原密钥。

取款速度控制

这种保险柜不仅提供了在遭遇未经许可的访问时追回资金的办法，还添加了由共识机制来强制执行的取款速度限制。

多次操作

本协议支持在同一个保险柜上执行数量可观但有限的存款和取款次数。这使得这种保险柜设计比一次性的保险柜设计灵活得多。

备份

这种保险柜可以备份成一个一段非常小的、恒定大小的数据。

重大缺点

复杂性

这套协议可能生成多达几百万笔交易；它需要通过严格的代码质量检验和审计，才能达到基本的可信任度。而且，复杂性自身就是一种风险，让协议对它的目标使用场景 —— 大额资金 —— 变得不那么吸引。不过，只要有 冷存储密钥/复原密钥 逃生舱，就可以在一定程度上缓解这个最令人担心的风险。

计算繁重

计算负担会随着存款增量的粒度、允许同一时间 取款/存入 的增量的数量以及保险柜支持的操作总次数而增加。所有会改善用户体验的做法都会导致计算负担以及链内交易费用增加。

信任保险柜的生成程序

本方案的计算复杂性导致了需要建立信任的问题。生成保险柜的设备必须足够强大，能够枚举用户想要的操作，同时还得是能够信任得。当前，以实用的参数生成保险柜实例，需要与最新的商品个人电脑或移动设备性能相当的硬件，但这些系统都是难以信任的。离线的个人电脑最符合这个要求，但是离线的电脑自身已经能够在相当程度上满足用户的安全性要求，无需加入任何复杂的保险柜。STARKs 也许能够在硬件签名器内实用地验证保险柜，这我认为是未来工作的一个重要方向。

取款需要两步

因为每一个保险柜都是预先计算出来的，资金无法直接取出给收款方。相反，成熟的取款可以被热钱包花费，热钱包可以转发给收款方。这意味着，如果热钱包被攻陷了，那么成熟的取款也可能被盗走。这也意味着，授权一次取款时复杂的，因为资金的最终目的地并不包含在取款交易中。OP_VAULT 和 OP_CCV 都解决了这个问题（事实上，也会完全淘汰本设计。）

隐私性

严格的取款速度控制要求资金汇集到一个 UTXO 中。这是链上隐私性的重大牺牲。

手续费

这个缺点并不是这个协议内生的，而来自这个概念验证实现的设计：热密钥与热钱包密钥是相关的。因此，攻击者可以先吸干你的热钱包、阻止你为确认 追索/复原 交易而支付手续费。

这个问题可以通过确保瞭望塔使用另一个密钥、安排了专项资金为复原交易支付手续费来缓解，不论这个瞭望塔服务是由用户自己运行，还是由第三方运行。

协议概述

协议的详细说明还在编写中。

一个保险柜就是一个规模很大的 DAG（有向无环图），由预先计算的交易组成；这些交易之间的转换则用 OP_CHECKTEMPLATEVERIFY 来强制执行。保险柜被配置成具有下列参数：

  • scale：基本的取款和取款增量。对保险柜的每一次操作都是这个数量的聪的倍数。
  • delay：每多取出一份增量，需要额外等待的区块数量
  • max-withdrawal：可以一次性取出的最大数量
  • max-deposit：可以一次性存入的最大数量
  • max-depth：保险柜可以支持的操作数量（DAG 的深度）

这些参数控制着安全性、便利性和预计算成本之间的取舍。

历史

本保险柜项目始于一项实验：仅使用 CTV，有多大可能做出便于使用的保险柜。人们普遍认为，单靠 CTV 不足以构造出理想的响应式保险柜（reactive valut），但 CTV 确实能够开发出预先计算的状态机。这些构造可以带来多种多样的链内合约，唯一的限制因素在于预先计算。在纯粹理论意义上，CTV 加上 taproot 可以表达极端复杂但最终可以枚举的交易转换图，但只有通过穷举每一种可能的状态和状态转换才能实现。而在现实中，只要参数集合超过严格约束的大小，这在计算上就变得不可行。

我的发现是，这种方案对于不多的参数，是实用的，只是预先计算的速度会随着参数集的扩大而迅速破坏用户体验。缓存可以实现，为了缓解对后续运行的延迟也应该实现，但即便如此，保险柜的初始化计算也可能要耗费相当长时间。因此，“实质上无限制” 的保险柜，其参数远远高于任何实际可预测的用法，希望似乎破灭了。不过，接受一些实用性上的限制（可以明确告知用户），MCCV 提供了有用的功能。

比较

本方案不是第一种保险柜设计，也不是第一种利用了 OP_CHECKTEMPLATEVERIFY 的保险柜设计。不过，就我所知，这是第一种以这种方式结合 OP_CHECKTEMPLATEVERIFY 和 taproot 的公开的保险柜设计。

simple-ctv-vault

顾名思义，“简单 CTV 保险柜（simple-ctv-vault）“ 希望尽可能简单。它启发了我开发 MCCV，我希望知道更复杂的构造有多实用。简单 CTV 保险柜让一个 UTXO 可以要么取款到一个热地址（带有时延），要么清扫到一个冷地址。这依然是 MCCV 的基本原理，只不过简单 CTV 保险柜只支持一次性的存入和取款。

Bryan Bishop 的 “Bitcoin Vaults”

我真希望自己早一点知道 Bryan Bishop 的 “Bitcoin Vaults”。这种设计在概念上和方向上都类似于 MCCV 。与 MCCV 一样，它也将保险柜按价值切分成几份，叫做 “shard”。它支持受到约束的保险柜操作，要么用毁掉了私钥的预签名交易来强制执行，要么通过 OP_CHECKTEMPLATEVERIFY 来执行，只不过它是在 taproot 激活之前设计出来的。没有 taproot，增加花费路径的数量就需要（为花费交易）使用提及更大的 witnessScript（见证脚本）。Bryan 谨慎地挑选了花费路径，使得保险柜可以：将资金推送到冷存储；将保险柜分割成许多份；剥离其中一份，剩余的则仍留在保险柜中。这最后一项跟 MCCV 的特性尤其相似。我现在的直觉是，taproot 高效表示替代性花费条件的能力，有力的削弱了将保险柜分割成许多份的需要。使用 MCCV，用户可以取出足够多的增量来满足自己的需要，而留存的保险柜会保护剩下的余额。Taproot 的效率也让 MCCV 可以让存款进入已有的保险柜，这在 Bryan 的协议中是做不到的，虽然这是以预先计算许多状态为代价的。虽然 MCCV 协议设计是在我知晓 Bryan 的工作之前确定的，一些相似的设计元素，比如将保险柜分割成许多份，以及在取款过程中剥离数量，使我感觉如遇知音。

OP_VAULT 和 OP_CHECKCONTRACTVERIFY 设计

希望不要引起任何跟限制条款操作码有关的争议，我只是想指出，这些操作码很大程度上会取代我的设计。使用这些操作码，就可以避免所有让本保险柜设计显得可怕的预先计算。而且，它们还允许单步取款，也就是收款方可以在取款交易中指定，这可以协助由瞭望塔执行的透彻授权，并且让收款方可以直接领取自己的资金（虽然收款方将需要额外的信息来清扫这些输出）。话说回来，我认为 OP_VAULT 和 OP_CHECKCONTRACTVERIFY 激活的可能性远远低于 OP_CHECKTEMPLATEVERIFY，因此值得探索一种仅使用 CTV 的设计。

请求反馈

如能提供对以下事项的反馈，我会非常感激：

  • 整体的协议设计
  • 这种设计与更简单的设计的取舍
  • 关于保险柜的整体思考
  • 用户体验：这 只是 一个概念验证项目，有一些已知的使用体验缺陷，但用户操作可能性皆已准备好测试。请参与用户指南。
  • 性能和预计算成本

结论

本方案有大量缺点，但依然在管理资金的安全性上提供了有趣的提升。它提供了可以等量齐观的用户体验，而无需依赖于 OP_VAULT 和 OP_CCV，尤其是如果我们能在下述方向上做出改进的话。

未来的工作

许多其他工作同样吸引我的注意力，所以这不是在承诺近期内就会投身于这些方面。不过，其中有一些，我认为是非常有趣的，值得尽快开始探索。

潜在的未来工作包括：

  • 瞭望塔软件：瞭望塔所需的所有特性在本命令行界面工具中皆已齐备，但尚未集成为一个有用的自动化特性。
  • 委托复原：通过仅委托发起复原操作的能力，允许 准-受信任的 瞭望塔保险柜。
  • 缓存保险柜计算：在保险柜初始化生产后，显著提升软件的响应性。
  • CPU 优化：多种多样的优化，其中许多是容易摘到的果实。
  • 通用化：适配软件堆栈以支持其它 CTV 状态机协议。
  • GPU 加速：这种保险柜的并行友好设计也让它适合使用 GPU 来加速。
  • 有望为硬件签名器实现基于 STARK 的验证

STARK 验证的想法是非常有趣的。它将允许强大的消费者硬件来生成保险柜及其形式正确性的证据，而更安全的硬件签名器将使用紧凑的证据来验证形式正确性。

（完）