比特币扩容方案：RGB

ConFi-Conflux · 19 April 2024 02:20

本文意图深入探讨各种技术概念并探索协议设计，同时我们欢迎读者主动参与为我们的内容提供反馈和观点。由于每位作者的专业兴趣点不同，每篇文章可能不会涵盖各个协议的全部细节，因此我们特别期待并欢迎读者的详细探讨并补充我们的内容。

请注意，虽然我们在准备这篇文章时已经尽力保证内容的准确性，但是因为诸多可能的因素，其中可能仍存在错误或不准确之处，我们非常乐于相关错漏接受各位的指正。这样的共享与学习过程可以帮助我们共同进步并推动技术的发展。

您可以访问 Exploring Bitcoin Scaling Solutions: RGB 和 Exploring Bitcoin Scaling Solutions: RGB ++ 获取英文版内容

我们将推出一系列关于比特币扩容解决方案的文章，这些文章将致力于简化复杂技术，并详细解释它们是如何使区块链运行得更快、更高效的。

它们将涵盖 Lightning Network、rollups 、sidechains 等多种技术，使您对每种技术的工作原理、在提速和降低成本方面的优势，以及如何进行扩容有更清楚的认识。本文将重点探讨基于 RGB 的比特币扩容方案。

RGB

概述与愿景

RGB 是一个建立在比特币区块链之上的智能合约平台，它通过客户端验证范式，实现了在比特币网络上运行智能合约的能力。RGB 的核心特点包括数据的链下存储、以及使用比特币脚本作为安全和所有权控制系统。该平台旨在提供一个超越传统以太坊类智能合约系统的解决方案，通过分离智能合约的发行者、所有者和状态演变的概念，为去中心化应用和数字资产管理提供了一个更加分层、可扩展、私密和安全的环境。

协议速览

我们在这部分会尽量避免在内容中包括协议的复杂的细节。使用尽量简单化的方式解释协议的工作方式。

基础工作方式

UTXO 全称为 Unspent Transaction Output，为比特币中的基础概念。不熟悉的朋友可以先阅读 wiki 条目。我们不在这里对 UTXO 进行详细解释。

RGB 作为智能合约平台，其整体的设计均与 UTXO 绑定。我们先以一个例子说明其工作原理。假定通过 RGB 发行了某种资产 100 枚，那么该资产会与某个 UTXO 绑定。有权花费该 UTXO 的用户能在花费 UTXO 时，才可以在交易中指定 RGB 资产如何转移（RGB 称之为所有权）。如下图

UTXO1 上绑定了 100 枚 RGB 资产。将 UTXO1 花费后，得到了 UTXO2 与 UTXO3（黑色箭头）。交易中同时包含了 RGB 资产如何转移的指示（红色箭头），将 100 分为了 30 与 70 两部分，前者与 UTXO3 绑定，后者与 UTXO4 绑定。

RGB 合约旨在实现通用的智能合约逻辑，因此合约逻辑与 UTXO 的转移是解耦的。我们可以看到，RGB 资产的转移不必与 UTXO 的花费绑定。

而因为 UTXO 只能被花费一次，所以与该 UTXO 绑定的 RGB 资产也只能被转移一次。如果比特币安全，UTXO 无法被双花，RGB 资产也无法被双花，从而保障了协议安全。

RGB 将这一设计称作一次性封条。

如何在链上指示 RGB 操作

为了隐私性与智能合约的表达能力，RGB 没有简单地将明文写在比特币脚本中，而是在链上提交一个与操作相关的哈希值（术语称为“承诺”）。RGB 的协议参与方可以在链下验证链上的哈希值是否与该操作匹配。

我们在这里不讨论承诺是如何提交的。但就最终结论而言，链上总会出现一个相关的承诺值。

这种方式保障了 RGB 交易的隐私性，对于非 RGB 协议的参与方而言，它所能观察到的链上行为如下图：

可以看到，由于无法通过哈希值反过来获得原始的 RGB 操作，非参与方甚至无法得知 RGB 资产的存在。

同时由于链上仅包含了操作的哈希值，因此提交到链上的数据大小始终是恒定的，这使得链下的复杂操作成为了可能，同时也仅有常数级别的费用开销。

客户端验证

RGB 提交到链上的仅包含哈希，交易时验证哈希是否有效则是协议安全的基础。RGB 通过称之为“客户端验证（client-side validation，CSV）”的方式保证交易的有效性。RGB 相关的数据全部在链下由交易方保存，在交易时由交易方自行决定数据如何传递，在交易数据传递后交易方可以根据交易数据在本地客户端验证交易的有效性。

我们用示意图表明客户端验证做了什么（注意：为了理解的方便，该图没有精确地表示出 RGB 协议的所有细节）。

我们仍然使用上文的例子说明。Bob 是 UTXO1 的所有者，他需要将 70 枚 RGB 资产转移给 UTXO4 的持有者 Alice。

在交易的过程中，产生了新增数据 data2，Alice 因此接收了 Bob 发送的所有数据 data0，data1 与 data2。
Alice 阅读获得的 RGB 数据 data0，data1，data2，得知了 RGB 资产的状态变化（蓝色虚线）。
Alice 会验证链上是否存在 RGB 数据（data2，data1…）的哈希（绿色虚线），以及相应交易是否被比特币确认。从而确保 RGB 数据的有效性。Alice 需要验证所有的 RGB 数据是否有效，即从 RGB 合约被创建，也就是 data0 对应的链上交易（图中未画出），到最新的交易。Bob 在 Alice 接收到资产时也进行过相同的验证。

客户端保障隐私性的方式非常极端。我们可以想见，即时是 RGB 合约的部署者（持有 data0），如果无法拿到 data2，他也无法知晓 Bob 与 Alice 间发生的这笔交易。

信任与安全

由于“安全”是一个比较重要的问题。在这里我们会从“信任”的角度分析用户需要信任的协议与应用中的各环，并给出分析。

如没有另外提及，我们认为协议中使用的经典密码算法是可信的（不考虑量子计算机）。

用户需要信任比特币网络。
- 比特币上的交易不会被双花。否则 RGB 资产也会被双花。
- 比特币交易不会被审查。否则RGB交易可能无法上链。
用户需要信任链下 RGB 的执行引擎（包括虚拟机与智能合约设计）。用户的 RGB 资产与 UTXO 绑定，但在链上仅有 RGB 操作的哈希提交，而没有与比特币脚本的交互，因此链上无法以任何方式确认 RGB 交易是否有效。而如果链下执行引擎出错（如执行引擎的代码错误，或合约的逻辑错误），将有可能导致链下产生无效的状态，或提交的哈希无法与 RGB 状态对应。这种情况下，一旦 UTXO 交易被花费，用户手中的状态无法被正确验证，将会导致资产丢失。

我们可以看到，RGB 协议并没有为用户引入过多的信任负担。用户可以几乎自行验证协议的每一个部分，确保协议在正确运作。但这同样也为用户的使用带来了负担。

杂项

虚拟机

RGB 实现了一个图灵完备的虚拟机 AluVM。

可扩展性

每笔 RGB 交易与一笔比特币交易绑定，这限制了 RGB 的处理能力。但 Bifrost协议也被提出，作为比特币闪电网络的扩展，使得 RGB 支付可以在闪电网络上进行。

TVL

由于 RGB 的隐私性，TVL 尚无可以统计的方法。

RGB 小结：优势与劣势

优势：

隐私性：RGB 在链上仅提交哈希，以客户端验证的方式保证了交易的隐私性。除交易方外其他人无法获知交易详情。
（复杂合约的）链上交易费用：在链上仅提交交易哈希，链上所需的交易费用与合约逻辑无关。
信任：协议中的额外信任需求极少，用户几乎可以验证协议中的一切。

劣势：

数据保存：用户交易时需要保存有 RGB 数据，数据丢失等同于资产丢失。
交易时需要多方交互。当某一方离线时，交易变得不可能。这也使得客户端的设计变得困难。
验证成本高：每次交易时，客户端都要验证状态，当交易次数增加时，验证开销可能会变得极为庞大。此外这一验证过程也需要验证比特币主网数据，因此也会增加本地的存储开销（本地保存）或一定的网络开销（与 RPC 节点或相关服务方交互）。

RGB 的这些劣势加大了客户端构建的难度，也使得用户的学习门槛变得极高。

RGB++

概述与愿景

RGB++ 由 Nervos CKB 的 Cipher 提出。Nervos CKB 是一条基于 UTXO 模型（CKB 中称之为 Cell）的公链。RGB++ 是一个基于 RGB 的扩展协议，它通过将 RGB 的 UTXO 所有权映射到 Nervos CKB 的 Cell 上，并利用 CKB 链和 Bitcoin 链上的脚本约束来验证状态计算的正确性和变更所有权的有效性。RGB++ 希望解决原 RGB 协议在实际落地中的技术问题，将客户端的工作转由 CKB 链承担。

协议速览

我们在这部分会尽量避免在内容中包括协议的复杂的细节。使用尽量简单化的方式解释协议的工作方式。

工作原理

RGB++ 是 RGB 的拓展协议，因此我们推荐读者在阅读以下内容前，确保已经了解了 RGB 协议的工作模式。而 RGB++ 的核心在于将原有的 RGB 的客户端验证范式改为直接公开到 Nervos CKB 链上，并由 Nervos CKB 充当执行引擎。我们仍然复用在 RGB 协议中使用的例子进行解释，如下图（注意，该图仅用于示意 RGB++ 基础的工作方式，为了理解的方便存在一些不准确）。

图中 Bob 向 Alice 发送 70 枚 RGB 资产。与之前的客户端验证不同，此时所有的 RGB 数据都被提交到了 CKB 链上公开，同时 CKB 也会作为交易引擎执行并保存 RGB 合约状态。

Bob 可以直接通过 Nervos CKB 得知自己拥有的 UTXO1 上绑定了 100 枚 RGB 资产。
当 Bob 向 A 发送资产时，他不必再将 data0 与 data1 也提交给 Alice，Alice 可以自行在链上读取当前的合约状态或历史数据。
在比特币上提交承诺的交易（0x345AB…D7654）确认后，Bob 可以向 CKB 提交包含了 RGB 数据（data2）的交易，CKB 的节点会同时运行比特币的轻节点，确认比特币链上存在承诺。
在交易被 CKB 执行后，Alice 能够通过 CKB 读取到自己持有的 UTXO4 上此刻被绑定了 70 枚 RGB 资产。

可以看到，原有 RGB 的客户端的绝大多数功能现在被 CKB 链承担了，用户端在 RGB++ 中不必承担繁重的数据储存与验证成本。而负面影响则是 RGB 协议的隐私性当前不复存在。

交易流程详解

RGB++ 协议的白皮书对交易的流程作了非常详尽的解释，这里我们借用原文的表述，结合上图解说。

链外计算
- Bob 选中下一次要使用的一次性密封条（即 btc 交易要花费的 UTXO），例如 UTXO1。
- Bob 链外计算并生成一笔将要发送到 CKB 上的 RGB++ 交易: CKB_TX。CKB_TX 中包含 RGB 状态变更所需数据。
- Bob 链外计算承诺值 commitment(0x345AB…D7654)
BTC 交易提交
- Bob 生成并发送一笔比特币交易，花费 UTXO1，通过 OP_RETURN 加入上述的commitment(0x345AB…D7654)。
CKB 交易提交
- Bob 发送 CKB_TX 到 CKB 链上
- 用户最新状态由 CKB_TX.output.data 维护
- 下一次状态变更（Alice）需要使用 UTXO4, CKB_TX.output
链上验证
- Bitcoin UTXO1 仅被花费一次。
- CKB 通过 Bitcoin Light Node，验证承诺值在比特币链上，且花费了正确的 UTXO。
- CKB 验证 CKB 上合约的状态转移符合预先约定的合约规则。

信任与安全

由于“安全”是一个比较重要的问题。在这里我们会从“信任”的角度分析用户需要信任的协议与应用中的各环，并给出分析。
如没有另外提及，我们认为协议中使用的经典密码算法是可信的（不考虑量子计算机）。

用户需要信任比特币网络。
- 比特币上的交易不会被双花。否则 RGB(++) 资产也会被双花。
- 比特币交易不会被审查。否则 RGB(++) 交易可能无法上链。
用户需要信任 CKB 的交易执行引擎。理由同 RGB。
用户需要信任 CKB 能会访问 Bitcoin 近行交易验证。否则非法状态将有可能上链。
用户需要信任 CKB 不会审查用户交易。如果用户交易被审查无法上链，将无法获得交易执行结果。但是此时也能够将协议由 RGB++ 回退到 RGB，重新启用客户端验证的范式，离线计算交易执行结果。
用户需要一定程度信任 CKB 的一致性（一致性可以理解为被确认的交易是否会回滚）。
- 对应比特币上的承诺，恶意的攻击者无法构造出另一笔 CKB 交易，包含不同的执行内容。用户不必担心 CKB 的一致性导致 RGB 资产被双花。
- 但用户需要考虑到，如果 CKB 回滚可能导致 CKB 交易数据丢失，而用户未保存相应交易数据，将可能进而导致 RGB++ 数据永久丢失。

需要注意的是，上面的信任分析没有考虑 RGB++ 计划引入的扩展功能，例如交易折叠、global state 等功能。

RGB++ 小结：优势与劣势

RGB++ 是 RGB 的扩展，我们先分析 RGB++ 相比 RGB 的优劣。

优势：

用户不必自行保存数据，而是由 CKB 保存。
执行引擎的绝大部分职责由 CKB 担当，用户能够从 CKB 链上读取RGB 合约的最新状态，也不必每次从头运行 RGB 数据。
CKB 通过 Bitcoin 轻节点自动验证交易，用户不必自行验证。

劣势：

交易不再具有隐私性。
交易需要在 CKB 上执行。限制了 RGB++ 合约执行复杂交易的能力。同时需要根据交易的复杂性支付费用。
需要引入额外的对 CKB 链的信任依赖。

RGB++ 并没有完全继承 RGB 的优点，它牺牲了 RGB 方案的隐私性，并需要用户的部分额外信任，但在此基础上大幅提升了 RGB 协议的可用性。

而作为比特币的扩容方案，RGB++ 有如下优势与劣势：

优势

信任：RGB++ 中 CKB 链充当了比特币链下公共计算引擎的作用，负责验证与运行协议，而无需跨链桥。协议中引入的额外信任需求非常轻度，用户容易验证 CKB 链是否在作恶，同时也有着回退到客户端验证的选项。

劣势

没有很好地解决可扩展性问题。（RGB++ Light Paper 中提出的交易折叠可以一定程度上缓解这个问题，感兴趣可以阅读后文）。

附录讨论：EVM 中 RGB 执行引擎的伪代码构建

我们在文中提到，图灵完备的 EVM 也能作为 RGB 架构的执行引擎。下面通过 伪代码 实现了一个 demo 合约，用于在 EVM 链上部署一个类 RGB++ 的执行引擎。

BTC_STATE 是一个特殊实现的合约，我们假定它可以（通过一个轻节点）读取比特币链上已确认的信息。同时任何人都能手动通过 RGB_CONTRACT 的 openCommitment 将交易 data 公开，将 EVM 作为执行引擎，执行 RGB 交易。这里我们假定交易的承诺值是通过提交到链上的。

// BTC_STATE can read bitcoin confirmed state
contract BTC_STATE {
  stuct TXO {
    uint256 btcTxId;
    uint256 outputIndex;
  }
  // a bitcoin tx will have at most 1 OpReturn
  function readBitcoinOpReturn(uint256 btcTxId) returns (bytes);
  // or
  function readBitcoinTransactionOutputScript(TXO txo) returns(bytes);

  function isBitcoinTransactionOutputSpent(TXO txo) returns(boolean);
  // ...
  function readBitcoinOrdinalIndex(TXO txo, uint256 satoshiIndex) returns (uint256);
  // ...
  function readBitcoin...(uint256 btcTxId) returns (bytes);
}

contract RGB_CONTRACT {
  struct RGB_DATA {
    TXO input; // could be multiple, only for reference
    TXO output; // could be multiple, only for reference
    bytes payload;
  }
  mappinp(uint256 => bytes) utxoStatus;
  mappinp(uint256 => boolean) utxoPermission;
  function openCommitment(RGB_DATA calldata data, bytes32 salt) public {
    isValidOpen(data, salt);
    utxoPermission[calcTxoHash(data.input)] = false;
    utxoPermission[calcTxoHash(data.output)] = true;
    execute(data.payload);
  }
  function calcTxoHash(TXO txo) pure returns (uint256);
  function calcCommitment(RGB_DATA calldata data, bytes32 salt) pure returns (bytes32);
  function execute(bytes payload) internal;
  function isValidOpen(RGB_DATA calldata data, bytes32 salt) {
    require(utxoPermission[calcTxoHash(data.input)], "from utxo should have permission");
    require(
      calcCommitment(data, salt) == BTC_STATE.readBitcoinOpReturn(data.input.btcTxId)
    );
    _;
  }
}

比特币扩容方案：RGB

RGB

概述与愿景

协议速览

基础工作方式

如何在链上指示 RGB 操作

客户端验证

信任与安全

杂项

虚拟机

可扩展性

TVL

RGB 小结：优势与劣势

更多细节

状态机复制与链下计算引擎

承诺方案

Proof of Publication

相关资源

RGB++

概述与愿景

协议速览

工作原理

交易流程详解

信任与安全

RGB++ 小结：优势与劣势

更多细节

同构绑定

交易折叠

global state 与其带来的安全风险

相关资源

附录讨论：EVM 中 RGB 执行引擎的伪代码构建

比特币扩容方案：RGB

RGB

概述与愿景

协议速览

基础工作方式

如何在链上指示 RGB 操作

客户端验证

信任与安全

杂项

虚拟机

可扩展性

TVL

RGB 小结：优势与劣势

更多细节

状态机复制与链下计算引擎

承诺方案

Proof of Publication

相关资源

RGB++

概述与愿景

协议速览

工作原理

交易流程详解

信任与安全

RGB++ 小结：优势与劣势

更多细节

同构绑定

交易折叠

global state 与其带来的安全风险

相关资源

附录 讨论：EVM 中 RGB 执行引擎的伪代码构建

附录讨论：EVM 中 RGB 执行引擎的伪代码构建