2 月 13 日，CKB 的联合创始人 Cipher 提出了 RGB 的扩展协议：RGB++。随即在市场上引起很多人的关注，也在一定程度上影响了 CKB 的二级市场价格。
在这份协议出来之前，我与 Cipher 针对 RGB 协议有过几次深入的交流，讨论了该协议的雏形构思，因此写一个短篇阐述我对于 RGB++ 这个协议的通俗理解、个人看法及我认为该协议可能的作用。
1、概述 RGB++：扩展 RGB 技术的使用场景
概括来说，理解 RGB++ 分为以下几点：
1.1 它是一个基于 RGB 的扩展协议
它利用了部分 RGB 协议中的技术，严格上不完全属于 RGB 的生态项目，但是扩展了 RGB 技术的使用场景。
1.2 它扩展了当下 RGB 协议的能力
解决了当下 RGB 协议在实际落地中的技术问题，并提供了更多的可能性，比如「验证环节」、「合约可编程性」、「图灵完备的虚拟机」等。
1.3 它是通过 UTXO 同构映射来实现的
将比特币 UTXO 映射到 Nervos CKB 的 Cell 上，并利用 CKB 链和 Bitcoin 链上的脚本约束来验证状态计算的正确性和变更所有权的有效性。这种同构映射的思路我认为有较强的可扩展性。
2、为什么要提出 RGB++ 协议？
熟悉我的朋友知道，我是一个深耕 RGB 协议的研究者，一直跟进 RGB 协议的发展和生态的发展情况。在持续的调研中，我发现尽管 RGB 协议在设计上非常美好，但是在实际落地过程中存在一些问题：
2.1 RGB 开发相对缓慢
原因之一是绝大部分的设计都是新的理念或是形成一个新的标准，这些都需要细致的全局构思和全新的代码实现。
原因之二是整个协议层参与的开发者数量较少，从 LNP/BP 的人员构成还有当下生态项目的数量可见一斑。
2.2 RGB 的开发会受到一些非受控的因素的影响
比如：RGB 一般来说要构建在闪电网络上，然而当前的 bolt-ln 又不能很好地支持 RGB 的合约，所以 LNP/BP 协会提出了一个新的闪电网络标准 bifrost，但是这又需要很多的工作要做，甚至需要等待闪电网络的整体发展。
再比如：RGB 的转移中会涉及到 invoice 和 committee 的传递，当前可以通过比如 web2（推特、tg 等等）或者 p2p 的网络来进行，但是如果从统一层面来看的话，需要一个标准的传输标准来进行，这是 storm 节点，但是构建这样的网络也需要很多工作要做。
2.3 RGB 的 AluVM 虚拟机目前缺乏完善的开发工具和实践代码
也就是说，即使现在 v0.11 完全 release 了，也仍然需要不少时间来检验虚拟机的性能和可靠性，也需要很多时间来积累通过 AluVM 开发代码的经验甚至标准库。
这些问题让 RGB 在这个争分夺秒的市场多少显得有些异类，很像是 BTC 早期时代的开发状态，这会带来很多不确定性，市场周期的影响（错过资金牛市期），情绪的影响，其他新技术融合（其他技术与 RGB 部分技术的结合实现「抢跑」）的影响等等。
概括成一句话，就是：RGB 极具成长性，但协议完全体落地需要时间较长且具有不确定性。
这就是 RGB++ 协议提出的背景和要解决的问题。
3、RGB++ 解决方案的技术重点：同构映射
因此，在早期的交流中，重点在「如何解决 RGB 落地中的这些问题」、「是否可以利用 CKB 现有的技术来一定程度上解决这个问题」上。
Cipher 创造性地利用了 RGB 的核心点「UTXO」和 CKB 的底层架构同源的特点，提出了「同构映射」的方案，并逐渐铺设出了「RGB++」的协议内容。
参看下图，他将 RGB 协议中的两个关键点与 CKB 的架构做了结合：
1）作为 RGB 容器的 UTXO 可以和 CKB 的 Cell 进行映射，通过 Cell 中的 lock 来实现。
2）作为验证的链下客户端验证可以转变成 CKB 的链上公开验证，验证的数据和状态可以对应上 Cell 里的 data 和 type。
通过「同构映射」，实现了 RGB 上 committee 在 CKB 上进行解析的过程，并且，配合兼容性，用户依然可以在 RGB 上进行解析，这是非常有意思的功效。
如果再深入分析，事实上 Cipher 将 RGB 的技术进行了「解析化」、「模块化」，然后思考某一个模块是否可以有其他的技术路线或者替代选项，从而衍生更多的可能性。
而在「同构映射」后，扩展性就自然而生，可以实现各项扩展功能。
3.1 交易折叠
利用 CKB Cell 的可编程能力，可以将多笔 CKB 交易与一笔 Bitcoin RGB++ 交易对应，这样就可以将低速低吞吐量的 Bitcoin 链使用高性能的 CKB 链进行扩容。
如果将「交易折叠」再做扩展，原则上并不是每一次状态变化都需要在 Bitcoin 上同步，相当于在 CKB 上加入了「链下验证」这样的选项。
3.2 无主合约
无主合约指的是任何人在满足合约的约束前提下都可以对状态进行变更，而不要求指定的数字签名提供方进行变更。
这种合约为复杂的合约方式比如 AMM 等创造了基础。
3.3 非交互式转移
RGB 协议转账的一个提点是需要双方通讯某些信息才能完成，其带来了一定的优势（不会收到 scam 的 token 等），但是也增加了用户理解难度和产品复杂度。RGB++ 可以利用当前的优势，将交互行为放置在 CKB 环境里面，采用发送-领取两步操作来实现非交互式转账逻辑。
这种转账逻辑是实现大规模空投的基础。
3.4 AMM+DEX
可以引入 CKB 的网格 AMM 设计，从而实现基于 UTXO 的做市商模型，虽然与 Uniswap 的价格曲线做市模型不同，但是对于 UTXO 模型来说已经是长足的进步了。
4、RGB++ 协议的作用
由于协议刚提出，具体的开发实现还没有完成，加上很多人对于 RGB 协议本身并不足够了解，因此对于 RGB++ 可能引起的「化学反应」还不太敏感，我将从以下几个层面阐述我对于 RGB++ 协议作用的观点：
4.1 对于 CKB：RGB++ 会是其争夺比特币正统 L2 市场的关键锚点之一
CKB 因其 POW 机制+增强的「UTXO」模型享有「正统性」，但其网络及生态发展在早期的众多明星机构投资后并没有亮眼的表现。
其在今年转向到比特币 L2 后，我认为这对于 CKB 是一个重大的机遇期。一方面相关的技术底层、基础建设经过这几年的发展已经逐步完善，另一方面算是恰逢其会了这一轮的热点。
在和 Cipher 的聊天中，他提出一个让我非常受益的观点：比特币 L2 之争的关键点在于 L1。
RGB++ 让 CKB 与比特币主链之间产生了更深刻的联系，从而为其带来了更多的「正统性」，这就是我认为其是关键锚点之一的原因。
题外话：关于「正统」L2
L2 的概念相对成熟的说法是从 ETH 上发展而来的，随着各种 L2 方案的发展、模块化的发展，L2 的定义越来越模糊，在 ETH 上更贴近于实用主义的思路，所谓「正统」的概念是慢慢淡化的。
但是对于比特币网络而言，「正统」的概念一直以一种比较强的信号呈现于其整个发展过程中。当下，按照我个人的观点，L2 的「正统性」强度（由高到低）依次为：
1）闪电网络、RGB、BitVM
对于这三者大家都比较熟悉了，总体来说，三者实现的路径有本质上的区别，且针对的点也有所不同，当前发展程度闪电网络相对最为成熟，其次是 RGB，最后是 BitVM。
2）侧链
诸如 Liquid、 Stacks 、CKB 之类，他们大多数依然是基于 UTXO 的架构，加上一定的变形或者创新，实现在扩展性（如隐私性、可编程性）的提升、共识机制上的优化。
侧链在一定程度上可以理解为 BTC 的实验链，实验在 BTC 主链上的一些新功能或暂时无法实现的功能。
3）其他
这部分可能包括「基于跨链协议的 L2」、「基于 EVM 的 L2」等，我基本赞同 Ajian 老师的看法：
4.2 对于 RGB：RGB++ 扩充了其与其他 UTXO 架构公链结合的可能性
RGB 协议本身就有与其他 UTXO 架构公链结合的可能性，LNP/BP 协会的官推表明会支持与 Liquid 的互操作性。
通过 CKB 与 RGB 部分技术的结合，会在一定程度上验证这种结合的「实践有效性」。
更近一步来说：如果我们将 RGB++ 协议再抽象一下，变成一个更加宽泛的扩展层，用于对接 RGB 协议与所有 UTXO 架构且有一定扩展性的公链，那么它的叙事和价值会大大增强，这也是我认为 Cipher 有可能会在下一阶段努力的方向。
同时，这也为 RGB 生态中的项目发展提供一些其他的备选项，这种备选项不同于简单的「多签跨链桥」，而是基于原生的方式。
对于其他比特币 L2：提供了融合 RGB 协议的技术参考
Cipher 对于 RGB 技术架构的解析化，会对其他 L2 的技术人员提供一个很好的思维范例。
它们可以结合自身项目的技术特点和优势，融合上 RGB 中部分它们需要的技术，然后「组合」成一个新的产品范式，甚至实现「抢跑」（这里的「抢跑」并不是贬义词，它反映的是技术的组合性和 BTC 生态发展中的创新性，同时「抢跑」也依然会促进 RGB 协议的普及和发展）。
总的来说，尽管 RGB++ 现在仅仅处于白皮书阶段，但是从理论上看，我对其比较看好，这会会为 RGB 协议带来新的血液，也可能会唤醒 CKB 网络的活力。
（声明：请读者严格遵守所在地法律法规，本文不代表任何投资建议）
