理解RGB协议

免责声明：出于教育目的，本文中描述的某些概念已被简化，并且为了避免新术语过多，某些术语可能与技术规范有所不同。

近期，人们对比特币和闪电网络上发行代币的兴趣日益浓厚。创建代表资产的代币，使其能够以比特币提供的相同安全性和便利性进行转移和存储，这并不是一个新想法。实际上，早在 2013 年，Counterparty 和 OmniLayer（前身为 Mastercoin）等协议就已率先提出，后来被以太坊和其他山寨币采用，而如今大部分区块链代币活动也发生在这里。然而，使用山寨币来保障金融资产并不理想，因为它们无法提供与比特币相同级别的安全性和去中心化程度。因此，多年来出现了一些项目，试图将基于比特币的代币协议现代化，并使其与闪电网络兼容，尤其是 RGB、OmniBolt 以及最近的 Taro。本文将重点介绍 RGB，旨在全面概述其工作原理和价值主张。

比特币协议上的传统代币

较老的基于比特币的代币协议（如 Counterparty 和 OmniLayer）通过在比特币交易中嵌入元数据来“着色”交易，并标记该交易应被视为代币转账。此类标记通常发生在 OP_RETURN 输出中，普通比特币节点会忽略它，但代币协议感知节点可以解释它，并强制执行代币协议的验证规则。

虽然这种设计很有效，但也存在一些缺点：

1. 与代币转账相关的信息量受限于 OP_RETURN 输出允许的字节数。根据标准规则，最大为 80 字节，足以编码基本交易数据，但不足以应对更复杂的用例。
2. 代币协议节点需要扫描整个区块链，在 OP_RETURN 输出中查找与用户相关的代币转账。随着区块链规模的增长，这一过程会消耗更多资源。
3. 用户的隐私性很差，因为所有交易数据都对链上任何人可见，而且你使用的代币的匿名集可能比你通常使用比特币时享受的匿名集小几个数量级。

转移到链下

为了改进这一设计，RGB 项目提出了一种更具可扩展性、更注重隐私且更具未来性的解决方案，该方案基于客户端验证和一次性密封（single-use seals）的概念，该概念最初由 Peter Todd 于 2017 年提出。

该方案的核心是仅将比特币区块链用于其不可或缺的用途，即利用其工作量证明和网络去中心化来防止双重支付并抵抗审查。所有代币转账的验证工作可以移出全局共识层，保持在链下，委托给接收支付的客户端。

这一切是如何运作的呢？在 RGB 中，代币始终需要分配给一个比特币 UTXO（可以是现有的，也可以是专门创建的），而要转移代币，你需要花费该 UTXO。在花费 UTXO 时，比特币交易必须包含对一条包含 RGB 支付信息的消息的承诺，该消息定义了输入、代币将要发送到的比特币 UTXO、资产 ID、数量、花费条件以及你可能想要附加的其他数据。

如果你有代币分配给了比特币交易 A 的输出 1，要转移它们，你需要创建一个 RGB 交易和一个从交易 A: 输出 1 花费的比特币交易，该交易要承诺该 RGB 交易。如你所见，RGB 交易将代币从比特币交易 A: 输出 1 转移到比特币交易 C: 输出 2（此图中未显示），而不是转移到比特币交易 B 的任何输出。在大多数情况下，我们可以预期交易 B 的输出只是更改地址，将所花费 UTXO 拥有的聪减去手续费后发送回所有者，同时承诺 RGB 交易以避免双重支付的可能性。

因此，要移动分配给比特币 UTXO 的 RGB 代币，总是需要一笔比特币交易。但是，RGB 转移的输出不必与比特币交易的输出相同！正如上例所示，RGB 交易可以将其输出指向一个与承诺它的比特币交易完全无关的 UTXO。这意味着 RGB 代币可以从一个 UTXO “传送”到另一个 UTXO，而不会在比特币交易图中留下任何痕迹。这对于隐私性非常有利！

在这种设计中，比特币 UTXO 被用作包含 RGB 资产的一次性密封，要转移资产，你基本上需要打开旧密封并关闭一个新密封。

RGB 特定的支付数据通过专用通信通道在链下传输，从付款方客户端到接收方客户端，接收方将验证 RGB 协议规则是否得到遵守。这样，区块链观察者将无法提取任何关于 RGB 用户活动的信息。

不幸的是，验证传入支付不足以确保发送方确实拥有刚刚发送给你的资产。因此，要将接收到的支付视为最终确认，你还需要从付款方那里接收与刚刚发送的代币相关的所有交易历史，一直追溯到最初的发行。通过验证所有交易历史，你可以确保资产没有被通胀，并且附加到资产上的所有花费条件始终得到遵守。

这种设计有助于可扩展性，因为你不需要验证资产的整个历史，只需验证与你自己相关的那些交易。此外，交易不广播到全局账本这一事实提高了隐私性，因为更少的人知道你的交易存在。

盲化秘密

为了进一步提高隐私性，RGB 支持输出盲化。这意味着在支付请求中，你与需要付款给你的人分享时，你不会透露你想要接收代币的 UTXO，而是要求付款方将代币发送到一个哈希值，该哈希值是由 UTXO 本身与一个随机盲化秘密连接而成的。这样做，付款方将不知道代币被发送到了哪个 UTXO，因此交易所或其他服务提供商不可能知道他们是否在向某个被监管机构“列入黑名单”的 UTXO 提现，也无法监控代币将来何时会被花费。

记住我以便更快登录

请注意，当代币被花费时，盲化秘密必须向接收方披露，以便她能够验证交易历史中的比特币部分。这意味着使用 RGB，你在当下拥有完全的隐私，但未来的代币持有者将能够看到所有参与过转移的 UTXO。因此，尽管在接收和持有代币时享有完美的隐私，但随着代币在人们之间不断转移，用户过去金融活动的保密性会逐渐降低，最终接近我们享受的过去比特币交易历史相同的隐私水平。

闪电网络兼容性

由于 RGB 建立在比特币之上，因此也可以在闪电网络上移动 RGB 代币，并且已经有人在这方面开展工作。由于闪电网络是一种基于支付通道的可扩展性解决方案，实际上需要一些努力来为每种资产引导出一定水平的通道流动性，这可以通过资产被广泛采用来实现，也可以通过通道管理软件直接连接到支持用户感兴趣的资产的节点，创建某种特定资产的子网络来实现。

另一种使不太流行的资产在闪电网络上可行的解决方案是引入提供特定资产与比特币之间兑换服务的节点。这样，一旦兑换成比特币，价值就可以利用比特币流动性在网络中中继，当到达路径的另一端时，另一个兑换节点会将比特币转换回原始资产。这将消除对流动性强的特定资产网络的需求。然而，要使其实用，每种资产相对于比特币的交易量需要足够高，以激励做市商在网络的多处运营兑换节点，提供足够低的买卖价差，以避免在两次兑换过程中从支付中扣除太多价值。

闪电网络可能的图形化表示，带有 RGB 彩色通道。灰色圆圈代表普通 LN 节点，而彩色圆圈代表支持特定 RGB 资产的节点。当沿闪电路径转移资产时，会有一些节点同时拥有彩色和普通比特币通道，它们将充当兑换节点，利用比特币流动性使支付到达目的地。

高级智能合约

通过使用比特币交易，RGB 自动继承了比特币的所有智能合约能力，但它并不局限于此！当你向对手方转移代币时，可以在支付中定义额外的花费条件，对手方将来必须满足这些条件。这些额外的花费条件不会由区块链全局共识强制执行，而是由 RGB 节点验证过程强制执行。这意味着如果试图在不遵守 RGB 特定花费条件规则的情况下花费代币，接收方节点将验证失败，并将该支付视为未最终确认，这对发送方来说尤其糟糕。实际上，当 RGB 支付失败时，花费了代币所属 UTXO 的比特币交易可能已经在区块链上确认，这意味着这些代币不再分配给任何 UTXO，可以视为已被销毁，这是在编写 RGB 智能合约时需要考虑的动态机制。

另一个需要记住的权衡是，虽然 RGB 合约可以提供比任何替代方案更多的隐私和可扩展性，但其状态不能全局访问，也不能无主（正如在其他区块链中那样），这可能对某些用例构成限制。

由于 RGB 的客户端性质，可以无需许可地提出和实现多种智能合约框架。在撰写本文时，已经有一个名为 AluVM 的项目正在朝这个方向努力。

RGB 与替代方案的比较

任何对采用 RGB 感兴趣的人都会想知道它与替代代币协议相比如何。让我们分析几个例子：

基于山寨币的代币

大多数基于山寨币的代币协议（例如 ERC-20）提供具有全局无主状态的智能合约，这使得部署去中心化交易所和其他金融应用变得容易，但它们难以扩展，缺乏隐私，并且继承了这些山寨币的所有缺点，例如运行节点成本高、去中心化程度低、抗审查攻击能力弱。

Liquid 资产

Liquid 是一个联盟式比特币侧链，提供一些有趣的功能，如原生资产支持和机密交易，以向区块链观察者隐藏支付金额和正在转移的资产 ID。然而，联盟模型再次带来了去中心化程度低和抗审查能力弱的问题。

OmniBolt

OmniBolt 是 OmniLayer 的闪电网络兼容版本，在文章开头简要介绍过。它的权衡与 RGB 非常相似，但隐私性和可扩展性较差，因为所有代币相关数据都保留在链上。

Taro

在 2022 年迈阿密比特币大会上宣布的 Taro 是一个由 Lightning Labs 支持的项目，旨在将资产引入闪电网络。根据已发布的规范，其设计与 RGB 非常相似，具有基本相同的特性和权衡。在撰写本文时，RGB 和 Taro 之间的主要区别似乎是 RGB 已经发布了一些可审查的代码，而 Taro 只有规范。但另一方面，你可以说 Taro 得到了闪电生态系统中最好团队之一的支持，这为未来的实现创造了良好的期望。鉴于这两种设计的相似性，如果 Taro 和 RGB 最终能够互操作，那将是一件好事，但只有时间才能证明是否会出现实现这一目标的正确激励机制。

结论

如果你对比特币上的代币感兴趣，RGB 无疑是值得关注的项目。要了解更多信息并加入致力于 RGB 开发的贡献者和公司，这里有一些链接供你探索：

RGB 教育资源： rgb.info

RGB 协议 GitHub： https://github.com/rgb-protocol

• 原文链接： medium.com/@FedericoTeng...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～