RGB 是由 LNP/BP 标准协会开发的可扩展且保密的比特币和闪电网络智能合约系统。它采用了私有和共同所有权的概念，是一种图灵完备的、无信任的分布式计算形式，不需要引入代币的非区块的去中心化协议。

撰文：Bill，Waterdrip Capital；Marvin、Neo，Infinitas

指导专家：洪蜀宁

引言：

约 45 亿年前，地球形成

约 35 亿年前，单细胞生物开始蠕动

约 30 万年前，智人（Homo sapiens）作为现代人类开始出现

约 150 年前，现代计算机的底层代码开始飞速运转

约 14 年前，比特币区块链的第一个区块「Genesis Block」（创世块）诞生，亦是整个比特币网络的起点

约几个月前，GPT 4.0 发布，与此同时，比特币背后的诸多核心技术，集体有了实质性的重大突破

此时此刻，正在阅读这些文字的你，或许对 RGB 充满了好奇和困惑

……

在加密资产的世界中，比特币无疑是最被人们所熟知的存在。然而，当人们在谈论比特币的时候，往往只关注它的价格、市值和交易量，却忽略了它背后的技术革新和应用潜力。我们在去年发布的《比特币闪电网络上的 DeFi 研究》中提到的诸多核心技术，都集中在今年上半年有了实质性的重大突破，比如：

• Lightning Labs，推出了 Taproot Assets v0.2（原称为 Taro）测试网；
• OmniBOLT，上线了 Mainnet，并实现了将 USDT 通过闪电网络进行收发和转账功能；
• RGB 协议，推出了更强大、更灵活、更安全的 RGB v0.10 版本。
• ……

说起 RGB 协议，人们对它也许既熟悉又陌生，熟悉源于 RGB 的概念早在 2016 年就被提出，很多人都知道 RGB 协议的存在，但是经过数年发展，它却并没有得到广泛的关注和应用，大家似乎也找不到 RGB 协议的具体应用案例。

我们经过调研分析后认为造成这一现象的主要原因，是在 RGB 协议的早期版本中，其功能相对有限，且 RGB 协议的思想具有高度的原创性和独特性，技术栈相当宏大，开发人员需要深度理解比特币和智能合约的原理后才便于上手使用。然而，随着 RGB 协议的不断发展和精进，这种情况正在发生改变。

一、初识 RGB

1、什么是 RGB

RGB 是由 LNP/BP 标准协会开发的可扩展且保密的比特币和闪电网络智能合约系统。它采用了私有和共同所有权的概念，是一种图灵完备的、无信任的分布式计算形式，不需要引入代币的非区块的去中心化协议。

RGB 的设计目的是在 UTXO 区块链（如比特币）上运行可扩展、稳健和私密的智能合约，以实现一切可能性。通过 RGB，开发者可以执行如代币发行、NFT 铸造、DeFi、DAO，以及更多复杂的多类别智能合约。

RGB 协议是基于 Peter Todd 在 2016 年提出的客户端验证（client-side validation）和一次性密封（single-use-seals）的概念，在比特币生态系统的第二层和第三层上（链外）运行的客户端状态验证和智能合约系统。（下面仅对这两个概念进行简单介绍，有兴趣的读者可以查看 Peter Todd 原论文：https://petertodd.org/2017/scalable-single-use-seal-asset-transfer )

客户端验证（client-side validation）：

客户端验证是由 Peter Todd 在 2016 年提出的范式。其核心思想是，在分布式系统中，状态验证不需要所有参与去中心化协议的各方全局执行；相反，只需要参与特定状态转换的各方进行验证。采用这种方法，状态转换不是发布到全局网络中，而是通过使用密码哈希函数等方式转化为一个简短的加密承诺，该承诺需要成为某种「出版证明（Proof-of-Publication）」媒介的一部分，并具备收据证明、非发布证明、成员资格证明这三个主要特点。第一个客户端验证系统是 OpenTimeStamps 协议，同样是由 Peter Todd 在 2014-2016 年间提出和开发的。

一次性密封（single-use-seals）：

可类比为现实世界中用于保护货运集装箱的一次性封条。一次性密封的原语是单个仅可一次性地封装消息的独特对象，确保这条消息只能被使用一次，一旦被使用即被永久性地打开，无法再次封闭。简而言之，一次性密封是一种抽象机制，用于防止双重支付。

2、RGB 简史

RGB 最初构想可以追溯至 2016 年，由 Giacomo Zucco（BHB Network）基于 Peter Todd 关于客户端验证和一次性密封的早期理念提出，于 2017 年由 BHB Network 在原始 MVP 中实施，并得到 Poseidon Group 的支持。

2019 年，Maxim Orlovsk 和 Giacomo Zucco 共同成立了 LNP/BP 标准协会（https://www.lnp-bp.org），旨在推动 RGB 从概念诞生到实际应用的阶段。该协会得到 Fulgur Ventures、Bitfinex、Hojo 基金会、Pandora Prime 和 DIBA 的支持。

（Maxim Orlovsk）

从 2019 年开始，Maxim Orlovsky 博士担任 RGB 协议的主要设计师和首席贡献者，设计和实现了当前的 RGB 协议形式。自 2019 年以来，RGB 在设计和协议同行评审方面进行了重新构思和重新设计，成为一种通用的计算和保密智能合约系统。

2021 年，LNP/BP 标准协会成功地展示了 RGB 搭载了图灵完备的虚拟机（AluVM），同时 RGB 在闪电网络上也开始运行，使用了由 Maxim Orlovsky 博士在协会进行的完整的闪电协议的 Rust 重新实现（LNP Node）。

2022 年，LNP/BP 标准协会推出了一个关于 Contractum 语言 ( 新型高级语言 ) 的新网站（contractum.org），用于为 Bitcoin 和 LightningNetwork 编写 RGB 智能合约。Contractum 作为一种功能性声明式编程语言，专为使用 RGB 技术在比特币和闪电网络上运行的智能合约开发而设计。

今年，2023 年 4 月，LNP/BP 协会宣布 RGB v0.10 发布，这是 RGB 协议发展中又一重要里程碑，为比特币和闪电网络带来了完全支持智能合约的功能。是这些比特币开发者、贡献者、相关公司之间长期跨行业合作以及四年多广泛的开发工作的成果。（RGB v0.10 可以在 https://rgb.tech 中进行下载和安装，该网站还包含许多用户和开发者指南。RGB 源代码可以在 https://github.com/RGB-WG 找到。）

二、理解 RGB：

1、背景

许多年来，一些项目及团队始终在研究在比特币上发行代币的协议并尝试突破使之与闪电网络兼容，其中代表有 OmniBOLT、 Taproot，以及 RGB。

我们熟知的在比特币上发行代币的协议，比如 OmniLayer，其工作原理是在比特币交易中插入元数据来「染色」，并表示该笔交易应该被理解成一笔代币转移。Omni 协议中的 USDT（Tether）可以被看作是染色币的一种形式。在 Omni 协议中，USDT 是以 Tether 代币的形式存在，它通过在比特币交易中使用 Omni 协议的特定交易类型来表示。具体来说，当用户在 Omni 协议上发起一笔 USDT 交易时，他们会在比特币交易中添加 OmniLayer 的特殊数据字段，以指示该交易涉及 USDT 代币的转移。这种方式使得比特币交易能够代表 USDT 代币的转移，并且 USDT 的持有者可以使用比特币的地址来接收、发送和存储 USDT 代币。

这样的信号机制通常是用 OP_RETURN 操作码来实现的，带有该操作码的输出会被普通的比特币节点无视，但可以被能够感知这些代币协议的节点解释，这些节点会实施代币协议的验证规则。

虽然这种设计是很高效的，但它也存在一定局限：

1）与代币转账相关的信息量被限制在 OP_RETURN 输出可以容纳的字节数以内，一般来说是 80 字节，这个空间对普通的交易数据编码来说足够了，但更复杂的应用场景就难以被满足。

2）代币协议节点需要扫描整条区块链、在 OP_RETURN 输出中搜索可能与用户相关的代币转账，整个流程会因为比特币区块链体积的增长而更加耗费资源。

3）用户的隐私性方面，所有的交易数据对所有人都是可见的。

2、RGB 的解决方案：链下转移

怀着优化这种设计的目的，RGB 协议提出了一种更可扩展、更加隐私、更面向未来的解决方案，其基石是 Peter Todd 在 2016 年 提出的客户端验证（client-side validation）和一次性密封（single-use-seals）的概念。

RGB 协议的核心理念是，仅在必要的时候才调用比特币区块链，也就是利用工作量证明和网络的去中心化来实现重复花费保护和抗审查性。所有的代币转移的验证工作都从全局共识层中移除、放在链下，仅由接收支付的一方的客户端来验证。

工作原理：

在 RGB 的某个合约中，创世代币都归属于一个比特币 UTXO（无论是已经存在的，还是临时创建的），而为了转移代币，你需要花费此 UTXO。在花费这个 UTXO 的时候，比特币交易必须额外添加一个输出，该输出包含对一条消息的承诺，这条消息的内容就是 RGB 的支付信息，它定义了输入、这些代币将被发送到哪个 UTXO、资产的 id、数量、花费的交易以及其它需要附加的数据。

如果你有一笔归属于比特币交易 A 的 #1 输出的代币，要转移这些代币你就需要创建一笔 RGB 交易以及一笔花费交易 A 的 #1 输出的比特币交易，并且这笔比特币交易承诺了 RGB 交易。如你所见，RGB 交易是把代币从比特币交易 A 的 #1 输出转移到比特币交易 C 的 #2 输出（这笔交易在图中没有表现出来），而不是转移给比特币交易 B。在大部分情况下，我们可以预期交易 B 的 #0 输出就是找零地址，为的是在减去矿工手续费后将剩余资金发回给原来的所有者；同时 #1 输出是为了承诺 RGB 交易，以避免重复花费。

隐私性保护：

为了转移归属于一笔比特币交易的 RGB 代币，需要发起一笔比特币交易。但是，RGB 转账的输出不需要跟比特币交易的输出相同。就像我们上面这个例子，RGB 交易的输出（比特币交易 C 的 #2 输出）可以跟承诺这笔 RGB 交易的比特币交易（交易 B）没有任何关联。这就意味着，RGB 代币可以从一个 UTXO「传送」到另一个 UTXO 中，而完全不会在比特币交易图中留下任何痕迹，这极大地提高了隐私性。

在这种设计中，比特币的 UTXO 的作用是装载 RGB 资产的一次性容器，要转移资产，你只需要打开新的容器、关上旧的容器。

RGB 代币的具体支付信息是在链下通过专门的通信通道来传输，从支付者发往接收者的客户端并由后者来验证其没有违反 RGB 协议的规则。如此一来，区块链观察者将无法获得任何关于 RGB 用户活动的信息。

验证闭环：

不过，验证发来的支付信息还不足以确保发送者真的拥有要发送给你的资产，因此，为了确保发来的交易具有终局性，你还必须从支付者处接收关于这些代币的所有交易的历史，即从当前的这一笔一直追溯到其最初的发行的那一笔。验证了所有的交易历史，你就可以保证，这些资产没有被通胀、附加在资产之上的所有花费条件都得到了满足。

这个设计也有益于可扩展性，因为你无需验证这种资产的所有历史，只需要验证跟你有关的部分。而且，交易不会广播到全局账本中的设计，也提高了隐私性，因为更少人知道了你的交易的存在。

盲化秘密值：

为了进一步提高隐私性，RGB 还支持盲化输出（blinding of outputs），意思是说，在你向支付方发送支付请求的时候，你无需公开自己用来接收代币的 UTXO，只需要求支付方把代币发给一条哈希值，这条哈希值是你用目标 UTXO 本身拼接一个随机盲化秘密值之后生成出来的。这样一来，支付方就无法知道代币会发送给哪个 UTXO，因此交易所和其它服务商也无法知道用户是否正在取款到被一些监管机构「黑名单」的 UTXO 中，也无法知道这些代币未来是如何花费的。需要注意的是，在代币被花费的时候，盲化秘密值必须向接收者公开，以便后者能验证交易历史中跟比特币交易有关的部分。这意味着，使用 RGB 的时候，你在当下拥有完全的隐私性，但未来的代币持有者将能看到自己手上的代币的转移历史中的所有 UTXO。因此，虽然在接收和持有 RGB 代币时你可以获得完美的隐私性，但用户过往金融活动的机密性会随着代币的不断转移而不断降级，最终趋向于跟我们的比特币交易历史同样的隐私性。

3、RGB 的主要特性

通过对以上内容的理解，我们可以总结出 RGB 具有如下几个主要特征：

1、高保密性、安全性、可扩展性

2、没有比特币时间链的拥堵，因为交易只保留需要额外存储的同态承诺

3、未来可升级而无需硬分叉

4、具有较比特币更高的抗审查性：矿工无法看到交易中的资产流动情况

5、没有区块和链的概念

值得注意的是，当我们提到区块链（Blockchain）时，一般会涉及到区块（Block）和链 (Chain) 这两个概念，而 RGB 中没有区块和链的概念，因为它是一种客户端验证技术，是一个非区块的去中心化协议。

三、RGB v0.10 的无限可能性

RGB v0.10 版本标志着一次重大突破，将 RGB 推进到了即将投入商用的系统阶段。它引入了最后一次打破共识的更改，旨在保持未来 RGB 版本的完全向后兼容性。此外，它也解锁了最后一批功能，用于实现完全功能的智能合约，这些智能合约可以由合约开发者任意定制。

RGB v0.10 的发布，其中包括共识层、标准库（用于钱包 / 交易所集成等）和命令行工具。下面的表格是我们根据 RGB 官方材料整理总结的新旧版本之间的主要区别，想要了解更详尽内容的读者可查看 RGB 官方文档和视频介绍:

https://rgb.tech/blog/release-v0-10/ https://www.youtube.com/@LNPBP/videos

1、RGB v0.10 解读

总的来说，RGB 协议的 v0.10 版本解决了许多旧版本存在的问题，包括智能合约开发的限制、共识层的触及、编码格式的局限性、Rust Bitcoin 的依赖问题、WASM 兼容性缺失、全局状态和上下文管理问题、与 Lightning Network 的集成问题、备份过程的不灵活、移动钱包的支持不足等。这些改进使 RGB 协议更强大、更灵活、更安全，并为未来的发展打下了坚实的基础。具体来说，RGB v0.10 版本为 RGB 引入了以下功能支持：

RGB 合约中的全局状态

RGB 引入了全局状态（Global State）的概念，这是一种全新的功能，对于在 RGB 上构建复杂的应用程序来说（如合成资产、算法稳定币等）非常重要。现在，每个 RGB 合约都有一个可以被虚拟机和客户端（如钱包等）访问的全局状态。

合约接口

在这个版本中引入的接口，通过明确定义的 API 表示了一种标准化的方式来传递各种智能合约。接口可以与以太坊世界中的合约 ABI 和 ERC 进行比较，然而与以太坊不同的是，它们既不需要强制标准化（如 ERC），也不需要单独分发，而是始终与合约一起打包。通过使用接口，钱包和其他软件可以为用户提供一个语义感知的用户界面，用于处理合约 - 合约开发者还可以随着时间推移向其现有合约添加更多接口，而无需更新不可变的合约本身。

RGB 智能合约的基本构成：RGB 智能合约由 Genesis（创世）、State（状态）和 Transitions（转换）三部分组成。Genesis 定义了合约的基本属性和规则，State 是合约的当前状态，Transitions 则是状态之间的转换。RGB v0.10 引入了一种新的智能合约模型，这种模型更加灵活和强大，可以支持各种复杂的应用场景。

严格的类型系统

新的编码格式是指「strict types」系统，严格类型是一种新的功能性数据类型系统，用于 RGB 合约状态的表示和内省。它允许在编译时对任何数据的大小进行保证，从而简化 RGB 在低端和有限内存设备（如硬件钱包）上的操作。整个 RGB 共识层现在都被编译为严格类型，这允许对发布之间的二进制兼容性进行正式证明。

换句话说，这个新的编码格式将会使得 RGB 的使用变得更加简单和安全，同时也将会使得资产发行者和合约开发者能够使用额外的元数据来签名他们的资产或合约，这将有助于验证资产或合约的身份。

在 Rust 中编写合约

可以使用 Rust 编写和编译 RGB 智能合约。由于严格类型的存在，现在还可以将 Rust 数据类型直接编译到 RGB 合约中。

状态内省（State introspection）

合约可以在虚拟机使用的验证代码中内省其自身状态，这为编写与比特币交易、DLC 和其他复杂数据交互的复杂合约形式打开了可能性。

基于 URL 的发票格式

以前，RGB 使用 Bech32m 编码的发票，这些发票非常长，不易读，并且大多数软件无法自动打开。新的格式更短，用户更易验证，可以作为预配置软件的链接自动打开。

WASM 支持

RGB 标准库可以在没有 I/O 和文件系统访问的情况下运行，也就是说，它可以在网页或浏览器插件中运行。

Tapret 描述符和自定义派生

RGB 使用基于 Taproot 的 OP_RETURN 承诺（简称为 tapret），它需要在描述符级别上进行支持，以便钱包可以将具有调整输出的交易视为属于钱包描述符的交易。新版本还引入了自定义派生索引，防止非 RGB 钱包意外消费带有 RGB 资产的输出（从而破坏资产）。

简化的依赖关系

RGB 共识层现在使用较少的依赖项，提高了 API 的稳定性。LNP/BP 放弃了来自 Grin 项目的自定义 bulletproofs 实现的依赖。

简化的集成

许多以前需要多个 API 调用以及跨语言编码复杂数据结构的操作现在都可以通过单个 API 调用来完成。RGB 合约状态以 JSON 对象表示，可以在不同的语言之间进行序列化而无需繁琐的操作。

简化的用户体验

以前使用 RGB，钱包或用户必须运行 RGB 节点，并通过 RPC（或 cli 工具）进行接口交互 - 并使用许多其他库和命令行工具来执行大部分 PSBT 等操作。新版本中，这个复杂的堆栈被单个 API 库和 rgb 命令行工具取代。

2、RGB v0.10 有哪些重大突破？

前文中提到了我们认为造成 RGB 经过了几年的发展，却没有得到广泛的关注和应用的主要原因。而经过对 RGB v0.10 版本的研究，我们有理由认为，这一现象即将改变，甚至改变正在发生。

1、在之前的版本中，独立开发者为什么不能进行复杂智能合约开发？

在 RGB v0.10 之前的版本中，独立开发者会面临在进行复杂智能合约开发时的一些挑战。这主要是由于以下几个原因：

1）协议的不稳定性：在早期版本中，RGB 协议可能会经历一些重大的变化，这可能会导致已经开发的智能合约无法在新版本的协议上运行。这种不稳定性可能会阻碍开发者进行复杂的智能合约开发。

2）缺乏工具和资源：在早期版本中，可能缺乏足够的工具和资源来帮助开发者进行复杂的智能合约开发。这包括缺乏详细的文档、教程或者开发工具等。

3）协议的复杂性：RGB 协议的设计和实现可能相当复杂，这可能会对独立开发者构成挑战。例如，RGB 协议使用了一种名为「client-side validation」的新颖的验证机制，这可能需要开发者有深入的理解和专业知识才能进行复杂的智能合约开发。

然而，随着 RGB 协议的发展，这些问题正在得到解决。例如，RGB v0.10 版本引入的一种新的类型系统，称为「strict types」，这可以帮助开发者更容易地进行复杂的智能合约开发。此外，该版本还提供了更多的工具和资源，以帮助开发者理解和使用 RGB 协议。

2、为闪电网络带来完全支持智能合约的功能成为可能

因为 RGB 是建立在比特币上的，使用闪电网络来转移 RGB 资产在理论上是可行的。但在之前的版本中，由于架构限制，RGB 无法在任何现有的闪电节点中使用。2021 年，RGB 开发了自己的架构，称之为 LNP Node，并使用 Rust 编写。它本身并不依赖于 Bitcoin Core，如果用户想要在闪电网络中将 RGB 与 Taproot 结合使用，则需要等待 Rust-bitcoin 完成对 Taproot 的支持。

而现在，随着 RGB v0.10 版本的发布，LNP/BP 协会宣布了未来要做的重点，就是计划在未来几个月内完成对 Lightning Network 的支持，使 RGB 资产可以通过 Lightning Network 进行转移。

RGB 如果完成了 Lightning Network 的兼容和支持，可以提高 RGB 资产的流动性和可用性。通过 Lightning Network，用户可以快速、便宜地转移 RGB 资产，而无需等待比特币主网的确认。这对于需要频繁交易 RGB 资产的用户来说是非常有用的。

更重要的是，RGB 可能为闪电网络带来完全支持智能合约的功能。

闪电网络具有惊人的速度、极低的费用和卓越的安全性。然而，因为比特币本身并不支持复杂的智能合约，闪电网络在智能合约方面受到了一定限制。

RGB 能够支持复杂的智能合约功能是因为其经过了深思熟虑的设计，专门为在闪电网络上实现智能合约而创建。首先，RGB 采用了 Turing 完备的虚拟机（AluVM），这是一种强大的计算引擎，允许在闪电网络上运行复杂的智能合约。AluVM 使得 RGB 能够处理复杂的计算逻辑和数据操作，从而实现了各种类型的智能合约。

RGB 在其设计中充分考虑了闪电网络的特点和需求，可能会为闪电网络带来完全支持复杂智能合约的能力，无论是 DeFi、NFT、GameFi，还是 SocialFi，RGB 都有可能在闪电网络上实现。

这一无与伦比的组合不仅可能会让闪电网络成为一颗璀璨的明星，也可能会使得其他区块链黯然失色。随着越来越多的资金和开发者涌入到比特币闪电网络和 RGB 的开发，有望使得比特币和闪电网络的生态系统达到全新的高度。

四、RGB 与其它方案的比较

1、基于山寨币的代币协议

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

2、Liquid 资产

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

3、OmniBOLT

OmniBOLT 是 OmniLayer 的兼容闪电网络的版本。OmniLayer 在前文中已经简要介绍过了（感兴趣的读者也可以阅读《比特币闪电网络上的 DeFi 研究》，这里有更详细的介绍）。

OmniBOLT 的取舍跟 RGB 非常相似，区别点在于这两个协议的设计目标不同，相比 RGB，OmniBOLT 在隐私性方面相对较弱，因为和比特币一样，代币相关的数据都存放在链上。但是 OmniBOLT 在稳定币支付业务上具有得天独厚的优势，且经过了时间的检验。今年 6 月份 Mainnet 已经上线，并实现了将 USDT 通过闪电网络进行收发和转账功能。

4、Taproot (Taro)

在 Bitcoin 2022 Miami 大会上，Taro 发布。Taro 背后是 Lightning Labs 团队，协议的目标是将资产带到闪电网络上。根据已经放出的技术规范，整个设计与 RGB 非常相似，特性和取舍基本上是一样的。

RGB 和 Taro 的主要区别似乎在于:

1）RGB 更早，已经公布了可以审核的代码，但是资金缺乏，缺少运营人员。

2) Taro 目前只是一种规范，但另一方面，Taro 的背后是 Lightning Labs，团队于去年 4 月份募资 7000 万美金，并在今年 5 月份推出了 Taproot Assets v0.2（原称为 Taro）测试网。

如果 Taro 和 RGB 最终可以相互操作，让这种互操作性得以发生的激励因素是否存在，目前还无法判断。

五、值得关注的 RGB 生态项目 / 开发团队

1、Infinitas

官网：https://www.iftas.tech/

Infinitas 是最早开启基于比特币构建图灵完备的智能合约赛道的项目之一，作为揉和 RGB 协议和闪电网络的比特币应用生态网络，旨在实现更高的隐私保护、卓越的吞吐量和出色的低延迟交易处理。Infinitas 作为一项创新的区块链解决方案，自 2021 年起夯实基于 RGB 的比特币图灵完备智能合约想法，充分发挥了比特币的安全性和共识机制，允许在比特币网络上创建更复杂的应用程序和智能合约，希望为用户带来卓越的交易体验。项目技术核心由比特币底层部分代码建设者，最早关注到 RGB 协议且进行翻译相关工作的 Top 级区块链科学家团队带领。Infinitas 将优先提供 Online IDE，数据浏览器，接入主流钱包等方式让开发者和用户参与到生态中，真正支持 RWA 和全链游戏等大体量商业应用的落地。

项目特点：

• 全网哈希算力保护：继承了比特币区块链的高安全性，确保了 Infinitas 资产在比特币区块链中得到全网哈希算力的保护，增强了资产的安全性。
• 更高水平隐私保护：实现了 Infinitas 资产的更高水平隐私保护，并引入了无需信任的比特币锚定机制，进一步加强了用户隐私。
• 适配器技术：通过 Infinitas 适配器技术，用户可以实现对比特币完整状态的了解，增强了对资产状态的感知能力。
• 丰富全局状态：通过完善和扩展 RGB 的全局状态（Global State），为虚拟机和客户端（如钱包等）提供访问接口。尤其在智能合约地址的信任方面进行特殊加强，从而关键性地支持了在 RGB 生态系统中构建复杂的应用程序。这一举措还使得不同系统能够相互理解和解释各自的状态，进一步推动了整个生态系统的发展。
• 优化闪电网络：通过对闪电网络的改进（如轻区块技术、节点自动扩容技术以及离线时的自治能力），实现了更高的交易吞吐量，同时保持低延迟的交易确认时间。
• 开发者友好：使用 Rust 语言，以 Schema 层作为开发基建，可以让普通人都参与到开发中。

据悉，Infinitas 会拥有其原生经济的激励方案，前期将采用挖矿形式在市场产出以促进生态的长期发展。作为业内优先打造图灵完备的比特币应用生态项目，或将成为比特币资产应用的现象级引爆点及推动 Crypto 大规模采用的一次重大飞跃。目前测试网暂未上线，可保持关注。

2、COSMINMART

https://cosminmart.com/

COSMINMART 是以闪电网络为基础，兼容 RGB 等协议，支持智能合约的全新比特币应用生态。

• COSM Wallet：COSMINMART 旗下核心产品，在整个比特币生态网络具有广泛适用性，现已支持比特币主网及闪电网络转账，RGB 协议资产转账等功能，将逐步兼容 Stacks，Rootstock 等生态系统。
• COSM Market ：是目前较早支持比特币衍生资产聚合交易平台之一，将逐步扩大支持范围，为各类比特币衍生资产交易提供便利。
• COSM Lanuchpad： 旨在筛选具备优质潜力的比特币生态项目，致力于比特币生态的可持续发展。

COSMINMART 率先定义 Web4 概念，积极推进 RGB 新协议标准制定，发行闪电网络稳定币，结合 Nostr 等协议及闪电网络交易优势，将传统 APP 与闪电网络深度融合，希望引领闪电应用（Lightning-Application）的崭新时代。

据悉，COSMINMART 计划在今年年底推出公测产品，可保持关注。

3、Pandora Prime Inc

https://pandoraprime.ch/

Pandora Prime ( 潘多拉主星 ) 是一家位于这是一家总部位于 Verify Valley（纳沙泰尔州）的瑞士公司，同时也是 LNP/BP 的创始成员。

Pandora Prime 致力于使用 RGB 智能合约和闪电网络的结合来开创比特币金融（Bitcoin Finance）。他们从比特币上的可编程资产（RGBTC 和 CHFN）开始，这些资产可以通过闪电网络在交易吞吐量方面扩展到 VISA/MasterCard 级别，另外，也提供便利的设施来交换这些资产，无需繁琐的 KYC 程序即可进行 1,000 瑞士法郎以下的交易（符合瑞士法律规定）。目前，他们的产品包括 MyCitadel（钱包）、RGB Explorer（浏览器）和 Pandora Network 等。

MyCitadel

https://mycitadel.io/

MyCitadel 是 Pandora Prime 的一个品牌，MyCitadel 是第一个支持 RGB 的图形用户界面钱包，由 RGB 开发人员于 2021 年创建。它提供跨平台桌面钱包和 iOS/iPad 钱包。移动钱包可以处理可替代性的 RGB 资产。

RGB Explorer

https://rgbex.io/

RGB Explorer 是由 Pandora Prime 开发的第一个提供 RGB 资产注册和智能合约的浏览器。目前支持 RGB20、RGB21、RGB25，可以显示的资产有 LNPBP、RGBTC、dCHF 和 RGBEX 这四种。

DIBA（DIGIT ALBITCOIN ART）

https://diba.io/

DIBA 致力于通过帮助人们理解、拥有和使用建立在比特币之上的非托管数字资产，提升社区的发展。并希望以去中心化和包容性赋权原则塑造数字艺术和资产经济。

DIBA 是第一个使用 RGB 智能合约协议和闪电网络来交易比特币 NFTs 的市场（DIBA 称之为）。目前 DIBA BETA 正在运行于比特币测试网，即将上线比特币主网，可保持关注。

Bitmask

https://bitmask.app/

该钱包由 DIBA 创建，是 RGB 生态的首个 NFT 钱包，可在 Web 浏览器中运行，并与类似以太坊上的 MetaMask 一样与 RGB 合约进行交互。

5、IRIS Wallet

https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

IRIS Waller，Bitfinex 团队开发的第一个 Android 钱包，致力于 RGB 集成和 RGB 相关工具。支持可替代和不可替代资产（fungible and non-fungible assets）。Iris Wallet 支持从发行到支出和接收的 RGB 资产操作，将所有功能包装在一个熟悉的钱包应用程序中，并尽可能多地抽象出技术细节。目前这还是一个实验性应用程序，建议仅用于少量比特币和低价值资产。

6、Bitswap-BiFi

https://github.com/BitSwap-BiFi/Bitswap-core

目前 RGB 生态正在积极探索 DEX 方案，以解决 RGB 资产流动性问题。Bitswap 的演示和概念验证中，展示了如何将「SWAPS」引入 DEX，但暂时没有 AMM 或 LP。目前还处于验证阶段，非常早期，同样值得关注。

六、回顾和展望

RGB 协议从最初的构想迈进至今，经历了近 6 年的演进。虽然到了今天，RGB 协议尚未在广泛范围内受到关注和应用，但历史经验告诉我们，人们常常高估了新创意的迅速普及速度，同时低估了这些构想最终被广泛接受时可能引发的颠覆性影响和速度。实际上，随着 RGB 协议 v0.10 版本的推出，我们正站在一个崭新的起点，目睹着像比特币一样具备无限可能性的未来。

全新版本的 RGB 协议引入了一系列重要的更新，这些更新使得 RGB 协议不仅能够在比特币网络和闪电网络上进行多种资产的发行和转移，还具备了支持更为复杂智能合约的能力。尽管 RGB 协议尚未完全实现与闪电网络的兼容，然而我们坚信，在未来的几个月中，LNP/BP 协会及相关开发团队有望取得更为显著的进展。我们怀着对 RGB 协议与闪电网络的完美融合的期待，这将成为 RGB 协议与比特币共同迈向另一个重要里程碑的体现。

RGB 协议所带来的这些新功能和改进，特别是对闪电网络的完全兼容性，为比特币的未来点燃了一盏明灯。这些变革打开了通向未知领域的大门，让我们透过其中看到了比特币的无限潜能。在这未知的领域中，比特币不再仅仅是一种简单的支付手段，而是一个能够承载复杂应用的强大平台。而 RGB 协议，则成为了构筑这一平台的基石，可能引领我们迈向一个崭新的 Crypto 世界。

附：参考文献：

https://rgb.techhttps://rgbfaq.com

https://lnp-bp.orghttps://twitter.com/lnp_bp

https://www.youtube.com/@LNPBP/videos

https://blueprint.rgb.network

https://www.youtube.com/watch?v=DtkTE6m0zio

https://petertodd.org/2017/scalable-single-use-seal-asset-transfer

https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059

https://www.contractum.org/