作者：Robin Linus
来源：https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
摘要： CTV 通过消除对一笔预签名承诺交易和根本上基于诚实参与者的安全假设，提升了 BitVM 桥。此外，CSFS 极大地提升了资本效率并降低了启动负担。
引言
在 BitVM 中，我们使用承诺了输入的限制条款（input-commiting covenants）来表示状态，比如说，我们将 “如果没有人发起挑战，运营者就可以从桥接合约中取出资金” 这一状态表示为一个具体的输出，挑战者可以将它烧掉，以表明他们认为运营者的取款需求是恶意的，从而迫使运营者进入挑战流程。相反，在皆大欢喜情形中，该输出能够 “幸存” 度过整个挑战期，然后运营者就可以用它来执行取款交易。
当前的 BitVM 桥接合约设计依赖于模拟的限制条款，以保证存款的安全性。这种承诺需要 1-of-n 诚实参与者假设，并且在实践中会引入多种不合人意的复杂性。一直到最近，我们都以为 CTV 是不足以替代承诺交易的，因为 CTV 被设计为仅承诺 输出，而不承诺 输入。然而，真相表明，有一个技巧可以启用我们所需的功能。
脚本签名技巧
关键的想法是利用这样一个事实：CTV 可以承诺所有输入的脚本签名。假设我们想要表达 “输入 A 仅与输入 B 一起才能花费”，我们可以这样做：
- 定义输入 B 为一个（传统的） P2SH 脚本。
- 预先使用
SINGLE|NONE这个 sighash 标签生成一个签名，本质上是只签名了输入 B。这个签名仅仅承诺了输入 B，又因为 P2SH 并非隔离见证类型，所以这个签名将出现在输入 B 的 “脚本签名（scriptSig）” 字段中。 - 定义输入 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 可以降低资本开销和操作复杂性，为更可扩展、更去中心化的桥接合约铺平道路。虽然还有一些开放性挑战 —— 比如让资金锁入编程完全非交互的操作 —— 新的设计代表着迈向信任最小化、实用的比特币互操作性的重大一步。
Robin Linus2025-04-14
https://www.btcstudy.org/2025/04/14/how-ctv-csfs-improves-bitvm-bridges/