将欺诈证明引入比特币，第二部分

将欺诈证明引入比特币，第二部分

BitVM 和 OP_CAT 结合欺诈证明

2025年2月16日

在上一篇文章中，我们一般性地讨论了欺诈证明，特别是乐观 rollups（如 Arbitrum 和 Optimism）以及乐观 zk 证明（如 Kailua）的工作原理，以及欺诈证明系统固有的不同权衡。

欺诈证明基本上是可以在执行计算之前被公开争议的计算（即，在 撤回期 之后）。为了使计算能够被公开争议，有两个关键要求：（1）高效的链上挑战，即计算可以在链上被争议，以及（2）数据可用性，公众可以获取足够的信息来争议计算。

欺诈证明有许多权衡。可以将计算切割成较小或较大的块，并且协议中可以有更多或更少的轮次。欺诈证明还允许修改。例如，由于撤回期，用户体验受到欺诈证明的影响。卫星解决方案如快速确认可以通过允许第三方促进经过验证的撤回，通常是小额款项，使用户体验得到改善。

尽管我们通常将乐观 rollup 和 zk rollup（即欺诈证明与有效性证明）分开，它们是可以结合在一起的两种技术，这对于我们今天的话题——在比特币上验证欺诈证明很重要。让我们先从 BitVM 开始。

BitVM

BitVM 是 Robin Linus 在 2023 年 12 月提出的一种创新设计。BitVM 的第一个版本完全使用欺诈证明，根本没有使用 zk 证明，使比特币具备可编程性。在高层次上，该程序被转换为布尔电路，在该电路中，信号以 1 和 0 的形式输入。该电路由布尔门构成，这些门接受两个输入线，并生成一个输出线。例如，NAND 门在两个输入线为 1 时输出 0，否则输出 1。可以有许多不同的布尔门。输入线通常是另一个门的输出线。任何程序都可以格式化为布尔电路。

在 BitVM 中，如果程序执行不正确，则挑战者可以找到至少一根错误的输出线。挑战者可以要求运营者揭示这根输出线的两个输入线。如果输出线不正确，那么至少有一个输入线必须是错误的，挑战者可以继续这样做，直到运营者最终（1）未按照协议回应或（2）在 0 和 1 上揭示相同的输入线（在一个门中当作 0，而在另一个门中当作 1），这将是一个矛盾。

当以上任一情况发生时，BitVM 可以削减运营者的责任，这就是其安全性的来源。当运营者违反协议时，运营者将失去“安全押金”。

• 如果运营者在某个时间窗口内未能根据协议做出回应（类似于撤回期），挑战者可以削减运营者，使运营者失去安全押金。

• 如果运营者在 0 和 1 上揭示相同的输入线，挑战者也可以相应地削减运营者。

BitVM 的创新在于如何在比特币脚本中实现这两个削减条件。

第一个削减条件是通过预签名交易（由运营者和挑战者生成并达成共识）以及比特币本机的 锁定时间 机制实现的。预签名交易强制运营者跟随挑战-回应的链，在此情况下，运营者在每个时刻唯一能做的就是“正确回应”挑战。如果运营者未能及时回应，预签名交易提供了一条“不愉快的”路径来削减运营者，挑战者可以在运营者“超时”未做响应时执行业务。

第二个削减条件是要求挑战者展示表示输入线的两个冲突的数字签名。在 BitVM 协议中，当运营者揭示某个输入线时，运营者还被要求生成该线标识符及其值的数字签名。如果运营者表现不当，挑战者可以看到两个签名，签名同一线标识符，但值不同。通过展示这两个签名，挑战者可以削减运营者的责任。

请注意，单靠削减不足以构成欺诈证明。正如我们在 第一部分 中提到的，欺诈证明与削减之间有一个微妙的区别：

• “欺诈证明不依赖于削减。如果计算是错误的，总有一种方法可以对其提出质疑并使其无效，这样错误的状态就永远不会在 L1 链上实现。”

• “削减协议依赖于削减。如果所有节点都不怕被削减（例如，有人贿赂他们不当行为并会补偿被削减），即使计算是错误的，它仍然可以被接受。”

这在 BitVM 的第一个版本中是一个问题，因为它只能实现削减，但不会成为欺诈证明协议。如果运营者管理数十亿美元，却只有几百万的安全押金，则运营者几乎是“被激励”去不当行为。虽然将安全押金设得很高是可能的，但这通常会带来与押金金额成比例的成本，因为运营者可能本可以利用这些资金在借贷协议（在 CEX 和 DEX）中赚取被动收入。

这种限制对于比特币脚本的可编程性来说是固有的（没有 OP_CAT）。因此，在 2024 年 8 月，发布了 BitVM 的新版本，称为 BitVM2，专注于一种特殊的用例，其中削减恰逢足以构成欺诈证明。

BitVM2 作为锁定和铸造桥

与专注于一般计算的 BitVM 第一个版本不同，BitVM2 专注于一种特定的用例——锁定和铸造跨链桥。虽然 BitVM2 仅支持特定类型的跨链桥似乎非常有限，但这恰恰是将比特币低信任化地桥接到其他链所缺失的基本部分。

今天，我们确实有一些跨链解决方案，它们将 BTC 桥接到以太坊和其他链，包括 wBTC (包装 BTC) 和 cbBTC (Coinbase BTC)，但它们大多数是基于托管的。例如，在 wBTC 中，要在另一个链上铸造 BTC，需要将比特币 BTC 发送到一个由 WBTC DAO 中的机构持有的多重签名钱包中。而 cbBTC 是一个由 Coinbase 支持的中心化解决方案。集中的方式有其优势，因为它们灵活且有时成本较低，通常具有良好的用户体验，但这并不是一个低信任化的解决方案。

缺乏信任最小化通常是稳定币脱钩的原因，因为在突发抛售期间，人们可能对保管人是否能够偿付其债务没有充分信心。有许多脱钩的例子，虽然大多数是暂时性的，例如在泰达币和 Circle 的情况，但某些稳定币则在脱钩后消失，例如 TerraUSD。Kraken 有一篇文章讨论了 稳定币脱钩的历史。

比特币上几乎没有发生过脱钩，但 wBTC 也曾在 2022 年 12 月 Alameda 和 FTX 破产时发生过 轻微的脱钩，那是暂时性的。

比特币最近的相关例子是 THORChain。它不是一个稳定币或封装的 BTC，而是一个借贷协议，用户可以用 BTC 作为抵押，并借出其他资产如 RUNE。然而，该借贷协议本身存在“死亡螺旋动态”问题，即当人们对 RUNE 失去信心并希望赎回 BTC 时，RUNE 的价格将持续下跌。尽管封装的 BTC 不是借贷协议，但我们可以从 THORChain 学到一个教训，即协议的设计应该如此，以便在“任何市场条件”下，可以按照 1:1 的比例赎回 BTC。

这就引出了 BitVM2 的核心动机——建立一个锁定和铸造的桥。假设我们有一个比特币和以太坊之间的桥。

• 要在以太坊铸造新的包装 BTC，Alice将 1 BTC 锁定在比特币中放入一个 BitVM2 程序中。可以公开验证此 BTC 是否已正确存入有效的 BitVM2 程序中。

• 要将以太坊中的包装 BTC 兑换回比特币中的原生 BTC，Bob将包装 BTC 发送到以太坊中的智能合约中，而该合约会“销毁”这一包装 BTC。然后，运营者找到一个合适的 BitVM2 程序，其中有一个锁定的 BTC。运营者在比特币网络上向Bob发送 1 个原生 BTC，然后执行业务，声称运营者已根据解锁协议正确地将原生 BTC 发送给用户。人们可以对此声明提出质疑。

• 如果声明未被质疑，运营者收到 1 个原生 BTC，这与运营者之前发送给Bob的 1 BTC 相等。如果声明被质疑并被证明不正确，运营者将无法收到 1 个原生 BTC，因为 BitVM2 程序未能确认运营者确实根据协议发送了一个 BTC。

在这种用例中，削减和欺诈证明是等效的，因为如果运营者行为不当，运营者将根本无法收到运营者之前预付给Bob的 1 BTC。

这种设计的一个优点是，尽管 BTC 最初是由Alice存入的，但它可以兑现给另一个用户，这里是Bob，只要跨链协议同意该取款是正确的（按照 BitVM2 程序中定义的逻辑）。这种灵活性可以实现，因为 BitVM2 程序运行的是通用的 ZKP 验证器。只要逻辑，即使非常复杂，也能够被准确编程成零知识证明，BitVM2 就可以验证它。

BitVM2 程序工作流

BitVM2 的详细交易流程由于一些优化和安全机制而变得复杂。但 BitVM2 白皮书也呈现了一个简化的工作流，如下所示，应该足以让我们理解其工作原理。

当Alice在比特币网络上存入 1 BTC 时，便开始了如上所示的存款交易。在验证存款已正确完成至 BitVM2 程序后，协议便可以在其他链上铸造新的包装 BTC（这可以通过跨链消息协议完成）。

BTC 可以在 BitVM2 程序中锁定很长时间，直到需要赎回。如上所述，Alice锁定的 BTC 可以根据规定的逻辑赎回给不同的用户，即Bob，因此运营者可以选择任何可用的锁定 BTC 进行解锁。

为了赎回，运营者首先将在比特币链上向Bob提供 1 BTC。然后，运营者生成一个零知识证明，可以通过 BitVM2 程序进行验证（即接受质疑）。如上图所示，该初始状态为 z_0。

运营者通过一个事务触发“请求付款”，包括上图所示的初始状态 z_0。在此时，任何在比特币链上的人都可以看到运营者目前正在请求付款（由于成功赎回 1 BTC 给Bob）。如果这正确，并且在整个挑战期间，没有人对这个证明提出质疑，它将到达右边的“付款”交易，其中锁定的 BTC 将给予运营者（之前已经向Bob提供了资本）。

然而，如果证明不正确，可以通过发送“挑战”交易提出质疑，其中运营者需要通过“确认”交易揭示中间计算结果。“确认”交易中的信息需要满足生成欺诈证明的数据可用性需求。如果挑战者发现错误，挑战者可以驳斥计算。如果在挑战期内没有人对计算提出异议，运营者可以继续赎回 1 BTC。如果在挑战窗口内没有提出“驳斥”交易，运营者可以继续进行“付款”交易。

BitVM2 的核心机制是驳斥错误的计算。这里，与包装和解锁相关的计算涉及两个链的最新状态，本质上是运行两个轻客户端。

首先，BitVM2 程序运行一个比特币轻客户端。它需要验证运营者是否已正确将 1 BTC 发送给Bob（且此交易对应于此取款，不是先前的取款）在比特币区块链上。为了做到这一点，BitVM2 程序不仅需要检查向Bob转账的具体交易，还需要验证该交易是否在实际的比特币链上，而不是侧链或分叉上。

其次，BitVM2 程序还需要运行一个轻客户端来验证铸造包装 BTC 的其他链，例如以太坊。该轻客户端需要验证已销毁的包装 BTC 的以太坊区块链上的锁定和铸造智能合约，并且这正是已分配给Bob的 BTC。

有多种解决方案可以实现轻客户端，具备不同的信任假设和不同的实施难度。但通常，运行这两个轻客户端所必需的计算是巨大的，这使得“确认”交易将过大，或者“驳斥”交易变得过于复杂。为了解决这一限制，BitVM2 使用零知识证明，将整个计算封装在零知识证明中，而不是进行实际的计算，BitVM2 程序仅验证零知识证明。

在这里，我们不使用零知识证明的隐私属性，而是使用可扩展性，因为验证证明的成本可以显著低于进行计算的成本。

BitVM2 作为案例研究

请回忆一下在 第一部分 文章中，我们为 BitVM 提供了一个信息卡。

-------------
BitVM（在 BitVM 2 桥中）
-------------
承诺计算：
- 验证 ZK 证明，证明事务的执行
证明有罪的方法：
- 委托计算的裁判
证明无罪的方法：
- 在撤回期内未被证明有罪
-------------

我们可以看到 BitVM2 桥符合标准的欺诈证明范式，而与 Arbitrum 或 Optimism 的唯一区别在于，正在验证的计算首先被封装成一个零知识证明，而链上的计算则是验证这一零知识证明。使用零知识证明的原因是为了降低链上计算的开销，使在比特币区块链上的挑战-响应协议变得可承受。

同样的技术也可以应用于 Arbitrum 或 Optimism，以减少挑战期交互回合数，如 RISC Zero 的 Kailua 所建议的。

BitVM2 桥的局限性

现在我们来谈谈 BitVM2 桥的一些局限性，正如已在 BitVM2 桥 论文中列出的一样。人们曾经对 BitVM2 存在的许多其他问题主要通过一些工程努力可以解决，但这些是由于比特币脚本的限制而固有的开放问题。

• 需要一个委员会预签名交易。 因为比特币脚本没有启用契约的操作码，BitVM2 桥需要额外的信任假设才能正常工作，即需要一个委员会成员生成并预签名运营者将使用的交易。这些交易将连接在一起，运营者必须按照顺序调用这些交易。在Alice将 1 BTC 存入协议之前，Alice可以检查这些交易是否被正确生成，如果它们看起来正确再继续存入。安全性依赖于委员会中的至少一名成员删除用于签名交易的密钥，否则，如果整个委员会与运营者串通，该系统将变得不安全。

• 大型非标准交易。 BitVM2 桥可能拥有超过 400KB 标准交易大小（这是一个软限制），但低于 4MB 硬限制的“确认”和“驳斥”交易。非标准交易仍然可以被比特币链接受，但通常需要矿工的协作，这虽然可行但可能成本较高。

• 固定存款金额。 委员会生成并预签名的交易链将固定一个特定的存款金额，Alice需要恰好存入该金额。稍后，当Bob在比特币链上赎回 BTC 时，需要赎回整整 1 BTC，不能部分赎回Alice锁定的 BTC。虽然通过预生成不同金额的 BitVM2 程序提供一些灵活性是可能的（例如，0.5 BTC、0.25 BTC、0.1 BTC），但是如果用户可以指定任意金额将不会像那样灵活。此外，存款金额不能太小，因为运行 BitVM2 协议需要成本。

• 运营者必须在 peg-out 时预支付 BTC。 协议要求运营者必须预支 BTC，然后为此 BTC 从 BitVM2 桥确认“付款”。由于 BitVM2 桥有挑战期，对运营者的付款不会立即到位，运营者需要有额外的 BTC 来赎回更多用户。如果发生大量赎回，运营者可能会面临没有足够 BTC 流动性来响应所有赎回请求的可能性，并且必须“等待”付款到来，这可能需要一到两周。换句话说，BTC 的大量赎回仍然可以处理，但必须根据运营者的流动性减缓。

• 轻客户端的安全性。 轻客户端的安全设计非常关键，尤其是比特币脚本没有魔法操作码允许脚本自我检查比特币区块链，甚至学习最新的区块编号或时间。到目前为止，更实用的解决方案是使用几个第三方服务，包括 Chainlink CCIP 和 zkBridge。

此外，我们还假设至少有一个运营者愿意参与协议，因此通常 BitVM2 桥需要多个运营者为同一 BitVM2 程序服务，这样即使其中一个不参与，其他运营者也可以参与。当然，这会带来审查风险。

去中心化可能很棘手。BitVM2 协议中挑战协议的具体工作方式也限制运营者需要为每个 BitVM2 程序获得许可，不能直接从公众（或从权益证明协议）获得来源。一个补救措施是在具有安全押金的卫星协议中补偿用户，当运营者未能响应请求时，但这只能对安全押金的范围内提供补偿。

换句话说，在不添加新操作码到比特币链的情况下，比特币的可编程性仍然自然受到我们上述讨论的 BitVM2 桥能提供的限制。

OP_CAT 或其他契约操作码

关于比特币链中操作码升级的讨论非常多。尽管有许多提案，大多数围绕“契约”，在比特币 Wiki 中列出的 讨论 页面中。

契约基本上是比特币交易，其中对应的比特币脚本能够查看交易的输入和输出。此前，比特币脚本没有这些能力。所有比特币脚本能够做到的只是验证交易上的签名或检查一些支出条件，例如来自脚本源的 UTXO 的锁定时间，这也是为什么 BitVM2 桥设计必须依赖于委员会生成和预签名交易以强制执行运营者的工作流。

为了改变这种情况并为比特币带来更多可编程性，人们在考虑对比特币的操作码升级。有八个操作码和一个额外的操作码标志 正在讨论，包括：

• OP_CCV: CV 是“检查合约验证”的简称。它检查交易的给定输入或输出是否在由 taptree 调整的 P2TR 公钥下。这个操作码将与 OP_CAT 一起使用。

• OP_CAT: CAT 是“连接”的简称。它是一个简单的操作码，从堆栈顶部拉取两个字符串并将它们组合成一个字符串。

• OP_CTV: CTV 是“检查模板验证”的简称。它的功能与 CCV 有些相似，但基于限制在 P2TR 的不同实现。它计算交易的输入和输出的一些信息的哈希值。这个操作码也理想地与 OP_CAT 一起使用。

• OP_CSFS: CSFS 是“从堆栈检查签名”的简称。它是 CSV 操作码（签名验证检查）的扩展。CSV 和 CSFS 都允许脚本指定签名和公钥，但 CSV 不允许脚本选择消息——它与交易体验证签名，而 CSFS 则要求脚本为签名提供消息，这实现了一些委托用例。

• OP_PAIRCOMMIT: PAIRCOMMIT 是一个操作码，可以将两个元素组合在一起进行哈希，这可以用于 Merkle 树的验证。使用 OP_CAT 和 OP_SHA256 也可以实现相同的功能，但 PAIRCOMMIT 是一个更受限和具体的版本，优点在于它不启用契约，因此规避了潜在的风险和问题。

• OP_INTERNALKEY: INTERNALKEY 是一个读取 P2TR 交易的 taproot 内部密钥的操作码。这个操作码具有非常特定的用途，并主要用于闪电网络。其功能可以通过 OP_CCV 获得一定程度的体现。

• OP_VAULT: VAULT 是用于实现标准递延提取保险库的操作码，通常用于防止钱包被黑客攻击。其想法是，从保险库的提取将在比特币链上可见，并在冷却期内延迟，这段时间可以撤销该提取。这与一般的契约关系较小，但它实施了一些流行的用例。

• OP_TXHASH: TXHASH 是 CCV 和 CTV 的更概括版本，用户可以指定交易字段选择器并计算这些字段的哈希。这在与 OP_CAT 一起使用时特别有用。

• SIGHASH_ANYPREVOUT: ANYPREVOUT 不是一个操作码，而是 OP_CSV 的提议功能标志，它改变了签名验证的行为，以省略关于交易的某些信息。它可以在一定程度上通过 OP_TXHASH 和 OP_CSFS 替代。

活跃于比特币生态系统的开发者们在分享他们的看法，并在某种程度上“投票”支持这些协议。目前，三个操作码—OP_CAT、OP_CTV、OP_CSFS—获得了许多开发者的支持。但是是否会将这些操作码添加到比特币链中，何时添加，还需要一个流程。

我们在本文中的重点是 OP_CAT，因为这个单一操作码可以满足我们在比特币上验证 ZK 证明所需的多个功能——Merkle 树和递归契约。在所有这些操作码中，OP_CAT 是一个更基本的版本，已经可以用来构建有用的原语。

我们之前展示了如何利用 OP_CAT 构建完整的 有效性证明 的 ZK 验证器，使用 StarkWare 的 Stwo。它不使用欺诈证明，而只是纯粹的 ZK 证明验证，类似与 ZK rollup，且不同于乐观 rollup。如果我们使用它通过递归证明来验证 CairoVM，我们最终会得到一个比特币 STARK 验证器，其属性如下。

-------------
比特币 STARK 验证器（类型 I，仅有效性）
-------------
承诺计算：
- 执行 CairoVM
证明有罪的方法：N/A
证明无罪的方法：
- 运行 ZK 证明验证
-------------

完整证明验证（即有效性证明）的问题在于验证证明的成本。以最近比特币主网的费用率为 1sat/vByte，比特币价格约为 10万美元，每次验证证明将花费约 1250 美元。如果每 10 小时解决一次证明，则每年的证明验证费用将约为 111 万美元。

虽然这对于较大的 rollup 与 良好的收入（如 Base（去年 9200 万美元）和 Arbitrum（去年 4200 万美元））来说应该是可行的，但对于较小的 rollup 和个别应用（它们可能需要在每 10 小时验证超过一个证明），或者对于想要更频繁结算的 rollup，比如 Scroll 和 Polygon（例如每 30 分钟，这将变得约 20 倍更贵）来说是不可能的。

为了避免如此高的费用，我们必须避免对证明进行全面验证，同时保持去中心化。这导致了使用欺诈证明和 ZK 证明混合的解决方案。

-------------
比特币 STARK 验证器（类型 II，乐观验证有效性证明）
-------------
承诺计算：
- 验证一个 ZK 证明，证明事务的执行
证明有罪的方法：
- 委托计算的裁判
证明无罪的方法：
- 在撤回期间未被证明有罪
-------------

在此解决方案中，验证 ZK 证明的比特币脚本被切割成多个片段，每个片段的最终状态在链上呈现（因此，不希望有太多片段，因为这将导致太多的最终状态在链上发布）。

这几乎消除了链上的所有费用，第一次交易可能只需几美元。此时我们并不执行任何比特币脚本的片段，因此链上的费用，若无人对此提出质疑，极少且与比特币脚本的大小无关——我们只需发布几个中间状态的哈希。

如果有人想质疑证明呢？我们有两种方式将其进行质疑：

• 案例 1: 操作员运行片段。 挑战者标记脚本的特定片段，并要求运营者重新运行该片段以表明该片段可以成功执行。

• 案例 2: 挑战者运行该片段。 挑战者执行该片段并表明无法成功执行。

为了防止恶意的挑战者，想质疑有效证明并想弄乱运营者的操作者，我们可以要求挑战者承担执行该片段的成本。

• 在案例 1 的情况下，挑战者在标记该片段时存入抵押金，当运营者执行相应的片段时可以赚取这笔抵押金。抵押金将覆盖执行该片段的交易费用（留有费用突增的余地）。

• 在案例 2 的情况下，执行该片段的挑战者将直接支付交易费用。同样，由于我们期望每个片段在妥善切割后足够小，这个费用应该是可以管理的。

注意，我们甚至可以更进一步，推迟证明的生成到挑战者提出时，采用 Kailua 的思路。

-------------
比特币 STARK 验证器（类型 III，使用 Kailua）
-------------
承诺计算：
- 事务的执行
证明有罪的方法：
- 请求相应的 ZK 证明验证一部分计算但未能及时提供
- 或者，在提供 ZK 证明验证之后，已对这一 ZK 证明验证部分进行了委托
证明无罪的方法：
- 在撤回期间未被证明有罪
-------------

这种设计允许运营者在挑战者请求证明之前不生成 ZK 证明，并且在挑战发起后，运营者会有足够的时间生成证明。而且，在这个设计中，计算本身被切割成几个片段，每次挑战者请求 ZK 证明的特定片段，而不是一次性请求所有片段的 ZK 证明。

允许对 ZK 证明按片段进行请求以保持相同的安全保障，因为如果计算是错误的，至少有一个片段是错误的。它降低挑战者请求证明的成本——因为挑战者需要存入不低于生成证明的成本的押金，生成证明的工作量越少，押金可以设得更小，这降低了挑战的门槛。

凭借这两个变化，我们可以降低运营者的净链上成本，接近于零。这使其适合于频繁交易的应用。然而，与乐观方式相关的一些缺点。

首先，达到最终结论可能需要更长时间（有可能不需要）。之前，当我们执行完整的证明验证时，我们需要等待所有完成全面验证所需的交易在比特币区块链上得到确认。这本身已经需要不少时间，主要有两个原因：

• 完整验证包括多个交易，并且通常分布在几个区块中。因此，理所当然，全面验证将需要几个区块的结算，约 10 个区块（大约 2 小时）。

• 在操作上，由于完整的验证成本高，如果费用率很高，运营者可能会倾向于等待费用下降，或在费用率低于市场价格时接受更慢的纳入。

使用欺诈证明可能导致时间更长，因为我们需要某种撤回或挑战期，允许挑战者检查执行并将挑战事务纳入。设定这个挑战期本身是一个研究，但在理想情况下，可以认为一旦提示事务在链上发布，至多 10 分钟内挑战就可以完成检查并提交挑战交易，并且 1 小时对于必要时发起挑战也是足够的。

如果欺诈证明由几个轮次组成，则实现最终性所需的总体时间可能会比完整验证更长，但经过仔细设计，并假定挑战者能够响应，则相似时间内可以实现最终性。

其次，这依赖于挑战者在线和能够响应。正如我们在上一篇文章中讨论的，这个目标需要努力实现，因为挑战者可能没有足够的信息/基础设施，或没有足够的激励去回应。特别需要确保挑战者具备检查执行并提交挑战的软件，以及足够去中心化的挑战者网络。

第三，我们隐含假设比特币区块链没有审查。如果在挑战窗口内，所有矿工决定过滤任何试图对计算进行挑战的交易（例如，矿工在运营者的业务中有经济利益），那么挑战-响应机制将不再有效。比特币一直被认为具有抵制审查的能力，并且没有历史事件表明会发生阻挡挑战交易，但我们想提出这是可能的，尤其是在挑战窗口很短且仅涉及少数矿工的情况下。

第四，欺诈证明的程序更复杂。这更像是一个工程问题，但合理地切割计算需要重新编写比特币脚本，这不会像执行完整验证那样自然。特别记住，之前的比特币脚本在执行成功时会成功，在欺诈证明的案例中，我们需要反转这一点，使得在脚本失败（即挑战者检测到错误）时执行成功。这将需要大量的重写工作，如我们在比特币开发者邮件列表中的 帖子 所示。

结论

欺诈证明在区块链系统中提供了一种去中心化和低成本的验证离链计算的强大工具，在乐观 rollups 中取得了成功。

比特币的可编程解决方案，包括 BitVM 和基于 OP_CAT 的契约，都是利用欺诈证明来启用可编程性或降低成本，使其能够承受。本文描述了这些解决方案中如何使用欺诈证明。

请在 l2iterative.com 中找到 L2IV，并在 Twitter 上关注 l2iterative

感谢你阅读 L2IV 研究！此帖子是公开的，因此欢迎分享。

作者：Weikeng Chen，L2IV 研究合伙人

• 原文链接： l2ivresearch.substack.co...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～