比特币闪电网络和零知识证明技术为基础的的状态通道校验协议，通过二层，赋予比特币网络图灵完备的智能合约功能，并且用户能够保护隐私的方式安全地进行链下处理交易。

RGB 不仅只为发行代币而设计，同时具备发行和管理各种具有高扩展、可编程和可靠的数字资产。所以还支持金融领域以外的领域。

1. RGB 协议发展路径

• 2016 年 Giacomo Zucco 受 Peter Todd 的想法启发，开启了 RGB 协议概念性实践。
• 2017 年 Poseidon 组织发起的 BHB 网络上线原始版本的 RGB 协议。
• 2019 年 Maxim Orlovsky 和 Giacomo Zucco 建立 LNP/BP 标准协会来推广 RGB 协议的应用实践。Maxim Orlovsky 重新设计 RGB 协议。
• 2021 年 LNP/BP 标准协会验证了 RGB 图灵完备的虚拟机 (AluVM)，RGB 支持在比特币闪电网络运行。
• 2022 年引入了 Contractum 语言编写 RGB 智能合约，兼容比特币和闪电网络。
• 2023 年四月发布 RGB 0.10 版本正式宣告生产环境可用的比特币和闪电网络智能合约。

2. 协议设计逻辑

RGB 协议的核心思想围绕比特币网络第一层工作量证明 PoW 共识和二层链下数据存储两个重要环节。

分布式系统的重要价值无非就是节点间的共识维护。RGB 依赖比特币网络的共识，保留冗余的事件在 RGB 客户端，把客户端的数据通过简短的密码学哈希计算，产生短数据提交到比特币网络用以数据校验。此种方式确保了链下数据的有效性和完整性而不额外增加比特币网络一层数据冗余。

RGB 账本数据链下存储，意味着智能合约数据和状态变化过程产生的事件数据都不会上链。到此，开始提到单次使用封条 (single-use-seals) 和状态转移两个重要概念，RGB 协议不在链上存储虽有数据的前提下，得以有效地追溯和验证智能合约的状态。所以在处理和验证智能合约的状态和状态变化尤为高效率。

RGB 协议的基石建立在健壮的比特币第一层网络，工作量证明 (PoW) 的共识算法和全球公开账本。同时数据不必全部上链，利用比特币已有的账本基础设施，以交易为载体来存储链下数据的校验哈希。简而言之，利用比特币第一层协议来建立 RGB 的客户端校验机制。

2.1 客户端校验

RGB 智能合约的客户端校验模型，所有的数据都没有在比特币交易结构中，包含比特币网络和闪电网络的通道状态之中。这套系统运行于闪电网络，实现了扩容和隐私友好的高阶协议的基础功能。

2.2 RGB 智能合约

RGB 智能合约包含创世 (Genesis), 状态 (State) 和状态转移 (Transition) 三个基础组建。

• 创世 (Genesis) 声明智能合约，定义合约的属性和规则，其中包含了合约类型、目的和初始化设置。在代码中，创世部分设置了合约的起始点，例如在标识校验的合约中初始化特定的标识信息。
• 状态（State）: 状态代表在给定时间点的合约当前状态，实时的合约数据快照，这些数据包含虽有的变量值和资产信息。
• 状态转换 (Transition)：状态转换顾名思义即状态从某种状态转换到另一种状态变化规则。这些规则根据合约逻辑来决定状态如何变化。例如销毁操作 (op Revocation, op Transfer)，来约束标识如何从某中状态更变为另外一种状态，转账操作（op Transfer）定义代币转账逻辑。

通过以上三种组件是 RGB 智能合约的架构，定义和执行各种操作和合约协议。创世组件设置了规则和参数，状态维护合约当前的信息，状态转换组件控制状态改变的逻辑。

2.3 单次使用封条 Single-Use Seals

在保护用户隐私的前提下，为确保资产安全和高效地管理，RGB 协议使用一种称为 "single-use-seals" 单次使用封条的方法。该方式通过在比特币交易的输出中绑定资产（代币属于资产的一种），每次资产转移操作都必须打开一个就的封条并创建一个新的封条。单次使用封条代表着资产拥有权或合约状态。每次状态转换或状态或交易都会销毁对应的封条和新建一个新的封条，以此实现资产保护，也就是防止双花，确保资产转移的不可篡改。

以上操作仅发生在 RGB 客户端，并且产生的数据只有最后的哈希上链，以此实现了隐私保护，降低比特币账本的空间使用，最终实现了 RGB 二层的效率和可扩展性。

单次使用封条的步骤

1. 智能合约起始于创世操作，定义初始状态和对应的单次使用封条。定义了合约中的初始资产分发规则或权利。
2. 在合约中，状态代表当前资产的配置或权利，每个状态都和一个单次使用封条关联，表明资产当前的拥有权。
3. 状态转换是资产或权利的转移或改变过程。包含关闭当前的单次使用封条（代表旧状态）和新建一个新的封条。
4. 关闭一个封条涉及到封条的完整性校验并标记已被使用，防止再次使用。然后根据合约规则创建一个新的封条，以此代表新状态。
5. 状态转移，合约涉及到的参与者需要验证对应的单次使用封条的有效和法性。验证的过程通过 RGB 节点和参与方的钱包自动完成。

3. 建立 RGB 闪电网络通道

从支付的角度看 RGB 闪电网络通道的创建过程，有以下步骤：

3.1 通道创建

两个节点之间建立支付通道，BTC 是必须的。例如在 Umbrel (用户可以运行比特币和闪电网络节点)，用户在控制面板中点击 Bitcoin 标签，选择充值，然后用户把 BTC 转到 Umbrel 节点的比特币钱包地址，用户节点有了 BTC 之后，就可以创建闪电网络通道。

3.2 多签合约

通道核心是 2-2 多签合约，通过比特币上的哈希时间锁定合约来实现 (Hash Time Locked Contract - HTLC). 也就是两方同时控制 BTC，从技术的角度看，这些 BTC 是双方共同持有，单方各自持有解锁被锁定的 BTC 一般的控制权限。

3.3. 交易执行

通道内部，在多签合约中发起支付，每个通道 (channel) 代表比特币区块链中的一个 UTXO（HTLC 产生的交易输出），被两个节点共同控制，通俗讲就是共管账户。

3.4 链下交易

通过这些通道，用户可以在链下执行无限笔交易，明显地降低了交易手续费，同时也利用了比特币网络的安全性。

4 钱包的 RGB 协议交互

RGB 协议的关键在于用户通过钱包来交互复杂的交易和合约操作。结合官方的技术文档逐步解释这些操作步骤。

初始准备

钱包需准备特定的比特币交易草稿（学名叫 PSBT - Partially Signed Bitcoin Transaction 比特币交易的部分签名），类似对交易结构拟写合约纲要。

发信息到 RGB 节点

钱包把准备好的交易草稿（比如哪些 BTC 将会被转账）发送给 RGB 节点，这些节点用来专门处理 RGB 智能合约。RGB 节点准备一个记录，包含要发送的 BTC 所有的历史信息。类似相关历史记录的文件进行打包。

构建新的交易

基于 RGB 给钱包发送的记录，钱包构建新的交易，指定收款方和找零地址。类似传统的草稿合约中填写指定的收款方和支付信息。

RGB 节点的最终准备工作

RGB 完成对转账记录最后准备工作，同时准备一个披露文档。这个披露包含该次操作可能对其他合约的影响信息。这步确保完成这次交易所有相关的文件和记录的准备。

签名和广播交易

一旦以上准备工作的步骤完毕，交易记录被发送到收款方完成转账签名。收款方签名完毕，比特币交易的签名过程处理完毕，然后把交易广播到全网。然后 RGB 节点更新内部的记录来映射智能合约的最新状态。

以上处理步骤涉及记录准备、多方签名、最后确认和广播上链。RGB 协议通过这些手段确保智能合约的交易安全。

5. RGB 协议应用场景

金融领域应用场景

1. 项目方或公司的代币，主体发行但分布式交易，增强市场流动性和透明性。
2. 自动化管理贷款和债券，通过智能合约自动偿还贷款。
3. 运行于闪电网络的稳定币，替代法币作为支付的媒介。
4. 开发去中心化交易所
5. 实现算法稳定币或 AAM 解决方案，促进交易的流动性和稳定性。

非金融领域应用场景

1. DID 解决方案，实现个体能够掌控和管理自我的数字身份信息。
2. 建立去中心化域名注册系统
3. 管理数字内容的控制权和版权。
4. 代币化艺术品，艺术家和收藏家的交易平台。
5. 管理 DAO, 实现去中心化决策和治理。
6. 创建可证明和验证的审计日志系统，增强企业和项目的透明性和信誉。

6. RGB 协议的代码实现特点

RGB 在代码实现上体现了智能合约上的创新。有以下几点：

6.1. 模式概念 Schema Concept

RGB 协议运用了模式的概念，与面向对象中类的概念类似。模式定义了 RGB 资产标准，促进钱包、交易所和浏览器插件和比特币节点的支持。这套框架，一个 RGB 合约就是模式的实例，由模式的创建者（创世操作者 genesis operation）。这种方式把合约开发者 (schema developer) 和合约发行方隔离，让不具备编程和安全能力但在实际商业创新的非专业人员运作。

6.2. AluVM 虚拟机

RGB 引入了 AluVM 虚拟机，功能上类似于以太坊的 EVM，能够运行图灵完备的智能合约。它可以执行几乎所有类型的计算，但在操作复杂度上有约束。AluVM 通过计算的复杂度累计来限制计算，类似以太坊 Gas 的消耗机制。

6.3. 合约定义例子

RGB 在合约的定义中使用特定的数据类型，比如 PgpKey。这些类型不直接应用于某个合约中，而是在跨合约中的共享。合约状态和操作，比如标识和撤销，是被定义在合约状态之中，也潜在可能够被用于状态转移中。

6.4. 合约实例和状态转移

合约实例化设计到将模式应用到特定的情景，meSatoshiNakamoto 实现了去中心化身份的模式，定义了初始状态，把这些状态赋值给单次使用封条。状态转换，比如通过销毁操作，涉及到更新标识和把这些标识赋值给单次使用封条。

6.5. 扩展合约功能

RGB 提供了扩展合约的功能，比如添加 IOU (I Own You) 代币，在合约中表示 ownable state IOYTokens ，另外有一些全局状态，属于合约的属性，而不是单独被某个钱包，比如 IOYTicker, IOYName

6.6. 特殊的语法结构

智能合约中的全局状态 (global state) 和 ownable state 的区别在于：全局状态在合约中应用，而 ownable state 和特定的单次使用封条 (single-use seals) 关联。合约使用特殊的语法结构，比如说大括号、中括号和问号来表示集合或数组，这些数据类型会在状态操作，特殊语法可作为一种可选的写法。

6.7. 状态扩展的概念

状态扩展允许外部直接参与合约中特定的逻辑，例如资产销毁。状态扩展操纵允许任何人在没有上链的前提下创建状态扩展，等同于比特币交易尚未被打包到区块中确认。

6.8. 合约接口

• 标准化交互：合约接口提供一种标准的方式与 RGB 节点交互，规范 RGB 节点返回语义明确的状态、新建操作。
• 以太坊 ERC 标准类似性：这些合约接口与以太坊的 ERC 标准类似。比如创世接口命名为 RGBxxx ，被单独 LNP/BP 标准中得以规范化。
  

6.9. 新建创世代币接口的例子

• 接口定义：定义全局状态 global states（例如 Ticker, Name），和 ownable states（例如 Inflation, Asset）
• 接口实现：状态和操作的特定模式与接口绑定，例如同质化代币 (FungibleToken) 接口，实现了 global 和 ownable 状态被绑定于 DecentralizedIdentity 模式。
  

RGB 协议，独特的模式定义、AluVM 虚拟机，灵活的合约状态管理以及扩展插槽的机制，展现了赋能了比特币网络的智能合约创新。更多技术细节请查阅 RGB 协议的 Github 代码仓库 https://github.com/RGB-WG/blackpaper/tree/master