在这样一个最基本的场景。Alice给Bob发送 RGBT这个token。这个token是合约叫做C。

1.初始状态

​ 最开始Alice是拥有合约信息和密封当前状态的UTXO。Bob没有合约信息。

2.导入合约

​ BoB需要首先导入共识内容，也就是合约C（Contract Consignment）。因为他需要知道合约C是怎么运作的，并且要确认是不是他想要的那个合约。（核对合约id）

3.创建invoice

​ 因为链上存储的都是TX执行完毕后的结果。而且Bob没办法操控Alice的所拥有的状态并且Alice也不懂Bob用于密封新状态的UTXO是什么。所以需要告诉A把怎样的一个结果发到链上。这个就是Invoice了。这个invoice里面包含 指示 Bob创建一个遵循合约规则的新状态，并以隐藏的形式嵌入一个新的 密封 定义，指向他的一个 UTXO。通过这种方式，Alice 为 Bob 分配了新状态的一些所有权：例如，一定数量的代币的所有权。

4.支付invoice

​ 之后，Alice 使用一些 PSBT 钱包工具准备了一笔交易，该交易花费了由先前的 密封之前状态的UTXO 。在这个btc tx中，Alice 在一个输出中嵌入了对新状态数据的承诺，该数据使用 Opret 或 Tapret 规则，具体取决于所选的方法。简而言之A接受到这个Invoice然后执行。

5.确认交易完成

​ A执行完将结果（Transfer Consignment）发送给B让他确认下对不对B确认之后A就可以把执行结果发送到链上了（实际上A可以不管不顾直接把执行结果发送到链上）。等待链上确认完毕RGB的tx也就完毕了。

这个Transfer Consignment包含除了新状态之外，它还包含 Alice 已经拥有的客户端数据的有组织stash。

Bob在accept的时候是做了下面内容：

• 验证 Consignment中包含的每个 RGB 状态数据，包括最后一个将所有权分配给 Bob 对合约的 New State。
• 通过Consignment中包含的Anchor（锚点），他验证了从创世到最后状态发生的见证交易顺序的时间顺序，以及指向此处包含的 RGB 数据的相关承诺。

<p align="center"> <img src="https://raw.githubusercontent.com/EthanShang8989/rgb-learning-doc/master/%E8%BD%AC%E8%B4%A6%E6%B5%81%E7%A8%8B.png"/> </p>

更加细节部分

Assignments

在RGB合约内部还有一个类似UTXO的结构 Assignments 来记录RGB合约的交易信息。

Assignments 是负责 Seal Definition 操作和该 Seal Definition 绑定到的相关 Owned State 的核心结构。它们是将数字资产（在拥有状态中描述的）合法转让给由拥有特定比特币 UTXO 确定的新所有者的核心部分。Assignment 可以比作 Bitcoin Transaction Output，但可能嵌入更多的表现力和潜力。

每个 Assignment 都由以下组件组成：

• AssignmentType，它是存储在 Assignment 中的数字资产的标识符（例如，用于在令牌传输中声明传输函数的 assetOwner 声明）。

• Seal 定义，它是包含对 UTXO 的引用的子结构。

• Owned State，指定如何修改与 AssignmentType 关联的属性。

RGB 的独特特性在于，Seal Definition 和 Owned State 都可以以显示（Revealed）或隐藏（Concealed）形式呈现。这对于在状态转换的构建以及后续由合约涉及的各方进行验证时，选择性地保持高隐私性和可扩展性特别有用。显示形式的结构可用于验证在先前状态转换中输入的相同数据，这些数据的哈希摘要表示该结构的隐藏形式。

Seal Definition 和 Owned State 的所有四种显示/隐藏形式组合如下图所示：

<p align="center"> <img src="https://raw.githubusercontent.com/EthanShang8989/rgb-learning-doc/master/assignment.png"/> </p>

Seal Definition

Assignment 结构的第一个主要组件是 Seal Definition，其显示形式本身是由四个字段组成的结构：

• txptr：比简单的比特币交易哈希更复杂的对象，可以有两种不同的类型：
  • Genesis Seal：为 Genesis seal definition 创建的 Seal。它始终包含一个指向现有 UTXO 的 txid 字段。
  • Graph Seal：本身可以有两种形式：
  • 简单情况下，txid 指向被选为 Seal 的 UTXO。
  • WitnessTx 形式，解释为“自引用”定义。此构造的使用意味着 Seal Definition 所使用的交易与包含当前 Assignment 的见证交易相同。由于交易的最终 txid 取决于所有状态转换数据（包括 txptr），所以无法计算它，因为存在隐含的循环引用。实际上，WitnessTx 是一个空字段，用于处理多种情况下没有外部 UTXO 的情形，例如 Lightning Network 的承诺交易的生成和更新，或者接收者没有可用的 UTXO。
• vout：是输入到 txptr 中的 tx id 的交易输出编号，仅当 txptr 是 Graph Seal 时存在。txptr 字段和 vout 字段一起构成比特币交易的标准 outpoint 表示。
• blinding：8 字节的随机数，一旦 Seal 数据被哈希，可以有效隐藏这些数据，提高对暴力破解攻击的抵抗力。
• method：一个 1 字节字段，指示 Seal 关闭方法，将在相关见证交易中使用。可能值为 Tapret 或 Opret。

Owned States

Assignment 的第二个组件是 Owned State，负责定义和存储由 Seal Definition 分配的数据。在介绍 Owned States 的特性之前，有必要简单讨论一下该结构的 Conceal/Reveal 特性。与 Global State 不同，Owned States 有两种形式：

• Public Owned States：相关数据必须始终由其所有者递归地以显示形式保留和转移。例如，它们可以应用于某些必须绑定到所有权但始终公开显示的图像文件。可描述为：“有人拥有，大家都知道”。
• Private Owned States：相关数据保持隐藏，仅在作为验证历史的一部分时才被揭示。例如，代币合约中转移的代币数量通常保持私有。这种形式可以总结为：“有人拥有，没人知道”。

在 RGB 中，Owned State 只能定义为以下四种 StateTypes 中的一种：Declarative、Fungible、Structured、Attachments，它们都有各自的显示和隐藏形式：

• Declarative：一种没有数据的 StateType，代表合约方可以执行的某种治理权利。例如，它可用于投票权。它的隐藏和显示形式是相同的。
• Fungible：允许在代币合约中转移同质化单位的 StateType。显示形式包含两个字段：amount 和 blinding factor；隐藏形式转换为一个包含 Pedersen 承诺的单字段结构，该结构承诺显示形式中的 amount 和 blinding factor。在未来的更新中，可以实现零知识密码证明（例如 Bulletproof），以证明在相同的 State Transition 中引用同质状态的输入总和等于同质 Owned States 的总和，而不透露实际数量。
• Structured：一种可以容纳有序且受限的数据集合的 State Type，可用于复杂合约验证方案的输入。最大存储大小限制为 64 KiB。显示形式为序列化为字节的 blob 数据，隐藏形式是该数据 blob 的 SHA-256 标记哈希：SHA-256(SHA-256(tag_data) || SHA-256(tag_data) || blob)，其中 tag_data = urn:lnp-bp:rgb:state-data#2024-02-12。
• Attachments：用于附加具有定义用途的任意文件，例如媒体文件、音频文件、文本、二进制等。实际文件与 Owned State 结构本身分开存放，显示形式的 Attachment 结构包含三个字段：SHA-256 file_hash、MIME media type 和提供附加隐私的 salt factor。隐藏形式是这三个字段的 SHA-256 标记哈希：SHA-256(SHA-256(tag_attachment) || SHA-256(tag_attachment) || file_hash || media_type || salt)，其中 tag_attachment = urn:rgb:state-attach#2024-02-12。此外，下表还总结了每种 StateType 的技术特性：

Structured就是类似用ordinary在btc上面上传图片。可以传但是不多。

Attachments就是类似NFT中放个URL（通常是cid）指向一个任意大小的文件

Transition Bundle

RGB协议的一个重要通用特性是，能够将属于同一合约的不同状态转换（即具有相同的 ContractId）捆绑在一起。在最简单的情况下，如上面提到的 Alice 和 Bob 之间的情况，Transition Bundle 包含一个单独的状态转换。

然而，RGB 在其设计中嵌入了对多支付方操作（Multi-payer operations）的支持，例如 Coinjoins 和闪电网络通道的开启，在这些操作中，多个支付方（除了 Alice）拥有相同的资产。通过 Transition Bundles，每个参与方可以异步和私密地构建一个状态交易，将合约的所有权转移给一个（即 Bob）或多个对手方（多对多关系）。然后，相关方可以决定将这些状态转换分组到 Transition Bundle 中，并按照 RGB 对 MPC 和 DBC 的规则，构建一个单独的见证交易，关闭 Bundle 中状态转换所引用的所有 Seal Definition。

下图展示了与 RGB 合约相关的所有三种合约操作及其在相关于 RGB 合约的有向无环图（DAG）中的位置，按照它们在比特币区块链中的锚点进行排序：绿色为 Genesis，红色为状态转换，蓝色为状态扩展。

<p align="center"> <img src="https://raw.githubusercontent.com/EthanShang8989/rgb-learning-doc/master/bundleld.png"/> </p>

橙色部分表示比特币区块链中的区块，其中的承诺通过锚点链接到客户端数据。需要注意的是，普通状态转换与两种状态生成操作之间的主要区别在于缺乏 Seal 的关闭部分。因此，为了出现在区块链历史中，Genesis 和状态扩展都需要一个状态转换来关闭由它们构建的特定 Seal Definition。

另一个显而易见但关键的方面是，活动状态是从 Genesis 开始，在比特币区块链中按顺序提交并自我引用的合约操作的 DAG 末尾的最后状态。与已花费 UTXOs 相关的所有其他状态不再有效，但对于验证过程至关重要。

相关资料

https://docs.rgb.info/

https://rgb.info/resources/

https://rgb.info/

https://rgb.tech/

https://www.rgbfaq.com/

https://www.btcstudy.org/2023/09/12/the-potential-of-RGB-protocol/

群

https://t.me/rgbtelegram

仓库

https://github.com/RGB-WG

https://github.com/RGB-Tools

https://github.com/BP-WG

https://github.com/LNP-BP

https://standards.lnp-bp.org/

https://www.strict-types.org/

https://www.contractum.org/

https://www.aluvm.org/