1 引言

对于一个算法 f，两个互不信任的参与者，Alice 和 Bob，可以通过以下方式建立信任：

1. Alice 输入 x，运行算法 f，得到结果 y。Bob 也用相同的输入 x 运行算法 f，得到 y′。如果 y 和 y′ 相等，Bob 就认可 Alice 提供的输入 x 和输出 y。这是一种常见的有效性证明机制，通常应用于区块链共识中，其中 Alice 是打包区块的节点，而 Bob 是参与共识的节点。
2. Alice 输入 x，运行 zk.prove 程序，得到结果 y 和证明 proof。Bob 根据 f、y 和 proof 运行 zk.verify 程序。如果结果为真，Bob 就认可 Alice 的结果 y；如果结果为假，Bob 就不认可 Alice 的结果 y。这是一种有效性证明，Bob 可以是链上的合约。
3. Alice 输入 x，运行算法 f，得到结果 y。Bob 也用相同的输入 x 运行算法 f，得到 y′。如果 y 和 y′ 相等，就不做任何事情；如果 y 和 y′ 不相等，Bob 就会挑战 Alice，挑战的程序是 f。Alice 和 Bob 之间的互动次数可以是一轮或多轮。通过挑战-响应机制实现仲裁。这是一种欺诈证明，Bob 是挑战者，在线下监听并在线上发起挑战。
4. Alice 输入 x，运行 zk.prove 程序，得到结果 y 和证明 proof。Bob 根据 f、y 和 proof 运行 zk.verify 程序。如果结果为真，就不做任何事情；如果结果为假，Bob 就会挑战 Alice，挑战的程序是 zk.verify。Alice 和 Bob 之间的互动次数可以是一轮或多轮。通过挑战-响应机制实现仲裁。这是一种欺诈证明，Bob 是挑战者，在线下监听并在线上发起挑战。

对于上述 2、3 和 4，设 x 为 Layer2 交易和初始状态，f 为 Layer2 共识程序，y 为交易的最终状态，这与区块链的 Layer2 扩展解决方案相对应。

• 有效性证明：基于悲观假设，必须在接受之前证明其有效性，并立即生效。在有效性证明中，必须提供正确的 L2 状态转换的证据，体现出对世界的悲观看法——只有在状态被证明正确时，才会被接受。
• 欺诈证明：基于乐观假设，默认情况下是被接受的，除非有人证明其不正确。它有一个挑战窗口期，只有在挑战窗口期结束后才生效。在欺诈证明中，必须提供不正确的 L2 状态转换的证据，体现出对世界的乐观看法——状态转换被认为是正确的，除非有相反的证明。

表 1：建立信任的方法

另外，需要特别注意的是：

• 区分欺诈证明和有效性证明的关键不在于是否使用像 SNARK 或 STARK 这样的 ZK 证明系统。ZK 证明系统只是表达了所采用的证明方法，而欺诈或有效性则代表了证明的内容。因此，表 1 中的场景 1 被称为有效性证明。
• 有效性证明的时效性更好，但链上验证的复杂性较高；而欺诈证明的链上验证复杂性较低，但时效性较差。
• 对于表 1 中的案例 2 和 4，通过使用 ZK 递归和组合技术，可以计算和压缩多个 f，从而显著降低链上对链下计算的验证成本。

目前，得益于 Solidity 的图灵完备智能合约，欺诈证明和有效性证明技术在以太坊的 Layer2 扩展中得到了广泛应用。然而，在比特币的框架下，由于比特币的操作码功能有限、栈元素数量仅为 1000 以及其他限制，这些技术的应用仍处于探索阶段。本文总结了比特币框架下的局限性和突破性技术，研究了有效性证明和欺诈证明技术，并概述了比特币框架下独特的脚本分段技术。

2 比特币范式下的局限与突破

在比特币的框架下存在许多局限性，但可以通过各种巧妙的方法或技术来克服这些局限性。例如，使用比特承诺可以突破 UTXO 的无状态限制，Taproot 可以解决脚本空间的限制，连接器输出可以克服 UTXO 消费方式的限制，而智能合约则可以突破预签名的限制。

2.1 UTXO模型和脚本限制

比特币采用 UTXO 模型，其中每个 UTXO 都被锁定在一个锁定脚本中，该脚本定义了消费该 UTXO 所需满足的条件。比特币脚本存在以下限制：

1. 比特币脚本是无状态的；
2. 对于 P2TR 输出类型，单个交易中最多可以容纳约 400 万个操作码，填满整个区块，而对于其他输出类型，仅能使用 10,000 个操作码；
3. 单个 UTXO 的消费方式有限，缺乏对组合消费方式的探索；
4. 不支持灵活的合约功能；
5. 栈的大小限制为最多 1000 个元素（包括 altstack 和 stack），单个元素的最大大小为 520 字节；
6. 算术操作（如加法和减法）限制为 4 字节元素，无法扩展为 20 字节或更大的长元素，这在加密操作中是必需的；
7. 像 OPMUL 和 OPCAT 这样的操作码已被禁用，使用现有操作码来模拟它们的成本极高，例如模拟一次 BLAKE3 哈希，脚本大小约为 75K。

2.2 比特承诺：突破UTXO无状态限制

当前，比特币脚本是完全无状态的。在执行比特币脚本时，每个脚本的执行环境在完成后会被重置。这使得比特币脚本无法原生支持约束脚本 1 和 2 共享相同的 x 值。不过，这个问题可以通过一些方法来解决，核心思想是以某种方式对一个值进行签名。如果能够为一个值生成签名，就能够实现有状态的比特币脚本。换句话说，通过检查脚本 1 和 2 中 x 值的签名，可以确保在这两个脚本中使用相同的 x 值。如果存在冲突的签名，即对同一个变量 x 签署了两个不同的值，则可以施加惩罚。这种方法被称为比特承诺。

比特承诺的原理相对简单。每个比特都对应两个不同的哈希值，hash0 和 hash1。如果待签名的比特值为 0，则揭示 hash0 的前像；如果比特值为 1，则揭示 hash1 的前像。

以单个比特消息 m ∈ {0,1} 为例，相应的比特承诺解锁脚本仅由一些前像构成：如果比特值为 0，则解锁脚本为 preimage0——“0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”；如果比特值为 1，则解锁脚本为 preimage1——“0x47c31e611a3bd2f3a7a42207613046703fa27496”。因此，通过比特承诺，可以突破 UTXO 的无状态限制，实现有状态的比特币脚本，进而使得各种有趣的新特性成为可能。

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // 这是hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // 这是hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// 现在比特承诺的值在栈上。可以是 “0” 或 “1”。

目前，比特承诺有两种实现方式：

• Lamport一次性签名：Lamport 一次性签名：Lamport 一次性签名的原理相对简单，仅需使用哈希函数，适合与比特币兼容。对于消息中的每个比特，需要承诺两个哈希值，这导致签名数据相对较大。具体来说，对于长度为 v 比特的消息，公钥长度为 2v 比特，而签名长度为 v 比特。
• Winternitz 一次性签名：与 Lamport 签名相比，Winternitz 签名显著减少了签名和公钥的长度，但增加了签名和验证的复杂性。该方案允许根据需要灵活设置不同的哈希链长度 d，从而在长度和复杂性之间取得平衡。例如，设置 d = 15 可以使公钥和签名长度缩短约 4 倍，但验证的复杂性会增加 4 倍。这实际上是在比特币的栈空间和脚本大小之间的权衡。当 d = 1 时，Lamport 签名可以被视为 Winternitz 签名的特例。

目前，BitVM2 库实现了基于 Blake3 哈希函数的 Winternitz 签名。对应于单个比特的签名长度约为 26 字节。因此，可以看出，通过比特承诺引入状态是有成本的。因此，在 BitVM2 的实现中，消息首先被哈希以获得 256 位的哈希值，然后对该哈希值进行比特承诺，以节省开销，而不是直接对原始较长消息的每个比特进行承诺。

2.3 Taproot：突破脚本空间限制

比特币的 Taproot 软分叉升级于 2021 年 11 月激活，包含三个提案：Schnorr 签名（BIP 340）、Taproot（BIP 341）和 TapScript（BIP 342）。该升级引入了一种新的交易类型——Pay-to-Taproot（P2TR）交易。通过结合 Taproot、MAST（Merkel 抽象语法树）和 Schnorr 签名的优势，P2TR 交易能够创建更私密、更灵活且可扩展的交易格式。

P2TR 支持两种支出方式：通过密钥路径或脚本路径进行支出。根据 Taproot（BIP 341）的规定，当通过脚本路径支出时，相应的 Merkle 路径长度不能超过 128。这意味着 taptree 中的 tapleaf 数量不能超过 2^128。自 2017 年 SegWit 升级以来，比特币网络以权重单位衡量区块大小，最大支持 400 万权重单位（约 4MB）。当 P2TR 输出通过脚本路径支出时，仅需揭示一个单一的 tapleaf 脚本，这意味着区块中只包含一个 tapleaf 脚本。因此，对于 P2TR 交易，每个 tapleaf 对应的脚本大小最大可达约 4MB。然而，根据比特币的默认政策，许多节点只转发小于 400K 的交易；更大的交易需要与矿工合作进行打包。

Taproot 带来的脚本空间溢价使得使用现有操作码模拟诸如乘法和哈希等密码学操作变得更加有价值。在基于 P2TR 构建可验证计算时，脚本大小不再受 4MB 限制，而可以拆分为多个子功能，分布在多个 tapleaf 中，从而突破 4MB 的脚本空间限制。实际上，当前 BitVM2 中实现的 Groth16 验证器算法的大小高达 2GB。然而，它可以被拆分并分布在大约 1000 个 tapleaf 中，并通过与比特承诺相结合，约束每个子功能的输入和输出之间的一致性，从而确保整个计算的完整性和正确性。

2.4 连接器输出：突破 UTXO 支出方式限制

目前，比特币为单个未花费交易输出（UTXO）提供两种原生支出方式：通过脚本或公钥支出。因此，只要满足正确的公钥签名或脚本条件，UTXO 就可以被支出。两个 UTXO 可以独立支出，且不能添加限制来约束这两个 UTXO，这意味着必须满足额外条件才能支出它们。

然而，Ark 协议的创始人 Burak 聪明地利用 SIGHASH 标志实现了连接器输出。具体来说，Alice 可以创建一个签名将她的 BTC 发送给 Bob。由于签名可以承诺多个输入，Alice 可以将她的签名设为条件：只有在第二个输入被消耗时，Taketx 交易的签名才是有效的。第二个输入被称为连接器，它将 UTXO A 和 UTXO B 连接起来。换句话说，Taketx 交易只有在 UTXO B 没有被 Challengetx 消耗时才是有效的。因此，通过销毁连接器输出，可以阻止 Taketx 交易的有效性。

图 1：连接器输出示意图

在 BitVM2 协议中，连接器输出起到 if…else 函数的作用。一旦连接器输出被某个交易支出，它就无法被其他交易再次支出，从而确保其独占性。在实际部署中，为了允许挑战-响应周期，引入了带时间锁的额外 UTXO。此外，连接器输出还可以根据需要设置不同的支出策略，例如在挑战交易的情况下允许任何一方支出，而在响应交易的情况下仅允许操作员支出或在超时后允许任何人支出。

2.5 合约：突破预签名限制

目前，比特币脚本主要限制解锁条件，而不限制未花费交易输出（UTXO）如何进一步支出。这是因为比特币脚本无法读取交易本身的内容，无法实现对交易的自省。如果比特币脚本能够检查交易的任何内容（包括输出），那么就能实现合约功能。

当前的合约实现可以分为两类：

• 预签名：基于现有的比特币脚本能力，通过预签名构建有限功能的预定合约。这意味着参与者需要提前设计并签署所有可能的未来交易，从而将其锁定在特定的私钥和费用率上。一些方案甚至要求参与者为所有预签名交易生成短期私钥。一旦预签名完成，这些短期私钥会被安全删除，以防止攻击者获取并盗取资金。然而，每当添加新参与者或更新操作时，这一过程需要重复，导致高维护成本。例如，闪电网络通过预签名实现双方合约，并使用哈希时间锁合约（HTLC）技术实现多个双方合约的路由功能，从而实现信任最小化的扩展策略。然而，闪电网络需要预签名多个交易，并且仅限于两方，这使得其使用起来显得繁琐；在 BitVM1 中，每次初始化需要预签名数百个交易，而在优化后的 BitVM2 中，每次初始化需要预签名的交易数量也达到几十个。在 BitVM1 和 BitVM2 中，只有参与预签名的操作员有资格获得报销。如果有 n 个参与者参与预签名，每个参与者需要预签名 m 个交易，那么每个参与者的预签名复杂度将是 n * m。
• 引入合约操作码：引入新的合约功能操作码可以显著降低合约参与者之间的通信复杂性和维护成本，从而为比特币提供一种更灵活的合约实现方式。例如，OPCAT 操作码用于连接字节字符串。尽管其功能简单，但却非常强大，能够显著降低 BitVM 的复杂性；OPTXHASH 操作码则允许对合约内的操作进行更细致的控制。如果在 BitVM 中使用，可以支持更大范围的操作符，从而显著提高 BitVM 的安全性并最小化信任。此外，预签名方法本质上意味着 BitVM 中的操作员只能采用报销流程，这导致资本利用效率较低；而通过新的合约操作码，可能可以直接从 peg-in 资金池支付给输出用户，进一步提高资本效率。因此，灵活的合约模型将有效突破传统的预签名限制。

3 比特币 Layer2 扩容：有效性证明和欺诈证明

有效性证明和欺诈证明都可以用于比特币的 Layer2 扩展，其主要区别见表 2。

表 2：有效性证明与欺诈证明

基于比特承诺、Taproot、预签名和连接器输出，可以构建基于比特币的欺诈证明。同时，通过引入合约操作码（例如 OP_CAT），也可以基于 Taproot 构建比特币的有效性证明。此外，欺诈证明还可以根据 Bob 是否有入场系统分为许可欺诈证明和无许可欺诈证明。在许可欺诈证明中，只有特定群体能够作为 Bob 发起挑战，而在无许可欺诈证明中，任何第三方都可以作为 Bob 发起挑战。无许可欺诈证明的安全性优于许可欺诈证明，因为它降低了参与者之间勾结的风险。

根据 Alice 和 Bob 之间的挑战-响应交互次数，欺诈证明可以分为单轮欺诈证明和多轮欺诈证明，如图 2 所示。

图 2：单轮欺诈证明与多轮欺诈证明

如表 3 所示，欺诈证明可以通过不同的交互模型实现，包括单轮交互模型和多轮交互模型。

表 3：单轮交互与多轮交互

在比特币的 Layer2 扩展范式中，BitVM1 采用多轮欺诈证明机制，而 BitVM2 则采用单轮欺诈证明机制，bitcoin-circle stark 则利用有效性证明。在这几种机制中，BitVM1 和 BitVM2 可以在不修改比特币协议的情况下实现，而 bitcoin-circle stark 则需要引入新的操作码 OP_CAT。

对于大多数计算任务，比特币的 signet、testnet 和 mainnet 无法完全支持 4MB 的脚本，因此需要使用脚本拆分技术，即将完整的计算脚本拆分为小于 4MB 的块，并分布在不同的 Tapleaf 中。

3.1 比特币多轮欺诈证明

如表 3 所示，多轮欺诈证明适合那些希望减少链上仲裁计算，或无法一步定位问题计算段的情况。多轮欺诈证明顾名思义，需要证明者和验证者之间进行多轮交互，以找到问题计算段，然后根据这些段进行仲裁。

Robin Linus 的早期 BitVM 白皮书（通常称为 BitVM1）采用了多轮欺诈证明。假设每个挑战期持续一周，并使用二分搜索方法来定位问题计算段，Groth16 验证器的链上挑战响应期可能会延长至 30 周，导致时效性差。虽然目前有团队在研究比二分搜索更高效的 n-ary 搜索方法，但其时效性仍显著低于单轮欺诈证明的 2 周周期。

目前，比特币中的多轮欺诈证明使用许可挑战，而单轮欺诈证明则实现了无许可挑战方法，从而降低了参与者之间勾结的风险，增强了安全性。为此，Robin Linus 充分利用了 Taproot 的优势来优化 BitVM1，不仅将交互轮数减少到一轮，还将挑战方法扩展为无许可方式，尽管这增加了链上仲裁计算的成本。

3.2 比特币的一轮欺诈证明

在这种模型中，欺诈证明的验证只需证明者和验证者之间进行一次交互。验证者只需发起一次挑战，而证明者只需回应一次。在回应中，证明者必须提供证据，证明他们的计算是正确的。如果验证者在证据中发现不一致之处，则挑战成功；否则，挑战失败。单轮交互欺诈证明的特征如表 3 所示。

图 3：单轮欺诈证明

2024年8月15日，Robin Linus 发布了《BitVM2：将比特币连接到第二层》的技术白皮书，其中实现了一种跨链桥，采用了类似于图 3 所示的单轮欺诈证明方法。

3.3 使用 OP_CAT 的比特币有效性证明

OP_CAT 是比特币发布时脚本语言的一部分，但因安全漏洞在2010年被禁用。尽管如此，比特币社区多年来一直在讨论重新启用 OP_CAT 的可能性。目前，OP_CAT 被分配了编号 347，并已在比特币的 signet 网络上启用。

OP_CAT 的主要功能是将堆栈中的两个元素合并，并将结果推回堆栈。这一功能为比特币上的合约和 STARK 验证器提供了新的可能性：

• 合约：Andrew Poelstra 提出了 CAT 和 Schnorr Tricks I，利用 OP_CAT 和 Schnorr 技术在比特币上实现合约。Schnorr 算法是一种适用于 P2TR 输出类型的数字签名；对于其他输出类型，可以使用类似的 ECDSA 技术，例如在使用 CAT 和 ECDSA 的契约中所示。借助 OP_CAT 合约，STARK 验证器算法可以分解成多个交易，逐步验证整个 STARK 证明。
• STARK 验证器：STARK 验证器的主要功能是将数据连接在一起并进行哈希。与代数运算不同，哈希是比特币脚本中的一种原生操作，可以显著减少开销。例如，OPSHA256 在原生形式中是一个单独的操作码，而模拟版本则需要数百个操作码。STARK 中的主要哈希操作包括验证 Merkle 路径和 Fiat-Shamir 转换。因此，OP_CAT 对 STARK 验证器算法非常友好。

3.4 比特币脚本拆分技术

尽管在 SNARK/STARK 证明后，验证证明所需的计算负载远低于直接运行原始计算 f 的负载，但在将其转换为比特币脚本以实现验证器算法时所需的脚本量依然庞大。目前，基于现有的比特币操作码，优化后的 Groth16 和 Fflonk 验证器脚本的大小均超过 2GB，而单个比特币区块的大小仅为 4MB，因此无法在单个区块内运行整个验证器脚本。然而，自 Taproot 升级以来，比特币支持通过 tapleaf 执行脚本，这使得验证器脚本可以拆分为多个块，每个块作为一个 tapleaf 来构建 taptree。块之间的一致性可以通过位承诺来保证。

在 OP_CAT 合约的情况下，STARK 验证器可以拆分为多个小于 400KB 的标准交易，从而使整个 STARK 有效性证明的验证可以在不需要与矿工合作的情况下完成。

本节将重点介绍在现有条件下比特币脚本的拆分技术，而不引入或激活任何新的操作码。

在进行脚本拆分时，需要平衡以下几个方面的信息：

• 单个块的脚本大小不得超过 4MB，并应包括输入位承诺脚本、交易签名等其他内容。
• 单个块的最大栈大小不得超过 1000。因此，每个块的栈应仅保留必要的元素，以确保有足够的栈空间进行脚本大小优化，因为比特币的交易费用与栈大小无关。
• 在比特币上，位承诺的成本较高。因此，应尽量减少两个相邻块之间的输入和输出位数，目前 1 位对应 26 字节。
• 为了方便审计，每个块的功能应尽可能清晰。

目前，脚本拆分的方法可以分为以下三类：

• 自动拆分：该方法寻求一种拆分方式，使脚本大小约为 3MB，并在栈大小和脚本大小的基础上最小化栈大小。其优点是独立于特定的验证器算法，能够扩展到任何计算的脚本拆分。缺点包括：(1) 整个逻辑块必须单独标记，例如不能拆分的 OP_IF 代码块；否则，拆分脚本的执行结果可能会错误；(2) 块的执行结果可能对应于栈上的多个元素，需要根据实际计算逻辑标记需要应用位承诺的栈元素数量；(3) 每个块脚本的逻辑功能可读性差，审计困难；(4) 栈中可能包含下一个块不需要的元素，浪费栈空间。
• 功能拆分：该方法根据计算中的功能子函数进行拆分，明确子函数的输入和输出。在拆分脚本的同时，为每个块实现必要的位承诺脚本，确保最终块的总脚本大小小于 4MB，栈大小小于 1000。优点是功能明确、逻辑清晰、可读性好，便于审计。缺点是原始计算逻辑可能与脚本级逻辑不匹配，原始子函数可能是最佳的，但不一定代表脚本级的最佳性。
• 手动拆分：该方法的拆分点不是基于功能子函数，而是手动设置。这种方法特别适合单个子函数大小超过 4MB 的情况。优点是允许手动拆分大型脚本子函数，如与 Fq12 计算相关的子函数；每个块逻辑清晰、可读性强，便于审计。缺点是受限于手动调优能力，整体脚本优化后，之前设置的手动拆分点可能不再最佳，需要重新调整。

例如，经过多轮优化，Groth16 验证器的脚本大小已从约 7GB 降低至大约 1.26GB。除了整体的计算优化外，每个块也可以进行单独优化，以充分利用栈空间。例如，通过引入更高效的查找表算法，并动态加载和卸载查找表，可以进一步减小每个块的脚本大小。

由于 Web2 编程语言的计算成本和运行环境与比特币脚本截然不同，因此简单地将现有算法实现转换为比特币脚本并不可行。因此，需要考虑针对比特币场景的特定优化：

• 寻找能够优化内存局部性的算法，即使这可能会增加一些计算负担，以减少块之间的输入/输出位数，从而降低 BitVM2 的 assertTx 交易设计中对承诺所需的数据量。
• 利用相关操作的交换性（例如，逻辑运算），如 x&y = y&x，来节省近一半的查找表空间。
• 目前，Fq12 操作的脚本大小较大；可以考虑使用 Fiat-Shamir、Schwartz-Zipple 和多项式承诺方案，以显著降低 Fq12 扩展操作的计算复杂性。

4 总结

本文首先探讨了比特币脚本的局限性，并讨论了几种解决方案：利用比特币承诺克服 UTXO 的无状态限制，使用 Taproot 以突破脚本空间的限制，通过连接输出绕过 UTXO 支出方法的限制，以及通过合约来解决预签名的限制。接着，文章对欺诈证明和有效性证明的特征进行了全面的概述，包括许可与无许可欺诈证明的特点、一轮与多轮欺诈证明的区别，以及比特币脚本拆分技术的相关内容。

声明：

1. 本文转载自[aicoin]，著作权归属原作者[mutourend & lynndell, Bitlayer Labs]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。