比特币上的 RGB 协议是什么？完整技术指南

免责声明：出于教育目的，本文对部分概念进行了简化，同时为避免术语过于繁杂，某些用词可能与正式技术规范有所出入。

近年来，在比特币和闪电网络上发行数字资产的兴趣越来越强，但大多数方案都需要做出与比特币原则不符的妥协：链上数据膨胀、隐私丧失，或依赖引入新信任假设的联合系统。比特币上的 RGB 协议走了一条不同的路。

比特币上的 RGB 协议是一个开源协议，用于在比特币和闪电网络上原生发行和转让数字资产，无需使用侧链，也无需对比特币基础层做任何改动。所有资产数据保持私密且存储于链外，比特币仅被用作承诺层，提供防篡改的锚定。

简而言之：

• 在比特币和闪电网络上原生发行并转让数字资产
• 资产数据保持私密且存储于链外；仅有一个小型密码学承诺被锚定到比特币
• 官方资源：rgb.info · 技术文档：docs.rgb.info

目录

1. 为什么需要一个单独的协议在比特币上发行资产？
2. 比特币上的 RGB 协议是如何工作的？客户端验证
3. RGB 如何防止双花？一次性密封条
4. RGB 转移的完整步骤是什么？
5. 比特币上的 RGB 协议如何保护接收方隐私？
6. RGB 资产如何在闪电网络上工作？
7. 比特币上的 RGB 协议是否支持智能合约？
8. 在比特币上的 RGB 协议中可以发行什么？
9. RGB 与 Taproot Assets、Liquid 和以太坊相比如何？
10. 如何开始在比特币上的 RGB 协议上构建应用？

为什么需要一个单独的协议在比特币上发行资产？

比特币区块链非常擅长创建一份防篡改的所有权记录，任何人都可以在无需信任第三方的情况下进行验证。但将这一模式扩展到比特币本身以外的数字资产，在历史上一直面临结构性的问题。

早期在比特币上发行资产的方案，例如彩色币（Colored Coins）、Counterparty 和 OmniLayer，将资产数据存储在链上。具体来说，第一代资产协议将资产元数据直接嵌入比特币交易中，通常放在OP_RETURN 输出里。每一笔资产转移都被永久写入链上，且对所有人可见。

这种方式带来了三个相互叠加的问题：

区块链负担。每一笔资产转移都会增加数据，无论节点是否关心该资产，都必须永久存储这些数据。规模扩大后，运行全节点的成本不断攀升，进而威胁去中心化。

没有隐私。每一笔转移都永久可见。任何人都能看到谁向谁发送了什么、金额多少、发生在何时。对金融资产而言，这消除了一项基本属性。

可扩展性差。验证所有权需要从创世区块开始扫描整条区块链，随着链的不断增长，这项操作的成本也越来越高。

以太坊的ERC-20 标准选择了另一条路：一个独立的全局状态机，每个节点都公开执行每一个合约。这套系统实现了大规模的可编程金融，但代价是牺牲了隐私、比特币的安全模型，以及真正意义上的去中心化。

比特币上的 RGB 协议采取了一种根本不同的方法。

比特币上的 RGB 协议是如何工作的？客户端验证

比特币上的 RGB 协议通过客户端验证运作：转移双方私下验证资产数据，而比特币区块链只接收一个小型密码学承诺。

其核心理念是：让比特币区块链只做它最擅长的事——提供由工作量证明支撑的终局性和抗审查的结算。资产所有权记录、合约规则和转移历史，都可以在链下由直接相关方处理。区块链只需要知道发生了某件事，不需要知道具体发生了什么。

因此，并非每一个字节的数据都需要被所有人验证。事实上，比特币的全局共识对于在无需可信中介的情况下防止双花是必要的，但对于其他类型的信息（资产合约规则、钱包余额、转移历史），没有理由通知整个网络。

我们可以用一份经过公证的私人文件作为例子。公证人（比特币）确认某个特定事件发生在特定时间，且没有人可以否认这一点。但文件的具体内容完全只在相关方之间保留。

RGB 协议的设计一次性解决了这三个问题：

• 链上没有资产数据 → 没有区块链负担
• 转移对外部观察者不可见 → 默认具备隐私性
• 验证在本地并行进行 → 可扩展至任意规模

RGB 如何防止双花？一次性密封条

比特币上的 RGB 协议通过 一次性密封条防止双花：每个 RGB 资产都绑定到一个比特币 UTXO 上，花费该 UTXO 即授权这笔转移，这使得双花变得不可能，除非同时双花比特币本身。

一次性密封条是由 Peter Todd 提出的一种密码学原语。他给出的正式定义是：

「承诺在未来某个时刻提交一条尚未知晓的消息，且仅提交一次，使这一承诺的事实能够被特定受众的所有成员明确知晓。」

在 RGB 中的实现意味着每个 RGB 资产都绑定到一个具体的比特币 UTXO（Unspent Transaction Output）。要转移资产，发送方必须在一笔比特币交易中花费该 UTXO。花费该 UTXO 会「关闭」密封条，并授权一次状态转换。

比特币自身的工作量证明保证了一个 UTXO 只能被花费一次。因此，尽管比特币对绑定在其上的 RGB 资产一无所知，它依然能保证密封条只能被关闭一次。要双花一个 RGB 资产，就必须双花底层的比特币 UTXO——而这会被整个比特币网络立即拒绝。

比特币区块链充当每一次 RGB 状态转换的不可篡改锚点，同时完全不存储任何 RGB 数据。

RGB 转移的完整步骤是什么？

一次 RGB 转移由五个步骤组成：发送方准备一份包含完整资产历史的寄售包，通过链下方式发送给接收方，接收方在本地进行验证；随后发送方广播一笔只携带小型密码学承诺的比特币交易。

1. 寄售包。发送方准备一份转移寄售包，即一个数据包，其中包含该资产从创世到当前这次转移的完整状态转换历史，以及一笔未签名的见证交易。这些信息就是接收方独立验证所有权所需的全部内容，无需信任任何第三方。
2. 链下传输。 寄售包通过链下渠道发送，通常经由 RGB 代理服务器，但该协议也支持电子邮件、即时通讯应用、二维码或 Nostr 中继。这样一来，资产数据永远不会接触比特币区块链。
3. 接收方验证。 接收方在本地验证寄售包，检查整条状态转换链，确认每一次转换都锚定在真实的比特币交易上，并确认密封条被正确关闭。
4. 比特币承诺。 关闭密封条的比特币交易中包含一个确定性比特币承诺（Deterministic Bitcoin Commitment，DBC），可以用以下两种方式之一编码：
   • Opret：一个 34 字节的承诺（OP_RETURN + OP_PUSHBYTE_32 + 32 字节 MPC 哈希），放置在交易的第一个 OP_RETURN 输出中；
     Tapret：一个 64 字节的承诺，嵌入在 Taproot 交易的脚本路径花费（Script Path Spend）中。
   • 无论哪种方式，都不会有任何资产数据接触区块链
5. 状态转换捆绑包。 同一份比特币交易中，同一合约的多次状态转换会被归入一个状态转换捆绑包，让多笔转移可以共享同一个链上承诺。这一特性是推动可扩展性的重要关键。

接收资产的那个 UTXO，在链上与任何其他比特币 UTXO 都无法区分。见证交易只包含一个小型密码学哈希，不含任何资产数据，也不含收款地址。链上观察者无法得知哪个 UTXO 现在持有该资产——这一特性对接收方隐私有直接影响，我们会在下一节探讨。

比特币上的 RGB 协议如何保护接收方隐私？

比特币上的 RGB 协议通过盲化密封条保护接收方隐私：接收方提供的是对自己 UTXO 的密码学承诺，而不是 UTXO 本身，因此发送方永远无法得知转移的资产究竟落在哪个输出上。

当 Bob 想要接收一个 RGB 资产时，他不会把自己确切的 UTXO 发给 Alice。相反，他提供一个盲化密封条，也就是对自己 UTXO 的密码学承诺，这个承诺对 Alice 隐藏了真实的输出。Alice 会把这个盲化密封条嵌入到她构建的状态转换中。

结果就是，RGB 代币可以从一个 UTXO「传送」到另一个 UTXO，而不在比特币交易图中留下任何可见的痕迹。Alice 无法确定她刚发送的资产究竟落在哪个 UTXO 上。即使她监控区块链，也无法把这个 RGB 承诺和 Bob 的具体代币关联起来。

当 Bob 之后把资产转移给 Carol 时，他必须向 Carol 展示自己的密封条，因为她需要用它来验证资产的转让链条。因此，隐私性在最近一次转移时最强，而随着密封条沿链条向前被逐一揭示，更早的转移隐私性会逐渐降低。这是一个刻意的权衡：在转移当下拥有隐私，同时为接收方保留一条可验证的审计轨迹。

RGB 资产如何在闪电网络上工作？

RGB 资产可以原生运行在闪电网络上：它们可以和聪一起存放在支付通道中，并实现即时转移，继承闪电网络的全部安全保证，包括即时结算，以及每笔转移都无需链上确认。

开通一个 RGB 通道，首先需要一笔标准的比特币注资交易，创建一个 2-of-2 多签 UTXO，这和任何闪电通道的开通方式相同。随后，RGB 资产通过一次 RGB 状态转换被分配到该 UTXO 上。通道中的聪数量不需要相对于被转移的资产价值很大，但也不能忽略不计。聪的数量应当足以让惩罚机制在经济上有意义，并让 HTLC 输出保持在比特币粉尘限额之上。

随着通道的更新，会创建新的承诺交易，其中包含反映最新资产余额的、经过修改的 RGB 状态转换。在通道关闭之前，RGB 输入始终是最初那个在链上分配资产的注资多签。

为什么每一笔 RGB 闪电支付都会同时转移聪：

这一要求承担着两个具体功能，根植于闪电网络的安全模型。

惩罚机制。如果一方广播了旧的通道状态，对方可以使用撤销密钥花费该输出，同时取走聪和 RGB 资产。通道中的聪余额确保作弊行为会带来真实的经济代价，而不只是损失 RGB 代币。

HTLC 要求。每一笔被路由的支付，都需要 HTLC 输出包含高于比特币粉尘限额的聪。这种双重转移（聪 + RGB 资产）确保了无论 HTLC 是通过原像还是时间锁解决，比特币和 RGB 分配都能够被主张。

比特币上的 RGB 协议是否支持智能合约？

支持。比特币上的 RGB 协议通过 AluVM（Algorithmic Logic Unit Virtual Machine，算术逻辑单元虚拟机）支持可编程合约——这是一种基于寄存器的虚拟机，在相关方各自的设备上私下执行合约逻辑，而不是在全球网络上公开执行。

与以太坊的 EVM 不同——EVM 中每个节点都会公开执行每一个合约——AluVM 在链下运行验证。只有结果（某次状态转换是否有效）会被提交到比特币上。计算过程本身及其输入完全保持私密。

AluVM 脚本被嵌入在模式（Schema）中，并在客户端验证期间执行。模式采用纯声明式的方式：它们定义合约的规则和业务逻辑，而这些逻辑既不会成为全局状态的一部分，也不会被任何第三方看到。

因此，RGB 合约可以表达复杂的条件，比如转移限制、许可制发行和多方授权，而这些逻辑都不需要公开，也不需要由网络来执行。

一种边缘情况：如果某次状态转换未能通过客户端验证，但对应的比特币交易已经被广播，那么该 UTXO 密封条会被关闭，却没有分配任何有效的状态转换。这笔资产实际上就被销毁了。使用 rgb-lib 的设计良好的钱包，会在广播之前通过谨慎的交易构建来处理这一问题。

在比特币上的 RGB 协议中可以发行什么？

比特币上的 RGB 协议 v0.11.1 支持五种资产类型，称为模式（Schema）：NIA（固定供应量同质化代币）、IFA（可增发同质化代币）、UDA（非同质化资产）、CFA（可收藏同质化代币）和 PFA（许可制同质化代币）。

模式是声明式模板，编码了合约的完整规则：存在哪些状态、创世如何构造、可以发生哪些转换，以及应用怎样的 AluVM 验证逻辑。它们会被编译成 .rgb（二进制）或 .rgba（防护二进制）文件，供钱包集成使用。

v0.11.1 中官方支持的五种模式如下：

• NIA——不可增发资产（Non-Inflatable Asset）
  • 供应量硬性封顶的同质化代币。创世之后不能再创建任何新单位。这是把比特币的货币模型应用到任意资产上的方案。
  • 用途：比特币等值代币、固定供应量的积分、具有固定赎回池的代币化大宗商品、游戏内货币。
• IFA——可增发同质化资产（Inflatable Fungible Asset）
  • 供应量设有上限的同质化代币。支持增发（Inflate，铸造新单位）、销毁（Burn，可证明地减少供应）和链接（Link，一次性操作，用于连接到后继合约）。
  • 用途：稳定币、按计划排放的奖励代币、代金券计划。
• UDA——独特数字资产（Unique Digital Asset）
  • 非同质化资产。每个 UDA 都可以内嵌媒体文件（最多 64 KiB 的二进制数据块），或通过哈希摘要引用外部附件。转移仅限于单一目的地。
  • 用途：数字证书、活动门票、收藏品、可验证凭证。
• CFA——可收藏同质化资产（Collectible Fungible Asset）
  • 在 NIA 的基础上，为每次发行增加一个品项标签，用于标识收藏系列中的每一批次。
  • 用途：限量版艺术品系列、编号版画、体育卡牌收藏、按年份或版次区分的年份批次。
• PFA——许可制同质化资产（Permissioned Fungible Asset）
  • 一种同质化、不可增发的代币，每一笔转移都必须在交易元数据中包含发行方明确的密码学签名。
  • 用途：代币化股权、需要发行方批准的受监管稳定币、受合规限制的代币、代币化不动产份额。

比特币上的 RGB 协议与 Taproot Assets、Liquid 和以太坊相比如何？

比特币上的 RGB 协议比 Taproot Assets、Liquid 和以太坊 ERC-20 具有更高的隐私性和可扩展性，因为它是唯一一种通过客户端验证，把所有资产数据都保留在链下的方案。

协议	运行平台	隐私性	可扩展性	去中心化程度	状态
比特币上的 RGB 协议	比特币 + 闪电网络	高 链下、客户端验证	高 无区块链膨胀	完整的比特币安全性	自 2025 年 7 月起主网运行
Taproot Assets	比特币 + 闪电网络	部分	中等	完整的比特币安全性	主网，单一公司主导
Liquid Network	比特币侧链	机密交易	中等	联合多签	生产环境，存在信任假设
以太坊 ERC-20	以太坊	无——完全公开	受区块大小限制	独立的安全模型	成熟，DeFi 采用率高

RGB++ 不是比特币上的 RGB 协议。RGB++ 是由 Nervos/CKB 团队开发的一个独立协议，运行在 CKB 区块链上。这是一个由不同团队、采用不同架构开发的项目，与比特币上的 RGB 协议没有任何关联。

如何开始在比特币上的 RGB 协议上构建应用？

概念：从客户端验证和一次性密封条开始
构建钱包：使用 rgb-lib，支持 Rust 和 Python 绑定
运行闪电节点：使用 rgb-lightning-node
在测试网试用 CLI：使用引导式沙盒环境
核心协议：github.com/rgb-protocol
词汇表：docs.rgb.info/annexes/glossary