RGB++ 协议和比特币的未来：Cipher 从 2024 年新加坡比特币峰会上获得的见解

3 月 9 日，在 Nervos 基金会和 ABCDE 联合举办的比特币新加坡 2024 大会上，CELL Studio 创始人、RGB++ 协议作者 Cipher 发表了题为《RGB++ 协议概述与展望》的主题演讲。

以下是 Cipher 演讲的要点总结：

RGB 协议面临的挑战

RGB 协议已经存在很多年了，但由于以下几个因素，它尚未得到广泛采用：

交互式操作的挑战

在涉及BTC 、 ETH等的交易中，接收方只需提供地址，发送方今天或明天都可以转账，非常方便。相比之下，每笔 RGB 交易都要求接收方先开具发票。然后，发送方必须构造 RGB 交易并生成资产历史证明以发送给接收方。在收到此证明后，接收方必须执行客户端验证（CSV）。验证成功后，他们必须存储此证明以备将来交易。

因此，RGB交易不仅需要双方在线，还需要双方存储相关的历史数据。这对面向消费者的产品构成了重大障碍。

数据可用性（DA）问题

在 RGB 交易中，附上资产的历史证明至关重要。如果这个证明丢失了，它就和丢失私钥一样重要。谁来帮用户保管资产是一个数据可用性的问题。在最初的 RGB 协议中，为了保护隐私，没有其他人为用户存储资产，这意味着用户必须对自己的数据存储负责。

即使有适当的数据存储，请考虑这样一个场景：Alice 想要将 RGB 资产转移给 Bob。她如何向他发送这些资产的历史证明？使用电子邮件还是 Whatsapp？显然，通过任何集中式渠道传输都是不合适的，需要使用专门的 P2P 渠道。然而，P2P 渠道引发了保密性问题：为什么有人会协助传输这些敏感数据？这导致了一系列复杂的问题。

互操作性问题

RGB 资产的历史证明数据由用户自己保留，并在交易期间传递给接收者，但不公开。这导致数据分散在网络中的每个个体中。对于构建交易平台的人来说，无论是集中式还是分散式，都需要来自多个来源的数据来维护 RGB 的全局状态。有些 RGB 服务提供商会为应用程序开发人员集中和存储这些数据，但这种方法会削弱 RGB 的隐私。尽管有这种解决方案，但挑战仍然存在，例如促进持有不同用户 RGB 数据的各种服务提供商之间的数据传输。

智能合约/脚本执行环境的问题

RGB 中的智能合约或脚本执行环境面临重大挑战。它使用名为 AluVM 的虚拟机 (VM)，但其编程语言的具体细节尚未最终确定。此外，编译器和调试器等关键开发工具尚未完全开发。它还缺乏对共享状态和去中心化（无所有者）合约的支持。目前，AluVM 显然仍处于非常早期的阶段。

因此，RGB 面临众多复杂问题，每个问题都需要花费大量时间和精力。这些挑战大大延迟了 RGB 的有效实施。

RGB++ 协议概述

RGB 交易通过映射过程与比特币交易紧密相关。此外，RGB 交易需要链下基础设施，包括数据可用性 (DA)、客户端验证、P2P 网络、虚拟机、共享状态和去中心化合约。当考虑这样的基础设施时，自然会想到区块链，因为它具有数据管理、验证、虚拟机集成、P2P 网络、激励和智能合约功能。RGB++ 协议概念基于这一基本直觉，建议使用基于 UTXO 模型和图灵完备的 CKB 区块链来替代 RGB 所需的链下基础设施。

RGB++ 引入了同构绑定技术的概念。每笔比特币交易都包含一个输出。对于 RGB 交易，它需要在比特币输出中包含一个 OP_RETURN 段。该段包含特定的哈希数据，称为承诺。如果此承诺与另一条公共区块链上的交易哈希相符，并且如果两个交易的输入和输出是同构的（即它们在结构上对应），并且假设此替代区块链的 UTXO（未使用交易输出）具有图灵完备的计算和状态存储功能，则比特币区块链上的交易将与该另一条区块链上的交易完全集成或绑定。CKB（通用知识库）区块链满足这些先决条件。因此，在比特币上进行交易实际上等同于在 CKB 链上执行相应的交易。比特币交易状态的任何变化都会反映 CKB 链上交易状态的变化，并遵守 CKB 上存在的合约约束。这就是同构绑定技术的精髓，但这个概念包含很多复杂的技术细节，包括如何保持交易一致性、如何防止双花等，这里就不展开讲了。

同构绑定技术可以增强比特币的状态能力。例如，下图中的 btc_utxo#1。这个比特币 UTXO（Unspent Transaction Output）通常只表现出两种状态：锁定脚本和金额，后者代表余额。然而，在图中所示的 CKB（Common Knowledge Base）区块链上对应的蓝色 Cell 中，功能更加广泛。不同于比特币 UTXO 只能显示余额的有限功能，CKB 链上的这个同构 Cell 不仅可以存储余额数据，还可以存储各种其他类型的数据。

除了数据组件之外，Cell 还拥有一个类型脚本。该脚本有特定的用途：它定义了接收资产的条件并对资产类型施加了限制。

此外，Cell 包含一个锁定脚本，在本例中，该脚本明确链接到 btc_utxo#1。这种联系意味着，只有当 btc_utxo#1 被使用时，CKB 区块链上的 Cell 才能被使用。

在 CKB 平台上，我们实现了比特币轻节点。一旦发起比特币交易，它就会被中继机制捕获，然后将这笔交易作为一种证明形式转移到 CKB 区块链上。这个过程涉及验证交易在比特币轻节点上的存在，并确保承诺与交易同构。

通过这种方式，我们大大扩展了比特币的功能。它为直接在比特币上发行各种资产铺平了道路，并促进了图灵完备合约的扩展。

这种方法的好处是，我们成功地将图灵完备的脚本引入了比特币领域，同时保持了与比特币第 1 层（L1）几乎相同的安全状态。这是因为所有历史记录、交易和承诺都通过比特币 L1 上的 UTXO 链链接起来。

然而，代价是隐私性略有下降。在 RGB 的情况下，数据分散在各个用户之间，这使得其他人难以访问任何特定用户的 RGB 数据。使用 RGB++，所有链下数据都发布在 CKB 区块链上，该区块链维护这些状态，从而导致隐私性下降。然而，最坏的情况只是隐私性降低到比特币交易的水平；它不会暴露 IP 地址或个人身份信息。

其实，我们可以在 CKB 上实现一个增强的隐私层。四年前，我们和 Grin 社区合作写了一篇论文，讨论在 CKB 上使用 Mimblewimble 技术来创建这个增强的隐私层。未来，我们可以将这一层集成到 RGB++ 中，不仅可以隐藏交易金额，还可以切断交易历史的链接，这样隐私性会比 RGB 更强。

总而言之，我们以更简单的方式实现了 RGB 的愿景，并进一步扩展了它的功能。

释放比特币 L1 资产的潜力

这里对飞跃概念做一个简化的介绍。

同态绑定技术可以应用于比特币，同样适用于莱特币、Liquid 和其他基于 UTXO 的链。如前所述，在 RGB 和 RGB++ 系统中，收款人都是比特币 UTXO，拥有唯一的支出权力。当我在比特币上创建 RGB++ 交易时，我可以选择将收款人指定为莱特币 UTXO，而不是比特币 UTXO。因此，该资产“跳跃”到莱特币，因为其后续支出需要通过莱特币 UTXO 解锁。同样，该资产可以跳跃到 Liquid，甚至可以跳跃回比特币。

当然，还有一种特殊情况需要考虑。当一项资产跃迁到 CKB 区块链上时，它的数据解释层、合约层和所有权都在 CKB 上。这意味着它不再依赖于任何其他链，可以直接在 CKB 上进行交易和与智能合约交互。这可谓是跃迁到 L2。在 L2 上，用户可以进行数千甚至数万笔交易，直到有人决定将资产跃迁回比特币。这就是我们所说的交易折叠。无论是 RGB 还是 RGB++，交易都是在比特币区块链上进行的，而比特币区块链的挖矿费用非常昂贵。但是，一旦一项资产跃迁到 CKB 并进行交易折叠，费用就会大大降低，而且它随时都可以轻松回到比特币区块链。这整个过程不依赖任何多重签名桥，也不信任任何个人，唯一的要求就是等待更多的区块确认。从比特币区块链跃迁到 CKB 区块链需要等待 6 个比特币区块确认。要从 CKB 区块链跳回到比特币，需要 24 个 CKB 区块确认，以防止区块回滚/r。

这就是为什么我们说我们引入了一个新范式。当然，这不是我们的发明，而是 RGB 早期材料中存在的想法，其中 RGB 资产可以在不同的 UTXO 链之间跳跃。在将图灵完备性与跳跃到 CKB 相结合后，我们发现潜在的应用非常广泛，与以太坊多重签名桥的传统叙述大不相同。

前景

接下来我们来讨论一下可扩展性。比特币的交易速率约为每秒 7 笔交易（TPS），而 CKB 的峰值约为 200 TPS。如果考虑到合约执行和脚本验证成本，TPS 可能会降至约 50，与比特币相比，这还不到十倍的扩展。这还远远不够，那么扩展的选择是什么？我们看到两个主要方向：

• 状态通道：状态通道代表终极扩展解决方案，可提供极高的性能上限。然而，挑战在于实施多方合约的复杂性，使状态通道更适合支付交易和个人与服务器交互。Jan 将带领团队推进状态通道的研究。

  
  

• AppChain Stack ：基于 UTXO 模型构建第 2 层 (L2) 解决方案，L2 AppChain 将确保其锚定在 CKB 上，与其同构对齐。这种方法使我们能够在这个新范式中开发创新的扩展策略。这也是 CELL Studio 明年的重点。

  
  

最后，我想概述一下 RGB++ 的使命和路线图。RGB++ 旨在开发基础协议模块，以方便第三方开发人员和用户轻松使用和集成。RGB++ 协议的路线图如下，该协议已在 Bitoin 主网上线， RGB++ SDK已于 4 月 3 日发布。

由 CELL Studio 的创始人兼 RGB++ 协议的作者 Cipher 撰写。