BiHelix RGB V0.11版本前瞻：资产发行概要

作者: Zoom, Echo, BiHelix

引入

随着Nervos联创Cipher提出了名为RGB++的方案，市场上对RGB原生协议的讨论与热议也日益增长。RGB作为由LNP/BP标准协会打造的可扩展且保密的比特币与闪电网络智能合约系统，一直备受比特币生态开发者的青睐，被视为BTC原生拓展协议中具备巨大潜力的一环。作为比特币去中心化金融（BTCfi）和应用（DApps）的基础架构，RGB标志着将比特币的实用性从单一的价值储存功能拓展至更为广泛的领域，这是一项具有历史意义的里程碑。其引领的技术革新不仅令人振奋，更将为整个加密货币生态带来全新的发展方向与可能性。

2023年年末，RGB原生团队LNP/BP标准协会为了更好地迎接市场挑战并促进比特币生态的蓬勃发展，宣布RGB即将升级并发布v0.11版本。本篇文章将详细介绍 RGB v0.11 协议升级的功能和技术基础，全面概述 RGB v0.11 所支持的资产生成功能和交易功能，包括采用可信证明共识、可扩展性优化以及关键安全强化。我们深入研究了与现有共识方案相比的信念证明的基本原理和权衡，以及证明 v0.11 解锁的 Gas 节省和吞吐量增加的量化基准。

RGB 资产生成

目前 RGB 协议V0.11版本中内置三个资产类型，包括RGB20（代币），RGB21（NFT）和RGB25。以RGB20为例，我们讨论目前协议的实现步骤和可执行权利。

1. 首先，合约的发行者需要根据 RGB20 协议设置好关于 RGB 代币的初始状态，比如定义合约的细节：资产的名称、初始发行量，总供应量，增发，重命名，销毁等权限等。
2. 其次合约发行者指定一个来接收初始发行量的 UTXO，这样就可以创建一个简单的 RGB 资产。其中状态变更可以应用在变更资产所有权的权利上，也可以应用在别的类型的权利上。例如：

• 增发接口：当合约开启增发权限时，需要指定一个地址接收这笔增发的资产。当然 RGB20 限制了增发的上限，合约发行者不能无限增发。
• 销毁接口：合约发行者可以指定一个或多个人拥有代币的销毁权限。因为RGB20采用P2P交易（交易篇会介绍），所以用户很难把代币打入黑洞地址进行销毁。
• 重命名接口：合约可以进行更新资产名称。

因为 RGB 合约代码是存储在链下的，如果合约发行方不授权开源，用户很难验证资产信息。RGB合约一旦发行，不管是用户还是发行方都必须遵守合约发行时的状态定义，杜绝发行方作恶行为。

RGB 资产转让

RGB的交易模式采用 P2P（Peer to Peer）转让，这与 ETH 有很大的不同。这种转让模式需要双方都要在线，举个例子 “A 要发送100代币给 B ”操作如下：

1. B 创建发票指定发送 100 代币。
2. 接受人 A 提出转账。
3. B 确认转账并签名。
4. A 广播交易。
5. A 和 B 接受交易。

这其中 B 把这个发票发送给 A，A 拿到发票后只能遵从发票内容发送 100 代币给 B。B 需要确认已经接收到 100 代币才算成功。

• Q：为什么说两方都要在线 ？
• A：因为发票具有时效性，如果一段时间不使用，则失效，所以需要A拿到B的发票后立即转账。B 也要确保发票能够立即被 A 使用，才会创建发票。这里就约束了双方需要在发票有效时间内完成转账。

图：闪电网络通道交易

因为 RGB 使用的交易通道集成了闪电网络，所以交易过程可以参考闪电网络的转让过程，只是增加了“需要收款方再次确认”的步骤。这样的交易步骤使得收款方不会收到乱七八糟的钓鱼币，从而保护用户钱包安全。

RGB 资产交易

RGB 资产转移过程中的技术点

1. 一次性密封

该技术最早由Peter Todd在2016年提出，主要意思是“把一条消息加上一个密封条，确保这个消息只能被使用一次，因为你要知道消息就必须拆除密封条”。

一种简单的方法是设置一个公证的第三方服务端，每当某一个密封条打开或者锁上时就在公开的注册处发布证书，这样任何人都能验证自己关心的密封条的状态。

如果不使用一个受信任的实体来实现一次性密封的功能，可以使用比特币的 UTXO 来作为密封条。因为比特币的任何一个 UTXO 只能被花费一次。因此，把 UTXO 作为密封条，就可以在 UTXO 创建的时候锁上，在花费它的时候打开。

RGB 利用了这样的“一次性密封”技术，它将 RGB 资产的信息、合约的状态等都“包裹”在 UTXO 里面，当 UTXO 被花费的时候，资产的所有权、合约的状态就发生了转变。这意味着，每当一笔 RGB 交易发生时，实际上就是发送者给某个合约（定义了被转移的权利的那个）创建了一次状态变更。

2. 客户端验证

RGB 的验证和传统的“全球共识”验证不同，采用的是“客户端验证”的技术。在传统的比特币验证方式里，一个连接到网络的节点会持续不断地下载和验证区块以及交易池中的交易（全节点）。这样的节点对整条链上的 UTXO 集（区块链上所有未花费的输出的集合）有一个实时更新的试图，当它看到一笔新交易时，要验证其有效性，只需要验证该交易的所有输入都是该 UTXO 集的最新状态的一部分即可。

但是对于 RGB 而言，没有全局传播的数据，因此也没有这样的 UTXO 集的全局视图。一个 RGB 客户端在接受一笔交易后，不仅需要验证交易的最新状态是有效的，还必须对与交易相关的以往所有的状态转化作同样的验证，一路追溯到发行合约的创始状态。这看起来会会带来一个明显的缺点：导致验证时间很长。但是这仅仅出现在“一项具有很长的交易历史的资产时”才会出现，而且可以通过一个数据分享层（自愿的情况下）提前开始验证这部分交易历史数据。

这同时可以带来明显的优点：客户端不需要知道、也不需要验证全局中发生的所有交易。因为它只需要知道跟自己钱包相关的交易即可，它不需要验证其他的交易，因此每个客户端要验证的数据量都更小，系统扩展性明显增强。客户端验证完整链条的问题，BiHelix 提出递归零知识证明方案加以彻底解决。

3. 确定性的比特币承诺

RGB 防止“双花”是通过RGB承诺来实现的。这样的承诺需要实现：

• 涉及合约的多次状态转换可以承诺到单笔比特币交易中
• 每一次合约的状态转换都只能被承诺进比特币交易一次

实现的具体方式是：

1. 首先，跟某一个合约（或者说资产 ID）相关的所有状态转换，要确定性地聚合成一个承诺。
2. 然后，所有被转移的资产的承诺，要被聚合成一棵默克尔树。
3. 最终的根哈希值，就是最终的 RGB 承诺。
4. 为了保证跟其它无关 RGB、但同样也需要使用确定性比特币承诺的协议的兼容性，RGB 承诺和其它协议的承诺要再一次聚合（如 LNPBP-4 标准所述），如此得到的哈希值，才是实际上被嵌入比特币交易中的消息。
5. 批处理降低成本

由上节可以知道，我们可以将任何数量的状态变化“包裹”在单个比特币承诺里面，理论上可以实现大规模的批处理，从而为 UTXO 服务供应商提供更多应用场景。

• 场景：A 想同时给多人支付，给B转移一个 RGB20 资产，给 C 转移一个 RGB21 资产，给 D 转移一个合约的所有权
• 结果：A 只需为 B、C、D 各创建一个状态转换，并将所有的状态转换都承诺到同一笔比特币交易中就可以了，不需要占用更多字节。这意味着，不同状态的状态变化，因为包裹在一个承诺内，实现了批量处理。每笔 RGB 支付的链上手续费边际成本都可以非常小，因为同一笔手续费被任意数量的转账平摊了。

这里也存在局限性，即：这些状态转换信息必须要“包裹”在同一个 UTXO 里面，如果是存在多个，那么就需要增加这笔交易的输入，相应的成本等也会提高。但是相对于传统的每一个状态变化都需要一笔交易的情况，已经可以实现极大的改善。

5. 客户端之间的通信

客户端通信常见于一笔 RGB 转账的实现过程中。发送者需要给接收者（们）分享“consignment”，这种数据结构包含了验证转账所需的一切信息，包括可以追溯到合约创始状态的所有状态转换，需要从发送者通过通信方式转移给接收者。但是在 RGB 协议中不受通信渠道限制，有多种数据分享方式。常见的两种分享数据的方法：

• Storm：一种点对点的即时通信和存储系统，基于闪电网络。
• RGB 代理服务端：一种标准化的 HTTP JSON-RPC 服务端，其客户端可以上传和下载数据。用户可以运行自己的代理服务端，也是使用第三方的服务端。依赖于第三方的服务端会影响隐私性和抗审查性，但不影响安全性

客户端通信 BiHelix 也提出了自适应通信协议加以优化。

结论

尽管当前RGB v0.11版本仍处于Beta阶段，然而我们不难窥见，众多的RGB生态项目团队正积极为其贡献心血，共同携手推进v0.11版本的精细优化。作为RGB生态项目及RGB协议的倡导者，BiHelix团队一直在全力以赴，致力于实现RGB协议的工程化和商业化落地。加速推进闪电网络和RGB协议的兼容性，同时积极吸纳更多高质量的应用生态开发者，让他们深入学习和应用RGB协议将是其首要目标。

相信RGB协议愈加成熟的资产发行功能集，将为比特币生态带来更多创新，再一次将整个比特币生态推向新的高度随着RGB协议在比特币网络中的广泛应用，本文也将成为理解RGB背后机制和设计的不可或缺的重要参考资料。在这个充满活力的生态系统中，RGB的前景显得一片光明，正为比特币的演进注入新的活力和可能性。