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$ 步：
$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$
这样 $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$ 的某些具体实现，会尝试在：