跟比特币类似的新出的 RGB协议设计

一次性密封条

物理“一次性封条”是一种独特编码的塑料带，通常用于检测存储和运输过程中的篡改。 例如，当你在一个海运集装箱的门上锁上一个一次性封条，如果你再次打开门，发现带有你预期编号的封条完好无损，那么你就可以确定在运输过程中没有人打开集装箱（假设制作一模一样的印章已经够难了）。

同样，使用电子一次性印章（Peter Todd 于 2016 年首次提出），可以在消息上盖上电子印章，确保消息只能使用一次。 例如，假设消息是一块土地的所有权契约。 没有一次性印章，我可以把地契给很多人看，让大家相信我对这块土地拥有全部权利，然后再把一块地卖掉。 在证书上应用一次性印章，我们可以将拆封操作定义为出售土地的必要步骤，因此卖方无法将同一块土地出售给多人； 一旦 TA 尝试这样做，第二个买家会注意到土地已售出，因为电子印章已被破坏。

将一次性印章电子化的一种简单方法是设置公证服务器，以便在印章打开或锁定时在公共登记处颁发证书，以便任何人都可以验证他们关心的印章状态。 但是，此设置要求用户信任公证服务器，因此希望免信任和抗审查的协议不能使用此方法。

基于比特币的一次性印章

我们可以使用比特币未花费的交易输出（UTXO）作为印章，而不是使用可信实体来证明电子印章的打开和关闭。 实际上，一个UTXO可以看作是一个印章：创建时，印章被锁定； 用完了，封印就打开了。 根据比特币的共识规则，一次输出只能花费一次； 因此，如果我们将其用作印章，确保比特币共识规则得到执行的激励措施也将确保这样的印章只能被打开一次。

提供一个更现实的例子，让我们想象一个所有权证书，它定义了将所有权转移给新所有者的必要条件是花费一定的比特币 UTXO（这个 UTXO 的私钥应该由当前所有者控制），当这个UTXO 被花费，花费它的比特币交易将指定谁是转移财产的新所有者。 因为比特币交易的数据结构受到严格和深思熟虑的规则的约束，将所有关于接收者的信息编码到比特币交易本身会有一些限制（并且对相关各方的隐私有非常糟糕的影响），所以，甚至更好的是，只需在比特币交易中添加对接收者身份的承诺（例如，在输出字段中添加接收者 UTXO 的哈希值）。

从本质上讲，这相当于每次所有权转移时，我们都修改原来的合约，指明哪个新的比特币 UTXO 是最新的所有权控制者。

RGB 状态变化

RGB 协议使用上述“基于比特币的一次性印章”模型，这意味着每当发生 RGB 交易时，发送方实际上创建了一份合同（定义要转让的权利的合同）。 发生了状态变化。 以可替代资产为例。 首先，合约的发行者设置合约的创世状态，定义合约的细节，例如资产名称、总供应量以及有权移动该供应量的 UTXO。 然后，当第一次转移资产时，第一个 UTXO 的所有者可以创建一个状态更改，定义哪个 UTXO 将持有该资产。

状态变更可以应用于改变资产所有权的权利，也可以应用于其他类型的权利，例如在资产发行合约中，可以是二次发行的权利，或者增加/改变资产的特定属性资产（例如：元数据）权利。

核实

验证收到的 RGB 传输与验证收到的正常比特币支付有很大不同。 在比特币中，连接到网络的节点不断地下载和验证交易池中的区块和交易。 这样的节点总是有一个实时更新的 UTXO 集合（区块链上所有未花费的输出的集合）的视图，当它看到一个新的交易时，要验证它的有效性，它只需要验证所有的 Inputs are all part UTXO 集的最新状态。

在 RGB 中，不存在所有交易都通过其传播的全球网络，因此不可能创建与比特币的 UTXO 集等价的东西。 这意味着当收到付款时，RGB 客户端不仅需要验证交易的最新状态是否有效，而且还必须对所有先前的状态转换做同样的事情，一直回到发行的创世状态合同。

同时，这也意味着，不同于比特币和任何其他全球共识系统，在RGB协议中，客户端不需要知道或验证全球范围内发生的所有交易，因为它只需要知道与钱包相关的交易. 因此，每个客户端需要验证的数据量更小，整个系统的可扩展性也更强。

RGB 客户端在收到付款时需要一次验证大量数据可能会被视为一个问题，因为它可能会导致付款处理速度变慢 - 验证所花费的时间会更长。 但是，这个问题只有在你第一次持有交易历史很长的资产时才会遇到； 此外，可以开发新的数据可用性层（data availability layers），让客户端可以自愿跟随 Others 共享与合约相关的状态转换数据，让潜在的接收者可以提前开始验证部分交易历史。

确定性的比特币承诺

RGB 利用比特币区块链来防止双重支出，这是通过在特定比特币交易中提交 RGB 状态转换来实现的，该交易花费了当前持有被转移权利的 UTXO。 为了使这种承诺既可验证又安全，我们需要满足两个条件：（i）多个状态转换可以提交给单个比特币交易； (ii) 每次状态转换只能承诺一次进入比特币交易的Promise（否则有双花的可能）。

为了允许将多个状态转换放入一个 promise 中，必须多次聚合状态转换的内容：首先，必须确定性地聚合与某个合约（或资产 ID）相关的所有状态转换（到一个 promise 中） ; 然后，将所有转移资产的承诺聚合成一棵 Merkle 树，最终的根哈希值就是最终的 RGB 承诺。 为了保证与其他与RGB无关的协议的兼容性，但也需要使用确定性的比特币承诺，将RGB承诺与其他协议承诺再次聚合（如LNPBP-4标准所述），并得到哈希值, 是实际嵌入比特币交易中的消息。

在最终的 LNPBP-4 消息准备就绪后，有两种方法可以将其提交给比特币交易：

Taproot Commitment：包含LNPBP-4消息的OP_RETURN脚本，添加到比特币交易的第一个Taproot输出的TapTree（脚本树）输出的右上叶（top right leaf）； 并且这种关系将只显示向 RGB 进行链下转移的接收者。 这允许比特币交易仅使用一个 taproot 输出，将比特币更改发送回发送者，并包括此承诺，而无需添加额外的数据，也不会暴露交易可能包含 RGB 承诺的事实。 任何痕迹。 OP_RETURN 承诺：LNPBP-4 消息直接嵌入到比特币交易的第一个 OP_RETURN 输出中。 这将导致交易膨胀 46 字节，但同样不会透露任何关于 RGB 转置内容的信息，因为对于区块链观察者来说，它只是一个带有哈希的 OP_RETURN 输出（例如，它与打开时间戳事务）。 与 Taproot 的承诺相比，这种方法的优势在于它的简单性和易于实施。

在比特币交易中插入多个承诺的情况下，只有第一个与 RGB 验证规则相关，其他的将被忽略，因此任何双花的尝试都是毫无意义的。

批量处理

因为我们可以在单个比特币承诺中包含任意数量的状态转换，所以大规模批处理也是可能的。 例如，假设有人想同时支付给多人，他只需要为每个接收者创建一个状态转换，并将所有状态转换提交到同一个比特币交易中，就这样，不需要占用更多字节。 这意味着每次 RGB 支付的链上费用的边际成本可能非常小，因为相同的费用可以通过任意数量的转账进行分摊。

然而跟比特币类似的新出的，这种批处理技术只有在花费相同的 UTXO 时才有用。 如果用户要花费多个UTXO，每个UTXO都需要作为比特币交易的输入，交易量会增加，需要支付的链上交易手续费也会增加。 这意味着批处理对于使用池化 UTXO 的服务提供商特别有用，例如为大量用户操作提款的托管交易所。 例如，交易所可以每30分钟聚合一次所有提款请求，只需要支付一笔比特币交易的链上交易手续费，一进一出，可以及时支付给每个发起提款请求的用户. .

隐私

RGB 已经实现了更高程度的隐私，这要归功于客户端的设计验证（这对区块链观察者隐藏了信息），但是，我们在协议中添加了其他功能以进一步增强其隐私。

盲UTXO

为了让转账的接收方获得针对付款方的额外隐私，RGB 使用“盲 UTXO”而不是普通的 UTXO 作为支付的输出点。 这意味着当一个用户想要接收支付时，他不会分享他想要用来接收资产的UTXO，而是给出这个UTXO的盲形式，在UTXO之后拼接一个随机的盲秘密值哈希值。 这样，付款人就不知道资产去了哪里，付款人也看不到资产未来的花销方向（在常规的比特币链上支付中，付款人总能看到这些信息）。

在消费时，为了证明自己的 UTXO 是某项资产的所有者，发送方需要与接收方共享用于生成盲 UTXO 的盲秘密值，因此，在验证阶段，新的接收方可以是验证盲 UTXO 确实是从要花费的 UTXO 派生的。

盲 UTXO 示例：

UTXO:
ad3ebdcda0f83b37fffab0439c89fd3ef7d99c41c353a45a98d5983d9ad00183:0
盲化秘密值：
8114079862469528952
盲化输出点：

txob1kewrvnf8sjmarq65gv98lz2xrgxylpnlta8lc3p78fjxaw9qda4qkewlwr

防弹

为了隐藏资产交易历史中每次状态转换的具体值，RGB还实现了零知识证明机制； 这种机制被称为“Bulletproof”，由 Blockstream 开发跟比特币类似的新出的，它是“机密交易（Confidential Transactions）”（已经在 Liquid 侧链中使用）的优化和更高效的版本。 多亏了 Bulletproof，用户可以获得针对未来资产所有者的隐私。 虽然未来的拥有者可以看到从创世状态到自己状态的途中使用的所有UTXO，但是他们看不到每次状态转换转移的资产数量（但是得益于零知识证明，他们仍然可以验证有之前任何时候都没有隐藏的通货膨胀）。

您可以从 Blockstream 的博客了解 Bulletproof。

客户之间的沟通

为了完成 RGB 传输，参与的客户端需要相互共享一些数据。 具体来说，发送方需要与接收方共享委托，这是一个包含验证传输所需的所有信息的数据结构，包括可以追溯到合约创始状态的所有状态转换。

RGB 协议不关心用于此数据共享操作的通信通道，实际上这可以通过多种方式完成。 虽然你也可以用信鸽来拼货，但是RGB软件实现了一个更实用的电子通道。 目前RGB软件中共享数据的方式主要有两种：

通信方式的协调可以通过发票协议来完成，其中接收方提供一个或多个端点，发送方可以使用这些端点上传托运数据。

（结束）