RGB学习资源大全 - DaPangDun

很多人开始关注比特币的RGB协议，真的很开心。但是大部分人对于这样一个协议（尤其是技术相对复杂的协议）比较陌生，也不知道如何去研究和尝试该协议的内容和生态。

所以，特别写一篇持续更新的Mirror，来汇总相关的学习资料，提供一个相对来说合理的学习路径；同时，也作为个人学习RGB的一个记录。

BTC地址为什么有各种类型的？
在使用一些BTC钱包时，为什么每次使用后钱包的地址都不一样？
RGB上的第一个资产是？
RGB的交易是实时上链的吗？
介绍一下RGB到底能做什么？
RGB协议和主网、闪电网络之间的关系？
闪电网络目前用起来也经常有问题，为什么不选择运行在侧链上，而且老外为什么青睐闪电网络？
LNP/BP协会只接受捐赠，是不是可能反而会影响开发的进度？
泰达公司是要在RGB上发行稳定币吗？
RGB协议目前发展到什么程度了？
介绍下RGB生态下的各个项目？
RGB的链上安全性能够理解，那么链下安全性如何理解呢？
RGB的数据存储在哪？
说一下sideswap和liquid的关系？
RGB是链下存储的，那么链下数据的安全性由项目方保证吗？如果项目方的数据出现问题，资产是否有可能出现问题？项目方是否可能作恶？
通过Storm节点，能够实现数据在不同项目方之间互联，并实现数据的去中心化？
由于RGB协议是私密的，外界无法看到个人的交易数据。项目放能否提供个人交易、转账等信息？
是否有可能会出现一种类似于Liquid的证券资产（AMP）（必须向外界披露），使得必须符合一定规定的资产必须向外界披露？
如何证明一个资产是RGB资产？
既然不同项目之间的资产不能互操作，那么有没有可能存在一个共同的资产层呢？
RGB可以连接到不同的链，例如Liquid和其他L2吗？资产采取什么形式？它必须符合 RGB 资产规范吗？
如果RGB建立在闪电网络上，是不是可以这样考虑：RGB数据在链下记录，支付数据通过闪电网络确认，闪电网络数据通过多种模式上传到比特币主网进行确认？
由于RGB资产转移的特殊性，需要双方确认，那么构建类似uniswap的amm机制是不是很难呢？可以通过让用户提前授权某些权限来实现吗？

第四部分：参考链接

RGB技术官网
RGB BLACKPAPER
官方常见问题文档
AluVM虚拟机
优质的RGB协议分析报告

第一部分：科普部分-初步认识RGB

1. RGB是什么？

很多人看到RGB这三个字，会想到“三原色：red green blue”。如果从图标上看，还真是这么回事，这是因为RGB协议有利用到早期的“染色硬币”的概念。

这里我们说的RGB是一个协议，一个可以在比特币主网、闪电网络或者类似网络上运行，极端隐私的、可扩展的智能合约系统协议。

这个协议目前由LNP/BP协议维护和更新，bitfinex也参与部分代码工作。

你很难将RGB简单划分为比特币L2的范畴，它没有自己的链、它没有自己的层、他可以运作在BTC的其他L2上，所以，准确来说：它是一项通用性的技术。

在业界，普遍认为RGB和Bitvm会是BTC拓展的终极形态，因为他们都可以基于BTC原生性实现BTC生态的可扩展性，相对于Bitvm的遥遥无期，RGB已经在逐步落地。

值得一提的是：RGB是一项不局限于crypto的技术，它可以广泛运用到我们非crypto的场景中，等到协议越来越成熟，我们会看到越来越多的用例。

2. RGB能做什么？

从官方的介绍中，我们可以看到RGB协议可以实现的功能：

发行数字可替代资产，如股票、债券和其他形式的证券；
创建不同形式的收藏品（不可替代资产）；
创建和管理主权/去中心化身份和声誉系统；
创建并维护某些事件的可证明唯一的历史记录，这些历史记录可用于通过良好控制的部分数据披露进行审计；
设计和运行其他形式的任意复杂的智能合约

如果我们归类一下，可以看出：

可以发行资产（token、nft、domain等）
可以做数据层
可以做智能合约

从这个角度看，RGB可以让BTC具有现在EVM的绝大部分功能，但是它不是采用类似于“兼容EVM”的非原生形式实现的，而是原生实现的，不得不说这一套理论和设计理念很牛。

事实上，值得注意的是，RGB 智能合约系统与之前的方法都有很大不同，无论是基于比特币（彩色币、Counterparty、OMNI）还是非比特币（以太坊、EOS 等），它有自己独特的特性：

RGB 区分了智能合约的概念：发行人、状态所有者 和 状态演化；
RGB 将智能合约代码和数据保留在链下；
RGB使用区块链作为状态承诺层，使用比特币脚本作为所有权控制系统；而智能合约的演变是由链下模式和使用简单语言完成的

第一条的意思是，智能合约将进行更好的分层，发行人仅在发行时刻享有合约的权利，之后都是由状态所有者在不断的状态演化过程中享有权利；

第二条意思是，它将代码保留在链下，可以节省链上空间，提升运行速度，降低开发难度，但是又可以通过机制保证安全性；

第三条揭示了它的安全背书层（区块链），同时它是图灵完备的，可以支持简单的语言操作。

所以，下图可能更接近于正确的理解：

3. RGB的特性是什么？

从Dr. Maxim Orlovsky的教学视频中，我们可以看到官方认定的RGB特性包括：

极端隐私性
高度安全性
可扩展性
不拥堵
极高的融合性

我们来逐一拆分讲解：

1️⃣极端隐私性

数据只有所有者知道，而不是全世界都知道。因为RGB并不是采用传统的全球共识，而是采用客户端验证，所以不需要将数据广播到全局。只需要可以互相连通的两个客户端，就能够建立只有彼此的共识，这些数据也只有彼此知道（如果不分享给外界）；
金额是保密的，Pedersen 承诺和 Bulletproofs 结合了 Liquid 和 Grin 的最佳功能。类似于Liquid上的ct（confidential）概念，其他人无法看到具体交易的资产类型和资产金额。
默克尔化和部分数据揭示功能使许多过去的历史保持私密，甚至对未来的所有者来说也是如此。原则上RGB上一个交易是需要溯源到跟交易相关的以前的所有记录，但是部分揭示功能会让这个过程变的更简单一些，同时也会保护链上的历史信息保持一定程度上的隐私性；
无法从比特币区块链或闪电通道交易中提取特定于 RGB 的数据。也就是说，从RGB在链上提交的数据，是无法分析出信息的，因为他们都是隐私的，这也意味着传统的analysis将RGB上将寸步难行。

2️⃣高度安全性

状态隔离：状态是隔离的，合约只能通过通道内的特殊协议（Spectrum）进行交互。
形式化验证：合约属性可以用形式化模型证明。

这两点我还不怎么懂，需要研究下

3️⃣高度可扩展性

不受区块链可扩展性的限制，适用于闪电网络和任何其他通道。它不是仅仅只能用于btc或者闪电网络，其他的区块链也是有可能适用的。所以为什么我说RGB是一项通用技术范畴，跟现有的BTC生态划分体系不是一个东西。
与基于区块链的智能合约系统相比，客户为全面验证而保留的数据量显著减少。因为他是极端隐私的，你只需要保留和自己交易相关的数据即可，客户端不需要保存所有的数据。
智能合约级分片：多个合约保持独立的历史记录。使合约之间保持独立性、不干扰性。

4️⃣不拥堵

交易仅保留同态承诺，无需额外存储

5️⃣极高的融合性

与Taproot、Schnorr、eltoo、多方闪电网络通道、DLC...都可以做融合
与现有的L2，诸如Liquid等也可以做融合

所以，其实在我的眼里，RGB对于BTC更像是下面这样：

4. RGB技术点

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 软件中主要有两种分享数据的方法：

Storm：一种点对点的即时通信和存储系统，基于闪电网络。
RGB 代理服务端：一种标准化的 HTTP JSON-RPC 服务端，其客户端可以上传和下载数据。用户可以运行自己的代理服务端，也是使用第三方的服务端。依赖于第三方的服务端会影响隐私性和抗审查性，但不影响安全性。

5. 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的另一个重要原因，在理论基础上二者有非常多的交流，对于未来二者的结合我是十分看好。

6. RGB协议的现状

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这种大而深入的协议关注度不够，所以生态的发展上暂时也没有太多的起色（虽然相比之前已经好了一些，但我个人认为是资金的溢出效应造成的）

7. 我对RGB协议的未来展望

在表达观点的时候，我非常喜欢给出我的理由，因为这也是我做判断的依据；我不喜欢无脑去喊单，去fomo，那不符合我的本心。所以，我们先来梳理一下：

--BTC生态发展是当前矿工、老资金等共同希望的结果，市场上也需要新的叙事；

--BTC生态发展的基础技术条件已经具备，其中taproot升级就是很重要的一环；

--资产发行是生态发展的第一步，如果没有资产什么都玩不了。所以我们可以看到基于btc上发行资产的各个协议，并且逐步溢出到其他公链；

--生态发展不能仅仅是资产发行，它只能是第一步，第二步就是要对这些资产做应用场景，也就是要对资产进行处理、交换等，这需要智能合约，简单到复杂；

--当前的各个协议，目前我看到的基于原生的只有RGB和Bitvm，然后正如我前面所说，RGB走的更落地。

这就是我看好他的原因！

然而，事物的发展过程往往不会和想象中那么一致，借用一张图来表示一下：

第二部分：协议部分--认识LNP/BP

1. 认识LNP/BP

LNP：Lighting network protocol（闪电网络协议）

BP：Bitcoin protocol（比特币协议）

这是一家瑞士的非营利组织，负责监督比特币和闪电网络的第 2 层和第 3 层开放标准和协议。他们是 RGB、Bifrost、Storm、Prometheus、Kaleidscope 等 L2 和 L3 协议的创建者，也是闪电网络上#BiFi（比特币金融）生态系统的积极构建者。该协会由@dr-orlovsky和@giacomozucco于 2019 年创立

官网链接推特链接 github链接

github中包含了大量关于RGB及相关协议的开源资料，有技术的朋友可以好好看一看

LNP/BP的捐赠机构阵容非常强大，里面包含：

并且，泰达曾经多次表示：要在RGB协议上发行USDT，力推RGB协议的发展！

2. LNP/BP标准解析

2.1 LNPBP-1：公钥

待续…

第三部分：常见问题汇总

在这一部分，我将会把在学习中、社区运营中遇到的各种关于RGB和BTC技术的问题进行持续的汇总并更新在这个地方。

Q1. 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 」开头，其进一步减小了存储空间，提高了交易效率，并提供了更好的隐私性。

Q2. 在使用一些BTC钱包时，为什么每次使用后钱包的地址都不一样？

这是BTC上常用的一个技术手段：HD Wallet

这种技术允许一对“公私钥”生成无数个子公钥，也就是我们看到的地址；这种特性是为了保护btc钱包使用者的隐私性。

因为在传统使用时，为了确认交易，使用者会暴露自己的公钥，那么就有泄露自己真实身份的风险（可以去持续的追踪），但是在采用了HD Wallet之后，每一次使用后，都会转换成另外一个子公钥，这样就无法追踪。

具体可以参考下面的文档：

https://learnmeabitcoin.com/technical/hd-wallets

Q3. RGB上的第一个资产是？

很多人会去争论“第一个”这个名头，因为人们喜爱追逐第一

如果要说RGB上的第一个资产，那很可能是Maxim博士自己尝试的时候发行的，当然，你我都没有看到

如果说LNP/BP协会开放的RGB示例资产，那么可以参考下面的网站

https://rgbex.io/assets?filter=rgb20

如果说是在RGB协议下项目方bitmask上发行的资产，可以参考下面的网站

https://beta.bitmask.app/#/registry

但是bitmask也仅仅只是RGB协议下的一个项目方，因为RGB是“客户端验证”的，所以只要你能够搭建一个客户端，利用“命令行”也可以发行自己的“第一个RGB资产”

所以，争论谁是第一对于短期的宣传我认为有意义，但是从长久来看，资产能够内含的价值才更有意义。这种价值有可能是社区精神，也有可能是赋能等等。

Q4. RGB的交易是实时上链的吗？

事实上，并不能这么问，因为：RGB利用比特币网络是为了“安全性背书”“防止双花”的，原则上它可以运用在具备这种特性的任何其他网络上。

如果RGB交易运行在主网，那么它的交易就是在主网实时上链的；如果RGB交易运行在闪电网络上，那么它的交易数据是实时上闪电网络的，闪电网络的数据是链下存储的，只有在提现的时刻才会在BTC主网上链；如果RGB交易运行在其他网络上，也是根据其他网络的情况来决定数据的上链情况。

还必须指出的是：RGB的实际交易数据是存储在客户端的，上链的是关于交易的承诺（committee）的聚合。

Q5. 介绍一下RGB到底能做什么？

对于我而言，我认为RGB是一项可以对接L1/L2/L3的通用技术，可以做很多事情，同时是BTC生态发展非常关键的一环；它可以实现BIFI，即bitcoin+fi，这个可以是defi，nftfi，gamefi，也可以是其他形式的fi

事实上很多人关注RGB在crypto中的应用，但是RGB可以做的更多，比如债券、国债、现实资产与虚拟资产的结合等等

Q6. RGB协议和主网、闪电网络之间的关系？

RGB协议可以运行在主网上，也可以运行在闪电网络上，甚至未来运行在侧链上也是可能的。

RGB被设计在运行在闪电网络上，是为了扩展性考虑的，因为运行智能合约，主网的tps显然满足不了这种要求，而闪电网络的高tps可以满足，但是当前的bolt闪电网络是不能满足RGB复杂的智能合约要求的，所以需要升级到bifrost才能够成为完全体；

Q7. 闪电网络目前用起来也经常有问题，为什么不选择运行在侧链上，而且老外为什么青睐闪电网络？

当前是因为闪电网络通道的大小问题造成的，而且闪电网络设计之初就是为了小额支付；当然，如果你自己建立一个大的通道，也可以实现大额的支付（一般大额都走主网）

为什么采用闪电网络而不是侧链的原因我认为有两个：

1️⃣侧链普遍被认为原生性不够，因为侧链都是有自己的链、自己的节点、自己的区块和自己的共识机制，你甚至可以说它和BTC主网的关系不大；但是闪电网络可以理解为就是挂在BTC主网上的一个东西，原生性很强，被称为L2

2️⃣闪电网络理论上的TPS远高于侧链

Q8. LNP/BP协会只接受捐赠，是不是可能反而会影响开发的进度？

这种担忧我也有，特别是目前看起来捐赠也不多（其实对于泰达公司等这样的投资回赔率很高），但是我还是赞赏协会的这种精神，以一种非营利性的方式来做这样伟大的事情。

主体上来说，RGB协议的大部分工作已经完成，当然后续依然后很多的任务；我觉得如果RGB协议得到了越来越多人的关注，随着越来越多dev的加入，开发工作会变快。

Q9. 泰达公司是要在RGB上发行稳定币吗？

是的，并且多次表示

Q10. RGB协议目前发展到什么程度了？

截止2023年12月17日，大家都在等v0.11的更新，本次更新涉及到了智能合约、钱包等的更新；希望v0.11成为一个较大的稳定版本，这样生态下的项目方才能比较安心的开发。

如果v0.11 release，那么很快基于闪电网络的rgb资产的发行和转移就能实现（会非常快），但是复杂的智能合约依然有赖于bifrost闪电网络的开发。

Q11. 介绍下RGB生态下的各个项目？

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：这个就完全是蹭的，就不用参与了

Q12. RGB的链上安全性能够理解，那么链下安全性如何理解呢？

链下安全性依赖于项目方或者客户端本身，所以需要协会针对存储等建立统一的标准，从而保证资产等的安全性。

Q13. RGB的数据存储在哪？

主要的数据存储在链下的客户端，客户端之间未来可以通过storm节点来共享信息和通信。

Q14. 说一下sideswap和liquid的关系？

我简要介绍一下，Adam Back创建了blockstream公司，这个公司旗下有很多产品，比如elements侧链开发平台，他们还有green wallet产品，还有真实的矿池，还有与矿池相关的理财产品、金融产品等；

Liquid就是用elements这个平台开发出来的L2，sideswap是Liquid上的一个项目。

Q15. RGB是链下存储的，那么链下数据的安全性由项目方保证吗？如果项目方的数据出现问题，资产是否有可能出现问题？项目方是否可能作恶？

链下数据的存储安全性是由项目方来提供，用户可以通过备份数据的形式来保护自己的资产安全；当然，如果项目方数据出现问题，用户自己也没有备份数据，那么资产就会出现问题。

一些有恶意的项目方可能通过创建恶意软件来犯罪，但是 RGB的使用机制可以避免机制上的诈骗，当然rug这种其实在所有区块链中都很难防。

Q16. 通过Storm节点，能够实现数据在不同项目方之间互联，并实现数据的去中心化？

是的，使用Storm协议，对等点之间的数据是共享的，但是目前的开发已经超期了

Q17. 由于RGB协议是私密的，外界无法看到个人的交易数据。项目放能否提供个人交易、转账等信息？

不可以。项目方无法收集有关个人交易的信息，可能只能收集应用程序内部完成的号码传输（例如总统计数据）。例如，这发生在 Bitmask 中

当然，我个人认为如果用户授权相关的权限，那么应用程序就能够访问这些数据（会有点类似于Liquid上的揭盲密钥查看致盲信息）

Q18. 是否有可能会出现一种类似于Liquid的证券资产（AMP）（必须向外界披露），使得必须符合一定规定的资产必须向外界披露？

是的，但每家公司都需要遵守有关证券的监管。

Q19. 如何证明一个资产是RGB资产？

1）资产具有 ContractID 和 genesis 初始值

2）与RGB钱包兼容

3）开源

这样就能知道是否是RGB资产

Q20. 既然不同项目之间的资产不能互操作，那么有没有可能存在一个共同的资产层呢？

UTXO 就是“公共”资产层，但仅限于相同资产之间，例如：USDT<>USDT；未来我们可以实现让不同资产之间“互操作”，但是这需要 Bifrost

Q21. RGB可以连接到不同的链，例如Liquid和其他L2吗？资产采取什么形式？它必须符合 RGB 资产规范吗？

这是可能的，但目标链必须支持 UTXO 模型及其他可用模型，以便与 RGB Core 和交叉库集成。这种时候，资产需要遵循RGB20模型的规范。

Q22. 如果RGB建立在闪电网络上，是不是可以这样考虑：RGB数据在链下记录，支付数据通过闪电网络确认，闪电网络数据通过多种模式上传到比特币主网进行确认？

实际上，RGB 与 LN 是兼容的，你可以在任何 LN 实施中使用它，例如插入 CLN 或 LND。当使用 Storm时，每个示例在LN上确认是可能的；在 L1 上，仅当您打开/关闭通道或使用 HTLC 进行扫描时才会确认并对资产进行路由传输。

Q23. 由于RGB资产转移的特殊性，需要双方确认，那么构建类似uniswap的amm机制是不是很难呢？可以通过让用户提前授权某些权限来实现吗？

是的，这需要很多支持库来共同作用，

理论上可以通过授权的方式来简化流程，当然，只是理论上

第四部分：参考链接

1. RGB技术官网

在这里，可以了解到：

1️⃣RGB是什么，能做什么，优点是什么（跳转）

2️⃣如何尝试RGB库，例如命令行，安装节点、调取API等等（跳转）

3️⃣通过官方的视频来学习RGB（当然，对于非英语的，有难度）（跳转）

https://rgb.tech/

2. RGB Blackpaper

该文档解释了设计原理，并提供了有关 RGB 系统如何构造和工作的深入技术见解，包括：

1️⃣协议设计的概述和目标（跳转）

2️⃣“客户端验证”介绍，讲述了“Single-use-seals”和“Deterministic bitcoin commitments”（跳转）

3️⃣“RGB合约、状态和操作”的说明（跳转）

4️⃣“尝试RGB合约”的一些内容：包括撰写合约，与合约交互、P2P通信，与钱包交互等（跳转）

https://blackpaper.rgb.tech/

3. 官方常见问题文档

如果遇到问题，可以先看这个官方文档有没有解答

https://rgbfaq.com/

4. AluVM虚拟机（相对硬核，需要一些基础）

在这里，可以了解LNP/BP协会开发的图灵完备的Alu虚拟机

https://www.aluvm.org/

5. 优质的RGB协议分析报告

1️⃣CoinEx Research

A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin

https://www.coinex.com/en/blog/3654-a-brief-analysis-of-rgb-a-scalable-confidential-smart-contract-protocol-built-on-bitcoin

2️⃣Federico Tenga

Understanding the RGB protocol

https://medium.com/@FedericoTenga

3️⃣Bitfinex

How Can RGB Improve Bitcoin?

https://blog.bitfinex.com/education/how-can-rgb-improve-bitcoin/

4️⃣Waterdrip Capital

详解 RGB 协议：另辟蹊径，创造比特币资产发行新二层

https://foresightnews.pro/article/detail/40092

5️⃣ RGB 协议的设计

https://www.btcstudy.org/2023/01/10/overview-of-the-main-concepts-and-features-of-the-rgb-design/#%E4%B8%80%E6%AC%A1%E6%80%A7%E5%AF%86%E5%B0%81%E6%9D%A1

目录

第一部分：科普部分-初步认识RGB

第二部分：协议部分-认识LNP/BP

第三部分：常见问题汇总