查看原文
其他

RGB协议——引爆这一轮比特币生态大爆发!

B圈的咏琪 B圈的咏琪
2024-11-29

本文我会从以下几个层面来为各位详细的解读一下RGB协议:

  • 什么是RGB++协议?
  • RGB协议特性优势
  • 什么是链上Dobs?
  • Spore DOB的意义?
  • 概述 RGB++:扩展 RGB 技术的使用场景
  • 为什么要提出 RGB++ 协议?
  • RGB++ 解决方案的技术重点
  • RGB++ 协议的作用
  • RGB 与其它方案的比较

什么是RGB++协议?

要了解RGB++协议,就不得不先清楚其祖上RGB协议的逻辑:RGB协议通俗的讲是一种用户自我验证的链下行为,是一种特殊的P2P资产协议,是比特币链下的计算系统,无论你是资产的发送者还是接收者,都要亲自运行客户端,自行验证与自己有关的转账行为,俗称“交互式转账”,这和我们目前最常用的大量节点参与的共识验证完全背道而驰,很多人不理解抛去了共识验证为什么RGB协议还会诞生?协议转账是否安全?

RGB协议特性优势

1. 极强的隐私性没有了共识验证RGB协议所有的转账也就不被网络内任何节点观测到,可以随时更换交易对手方,不需要把交易请求发送给某些个数量有限的节点,除了转账的发起者和接收者,整个交易过程得到了极强的隐私保障,也给RGB网络赋予了比以太坊等网络更强的抗审查性

2. 极高的安全性由于RGB协议采用的是客户端验证的方式,用户需要自己运行客户端,亲自验证和自己相关的资产变动,例如转账者A发送一个BTC给接收者B,A需要先将转账信息和所涉及的资产数据发送给B,B亲自进行检查无误之后再将同意接收的信息发送给A,A再进行转账操作,过程中B为了防止收到假的代币或者有问题的资产,在检查时需要仔细查看A所提供的资产溯源信息以及证明,

3. 验证抗压性弱RGB协议独特的自我客户端验证方式虽然具有隐私性和安全性,但也仅针对小数量的交易数据验证,如果大批量的交易或者资产溯源过长的交易需要验证时,每笔交易都要求双方进行多次通讯,接收方要先验证发送方的资产来源,然后发送回执,批准发送方的转账请求,整个过程双方之间至少要产生三次消息传递,这将大大降低验证效率拉长验证时间 任何事物都具有两面性,RGB协议具有极强的隐私和安全属性的同时,也暴露出了数据不透明和大量交易笨拙的弊端,然而事物的发展就是取长补短,为了消除RGB协议的劣势,保存其优势,诞生了RGB++协议,下文会针对RGB++协议做专门的分析。

什么是链上Dobs?

Dobs释义为数码物,看过数码宝贝的我们不难理解,给代码赋予“生命”让它展示出成长类的体验是整个互联网时代的梦想,固定的代码不再代表固定的体现,就像人类起源是细胞,细胞分裂发展成不同的物种一样,如果你所购买的NFT能够成长为自己所期待的样子那该是多么酷的一件事,Spore DOB-0 协议把你的想象将变成现实 Spore 是部署在 CKB 区块链上的通用数码物创造协议,支持图像、链接、视频、音频、文本、代码等多种内容类型,生成的 DOB不可篡改并且完全存储于链上,而Spore DOB-0 协议是建立在 Spore 基础之上更加偏向于应用层的协议

Spore DOB的意义

1. 可组合性高:我们知道LOOT的火爆是因为其将短短几行的随机文字生成并存储在以太坊区块链上供任何人以任何方式阐释和使用,既有很强的随机性也有很高的自由创造性,但LOOT是将解码器Decoder和解码标记Pattern是融为一体的,Spore DOB则将其剥离,不同的解码器和不同的解码标记组合会产生不同的DOB主题,另外相比LOOT单一随机数的解码标记,Spore DOB的Pattern则是一串DNA字符串,随机的维度更广,可组合性也更高。

2. 唯一性强:我们知道哈希函数的最强特性就是抗碰撞性,哪怕改变其中一个很不起眼的字符都会产生不同的哈希值,DOB 的 DNA 通过哈希计算而来就是沿用了其抗碰撞性,也代表了每个DNA的唯一性。

3. 进化能力大:DOB 的 DNA包含了创作者根据其需要对 DOB 的各种属性进行定义和赋值的重要信息,但这只是基础,用户铸造DOB后,可以根据自己的喜好丰富 DNA 所表达的内容,并通过绘画、建模、音乐、文字描述等各种方式在社区中进行展示,甚至还可以在前端接入 AI 大模型,让 DOB 随着大模型的持续迭代而不断进化。

概述 RGB++:扩展 RGB 技术的使用场景

理解 RGB++ 分为以下几点:

5.1 它是一个基于 RGB 的扩展协议

它利用了部分 RGB 协议中的技术,严格上不完全属于 RGB 的生态项目,但是扩展了 RGB 技术的使用场景。

5.2 它扩展了当下 RGB 协议的能力

解决了当下 RGB 协议在实际落地中的技术问题,并提供了更多的可能性,比如「验证环节」、「合约可编程性」、「图灵完备的虚拟机」等。

5.3 它是通过 UTXO 同构映射来实现的

将比特币 UTXO 映射到 Nervos CKB 的 Cell 上,并利用 CKB 链和 Bitcoin 链上的脚本约束来验证状态计算的正确性和变更所有权的有效性。这种同构映射的思路我认为有较强的可扩展性。

6⃣为什么要提出 RGB++ 协议?

6.1 RGB 开发相对缓慢

原因之一是绝大部分的设计都是新的理念或是形成一个新的标准,这些都需要细致的全局构思和全新的代码实现。

原因之二是整个协议层参与的开发者数量较少,从 LNP/BP 的人员构成还有当下生态项目的数量可见一斑。

6.2 RGB 的开发会受到一些非受控的因素的影响

比如:RGB 一般来说要构建在闪电网络上,然而当前的 bolt-ln 又不能很好地支持 RGB 的合约,所以 LNP/BP 协会提出了一个新的闪电网络标准 bifrost,但是这又需要很多的工作要做,甚至需要等待闪电网络的整体发展。

再比如:RGB 的转移中会涉及到 invoice 和 committee 的传递,当前可以通过比如 web2(推特、tg 等等)或者 p2p 的网络来进行,但是如果从统一层面来看的话,需要一个标准的传输标准来进行,这是 storm 节点,但是构建这样的网络也需要很多工作要做。

6.3 RGB 的 AluVM 虚拟机目前缺乏完善的开发工具和实践代码

也就是说,即使现在 v0.11 完全 release 了,也仍然需要不少时间来检验虚拟机的性能和可靠性,也需要很多时间来积累通过 AluVM 开发代码的经验甚至标准库。

这些问题让 RGB 在这个争分夺秒的市场多少显得有些异类,很像是 BTC 早期时代的开发状态,这会带来很多不确定性,市场周期的影响(错过资金牛市期),情绪的影响,其他新技术融合(其他技术与 RGB 部分技术的结合实现「抢跑」)的影响等等。

概括成一句话,就是:RGB 极具成长性,但协议完全体落地需要时间较长且具有不确定性。这就是 RGB++ 协议提出的背景和要解决的问题。

7⃣RGB++ 解决方案的技术重点:同构映射

Cipher 创造性地利用了 RGB 的核心点「UTXO」和 CKB 的底层架构同源的特点,提出了「同构映射」的方案,并逐渐铺设出了「RGB++」的协议内容。

参看下图,他将 RGB 协议中的两个关键点与 CKB 的架构做了结合:

1)作为 RGB 容器的 UTXO 可以和 CKB 的 Cell 进行映射,通过 Cell 中的 lock 来实现。

2)作为验证的链下客户端验证可以转变成 CKB 的链上公开验证,验证的数据和状态可以对应上 Cell 里的 data 和 type。

通过「同构映射」,实现了 RGB 上 committee 在 CKB 上进行解析的过程,并且,配合兼容性,用户依然可以在 RGB 上进行解析,这是非常有意思的功效。

7.1 交易折叠

利用 CKB Cell 的可编程能力,可以将多笔 CKB 交易与一笔 Bitcoin RGB++ 交易对应,这样就可以将低速低吞吐量的 Bitcoin 链使用高性能的 CKB 链进行扩容。

如果将「交易折叠」再做扩展,原则上并不是每一次状态变化都需要在 Bitcoin 上同步,相当于在 CKB 上加入了「链下验证」这样的选项。

7.2 无主合约

无主合约指的是任何人在满足合约的约束前提下都可以对状态进行变更,而不要求指定的数字签名提供方进行变更。

这种合约为复杂的合约方式比如 AMM 等创造了基础。

7.3 非交互式转移

RGB 协议转账的一个提点是需要双方通讯某些信息才能完成,其带来了一定的优势(不会收到 scam 的 token 等),但是也增加了用户理解难度和产品复杂度。RGB++ 可以利用当前的优势,将交互行为放置在 CKB 环境里面,采用发送-领取两步操作来实现非交互式转账逻辑。这种转账逻辑是实现大规模空投的基础。

7.4 AMM+DEX

可以引入 CKB 的网格 AMM 设计,从而实现基于 UTXO 的做市商模型,虽然与 Uniswap 的价格曲线做市模型不同,但是对于 UTXO 模型来说已经是长足的进步了。

8⃣RGB++ 协议的作用

8.1 对于 CKB:RGB++ 会是其争夺比特币正统 L2 市场的关键锚点之一

CKB 因其 POW 机制+增强的「UTXO」模型享有「正统性」,但其网络及生态发展在早期的众多明星机构投资后并没有亮眼的表现。

其在今年转向到比特币 L2 后,我认为这对于 CKB 是一个重大的机遇期。一方面相关的技术底层、基础建设经过这几年的发展已经逐步完善,另一方面算是恰逢其会了这一轮的热点。

比特币 L2 之争的关键点在于 L1。

RGB++ 让 CKB 与比特币主链之间产生了更深刻的联系,从而为其带来了更多的「正统性」,这就是我认为其是关键锚点之一的原因。

8.2、关于「正统」L2

L2 的概念相对成熟的说法是从 ETH 上发展而来的,随着各种 L2 方案的发展、模块化的发展,L2 的定义越来越模糊,在 ETH 上更贴近于实用主义的思路,所谓「正统」的概念是慢慢淡化的。

但是对于比特币网络而言,「正统」的概念一直以一种比较强的信号呈现于其整个发展过程中。当下,按照我个人的观点,L2 的「正统性」强度(由高到低)依次为:

1)闪电网络、RGB、BitVM

对于这三者大家都比较熟悉了,总体来说,三者实现的路径有本质上的区别,且针对的点也有所不同,当前发展程度闪电网络相对最为成熟,其次是 RGB,最后是 BitVM。

2)侧链

诸如 Liquid、 Stacks 、CKB 之类,他们大多数依然是基于 UTXO 的架构,加上一定的变形或者创新,实现在扩展性(如隐私性、可编程性)的提升、共识机制上的优化。

侧链在一定程度上可以理解为 BTC 的实验链,实验在 BTC 主链上的一些新功能或暂时无法实现的功能。

3)其他

这部分可能包括「基于跨链协议的 L2」、「基于 EVM 的 L2」等。

8.3对于 RGB:RGB++ 扩充了其与其他 UTXO 架构公链结合的可能性

RGB 协议本身就有与其他 UTXO 架构公链结合的可能性,LNP/BP 协会的官推表明会支持与 Liquid 的互操作性。

通过 CKB 与 RGB 部分技术的结合,会在一定程度上验证这种结合的「实践有效性」。

更近一步来说:如果我们将 RGB++ 协议再抽象一下,变成一个更加宽泛的扩展层,用于对接 RGB 协议与所有 UTXO 架构且有一定扩展性的公链,那么它的叙事和价值会大大增强,这也是我认为 Cipher 有可能会在下一阶段努力的方向。

同时,这也为 RGB 生态中的项目发展提供一些其他的备选项,这种备选项不同于简单的「多签跨链桥」,而是基于原生的方式。

8.4、对于其他比特币 L2:提供了融合 RGB 协议的技术参考

Cipher 对于 RGB 技术架构的解析化,会对其他 L2 的技术人员提供一个很好的思维范例。

它们可以结合自身项目的技术特点和优势,融合上 RGB 中部分它们需要的技术,然后「组合」成一个新的产品范式,甚至实现「抢跑」(这里的「抢跑」并不是贬义词,它反映的是技术的组合性和 BTC 生态发展中的创新性,同时「抢跑」也依然会促进 RGB 协议的普及和发展)。

总的来说,尽管 RGB++ 现在仅仅处于白皮书阶段,但是从理论上看,我对其比较看好,这会会为 RGB 协议带来新的血液,也可能会唤醒 CKB 网络的活力。

9⃣RGB 与其它方案的比较

有兴趣接受 RGB 协议的人可能会感到困惑,它跟其它代币协议相比如何呢?我们用几个例子来分析一下:

9.1基于山寨币的代币

大部分基于山寨币的代币协议(例如 ERC-20)提供了具备全局无主状态(global unowned state)的智能合约,这使得部署去中心化交易做和其它金融应用变得很容易,但它们很难扩展、没有隐私性,也继承了这些山寨币所有的缺点,比如运行节点的成本很高、更低的去中心化和审查抗性。

Liquid 资产

Liquid 是一个比特币的联盟侧链,提供了一些有趣的功能,比如原生的资产支持以及机密交易(可以隐藏被转移的资产的 ID 和支付的数量)。但是,联盟模式也一样有低去中心化和审查抗性较弱的问题。

OmniBolt

OmniBolt 是 OmniLayer 的兼容闪电网络的版本。而 OmniLayer 在本文的开头我们已经简要介绍过了。它的取舍跟 RGB 非常相似,但隐私性和可扩展性更差,因为代币相关的数据都存放在链上。

Taro

RGB 和 Taro 的主要区别似乎在于,RGB 已经放出了可以审核的代码,而 Taro 还只是一种规范,但另一方面,你也可以说 Taro 是由闪电网络生态中最棒的团队之一背书的,这给未来的实现创造了良好的预期。出于它们的相似性,如果 Taro 和 RGB 最终可以相互操作,那就最好了,但只有时间能告诉我们让这种互操作性得以发生的激励因素存不存在。

9.2构建一笔CKB交易

(1)构建交易输入在输入中放入一个已绑定在比特币UTXO#0上的CKB 。

(2)构建交易输出创建CELL#1:用于设定RGB++资产所有权转移的条件,并将资产所有权从一个比特币UTXO转移到另一个比特币UTXO。

(3)计算Commitment即根据CKB交易数据计算哈希值,并把哈希值以commitment的形式写入比特币交易的OP_RETURN输出里面,这一步也由CKB系统自动完成。计算使用到的元数据包括CKB交易的输入输出数据,还有绑定的所有比特币UTXO数据。

(4)提交比特币交易这一步应该是由用户操作,在发起比特币交易的时候,在提交之前应该需要等待一会儿,系统会自动根据这笔交易在后台构建出CKB交易,并计算出哈希值填入到比特币交易的OP_RETURN里面,然后用户才可以点确认支付按钮。

(5)写入比特币数据CKB链上集成了比特币的轻节点,在智能合约层实现了一个比特币的轻客户端,可以实现对比特币的交易和区块数据的读取,并把比特币块头哈希数据写入CKB轻客户端保存的CELL里面。

(6)验证比特币交易根据Relayer写入的比特币区块头数据,CKB上的轻客户端可以验证比特币的某一笔交易是不是真的存在比特币的链上,它的UTXO信息是否有效,以及是不是能够与Commitment提供的信息进行匹配,还可以验证比特币交易里面的commitment是否与CKB交易的数据相吻合。

(7)CKB交易上链如果上一步验证的结果吻合,这笔CKB链上的交易会由中继器或者聚合器自动提交上链。由于CKB实现了完全的账户抽象和无主合约能力,因此这笔交易验证不需要用户提供签名,只需要根据前一步的验证结果提供比特币交易已经上链的证明就可以通过验证,通过验证,这笔CKB就会上链,如果没有通过,说明在比特币交易提交之后,CKB交易做了修改,交易数据跟Commitment对不起来,那么交易就会失败。

(8)交易费用

一笔RGB++交易,一般会涉及这几个费用 第一:比特币链上交易的手续费 第二:Paymaster的收费,这个部分包括CKB链上交易的收费。好像现在是7000聪,大概几美金 第三:如果有第三方参与,可能还会有第三方的收费。

如果你对RGB协议还有什么不懂的,或者是还有什么更高深的见解可以私信我


继续滑动看下一个
B圈的咏琪
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存