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
来源：https://talk.nervos.org/t/rgb-protocol-light-paper/7733
通过“同构映射”，实现了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老师的看法
来源：https://twitter.com/AurtrianAjian/status/1755121187741720964
4.2 对于RGB：RGB++扩充了其与其他UTXO架构公链结合的可能性
RGB协议本身就有与其他UTXO架构公链结合的可能性，LNP/BP协会的官推表明会支持与Liquid的互操作性。
来源：https://x.com/lnp_bp/status/1747930079252951058?s=20
通过CKB与RGB部分技术的结合，会在一定程度上验证这种结合的“实践有效性”。
更近一步来说：如果我们将RGB++协议再抽象一下，变成一个更加宽泛的扩展层，用于对接RGB协议与所有UTXO架构且有一定扩展性的公链，那么它的叙事和价值会大大增强，这也是我认为Cipher有可能会在下一阶段努力的方向。
同时，这也为RGB生态中的项目发展提供一些其他的备选项，这种备选项不同于简单的“多签跨链桥”，而是基于原生的方式。
对于其他比特币L2：提供了融合RGB协议的技术参考
Cipher对于RGB技术架构的解析化，会对其他L2的技术人员提供一个很好的思维范例。
它们可以结合自身项目的技术特点和优势，融合上RGB中部分它们需要的技术，然后“组合”成一个新的产品范式，甚至实现“抢跑”（这里的“抢跑”并不是贬义词，它反映的是技术的组合性和BTC生态发展中的创新性，同时“抢跑”也依然会促进RGB协议的普及和发展）
总的来说，尽管RGB++现在仅仅处于白皮书阶段，但是从理论上看，我对其比较看好，这会会为RGB协议带来新的血液，也可能会唤醒CKB网络的活力。
微信扫一扫 
