BitVM2：比特币上的无需许可验证

1. 引言

前序博客有：

• 基于BitVM的乐观 BTC bridge
• BitVM：Bitcoin的链下合约
• Bitcoin Bridge：治愈还是诅咒？

最初的 BitVM 设计仅限于两方设置。BitVM2结合了并行和冗余实例，以引入基于 1-of-n 诚实假设的多方配置。这些合约的主要限制是：

• 所有Verifiers都必须在编译时定义。
• 此外，设置成本随着Verifiers数量的增加而增加。

这意味着：

• 要破坏合约，必须贿赂的当事人数量总是有限的。

BitVM2 是一种新颖的变体，任何人都可以充当Verifier：

• 仍需要使用 1-of-n 诚实假设进行一次性设置，但在运行时任何人都可以挑战无效的断言，而不必成为初始 n个联盟成员之一。
  • 这克服了以前方案的局限性并改进了它们的信任假设。
  • 此外，简化了整体设计，并将trial的最大长度减少到两轮。

bridge还额外需：

• 预定义的m个operator，且至少其中一个operator必须诚实行事。然而，即使所有operators都不诚实，他们也无法窃取任何存款，最坏的情况只是烧掉它们——即浪费资金，变得不可用。

BitVM针对的问题为：

• 对于给定的程序$f$，想要验证对于某输入$x$和输出$y$，断言$f(x)=y$是否成立。如，$f$可以是某SNARK Verifier，如用于 Groth16 证明系统。然后：
  • $x$将是一个proof，且$y$是 SNARK 证明其有效性的某种输出状态。

若$f$是 SNARK Verifier，则程序太大，无法用单个比特币脚本来表示。实现 Groth16 Verifier可能会产生 20MB 的脚本。然而，最大脚本size是比特币区块大小 4MB。即使这样的size也可能大得不切实际。

2. 简单的解决方案

Lamport 签名提供了一种将程序拆分$f(x)=y$为多个步骤的方法。如$n=42$步：
$$\begin{gathered} f_1(x)=z_1 \\ {f}_2(z_1)=z_2 \\ {f}_3(z_2)=z_3 \\ ... \\ {f}_{42}(z_{41})=z_{42} \\ {f}_{43}(z_{42})=y \end{gathered}$$
这样$f$的计算可分散在多个区块上执行的 43 笔交易序列上。每笔交易将前一笔交易的输出状态作为输入状态。若Prover对任何状态$z_i$模棱两可，那么每个人都可以使用冲突的 Lamport 签名作为fraud proof欺诈证明。

这种方法提供了一种无需许可的方式来挑战Prover。然而，该解决方案的主要限制是：

• 其沉重的链上足迹，因为它仍然需要Prover来执行整个计算。
• 还引入了通过 Lamport 签名转换状态的开销。

3. Balanced解决方案

通过将Prover的一些繁重工作转移到Verifier的fraud proof欺诈证明上，可显著减少链上足迹。现在Prover只需同时承诺$x$、$y$和所有中间结果$z_1,z_2,...,z_{42}$。

任何Verifier都可以反驳任何错误的断言。在设置过程中，定义了一个包含 43 个脚本的 Taptree，以反驳$f_1,f_2,f_3,...,f_{43}$的任何计算。若某断言$f_i(z_{i-1})==z_i$不成立，则任何人都可从这些脚本中的任何一个中花费。这将最坏情况的总计算，减少到，由Verifier执行的单个步骤$f_i$。该步骤可能仍然需要大量的脚本实现。理论上，只要它适合单个区块，或者更好的是 400kb（standardness size）。实际上，对于$f$的某些具体实现，会尝试在：

• Prover的commitment size
• 和 Verifier的script size

之间找到最佳平衡。

实际上，这允许任何人，在Prover做出任何不正确的断言时，破坏Prover的output。否则，如果没有人反驳计算的任何部分，那么脚本就会超时并让诚实的Prover花费output。总共最多也就两轮。

该机制可以充当permissionless bridge verifier的基石。

4. BitVM2：Permissionless Optimistic解决方案

以下协议改进了上述设计的happy path（希望是common path），但代价是在最坏的情况下引入了两轮交互：

• 1）Prover提交输出状态y
• 2）若不正确，任何人都可以发起挑战
• 3）Prover承诺中间结果$z_1,z_2,...,z_{42}$
• 4）若不正确，任何人都可反驳断言$f_i$

为此：

以上设计的主要问题在于，Prover可窃取一些fees费用。在这种情况下，存款仍然是安全的，但Verifier失去了其抵押品。

攻击场景如下：

• Prover是恶意的
• Prover在没有有效 PegOut_Tx 的情况下执行其 KickOff_Tx
• Prover等待Verifier执行Challenge_TX，支付Prover执行挑战
• Prover不执行挑战，只是停止响应

以下修改解决了费用问题。但需要另外两个 n-of-n 预签名交易：

经改进后的设计，要求：

• 至少有一个诚实的Operator

否则资金最终将变得不可用。实际上，活性失败可用于通过勒索攻击窃取资金。 （如，只有你向我支付 50% 的赎金，我才会解冻你的资金。）

参考资料

[1] 2024年3月 Robin Linus gist BitVM 2: Permissionless Verification on Bitcoin
[2] BitVM 2: Permissionless Verification on Bitcoin