很多人开始关注比特币的RGB协议,真的很开心。但是大部分人对于这样一个协议(尤其是技术相对复杂的协议)比较陌生,也不知道如何去研究和尝试该协议的内容和生态。
所以,特别写一篇持续更新的Mirror,来汇总相关的学习资料,提供一个相对来说合理的学习路径;同时,也作为个人学习RGB的一个记录。
第一部分:科普部分-初步认识RGB
很多人看到RGB这三个字,会想到“三原色:red green blue”。如果从图标上看,还真是这么回事,这是因为RGB协议有利用到早期的“染色硬币”的概念。
这里我们说的RGB是一个协议,一个可以在比特币主网、闪电网络或者类似网络上运行,极端隐私的、可扩展的智能合约系统协议。
这个协议目前由LNP/BP协议维护和更新,bitfinex也参与部分代码工作。
你很难将RGB简单划分为比特币L2的范畴,它没有自己的链、它没有自己的层、他可以运作在BTC的其他L2上,所以,准确来说:它是一项通用性的技术。
在业界,普遍认为RGB和Bitvm会是BTC拓展的终极形态,因为他们都可以基于BTC原生性实现BTC生态的可扩展性,相对于Bitvm的遥遥无期,RGB已经在逐步落地。
值得一提的是:RGB是一项不局限于crypto的技术,它可以广泛运用到我们非crypto的场景中,等到协议越来越成熟,我们会看到越来越多的用例。
从官方的介绍中,我们可以看到RGB协议可以实现的功能:
如果我们归类一下,可以看出:
从这个角度看,RGB可以让BTC具有现在EVM的绝大部分功能,但是它不是采用类似于“兼容EVM”的非原生形式实现的,而是原生实现的,不得不说这一套理论和设计理念很牛。
事实上,值得注意的是,RGB 智能合约系统与之前的方法都有很大不同,无论是基于比特币(彩色币、Counterparty、OMNI)还是非比特币(以太坊、EOS 等),它有自己独特的特性:
第一条的意思是,智能合约将进行更好的分层,发行人仅在发行时刻享有合约的权利,之后都是由状态所有者在不断的状态演化过程中享有权利;
第二条意思是,它将代码保留在链下,可以节省链上空间,提升运行速度,降低开发难度,但是又可以通过机制保证安全性;
第三条揭示了它的安全背书层(区块链),同时它是图灵完备的,可以支持简单的语言操作。
所以,下图可能更接近于正确的理解:
从Dr. Maxim Orlovsky的教学视频中,我们可以看到官方认定的RGB特性包括:
我们来逐一拆分讲解:
1️⃣极端隐私性
2️⃣高度安全性
这两点我还不怎么懂,需要研究下
3️⃣高度可扩展性
4️⃣不拥堵
5️⃣极高的融合性
所以,其实在我的眼里,RGB对于BTC更像是下面这样:
RGB协议相对于其他协议,有自己非常独特的技术点,这里简单科普几个重要的部分:
4.1 一次性密封
该技术最早由Peter Todd在2016年提出,主要意思是“把一条消息加上一个密封条,确保这个消息只能被使用一次,因为你要知道消息就必须拆除密封条”。
一种简单的方法是设置一个公证的第三方服务端,每当某一个密封条打开或者锁上时就在公开的注册处发布证书,这样任何人都能验证自己关心的密封条的状态。
如果不使用一个受信任的实体来实现一次性密封的功能,可以使用比特币的UTXO来作为密封条。因为比特币的任何一个UTXO只能被花费一次。因此,把UTXO作为密封条,就可以在UTXO创建的时候锁上,在花费它的时候打开。
RGB利用了这样的“一次性密封”技术,它将RGB资产的信息、合约的状态等都“包裹”在UTXO里面,当UTXO被花费的时候,资产的所有权、合约的状态就发生了转变。这意味着,每当一笔 RGB 交易发生时,实际上就是发送者给某个合约(定义了被转移的权利的那个)创建了一次状态变更。
以RGB20为例:
1️⃣首先,合约的发行者设定了合约的创始状态,定义了合约的细节:资产的名称、总供应量等,并且发行者有权移动这些供应量的 UTXO;
2️⃣当资产被第一次转移时,第一个 UTXO 的所有者就可以创建一次状态变更,定义哪一个 UTXO 将持有这项资产;
3️⃣状态变更可以应用在变更资产所有权的权利上,也可以应用在别的类型的权利上,例如,二次发行的权利,或者是添加/改变 资产的特定属性(例如:元数据)的权利等。
4.2 客户端验证
RGB的验证和传统的“全球共识”验证不同,采用的是“客户端验证”的技术。
传统的比特币验证,一个连接到网络的节点会持续不断地下载和验证区块以及交易池中的交易(全节点)。这样的节点对整条链上的 UTXO 集(区块链上所有未花费的输出的集合)有一个实时更新的试图,当它看到一笔新交易时,要验证其有效性,只需要验证该交易的所有输入都是该 UTXO 集的最新状态的一部分即可。
但是对于RGB而言,没有全局传播的数据,因此也没有这样的UTXO集的全局视图。一个 RGB 客户端在接受一笔交易后,不仅需要验证交易的最新状态是有效的,还必须对与交易相关的以往所有的状态转化作同样的验证,一路追溯到发行合约的创始状态。
这看起来会会带来一个明显的缺点:导致验证时间很长
但是这仅仅出现在“一项具有很长的交易历史的资产时”才会出现,而且可以通过一个数据分享层(自愿的情况下)提前开始验证这部分交易历史数据。
这同时可以带来明显的优点:客户端不需要知道、也不需要验证全局中发生的所有交易
因为它只需要知道跟自己钱包相关的交易即可,它不需要验证其他的交易,因此每个客户端要验证的数据量都更小,系统扩展性明显增强。
4.3 确定性的比特币承诺
RGB如何防止“双花”,是通过RGB承诺来实现的,这样的承诺需要实现:
1️⃣涉及合约的多次状态转换可以承诺到单笔比特币交易中
2️⃣每一次合约的状态转换都只能被承诺进比特币交易一次
实现的具体方式是:
1️⃣首先,跟某一个合约(或者说资产 ID)相关的所有状态转换,要确定性地聚合成一个承诺
2️⃣然后,所有被转移的资产的承诺,要被聚合成一棵默克尔树
3️⃣最终的根哈希值,就是最终的 RGB 承诺;
4️⃣为了保证跟其它无关 RGB、但同样也需要使用确定性比特币承诺的协议的兼容性,RGB 承诺和其它协议的承诺要再一次聚合(如 LNPBP-4 标准所述),如此得到的哈希值,才是实际上被嵌入比特币交易中的消息。
4.4 批处理
由上节可以知道,我们可以将任何数量的状态变化“包裹”在单个比特币承诺里面,那么大规模的批处理理论上也是有可能的。
场景:A想同时给多人支付,给B转移一个RGB20资产,给C转移一个RGB21资产,给D转移一个合约的所有权
结果:A只需为B、C、D各创建一个状态转换,并将所有的状态转换都承诺到同一笔比特币交易中,就可以了,不需要占用更多字节。这意味着,每笔 RGB 支付的链上手续费边际成本都可以非常小,因为同一笔手续费被任意数量的转账平摊了。
但是我们也需要看到这里的局限性,即:这些状态转换信息必须要“包裹”在同一个UTXO里面,如果是存在多个,那么就需要增加这笔交易的输入,相应的成本等也会提高。但是相对于传统的每一个都需要一笔交易的情况,已经可以实现极大的改善。
这种批处理的能力对于使用合并UTXO的服务供应商来说非常重要,会有非常多的应用场景。
4.5 客户端之间的通信
为了达成一笔 RGB 转账,参与的客户端需要彼此分享一些数据。
如果你具体了解过RGB资产的转移步骤,那么可以知道,发送者需要给接收者(们)分享 consignment,这种数据结构包含了验证转账所需的一切信息,包括可以追溯到合约创始状态的所有状态转换。
consignment需要从发送者通过通信方式转移给接收者,但是RGB 协议不关心用于这种数据分享操作的通信渠道,因为有很多的方式可以去操作。但是,作为整体的一部分, 在 RGB 软件中主要有两种分享数据的方法:
大致有了对RGB协议的概念之后,我觉得这时候,我们可以去了解一下协议是怎么一步步发展起来的。任何这个级别的协议都不是一蹴而就的,必然经历了很多的更迭和革新。
设想阶段
RGB 最初由 Giacomo Zucco 和 Peter Todd 设想, Peter Todd 提出了客户端验证和一次性密封概念
开发阶段
最开始,由BHB Network、inbitcoin维护一段时间,并得到Poseidon Group的支持
随后,主要开发者变成 Alekos Filini
2019年中至今,Pandora Core AG 和 Maxim Orlovsky 博士已成为技术开发的主要贡献者
逐步成熟阶段
自2019年,RGB协议得到了很多贡献者、行业机构的帮助,逐步走向成熟。并且成为一个基于 LNP/BP 标准协会维护的一组标准的项目。
比如:在这个阶段,RGB从代币协议重构为通用智能合约系统,吸收了机密交易的许多部分,并使用了Blockstream的防弹技术。整体工作得到了 Bitfinex/Tether Inc 和 Fulgur Ventures 的财务支持。(这也是RGB协议的开发工作能够持续进行下去的基础)
Adam Back 的建议和 Blockstream 工程师在其RGB的技术设计中发挥的重要作用,包括 Andrew Poelstra(防弹、mimblewimple、机密交易)、Peter Wuille(机密交易、防弹)和 Christian Decker(闪电网络、系统)建筑设计)作品。所以这也是我关注Liquid的另一个重要原因,在理论基础上二者有非常多的交流,对于未来二者的结合我是十分看好。
RGB的主体协议开发工作完成的差不多,在v0.10版本资产发行等功能已经可以很方便的使用,但是在对接bolt-ln(当前的bolt闪电网络)时遇到一些问题,所以设计了bifrost标准协议用于智能合约的拓展,并进一步提出了Storm标准。
目前v0.11版本正在进行安全审计,预计在24年初将完成并发布,v0.11版本相对于v0.10有较大更新,二者的合约确定不再兼容,可能到时候会有方案进行资产的桥接,也可能没有,毕竟现在的版本均属于测试版本。
我比较期望v0.11协议版本会成为一个大的稳定版本,这将为协议下的生态项目开发带来一定的确定性。
接下来,我详细说一下RGB协议现存的问题:
1️⃣开发进度较慢
这个问题被很多人诟病,其原因有很多因素造成:
—LNP/BP协会的开发人员很少,主要的代码工作由Maxim博士和bitfinex完成
—LNP/BP为非盈利性组织,运营基本靠捐赠,虽然有Bitfinex/Tether Inc 和 Fulgur Ventures财务支持,但是资金使用上也需要精打细算(比如每年想搞一次线下会议都不一定有预算)
2️⃣不稳定性较强
这个不稳定性指的是“协议更新可能对于旧版本的破坏程度
例如这一次的v0.10对于v0.11在合约上的破坏(不兼容)就会造成较大的不确定性。
协议下的生态项目如果基于v0.10开发的功能在v0.11可能需要重做,这会带来很高的风险成本。但是从协会本身而言,它是为了整体的更新和规划,不怎么会在现阶段考虑这个问题。
3️⃣错配问题
协会本身考量的是协议整体的发展规划,与市场的需求不一定匹配。
4️⃣资金关注度不够
目前关注到RGB的大资金方还很少,机构还是沉浸在能很快看的到的叙事上,比如铭文等,对于像RGB这种大而深入的协议关注度不够,所以生态的发展上暂时也没有太多的起色(虽然相比之前已经好了一些,但我个人认为是资金的溢出效应造成的)
在表达观点的时候,我非常喜欢给出我的理由,因为这也是我做判断的依据;我不喜欢无脑去喊单,去fomo,那不符合我的本心。所以,我们先来梳理一下:
—BTC生态发展是当前矿工、老资金等共同希望的结果,市场上也需要新的叙事;
—BTC生态发展的基础技术条件已经具备,其中taproot升级就是很重要的一环;
—资产发行是生态发展的第一步,如果没有资产什么都玩不了。所以我们可以看到基于btc上发行资产的各个协议,并且逐步溢出到其他公链;
—生态发展不能仅仅是资产发行,它只能是第一步,第二步就是要对这些资产做应用场景,也就是要对资产进行处理、交换等,这需要智能合约,简单到复杂;
—当前的各个协议,目前我看到的基于原生的只有RGB和Bitvm,然后正如我前面所说,RGB走的更落地。
这就是我看好他的原因!
然而,事物的发展过程往往不会和想象中那么一致,借用一张图来表示一下:
第二部分:协议部分—认识LNP/BP
LNP:Lighting network protocol(闪电网络协议)
BP:Bitcoin protocol(比特币协议)
这是一家瑞士的非营利组织,负责监督比特币和闪电网络的第 2 层和第 3 层开放标准和协议。他们是 RGB、Bifrost、Storm、Prometheus、Kaleidscope 等 L2 和 L3 协议的创建者,也是闪电网络上#BiFi(比特币金融)生态系统的积极构建者。该协会由@dr-orlovsky和@giacomozucco于 2019 年创立
github中包含了大量关于RGB及相关协议的开源资料,有技术的朋友可以好好看一看
LNP/BP的捐赠机构阵容非常强大,里面包含:
并且,泰达曾经多次表示:要在RGB协议上发行USDT,力推RGB协议的发展!
2.1 LNPBP-1:公钥
待续…
第三部分:常见问题汇总
在这一部分,我将会把在学习中、社区运营中遇到的各种关于RGB和BTC技术的问题进行持续的汇总并更新在这个地方。
比特地地址类型主要有四种:
1️⃣遗留(Legacy)/支付公钥哈希(P2PKH)地址
这类事传统比特币地址,就是早期创建的时候的地址形式,所以也叫“遗留地址”或者“支付公钥哈希 (P2PKH) 地址”,因为在 2009 年比特币推出时,其生成方式是从公钥/私钥对的生成开始,在当时,这是创建地址的唯一方法。
这类地址都是以「1」开头的,因为在交易中使用最多的空间,因此也是最贵的地址类型。
2️⃣支付脚本哈希 Pay-to-Script-Hash(P2SH)地址
这类地址用的不是公钥的hash运算结果,而是利用某些脚本的哈希运算记过,可用于要求多重签名的转账事宜等。
这类地址以「3」开头,因为可以利用隔离见证节省交易费用,发送到 P2SH 地址比使用旧地址的钱包便宜约 26%。
3️⃣隔离见证地址(SegWit)Bech32 地址
Segwit 地址也称为 Bech32 地址,这种类型的比特币地址减少了交易中存储的信息量,它们不在交易中存储签名和脚本,而是在见证(commit)中。
这类地址以「bc1q 」开头,相对 P2SH 地址,Segwit 地址可以节省大约 16% 的交易费用,相对传统地址,节省 38% 以上的费用
4️⃣主根(Taproot)地址
为了提高区块空间的效率并改善费用,SegWit 在地址的构造方式上引入了一些变化。因此在 SegWit 地址的基础之上,开发出了 Taproot 地址,翻译为主根地址。
这类地址以「bc1p 」开头,其进一步减小了存储空间,提高了交易效率,并提供了更好的隐私性。
这是BTC上常用的一个技术手段:HD Wallet
这种技术允许一对“公私钥”生成无数个子公钥,也就是我们看到的地址;这种特性是为了保护btc钱包使用者的隐私性。
因为在传统使用时,为了确认交易,使用者会暴露自己的公钥,那么就有泄露自己真实身份的风险(可以去持续的追踪),但是在采用了HD Wallet之后,每一次使用后,都会转换成另外一个子公钥,这样就无法追踪。
具体可以参考下面的文档:
HD Wallets | Hierarchical Deterministic Wallets
An explanation of what an HD Wallet is, how they work in Bitcoin, and their history.
很多人会去争论“第一个”这个名头,因为人们喜爱追逐第一
如果要说RGB上的第一个资产,那很可能是Maxim博士自己尝试的时候发行的,当然,你我都没有看到
如果说LNP/BP协会开放的RGB示例资产,那么可以参考下面的网站
如果说是在RGB协议下项目方bitmask上发行的资产,可以参考下面的网站
但是bitmask也仅仅只是RGB协议下的一个项目方,因为RGB是“客户端验证”的,所以只要你能够搭建一个客户端,利用“命令行”也可以发行自己的“第一个RGB资产”
所以,争论谁是第一对于短期的宣传我认为有意义,但是从长久来看,资产能够内含的价值才更有意义。这种价值有可能是社区精神,也有可能是赋能等等。
事实上,并不能这么问,因为:RGB利用比特币网络是为了“安全性背书”“防止双花”的,原则上它可以运用在具备这种特性的任何其他网络上。
如果RGB交易运行在主网,那么它的交易就是在主网实时上链的;如果RGB交易运行在闪电网络上,那么它的交易数据是实时上闪电网络的,闪电网络的数据是链下存储的,只有在提现的时刻才会在BTC主网上链;如果RGB交易运行在其他网络上,也是根据其他网络的情况来决定数据的上链情况。
还必须指出的是:RGB的实际交易数据是存储在客户端的,上链的是关于交易的承诺(committee)的聚合。
对于我而言,我认为RGB是一项可以对接L1/L2/L3的通用技术,可以做很多事情,同时是BTC生态发展非常关键的一环;它可以实现BIFI,即bitcoin+fi,这个可以是defi,nftfi,gamefi,也可以是其他形式的fi
事实上很多人关注RGB在crypto中的应用,但是RGB可以做的更多,比如债券、国债、现实资产与虚拟资产的结合等等
RGB协议可以运行在主网上,也可以运行在闪电网络上,甚至未来运行在侧链上也是可能的。
RGB被设计在运行在闪电网络上,是为了扩展性考虑的,因为运行智能合约,主网的tps显然满足不了这种要求,而闪电网络的高tps可以满足,但是当前的bolt闪电网络是不能满足RGB复杂的智能合约要求的,所以需要升级到bifrost才能够成为完全体;
当前是因为闪电网络通道的大小问题造成的,而且闪电网络设计之初就是为了小额支付;当然,如果你自己建立一个大的通道,也可以实现大额的支付(一般大额都走主网)
为什么采用闪电网络而不是侧链的原因我认为有两个:
1️⃣侧链普遍被认为原生性不够,因为侧链都是有自己的链、自己的节点、自己的区块和自己的共识机制,你甚至可以说它和BTC主网的关系不大;但是闪电网络可以理解为就是挂在BTC主网上的一个东西,原生性很强,被称为L2
2️⃣闪电网络理论上的TPS远高于侧链
这种担忧我也有,特别是目前看起来捐赠也不多(其实对于泰达公司等这样的投资回赔率很高),但是我还是赞赏协会的这种精神,以一种非营利性的方式来做这样伟大的事情。
主体上来说,RGB协议的大部分工作已经完成,当然后续依然后很多的任务;我觉得如果RGB协议得到了越来越多人的关注,随着越来越多dev的加入,开发工作会变快。
是的,并且多次表示
截止2023年12月17日,大家都在等v0.11的更新,本次更新涉及到了智能合约、钱包等的更新;希望v0.11成为一个较大的稳定版本,这样生态下的项目方才能比较安心的开发。
如果v0.11 release,那么很快基于闪电网络的rgb资产的发行和转移就能实现(会非常快),但是复杂的智能合约依然有赖于bifrost闪电网络的开发。
bitmask/bitlight:非常正规的两个项目方,前者是在LNP/BP主页上公告的,聚焦于钱包和diba(nft市场)的开发,后者是聚焦于钱包、dex的开发;
pprgb:第一个有市场热度的rgb meme,暂时发行在liquid上的项目(注意定语)
seal:希望在rgb上发行NFT及赋能token的项目,坚持要在rgb上发行
UTXO exchange:想做rgb上的dex,采用零撸的方式空投,它发行的资产肯定是rgb资产,但是鉴于当前的形式,推测是采用中心化的形式,自行评估风险
BiHelix:原名叫infinity,后来改名叫intas,后来又改名叫Bihelix,写了很多的文章,做了很多的布道工作,但是早期和LNP/BP协议之间产生了不愉快,被认定为scam,我建议他们要好好处理这个问题,不然在这个赛道会比较难做
rgbdoge:推测是华人项目(我对于国人还是国外无所谓,看项目质量和策略),行动力很强,但是方向性不足(从最开始的“第一”之争,到要做平台,到要去liquid上发行)
bitrgb:一个要做RGB智能合约的平台,目前采用的是nostrasset的方式在做,之前推荐过zealy任务(撸白思路),但是鉴于“团队匿名/投资机构匿名/收费mint(价格好像不低)”,感觉风险很高
最近发现在LNP/BP tg里面,被maxim博士认定为scam
Inscriptionwar:这个就完全是蹭的,就不用参与了
链下安全性依赖于项目方或者客户端本身,所以需要协会针对存储等建立统一的标准,从而保证资产等的安全性。
主要的数据存储在链下的客户端,客户端之间未来可以通过storm节点来共享信息和通信。
我简要介绍一下,Adam Back创建了blockstream公司,这个公司旗下有很多产品,比如elements侧链开发平台,他们还有green wallet产品,还有真实的矿池,还有与矿池相关的理财产品、金融产品等;
Liquid就是用elements这个平台开发出来的L2,sideswap是Liquid上的一个项目。
链下数据的存储安全性是由项目方来提供,用户可以通过备份数据的形式来保护自己的资产安全;当然,如果项目方数据出现问题,用户自己也没有备份数据,那么资产就会出现问题。
一些有恶意的项目方可能通过创建恶意软件来犯罪,但是 RGB的使用机制可以避免机制上的诈骗,当然rug这种其实在所有区块链中都很难防。
是的,使用Storm协议, 对等点之间的数据是共享的,但是目前的开发已经超期了
不可以。项目方无法收集有关个人交易的信息,可能只能收集应用程序内部完成的号码传输(例如总统计数据)。
当然,我个人认为如果用户授权相关的权限,那么应用程序就能够访问这些数据(会有点类似于Liquid上的揭盲密钥查看致盲信息)
是的,但每家公司都需要遵守有关证券的监管。
1)资产具有 ContractID 和 genesis 初始值
2)与RGB钱包兼容
3)开源
这样就能知道是否是RGB资产
UTXO 就是“公共”资产层,但仅限于相同资产之间, 例如:USDT<>USDT;未来我们可以实现让不同资产之间“互操作”,但是这需要 Bifrost
这是可能的,但目标链必须支持 UTXO 模型及其他可用模型,以便与 RGB Core 和交叉库集成。这种时候,资产需要遵循RGB20模型的规范。
实际上,RGB 与 LN 是兼容的,你可以在任何 LN 实施中使用它,例如插入 CLN 或 LND。当使用 Storm时,每个示例在LN上确认是可能的; 在 L1 上,仅当您打开/关闭通道或使用 HTLC 进行扫描时才会确认并对资产进行路由传输。
是的,这需要很多支持库来共同作用,
理论上可以通过授权的方式来简化流程,当然,只是理论上
第四部分:参考链接
在这里,可以了解到:
1️⃣RGB是什么,能做什么,优点是什么(跳转)
2️⃣如何尝试RGB库,例如命令行,安装节点、调取API等等(跳转)
3️⃣通过官方的视频来学习RGB(当然,对于非英语的,有难度)(跳转)
Scalable & confidential smart contracts for Bitcoin & Lightning
该文档解释了设计原理,并提供了有关 RGB 系统如何构造和工作的深入技术见解,包括:
1️⃣协议设计的概述和目标(跳转)
2️⃣“客户端验证”介绍,讲述了“Single-use-seals”和“Deterministic bitcoin commitments”(跳转)
3️⃣“RGB合约、状态和操作”的说明(跳转)
4️⃣“尝试RGB合约”的一些内容:包括撰写合约,与合约交互、P2P通信,与钱包交互等(跳转)
RGB Blackpaper | RGB Blackpaper
Turing-complete, Scalable & Confidential Smart Contract Layer for Bitcoin & LN
如果遇到问题,可以先看这个官方文档有没有解答
在这里,可以了解LNP/BP协会开发的图灵完备的Alu虚拟机
1️⃣CoinEx Research
A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin
Blog | CoinEx - The Global Cryptocurrency Exchange
2️⃣Federico Tenga
Understanding the RGB protocol
@FedericoTenga">Federico Tenga – Medium
@FedericoTenga">Read writing from Federico Tenga on Medium. Working on Bitcoin stuff. Every day, Federico Tenga and thousands of other voices re…
@FedericoTenga">medium.com
3️⃣Bitfinex
How Can RGB Improve Bitcoin?
How Can RGB Improve Bitcoin? - Bitfinex blog
4️⃣Waterdrip Capital
详解 RGB 协议:另辟蹊径,创造比特币资产发行新二层
5️⃣ RGB 协议的设计
很多人开始关注比特币的RGB协议,真的很开心。但是大部分人对于这样一个协议(尤其是技术相对复杂的协议)比较陌生,也不知道如何去研究和尝试该协议的内容和生态。
所以,特别写一篇持续更新的Mirror,来汇总相关的学习资料,提供一个相对来说合理的学习路径;同时,也作为个人学习RGB的一个记录。
第一部分:科普部分-初步认识RGB
很多人看到RGB这三个字,会想到“三原色:red green blue”。如果从图标上看,还真是这么回事,这是因为RGB协议有利用到早期的“染色硬币”的概念。
这里我们说的RGB是一个协议,一个可以在比特币主网、闪电网络或者类似网络上运行,极端隐私的、可扩展的智能合约系统协议。
这个协议目前由LNP/BP协议维护和更新,bitfinex也参与部分代码工作。
你很难将RGB简单划分为比特币L2的范畴,它没有自己的链、它没有自己的层、他可以运作在BTC的其他L2上,所以,准确来说:它是一项通用性的技术。
在业界,普遍认为RGB和Bitvm会是BTC拓展的终极形态,因为他们都可以基于BTC原生性实现BTC生态的可扩展性,相对于Bitvm的遥遥无期,RGB已经在逐步落地。
值得一提的是:RGB是一项不局限于crypto的技术,它可以广泛运用到我们非crypto的场景中,等到协议越来越成熟,我们会看到越来越多的用例。
从官方的介绍中,我们可以看到RGB协议可以实现的功能:
如果我们归类一下,可以看出:
从这个角度看,RGB可以让BTC具有现在EVM的绝大部分功能,但是它不是采用类似于“兼容EVM”的非原生形式实现的,而是原生实现的,不得不说这一套理论和设计理念很牛。
事实上,值得注意的是,RGB 智能合约系统与之前的方法都有很大不同,无论是基于比特币(彩色币、Counterparty、OMNI)还是非比特币(以太坊、EOS 等),它有自己独特的特性:
第一条的意思是,智能合约将进行更好的分层,发行人仅在发行时刻享有合约的权利,之后都是由状态所有者在不断的状态演化过程中享有权利;
第二条意思是,它将代码保留在链下,可以节省链上空间,提升运行速度,降低开发难度,但是又可以通过机制保证安全性;
第三条揭示了它的安全背书层(区块链),同时它是图灵完备的,可以支持简单的语言操作。
所以,下图可能更接近于正确的理解:
从Dr. Maxim Orlovsky的教学视频中,我们可以看到官方认定的RGB特性包括:
我们来逐一拆分讲解:
1️⃣极端隐私性
2️⃣高度安全性
这两点我还不怎么懂,需要研究下
3️⃣高度可扩展性
4️⃣不拥堵
5️⃣极高的融合性
所以,其实在我的眼里,RGB对于BTC更像是下面这样:
RGB协议相对于其他协议,有自己非常独特的技术点,这里简单科普几个重要的部分:
4.1 一次性密封
该技术最早由Peter Todd在2016年提出,主要意思是“把一条消息加上一个密封条,确保这个消息只能被使用一次,因为你要知道消息就必须拆除密封条”。
一种简单的方法是设置一个公证的第三方服务端,每当某一个密封条打开或者锁上时就在公开的注册处发布证书,这样任何人都能验证自己关心的密封条的状态。
如果不使用一个受信任的实体来实现一次性密封的功能,可以使用比特币的UTXO来作为密封条。因为比特币的任何一个UTXO只能被花费一次。因此,把UTXO作为密封条,就可以在UTXO创建的时候锁上,在花费它的时候打开。
RGB利用了这样的“一次性密封”技术,它将RGB资产的信息、合约的状态等都“包裹”在UTXO里面,当UTXO被花费的时候,资产的所有权、合约的状态就发生了转变。这意味着,每当一笔 RGB 交易发生时,实际上就是发送者给某个合约(定义了被转移的权利的那个)创建了一次状态变更。
以RGB20为例:
1️⃣首先,合约的发行者设定了合约的创始状态,定义了合约的细节:资产的名称、总供应量等,并且发行者有权移动这些供应量的 UTXO;
2️⃣当资产被第一次转移时,第一个 UTXO 的所有者就可以创建一次状态变更,定义哪一个 UTXO 将持有这项资产;
3️⃣状态变更可以应用在变更资产所有权的权利上,也可以应用在别的类型的权利上,例如,二次发行的权利,或者是添加/改变 资产的特定属性(例如:元数据)的权利等。
4.2 客户端验证
RGB的验证和传统的“全球共识”验证不同,采用的是“客户端验证”的技术。
传统的比特币验证,一个连接到网络的节点会持续不断地下载和验证区块以及交易池中的交易(全节点)。这样的节点对整条链上的 UTXO 集(区块链上所有未花费的输出的集合)有一个实时更新的试图,当它看到一笔新交易时,要验证其有效性,只需要验证该交易的所有输入都是该 UTXO 集的最新状态的一部分即可。
但是对于RGB而言,没有全局传播的数据,因此也没有这样的UTXO集的全局视图。一个 RGB 客户端在接受一笔交易后,不仅需要验证交易的最新状态是有效的,还必须对与交易相关的以往所有的状态转化作同样的验证,一路追溯到发行合约的创始状态。
这看起来会会带来一个明显的缺点:导致验证时间很长
但是这仅仅出现在“一项具有很长的交易历史的资产时”才会出现,而且可以通过一个数据分享层(自愿的情况下)提前开始验证这部分交易历史数据。
这同时可以带来明显的优点:客户端不需要知道、也不需要验证全局中发生的所有交易
因为它只需要知道跟自己钱包相关的交易即可,它不需要验证其他的交易,因此每个客户端要验证的数据量都更小,系统扩展性明显增强。
4.3 确定性的比特币承诺
RGB如何防止“双花”,是通过RGB承诺来实现的,这样的承诺需要实现:
1️⃣涉及合约的多次状态转换可以承诺到单笔比特币交易中
2️⃣每一次合约的状态转换都只能被承诺进比特币交易一次
实现的具体方式是:
1️⃣首先,跟某一个合约(或者说资产 ID)相关的所有状态转换,要确定性地聚合成一个承诺
2️⃣然后,所有被转移的资产的承诺,要被聚合成一棵默克尔树
3️⃣最终的根哈希值,就是最终的 RGB 承诺;
4️⃣为了保证跟其它无关 RGB、但同样也需要使用确定性比特币承诺的协议的兼容性,RGB 承诺和其它协议的承诺要再一次聚合(如 LNPBP-4 标准所述),如此得到的哈希值,才是实际上被嵌入比特币交易中的消息。
4.4 批处理
由上节可以知道,我们可以将任何数量的状态变化“包裹”在单个比特币承诺里面,那么大规模的批处理理论上也是有可能的。
场景:A想同时给多人支付,给B转移一个RGB20资产,给C转移一个RGB21资产,给D转移一个合约的所有权
结果:A只需为B、C、D各创建一个状态转换,并将所有的状态转换都承诺到同一笔比特币交易中,就可以了,不需要占用更多字节。这意味着,每笔 RGB 支付的链上手续费边际成本都可以非常小,因为同一笔手续费被任意数量的转账平摊了。
但是我们也需要看到这里的局限性,即:这些状态转换信息必须要“包裹”在同一个UTXO里面,如果是存在多个,那么就需要增加这笔交易的输入,相应的成本等也会提高。但是相对于传统的每一个都需要一笔交易的情况,已经可以实现极大的改善。
这种批处理的能力对于使用合并UTXO的服务供应商来说非常重要,会有非常多的应用场景。
4.5 客户端之间的通信
为了达成一笔 RGB 转账,参与的客户端需要彼此分享一些数据。
如果你具体了解过RGB资产的转移步骤,那么可以知道,发送者需要给接收者(们)分享 consignment,这种数据结构包含了验证转账所需的一切信息,包括可以追溯到合约创始状态的所有状态转换。
consignment需要从发送者通过通信方式转移给接收者,但是RGB 协议不关心用于这种数据分享操作的通信渠道,因为有很多的方式可以去操作。但是,作为整体的一部分, 在 RGB 软件中主要有两种分享数据的方法:
大致有了对RGB协议的概念之后,我觉得这时候,我们可以去了解一下协议是怎么一步步发展起来的。任何这个级别的协议都不是一蹴而就的,必然经历了很多的更迭和革新。
设想阶段
RGB 最初由 Giacomo Zucco 和 Peter Todd 设想, Peter Todd 提出了客户端验证和一次性密封概念
开发阶段
最开始,由BHB Network、inbitcoin维护一段时间,并得到Poseidon Group的支持
随后,主要开发者变成 Alekos Filini
2019年中至今,Pandora Core AG 和 Maxim Orlovsky 博士已成为技术开发的主要贡献者
逐步成熟阶段
自2019年,RGB协议得到了很多贡献者、行业机构的帮助,逐步走向成熟。并且成为一个基于 LNP/BP 标准协会维护的一组标准的项目。
比如:在这个阶段,RGB从代币协议重构为通用智能合约系统,吸收了机密交易的许多部分,并使用了Blockstream的防弹技术。整体工作得到了 Bitfinex/Tether Inc 和 Fulgur Ventures 的财务支持。(这也是RGB协议的开发工作能够持续进行下去的基础)
Adam Back 的建议和 Blockstream 工程师在其RGB的技术设计中发挥的重要作用,包括 Andrew Poelstra(防弹、mimblewimple、机密交易)、Peter Wuille(机密交易、防弹)和 Christian Decker(闪电网络、系统)建筑设计)作品。所以这也是我关注Liquid的另一个重要原因,在理论基础上二者有非常多的交流,对于未来二者的结合我是十分看好。
RGB的主体协议开发工作完成的差不多,在v0.10版本资产发行等功能已经可以很方便的使用,但是在对接bolt-ln(当前的bolt闪电网络)时遇到一些问题,所以设计了bifrost标准协议用于智能合约的拓展,并进一步提出了Storm标准。
目前v0.11版本正在进行安全审计,预计在24年初将完成并发布,v0.11版本相对于v0.10有较大更新,二者的合约确定不再兼容,可能到时候会有方案进行资产的桥接,也可能没有,毕竟现在的版本均属于测试版本。
我比较期望v0.11协议版本会成为一个大的稳定版本,这将为协议下的生态项目开发带来一定的确定性。
接下来,我详细说一下RGB协议现存的问题:
1️⃣开发进度较慢
这个问题被很多人诟病,其原因有很多因素造成:
—LNP/BP协会的开发人员很少,主要的代码工作由Maxim博士和bitfinex完成
—LNP/BP为非盈利性组织,运营基本靠捐赠,虽然有Bitfinex/Tether Inc 和 Fulgur Ventures财务支持,但是资金使用上也需要精打细算(比如每年想搞一次线下会议都不一定有预算)
2️⃣不稳定性较强
这个不稳定性指的是“协议更新可能对于旧版本的破坏程度
例如这一次的v0.10对于v0.11在合约上的破坏(不兼容)就会造成较大的不确定性。
协议下的生态项目如果基于v0.10开发的功能在v0.11可能需要重做,这会带来很高的风险成本。但是从协会本身而言,它是为了整体的更新和规划,不怎么会在现阶段考虑这个问题。
3️⃣错配问题
协会本身考量的是协议整体的发展规划,与市场的需求不一定匹配。
4️⃣资金关注度不够
目前关注到RGB的大资金方还很少,机构还是沉浸在能很快看的到的叙事上,比如铭文等,对于像RGB这种大而深入的协议关注度不够,所以生态的发展上暂时也没有太多的起色(虽然相比之前已经好了一些,但我个人认为是资金的溢出效应造成的)
在表达观点的时候,我非常喜欢给出我的理由,因为这也是我做判断的依据;我不喜欢无脑去喊单,去fomo,那不符合我的本心。所以,我们先来梳理一下:
—BTC生态发展是当前矿工、老资金等共同希望的结果,市场上也需要新的叙事;
—BTC生态发展的基础技术条件已经具备,其中taproot升级就是很重要的一环;
—资产发行是生态发展的第一步,如果没有资产什么都玩不了。所以我们可以看到基于btc上发行资产的各个协议,并且逐步溢出到其他公链;
—生态发展不能仅仅是资产发行,它只能是第一步,第二步就是要对这些资产做应用场景,也就是要对资产进行处理、交换等,这需要智能合约,简单到复杂;
—当前的各个协议,目前我看到的基于原生的只有RGB和Bitvm,然后正如我前面所说,RGB走的更落地。
这就是我看好他的原因!
然而,事物的发展过程往往不会和想象中那么一致,借用一张图来表示一下:
第二部分:协议部分—认识LNP/BP
LNP:Lighting network protocol(闪电网络协议)
BP:Bitcoin protocol(比特币协议)
这是一家瑞士的非营利组织,负责监督比特币和闪电网络的第 2 层和第 3 层开放标准和协议。他们是 RGB、Bifrost、Storm、Prometheus、Kaleidscope 等 L2 和 L3 协议的创建者,也是闪电网络上#BiFi(比特币金融)生态系统的积极构建者。该协会由@dr-orlovsky和@giacomozucco于 2019 年创立
github中包含了大量关于RGB及相关协议的开源资料,有技术的朋友可以好好看一看
LNP/BP的捐赠机构阵容非常强大,里面包含:
并且,泰达曾经多次表示:要在RGB协议上发行USDT,力推RGB协议的发展!
2.1 LNPBP-1:公钥
待续…
第三部分:常见问题汇总
在这一部分,我将会把在学习中、社区运营中遇到的各种关于RGB和BTC技术的问题进行持续的汇总并更新在这个地方。
比特地地址类型主要有四种:
1️⃣遗留(Legacy)/支付公钥哈希(P2PKH)地址
这类事传统比特币地址,就是早期创建的时候的地址形式,所以也叫“遗留地址”或者“支付公钥哈希 (P2PKH) 地址”,因为在 2009 年比特币推出时,其生成方式是从公钥/私钥对的生成开始,在当时,这是创建地址的唯一方法。
这类地址都是以「1」开头的,因为在交易中使用最多的空间,因此也是最贵的地址类型。
2️⃣支付脚本哈希 Pay-to-Script-Hash(P2SH)地址
这类地址用的不是公钥的hash运算结果,而是利用某些脚本的哈希运算记过,可用于要求多重签名的转账事宜等。
这类地址以「3」开头,因为可以利用隔离见证节省交易费用,发送到 P2SH 地址比使用旧地址的钱包便宜约 26%。
3️⃣隔离见证地址(SegWit)Bech32 地址
Segwit 地址也称为 Bech32 地址,这种类型的比特币地址减少了交易中存储的信息量,它们不在交易中存储签名和脚本,而是在见证(commit)中。
这类地址以「bc1q 」开头,相对 P2SH 地址,Segwit 地址可以节省大约 16% 的交易费用,相对传统地址,节省 38% 以上的费用
4️⃣主根(Taproot)地址
为了提高区块空间的效率并改善费用,SegWit 在地址的构造方式上引入了一些变化。因此在 SegWit 地址的基础之上,开发出了 Taproot 地址,翻译为主根地址。
这类地址以「bc1p 」开头,其进一步减小了存储空间,提高了交易效率,并提供了更好的隐私性。
这是BTC上常用的一个技术手段:HD Wallet
这种技术允许一对“公私钥”生成无数个子公钥,也就是我们看到的地址;这种特性是为了保护btc钱包使用者的隐私性。
因为在传统使用时,为了确认交易,使用者会暴露自己的公钥,那么就有泄露自己真实身份的风险(可以去持续的追踪),但是在采用了HD Wallet之后,每一次使用后,都会转换成另外一个子公钥,这样就无法追踪。
具体可以参考下面的文档:
HD Wallets | Hierarchical Deterministic Wallets
An explanation of what an HD Wallet is, how they work in Bitcoin, and their history.
很多人会去争论“第一个”这个名头,因为人们喜爱追逐第一
如果要说RGB上的第一个资产,那很可能是Maxim博士自己尝试的时候发行的,当然,你我都没有看到
如果说LNP/BP协会开放的RGB示例资产,那么可以参考下面的网站
如果说是在RGB协议下项目方bitmask上发行的资产,可以参考下面的网站
但是bitmask也仅仅只是RGB协议下的一个项目方,因为RGB是“客户端验证”的,所以只要你能够搭建一个客户端,利用“命令行”也可以发行自己的“第一个RGB资产”
所以,争论谁是第一对于短期的宣传我认为有意义,但是从长久来看,资产能够内含的价值才更有意义。这种价值有可能是社区精神,也有可能是赋能等等。
事实上,并不能这么问,因为:RGB利用比特币网络是为了“安全性背书”“防止双花”的,原则上它可以运用在具备这种特性的任何其他网络上。
如果RGB交易运行在主网,那么它的交易就是在主网实时上链的;如果RGB交易运行在闪电网络上,那么它的交易数据是实时上闪电网络的,闪电网络的数据是链下存储的,只有在提现的时刻才会在BTC主网上链;如果RGB交易运行在其他网络上,也是根据其他网络的情况来决定数据的上链情况。
还必须指出的是:RGB的实际交易数据是存储在客户端的,上链的是关于交易的承诺(committee)的聚合。
对于我而言,我认为RGB是一项可以对接L1/L2/L3的通用技术,可以做很多事情,同时是BTC生态发展非常关键的一环;它可以实现BIFI,即bitcoin+fi,这个可以是defi,nftfi,gamefi,也可以是其他形式的fi
事实上很多人关注RGB在crypto中的应用,但是RGB可以做的更多,比如债券、国债、现实资产与虚拟资产的结合等等
RGB协议可以运行在主网上,也可以运行在闪电网络上,甚至未来运行在侧链上也是可能的。
RGB被设计在运行在闪电网络上,是为了扩展性考虑的,因为运行智能合约,主网的tps显然满足不了这种要求,而闪电网络的高tps可以满足,但是当前的bolt闪电网络是不能满足RGB复杂的智能合约要求的,所以需要升级到bifrost才能够成为完全体;
当前是因为闪电网络通道的大小问题造成的,而且闪电网络设计之初就是为了小额支付;当然,如果你自己建立一个大的通道,也可以实现大额的支付(一般大额都走主网)
为什么采用闪电网络而不是侧链的原因我认为有两个:
1️⃣侧链普遍被认为原生性不够,因为侧链都是有自己的链、自己的节点、自己的区块和自己的共识机制,你甚至可以说它和BTC主网的关系不大;但是闪电网络可以理解为就是挂在BTC主网上的一个东西,原生性很强,被称为L2
2️⃣闪电网络理论上的TPS远高于侧链
这种担忧我也有,特别是目前看起来捐赠也不多(其实对于泰达公司等这样的投资回赔率很高),但是我还是赞赏协会的这种精神,以一种非营利性的方式来做这样伟大的事情。
主体上来说,RGB协议的大部分工作已经完成,当然后续依然后很多的任务;我觉得如果RGB协议得到了越来越多人的关注,随着越来越多dev的加入,开发工作会变快。
是的,并且多次表示
截止2023年12月17日,大家都在等v0.11的更新,本次更新涉及到了智能合约、钱包等的更新;希望v0.11成为一个较大的稳定版本,这样生态下的项目方才能比较安心的开发。
如果v0.11 release,那么很快基于闪电网络的rgb资产的发行和转移就能实现(会非常快),但是复杂的智能合约依然有赖于bifrost闪电网络的开发。
bitmask/bitlight:非常正规的两个项目方,前者是在LNP/BP主页上公告的,聚焦于钱包和diba(nft市场)的开发,后者是聚焦于钱包、dex的开发;
pprgb:第一个有市场热度的rgb meme,暂时发行在liquid上的项目(注意定语)
seal:希望在rgb上发行NFT及赋能token的项目,坚持要在rgb上发行
UTXO exchange:想做rgb上的dex,采用零撸的方式空投,它发行的资产肯定是rgb资产,但是鉴于当前的形式,推测是采用中心化的形式,自行评估风险
BiHelix:原名叫infinity,后来改名叫intas,后来又改名叫Bihelix,写了很多的文章,做了很多的布道工作,但是早期和LNP/BP协议之间产生了不愉快,被认定为scam,我建议他们要好好处理这个问题,不然在这个赛道会比较难做
rgbdoge:推测是华人项目(我对于国人还是国外无所谓,看项目质量和策略),行动力很强,但是方向性不足(从最开始的“第一”之争,到要做平台,到要去liquid上发行)
bitrgb:一个要做RGB智能合约的平台,目前采用的是nostrasset的方式在做,之前推荐过zealy任务(撸白思路),但是鉴于“团队匿名/投资机构匿名/收费mint(价格好像不低)”,感觉风险很高
最近发现在LNP/BP tg里面,被maxim博士认定为scam
Inscriptionwar:这个就完全是蹭的,就不用参与了
链下安全性依赖于项目方或者客户端本身,所以需要协会针对存储等建立统一的标准,从而保证资产等的安全性。
主要的数据存储在链下的客户端,客户端之间未来可以通过storm节点来共享信息和通信。
我简要介绍一下,Adam Back创建了blockstream公司,这个公司旗下有很多产品,比如elements侧链开发平台,他们还有green wallet产品,还有真实的矿池,还有与矿池相关的理财产品、金融产品等;
Liquid就是用elements这个平台开发出来的L2,sideswap是Liquid上的一个项目。
链下数据的存储安全性是由项目方来提供,用户可以通过备份数据的形式来保护自己的资产安全;当然,如果项目方数据出现问题,用户自己也没有备份数据,那么资产就会出现问题。
一些有恶意的项目方可能通过创建恶意软件来犯罪,但是 RGB的使用机制可以避免机制上的诈骗,当然rug这种其实在所有区块链中都很难防。
是的,使用Storm协议, 对等点之间的数据是共享的,但是目前的开发已经超期了
不可以。项目方无法收集有关个人交易的信息,可能只能收集应用程序内部完成的号码传输(例如总统计数据)。
当然,我个人认为如果用户授权相关的权限,那么应用程序就能够访问这些数据(会有点类似于Liquid上的揭盲密钥查看致盲信息)
是的,但每家公司都需要遵守有关证券的监管。
1)资产具有 ContractID 和 genesis 初始值
2)与RGB钱包兼容
3)开源
这样就能知道是否是RGB资产
UTXO 就是“公共”资产层,但仅限于相同资产之间, 例如:USDT<>USDT;未来我们可以实现让不同资产之间“互操作”,但是这需要 Bifrost
这是可能的,但目标链必须支持 UTXO 模型及其他可用模型,以便与 RGB Core 和交叉库集成。这种时候,资产需要遵循RGB20模型的规范。
实际上,RGB 与 LN 是兼容的,你可以在任何 LN 实施中使用它,例如插入 CLN 或 LND。当使用 Storm时,每个示例在LN上确认是可能的; 在 L1 上,仅当您打开/关闭通道或使用 HTLC 进行扫描时才会确认并对资产进行路由传输。
是的,这需要很多支持库来共同作用,
理论上可以通过授权的方式来简化流程,当然,只是理论上
第四部分:参考链接
在这里,可以了解到:
1️⃣RGB是什么,能做什么,优点是什么(跳转)
2️⃣如何尝试RGB库,例如命令行,安装节点、调取API等等(跳转)
3️⃣通过官方的视频来学习RGB(当然,对于非英语的,有难度)(跳转)
Scalable & confidential smart contracts for Bitcoin & Lightning
该文档解释了设计原理,并提供了有关 RGB 系统如何构造和工作的深入技术见解,包括:
1️⃣协议设计的概述和目标(跳转)
2️⃣“客户端验证”介绍,讲述了“Single-use-seals”和“Deterministic bitcoin commitments”(跳转)
3️⃣“RGB合约、状态和操作”的说明(跳转)
4️⃣“尝试RGB合约”的一些内容:包括撰写合约,与合约交互、P2P通信,与钱包交互等(跳转)
RGB Blackpaper | RGB Blackpaper
Turing-complete, Scalable & Confidential Smart Contract Layer for Bitcoin & LN
如果遇到问题,可以先看这个官方文档有没有解答
在这里,可以了解LNP/BP协会开发的图灵完备的Alu虚拟机
1️⃣CoinEx Research
A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin
Blog | CoinEx - The Global Cryptocurrency Exchange
2️⃣Federico Tenga
Understanding the RGB protocol
@FedericoTenga">Federico Tenga – Medium
@FedericoTenga">Read writing from Federico Tenga on Medium. Working on Bitcoin stuff. Every day, Federico Tenga and thousands of other voices re…
@FedericoTenga">medium.com
3️⃣Bitfinex
How Can RGB Improve Bitcoin?
How Can RGB Improve Bitcoin? - Bitfinex blog
4️⃣Waterdrip Capital
详解 RGB 协议:另辟蹊径,创造比特币资产发行新二层
5️⃣ RGB 协议的设计