BitVM 概述：将有效性证明引入比特币

2024.04.26

BitVM 是比特币生态系统中最新的热门协议，有潜力使每个在比特币上构建的项目受益。让我们谈谈 BitVM 的设计以及它为比特币开启的新可能。

“ 比特币第二季^[3] ”正在进行中，开发人员和用户都对在比特币上构建项目以及为解决在比特币上构建永恒挑战带来新用例和新方法感到兴奋。

比特币不具备可扩展性。由于区块空间有限，交易费用可能会在网络拥堵时大幅波动。每秒仅处理 7 笔交易，每个区块仅包含约 1MB 的数据，如果要让数十亿用户使用比特币，仅靠比特币是不够的。你需要扩展解决方案^[4] 。

在比特币 L2s^[5]（Layer2 区块链）方面已经做了大量工作，以提高比特币的可扩展性和引入新功能。如今有数十个在比特币上构建的项目^[6] ，其中最有前景的研究和创新领域之一是比特币 Rollups^[7]。在高层次上，比特币 Rollups 使交易可以在链下发生，然后“卷起”成单个状态更改提交到区块链，同时有一个密码学证明系统，以便参与者可以验证提交的状态更改是否准确。

然而，将这种证明系统引入比特币存在挑战，这就是 BitVM 的作用所在。

什么是 BitVM？

BitVM^[8]是一种协议/规则集，可以实现在比特币上进行欺诈证明，开发人员可以立即使用该协议，实现在比特币上的各种用例，包括比特币 Rollups、最小信任桥等。BitVM 的核心设计将计算移到链下，并在比特币区块链上实现了欺诈证明机制。

BitVM 可以在比特币上实现欺诈证明。

BitVM 白皮书于 2023 年 10 月由 Robin Linus 发布（值得注意的是，Robin 是 ZeroSync^[9] 团队的一员，该项目致力于为比特币开发零知识证明系统），开发人员在过去几个月开始对该协议进行实验，并且越来越感兴趣。

你可以将 BitVM 视为参与者事先同意遵循的分布式协议/规则集，而不是由软件实现的实际虚拟机（例如以太坊虚拟机）。类似于比特币 Ordinals^[10] 的工作方式，这里存在社会共识的组成部分，参与者选择加入规则，并且这些规则在协议层面上并未完全执行。

BitVM 如此令人兴奋的原因在于它为验证比特币上的任意电路提供了挑战-响应协议——你可以在链下提出声明（例如，此证明有效），并使用比特币 L1 来验证。其中“在比特币上”是关键的，因为在比特币上构建非常困难，如果实施，BitVM 协议可以用于构建乐观 Rollups、双向 BTC 锚定等，这些可以使其他在比特币上构建的项目受益。

BitVM 解决了什么问题？

任何在比特币上构建的项目都知道与链交互有多么困难（在 Hiro，我们亲身体会到了这种痛苦）。在比特币上构建的挑战之一是，比特币没有处理复杂计算的能力。

没有智能合约。没有虚拟机。可编程性仅限于开发人员可以通过操作码^[11] （操作码）构建的内容，而该功能是有限的。引入新的操作码需要 BIP 和比特币分叉（这是非常困难的）。

因此，在没有分叉和新操作码的情况下，我们只能使用有限的可编程性。在扩展比特币的情况下，这种限制主要体现在两个方面：

如果要构建双向 BTC 锚定，很难从方程中去除信任。大多数 BTC 锚定今天涉及托管方，无论是单一机构还是控制多签的联盟，以处理存款/提款。有时被描述为“写问题”。在 Stacks 生态系统中，即将推出的 Nakamoto 升级^[12]包括设计用于最小信任桥——稍后详细介绍。
如果要通过 Rollup 将计算或交易移到链下，很难在比特币本身上验证和验证链下数据。这是一个验证问题。

对于这两个问题，BitVM 可以通过在比特币 L1 上实现挑战/响应协议来解锁戏剧性的设计改进。

BitVM 如何工作？

将 BitVM 视为一种协议或一组规则是一个很好的方式。如果两个方在事先同意遵循这些规则（这意味着他们需要相互合作），则可以进行任意的挑战-响应游戏。理论上，这可以用于在比特币上验证/证明任意复杂的程序（这些程序的实际执行发生在链下）。

让我们举个具体的例子。

假设 Alice 和 Bob 想玩一个抛硬币游戏。两位玩家各自在奖池中放入 0.5 BTC。正面赢得 1 BTC。Alice 拿着硬币并将首先抛硬币。Bob 希望确保 Alice 不作弊。以下是他们如何使用 BitVM 玩这个游戏（为简单起见省略了许多细节）：

Alice 和 Bob 同意遵循 BitVM 协议。
假设正面由值 H0 表示，反面由值 H1 表示。Alice 通过选择两个其他值，比如 P0 和 P1，并对它们进行哈希，生成了 H0 和 H1。因此，Hash(P0) = H0 和 Hash(P1) = H1。P0 称为 H0 的“原像”，P1 称为 H1 的原像。
Alice 与 Bob 分享值 H0 和 H1（实际上，Alice 不可撤销地“承诺”这些哈希值，因此她不能后来声称有不同的值）。Bob 不知道原像 P0 和 P1（并且“猜测”这些值是非常困难的，因此我们可以安全地假设 Bob 不会神奇地发现这些值）。
Alice 和 Bob 预先签署两笔交易：一笔用于挑战，另一笔用于响应。

在挑战交易中，Bob 将包含一个脚本，该脚本基本上检查提供的输入是否哈希为已知哈希值 H0 或 H1 之一——如果哈希为 H0，则 Bob 知道该值是正面；如果是 H1，则是反面。此外，脚本具有一个时间锁，如果在截止日期前未收到响应，则 Bob 获得奖池。
在响应交易中，Alice 可以通过包含相应的原像 P0 或 P1 来“揭示”抛硬币结果。如果 Alice 未包含任何值、包含两个值或包含除 P0 或 P1 之外的任何值，则 Bob 获得奖池。否则，如果值为 P0（正面），Alice 获得奖池。

现在我们准备开始游戏。Alice 抛硬币但尚未揭示结果。Bob 发出挑战交易，随后 Alice 广播响应交易。通过前面描述的脚本，在链上执行“欺诈检测”的逻辑。显然，这是一个琐碎且刻意设计的例子，但它展示了关键思想。对于一个稍微复杂的例子，考虑由一位名为 Super Testnet 的开发者设计的井字棋游戏。你可以在这里查看 GitHub 存储库^[13] ，甚至今天可以玩“bit tac toe^[14]”。Super Testnet 实际上向 Hiro 展示了这个游戏，你可以在下面观看：

Bitvm Crash Course on Youtube ^[15]

以下是游戏的高级组件：

井字棋是一个 9 宫格。第一位玩家 Alice 最多可以走 5 步，因此有 45 个预影像和哈希（每轮 9 个）。第二位玩家 Bob 最多可以走 4 步，因此有 36 个哈希。

井字棋有 3 种“作弊”方式：玩家可以在他们的回合放置多个 X / O；玩家可以覆盖他们先前使用过的方格；玩家可以覆盖对手先前使用过的方格。因此，挑战/响应协议围绕检测这些情况构建。

挑战交易将迫使另一位玩家“揭示”他们在哪个方格放置了 X 或 O。

响应交易将具有一个脚本，该脚本将针对上述所有 3 种情况进行检查：如果未检测到欺诈，则游戏继续（或游戏结束，因为有人获胜）。如果检测到欺诈，则挑战者获胜，证明者失败。

请注意，在这两种情况下，欺诈证明是手工制作的，并专门为该用例设计：井字棋的欺诈证明对于抛硬币或其他任何事情都不起作用。

回到大局，BitVM 白皮书描述了一种通用方法：针对任何程序，它提供了构建该程序的有效性证明的一种方式。关键见解如下：

从抛硬币的例子中，我们看到了如何验证单个比特：让我们称之为“比特承诺”证明。

有了比特承诺，我们可以构建逻辑门承诺：考虑布尔 AND / OR 运算符 - 针对任何两个输入（每个取值为 0 或 1），该运算符定义一个单一输出。因此，使用 2 个比特承诺作为输入和 1 个比特承诺作为输出，我们可以为任何逻辑门创建有效性证明。BitVM 白皮书使用了一个 NAND 逻辑门。

最后，任何任意计算都可以使用一系列逻辑门来表示。BitVM 白皮书将其称为“二进制电路”。这样的电路可以使用 Tapscript 有效地表示，每个 tap 树中的叶子代表一个单一的门承诺。

然后，挑战/响应协议基本上涉及验证特定门承诺的输出。在最坏的情况下，你可能需要验证每个单个门的输出。

查看这个存储库^[16] ，了解将任意程序转换为 tapleaf 电路的一种方法。

Stacks 如何适应？

BitVM 在 Stacks 生态系统中的两个明显且最相关的应用是：

改善 sBTC 的信任假设
为比特币上的 Stacks 块添加有效性证明

为什么选择这两个应用？当前的 sBTC 设计^[17]已经是正在开发中的比特币最安全、最小化信任的双向锚定之一。尽管如此，在安全模型和信任假设^[18]方面仍有改进的空间。与要求至少 30%诚实签名者或信任一组高声誉签名者不同，基于 BitVM 的方法理论上可以使 sBTC 只需一个诚实参与者即可运行。

同样，虽然每个 Stacks 块在比特币上结算，但当前设计仅允许你在拥有链状态的一份副本时独立验证 Stacks 数据。如果使用 BitVM，Stacks 块还包括有效性证明，那么你不仅可以检查完整性（给定 Stacks 块中的数据与存储在比特币上的哈希一致），还可以检查正确性（你可以通过查看存储在比特币上的证明验证给定 Stacks 块中的交易是否实际执行正确）。换句话说：这将使 Stacks 能够发展成为比特币上的乐观 Rollup。

如何利用 BitVM 实现这些应用的具体方法需要进行更多的研究和开发。但我们可以尝试在高层次上勾勒出一些想法。

BitVM 与 sBTC

考虑 sBTC 的例子：锚定进程非常简单，只需广播比特币交易即可完成。然而，在当前设计中，锚定退出过程依赖于签名者来处理请求（在 Stacks 上）。这带来了一些约束：

退出可能需要时间，这取决于有多少签名者离线/诚实。

你需要信任这个签名者网络，更广泛地信任整个 Stacks。

如果改为（或可能还要）在比特币上生成一个有效性证明并使用 BitVM^[19]，那么：

退出可以进行乐观处理（因此，在快乐路径上，可以更快地处理）。

该锚只需要一个诚实参与者即可运行；你不需要信任签名者网络的 30%。

关键是确切地找出如何构建有效性证明。BitVM 白皮书中描述的蛮力方法可以奏效，但可能会导致一个非常庞大的 tapleaf 电路（数十亿个节点）。这反过来意味着任何挑战都将需要很长时间（可能需要数周或更长时间），更不用说在注意力和资源（交易费用！）方面的成本。正如我们在井字棋的例子中看到的，可以构建更简洁的证明，专为特定用例定制，类似的方法可能对这种情况更有效。

BitVM 与 Stacks

至于整个 Stacks 块的有效性证明，有很多值得探索的设计空间。例如，证明是以单个交易的粒度还是整个块的粒度还是介于两者之间（比如构成因果依赖链的交易）？是否可能采取渐进式方法，比如首先为简单的代币转账生成证明，然后逐渐添加 Clarity 合约？这是否是比特币区块空间的良好利用，因为 Stacks 矿工和网络参与者已经有经济激励来维护 Stacks 链状态的完整历史？