CTV 和 CSFS 如何提升 BitVM 桥

<!--StartFragment-->

作者：Robin Linus

来源：<https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591>

引言

在 BitVM 中，我们使用承诺了输入的限制条款（input-commiting covenants）来表示状态，比如说，我们将 “如果没有人发起挑战，运营者就可以从桥接合约中取出资金” 这一状态表示为一个具体的输出，挑战者可以将它烧掉，以表明他们认为运营者的取款需求是恶意的，从而迫使运营者进入挑战流程。相反，在皆大欢喜情形中，该输出能够 “幸存” 度过整个挑战期，然后运营者就可以用它来执行取款交易。

当前的 BitVM 桥接合约设计依赖于模拟的限制条款，以保证存款的安全性。这种承诺需要 1-of-n 诚实参与者假设，并且在实践中会引入多种不合人意的复杂性。一直到最近，我们都以为 CTV 是不足以替代承诺交易的，因为 CTV 被设计为仅承诺 输出，而不承诺 输入。然而，真相表明，有一个技巧可以启用我们所需的功能。

脚本签名技巧

关键的想法是利用这样一个事实：CTV 可以承诺所有输入的脚本签名。假设我们想要表达 “输入 A 仅与输入 B 一起才能花费”，我们可以这样做：

1. 定义输入 B 为一个（传统的） P2SH 脚本。
2. 预先使用 SINGLE|NONE 这个 sighash 标签生成一个签名，本质上是只签名了输入 B。这个签名仅仅承诺了输入 B，又因为 P2SH 并非隔离见证类型，所以这个签名将出现在输入 B 的 “脚本签名（scriptSig）” 字段中。
3. 定义输入 A 是一个 P2TR 输出，并包含着一个 CTV 条件，该 CTV 的模板哈希值承诺了未来一笔交易的（各输入的）脚本签名，也就包括了输入 B 的签名。

结果是：输入 A 承诺了输入 B 的签名，这个签名又承诺了输入 B 。所以输入 A 只有跟输入 B 一起才能花费。

细节

这样的承诺是单向的：输入 A 承诺了输入 B，但反之不成立。双向的承诺在理论上会更好，但因为哈希循环，是无法实现的（即使我们拥有 TXHASH 或其它内省操作码）。

对我们的桥接合约来说，只要能约束输入 B 总是被烧掉，就足够了。但这个用 CTV 也是无法实现的 —— 那样的话，模板哈希值将必须承诺自己的 脚本签名，而签名已经承诺了输入 B、它的 TXID —— 这样就产生了一个哈希循环。

为了解决这个问题，我们重新设计了交易图，使得即使输入 B 不跟输入 A 一起被花费，合约也依然是安全的。新设计的具体内容超出了本文的范围，因为需要你对桥接合约的架构有更加深入的了解。

具体的提升

• CTV 带来了无条件的存款安全性。即使所有的运营者都是恶意的，他们也无法从桥接合约中盗取资金。虽然我们依然依赖于一个根本上的活性假设来保证取款，简化后的启动程序让我们可以大大扩大运营者集合 —— 可能是一个数量级。所以至少一个运营者保持在线的假设就有更大概率为真了。
• CSFS 替代了 Lamport 签名，将交易的体积降低了大约 10 倍。这大大地降低了桥接合约运营者的资本开销。
• 非硬化的密钥派生随着 CSFS 的启用成为可能，让任何人都可以非交互地计算出运营者的公钥。这大大简化了资金锁入的流程，因为运营者需要提供的数据量减少了。
• 在当前的设计中，资金锁入依然需要一个运营者签名，这就带来了审查的可能。虽然这可以使用别的系统来缓解，我们的长期目标是通过改变桥接合约来指出完全的非交互式锁入，从而完全消除交互需要。

出于这些理由，BitVM 联盟强烈支持 CTV + CSFS 提议。

结论

上述技巧表明，灵活地使用 CTV 和 CSFS，我们就可以极大地简化 BitVM 桥接合约的构造，同时提高安全性和效率。通过移除对预签名承诺交易的需要、移除根本上的诚实参与者假设，CTV 让桥接合约可以获得无条件的安全保证。与此同时，CSFS 可以降低资本开销和操作复杂性，为更可扩展、更去中心化的桥接合约铺平道路。虽然还有一些开放性挑战 —— 比如让资金锁入编程完全非交互的操作 —— 新的设计代表着迈向信任最小化、实用的比特币互操作性的重大一步。

<!--EndFragment-->