2 月 23 日，CELL Studio 创始人 / Nervos CKB 联合创始人 / RGB++ 协议作者 Cipher、Web3 华语 KOL 花椒、RGB 中文布道者大胖墩、极客 Web3 创始人 Fasut、CKB 生态基金 CMO/SeeDAO 发起人 Baiyu 以及 CKB 社区大使 CyberOrange，在 X Space 的直播活动中，和大家聊了 RGB++ 协议的前世今生。
这场直播持续了一个半小时，干货非常多，欢迎还没有收听的小伙伴点击下方链接收听音频回放：https://twitter.com/ckbcell/status/1760995772840268105?s=61&t=IYlGL8YIKMjrbZkcBRmuJA
以下是根据音频整理的重点内容：
1. RGB 协议的发展历程#
RGB 协议最早可以追溯到 Peter Todd 在 2016 年提出的客户端验证，其核心思想是，我们不需要所有的东西都放在链上，我们只需要区块链去做它能做的事情，比如轻量化的验证。这是一代目。
二代目是 Giacomo Zucco，他受到 Peter Todd 想法的启发，最初概念化了 RGB 协议，但这个 MVP 做得非常不完全。
三代目是现在的 Maxim Orlovsky。RGB 协议 90% 以上的代码，是 Maxim 博士贡献的，他没有进行融资，全靠捐赠和自掏腰包，但捐赠也只能解决个人的一些经济问题，没有足够的经费去招募大量的工程师。另外，Maxim 博士还成立了 LNP/BP 标准协会，以推动 RGB 协议走向实际应用。
关于 RGB 协议和 LNP/BP 标准协会的更多介绍，欢迎观看 Web3 华语 KOL 花椒制作的系列 Youtube 视频：https://www.youtube.com/playlist?list=PL9_Eoig1ztix_j6N6hqswuvDv3FDiSoJO
RGB 中文布道者大胖墩补充说，RGB 被视为比较正统的一种比特币扩容方案，被很多人寄予希望。但 LNP/BP 标准协会是非盈利性的，主要依赖于捐赠，没有足够的经费去招募开发者，导致 RGB 协议进展缓慢，目前还没有 roadmap，存在很多不确定性，而这又会进一步拖慢其他基于 RGB 的项目的开发进度，形成 “恶性循环”。
另外，目前 RGB 及其协会的控制权主要在 Maxim 博士一个人身上，大胖墩认为该协会应该更开放一些。
2. RGB++ 的诞生背景#
Cipher 介绍说，几个月前看到一篇介绍 RGB 的文章，文中提到了 RGB 协议存在数据传输、用户交互等方面的劣势，比如说 RGB 转账需要双方同时在线，需要进行交互式操作，发送方还需要提供资产的历史数据证明，等等。Cipher 认为 RGB 协议很优雅，但用户体验不够友好，甚至有些麻烦，而且在应用层实践上存在很多问题，比如 RGB 的数据分散在每个人的手里，导致做 DeFi 或者是做 DEX 等应用非常困难。
产品经理出身的他，敏锐地察觉到 RGB 协议的这些困难或者说劣势，其实可以直接在区块链上解决，比如不依赖任何人的 P2P 网络、共享数据、能验证交易的虚拟机、非交互式的操作体验。这也是 RGB++ 最早期的核心想法，即把 RGB 协议链外的客户端验证要做的事情，委托给一条图灵完备、基于 UTXO 模型和 PoW 共识机制的区块链去解决。
RGB++ 的优点有很多，比如可以实现交易的非交互性、交易折叠、用户体验非常友好等，缺点是隐私性没有 RGB 本身那么好，但也只是降低到比特币区块链的隐私保护水平。另外，需要指出的是，RGB 的隐私保护也不是完美的，因为发送方需要提供资产的所有历史证明，接收方能看到发送方之前的交易记录。在 CKB 上，其实可以用 Mimblewimble 协议来隐匿交易金额、斩断交易历史，让 RGB++ 拥有更好的隐私性，不过第一阶段团队没有精力去做这个。
另外，Cipher 还提到了 X 上关于 RGB++ 协议的一些争议，他认为大家可以做学术讨论，但不应该一上来就扣帽子说它是 scam。点此查看 Cipher 对于争议的回应。
最后，Cipher 还谈到了兼容性问题。RGB 用的是 AIuVM，RGB++ 第一版用的是 CKB-VM，技术上是不兼容的，但得益于 CKB-VM 使用的是 RISC-V 指令集，后续可以把 AIuVM 编译到 CKB-VM 上，做一个 RGB 兼容层。除此之外，还可以通过 jump 的方式实现资产的打通。
3. RGB++ 协议区别于 RGB 的地方#
CyberOrange 提到，RGB 最重要的两个技术是一次性密封和客户端验证，前者让 RGB 资产受到比特币区块链的保护，后者主要是验证 RGB 资产的交易。RGB++ 协议，除了让 RGB 用户使用客户端验证之外，还让他们多了一个选择 —— CKB 链上验证。如果交易的数额不是很大，用户可以不用自己去做一个完整的客户端验证，而是选择 CKB 脚本的验证。
第二点是隐私性，RGB++ 协议把数据放在 CKB 链上，让 CKB 充当 DA 层，其隐私性低于原版的 RGB 协议，这点前面 Cipher 有详细介绍。正如硬币有两面，把 CKB 作为 DA 层，设计 DEX 或者其他 DeFi 应用就会简单许多。
第三点是扩容能力的区别。理论上 RGB 的扩容能力可能会更强一点，因为它的客户端验证不需要区块链，但实际上 RGB++ 协议也可以借助其他的一些机制来实现扩容。
最后，CyberOrange 提到，RGB++ 和 RGB 也是可以实现兼容的。RGB 支持类似 jump 的操作，可以让 RGB 资产从一条 UTXO 链 jump 到另一条 UTXO 链，而 CKB 区块链也能支持这项功能，从而打通 RGB 资产和 RGB++ 资产。
「极客 Web3」创始人 Fasut 提到，RGB 的很多理念跟状态通道有点像，都是需要 verify by yourself（自己验证）。RGB 网络就像是无数个 OTC 玩家组成的网络，转账不需要取得所有人的共识，只需交易双方同意即可，交易的内容也只有交易双方知道。
不过，Fasut 提到，由于 RGB 交易发送方需要提供资产的所有历史记录，如果这笔资产转手次数特别多，数据量大，可能会带来存储压力和传输压力。另外，RGB 还存在资产碎片化存储的问题，每个人只存放跟自己有关的资产数据，每个人的客户端存储的数据都不一样，如果某个用户的客户端出了问题，数据又没有备份，那他的资产就永远动不了了。所以 Fasut 认为 RGB 牺牲了可用性来换取隐私性。
在 Fasut 看来，RGB++ 更像是 “乐观 RGB”，类似于乐观汇总（Optimistic Rollup），需要让用户相信第三方（这里指 CKB 区块链）不会作恶。RGB++ 把 RGB 的所有数据放到 CKB 链上，同时由 CKB 节点来验证 RGB 资产的交易，实现了可用性，让传统的 RGB 协议省去了很多麻烦。关于 RGB 和 RGB++，「极客 Web3」发布了一篇介绍非常全面的文章，欢迎还未看过的小伙伴点击链接阅读。
不过在 CyberOrange 看来，RGB++ 并不是强迫用户要去相信 CKB，而是提供了一个额外的选择，用户当然也可以自己使用 RGB 客户端来验证所有的交易。
关于前面提到的数据存储压力，花椒澄清说这已经不是问题了，Maxim 博士之前就有考虑这点，而且有钱包内嵌了本地的数据库，不再需要用户个人去单独运行 RGB 节点。关于 RGB 交易的 invoice，花椒咨询了 RGB 开发者，在主网上可以实现离线交易，但在闪电网络的通道里不行，必须交易双方同时在线。关于无主合约，RGB 没有 global state（全局状态），所以基于 RGB 做 DeFi 应用会很难，Maxim 博士为此设计了 Bifrost，它相当于闪电网络的一个子版本，每个 Bifrost 的通道相当于一个 Layer3，可以实现更多意义上的扩容。
4. RGB++ 的时间表#
Cipher 希望在今年 3 月底之前完成 RGB++ 协议第一版的 MVP，包含 RGB++ 在主网的上线，一个在 Layer2 上的支持 fungible token 和 NFT 的 DEX，以及对应的钱包和浏览器。
另外，Cipher 也在为 RGB++ 协议招募熟悉 Rust 和 C 语言的开发者，感兴趣的小伙伴可以单独联系他。
5. Q&A 环节#
Q1：RGB++ 对开发者的友好程度如何？
Cipher：无论是 RGB 还是 RGB++，开发者的主要工作都是在链外，而不是在比特币链上。对于 RGB 来说，开发者的大部分工作是怎么组装 RGB 交易、怎么生成 RGB 证明、在 RGB 上怎么写合约等等，在 RGB++ 上要做的事情是一样的，只不过很多事情 CKB 区块链直接给解决了。以做 DEX 为例，在 CKB 上变成了如何做一个能接受 RGB++ 资产的 DEX，它的开发难度和在 CKB 上开发其他合约的难度差别不大。目前 CKB 上的开发工具相对比较完善了，一个熟练的开发者经过几天的学习后，大概就可以上手做了。
Q2：RGB++ 和 CKB 代币之间是什么关系？
Cipher：每一笔 RGB++ 的交易，都会同步发出一笔比特币交易和一笔 CKB 交易。每一个 RGB++ 生态里的用户，其交易或者资产或者状态，在 CKB 链上都会有一个对应的 UTXO（Cell），会占用和使用一部分的 CKB。另外，开发者也会在 CKB 链上去开发合约。
Q3：CKB 获取到 RGB 的交易后，会压缩吗？
Cipher：《RGB++ Protocol Light Paper》里有提到交易折叠，可以将多笔 CKB 交易与一笔 Bitcoin RGB++ 交易对应，这样就可以将低速低吞吐量的 Bitcoin 链使用高性能的 CKB 链进行扩容。
另外就是状态压缩，CoTA 协议很早就实现了，你持有不论多少数量的代币，都可以压缩到一个 32 字节的空间里面。RGB++ 能不能实现类似的状态压缩，目前还没有做太多的研究，不过这是一个很好的方向。
Q4：如果在 CKB 上做开发，像 Subgraph、Oracle 等配套工具有吗？还是说需要等第三方来支持？
CyberOrange：预言机目前 CKB 链上还没有。其他的一些接口，CKB 有一个数据的编解码标准，可以用那个标准去解析数据，不过可能需要手动去编写一些东西。
Q5：CKB 的 tps 是多少？
CyberOrange：如果是简单转账的话，CKB 的 tps 可以达到 300 多。
Q6：RGB++ 安全性的文章里提到，比特币 6 个区块确认才几乎不会被 revert，CKB 大概需要 20 几个区块，这会不会对 RGB++ 的用户体验产生影响？用户可能不想等那么久？
Cipher：如果你只是发一笔一层的交易，它会同步发一笔 CKB 的交易，这个主要取决于比特币的出块速度，不需要等那么多区块确认，它其实和比特币上的转账体验一样。你提到的需要等 6 个区块确认，是资产从比特币 Layer1 上 jump 到 CKB 上，为了保证安全性，需要 6 个比特币区块确认后，才可以解锁 jump 过来的资产在 CKB 上的操作。这是由智能合约控制的，不需要多签或者第三方。之后在 CKB 链上的操作，只需等 CKB 上的十秒钟出块时间，如果要 jump 回到比特币链上，为了保证安全性，需要等 20 几个 CKB 区块确认。jump 的操作并不频繁，所以对用户体验的影响没有那么大，而且其他跨链方案往往也是要等比较长时间的。
Q7：计划 3 月底之前出来的 DEX，支持比特币铭文等资产吗？
Cipher：是的。