比特币跌破67000美元一枚,
几分钟速通RGB与RGB++协议设计:白话说明书
作者:Faust,极客web3 & BTCEden.org 联创
随着RGB++及相关资产发行的火热,关于RGB与RGB++协议原理的讨论逐渐成为更多人关注的话题。但大家意识到,要理解RGB++,必须先理解RGB协议。
原始的RGB协议在技术构造上略为晦涩,参考资料较为零散,至今没有多少系统性且较通俗易懂的参考资料,极客web3此前虽曾发表过两篇关于RGB与RGB++的系统性解读文章(可以看我们公号的历史记录),但据社区成员反馈,前述文章篇幅较亢长且太烧脑。
为了让更多人能更快理解RGB与RGB++协议,本文作者在香港活动期间,临时赶工完成了一篇关于RGB与RGB++的简短白话解读,可以在几分钟内读完,希望帮助更多社区爱好者更好、更直观的理解RGB与RGB++。
RGB协议:用户要亲自做数据验证
RGB协议是一种特殊的P2P资产协议,是比特币链下的计算系统,它在某些方面与支付通道类似:用户要亲自运行客户端,自行验证与自己有关的转账行为(Verify by yourself)。即便你只是一个资产接收者,也要先确定资产发送者的转账声明没有错误,然后这笔转账声明才能生效。显然这与传统的资产发送与接收形式截然不同,我们将其称之为“交互式转账”。
为什么要这样?原因在于,RGB协议为了保障隐私,没有采用比特币和以太坊等传统区块链中的“共识协议”(数据一旦走共识协议,就会被网络内几乎所有节点都观测到,隐私不好保障)。如果没有大量节点都参与的共识流程,该如何保证资产变更是安全的?这里用到名为“客户端验证”的思想(Verify by yourself),你要自己运行客户端,亲自验证和你相关的资产变动。
假设有个RGB用户叫Bob,他认识Alice,Alice要给Bob转来100枚TEST代币。Alice生成了“Alice to Bob”的转账信息后,要先把转账信息和涉及的资产数据发送给Bob,让他亲自检查一遍,确定无误才会进入后续流程,最终成为一笔有效的RGB转账。所以说,RGB协议是让用户亲自验证数据有效性,取代传统的共识算法。
但没有了共识,不同RGB客户端接收和存储的数据都不一致,大家只在本地存储与自己有关的资产数据,不知道别人的资产状况,这在保护隐私的同时,也构成了“数据孤岛”。如果有人声称有100万枚TEST代币,要转给你10万枚,你如何相信他?
在RGB网络中,如果有人要给你转账,必须让他先出示资产证明,回溯资产从初始发行到多次转手的历史来源,确定要转给你的Token没问题,这就好比,当你收到来路不明的纸币后,你要求对方说明这些纸币的历史来源,是否是指定的发行方制造的,以此来规避假币。
(图片来源:Coinex)
上述流程是发生在比特币链下的,仅凭这些过程还无法让RGB与比特币网络产生直接关联。对此,RGB协议采用了名为“single use seal”的思想,把RGB资产与比特币链上的UTXO绑定起来,只要比特币UTXO没有被双重消费,绑定的RGB资产就不会发生双重支付,这样就可以借助比特币网络来防止RGB资产发生“Re-organization”。当然,这需要在比特币链上发布Commitment,并用到OP_Return操作码。
在此梳理一下RGB协议的workflow:
1. RGB资产与比特币UTXO有着绑定关系,而Bob拥有某些个比特币UTXO。Alice要给Bob转账100枚代币,在接收资产前,Bob事先告诉Alice,应该用Bob的哪个比特币UTXO绑定这些RGB资产。
(图片来源:极客web3/ GeekWeb3)
Alice构造一笔 “Alice to Bob” 的RGB资产转账数据,附带这些资产的历史来源交给Bob去验证。
Bob在本地确认这些数据没问题后,给Alice发送一个回执,告诉她:这笔交易可以通过了。
Alice把这笔“Alice to Bob”的RGB转账数据构建成一棵Merkle Tree,把Merkle Root发布到比特币链上作为Commitment,我们可以把Commitment简单理解为转账数据的hash。