比特币上的 RGB 协议 —
词汇表。
这份 RGB 协议词汇表涵盖比特币上的 RGB 协议背后的核心概念——从基础密码学概念到协议专属术语。所有定义均基于 docs.rgb.info。
◎ 所有定义均来自 docs.rgb.info/annexes/glossary ↗
一种基于寄存器的虚拟机，用于比特币上的 RGB 协议中的私有合约验证和分布式计算。AluVM 执行嵌入在 RGB 模式中的状态验证脚本，验证状态转换是否符合合约的业务逻辑。与以太坊的 EVM 不同，AluVM 完全在客户端运行——从不上链。
docs.rgb.info ↗一组客户端数据，用于证明某个唯一承诺已被包含在一笔比特币交易中。在 RGB 中，Anchor 包含：见证交易的比特币交易 ID、多协议承诺（MPC）、确定性比特币承诺（DBC），以及——对于 Tapret 方案——额外交易证明（ETP）。Anchor 是将链下 RGB 合约数据与链上比特币交易联系起来的桥梁。
RGB 中相当于比特币交易输出的概念。Assignment 修改、更新或创建合约状态的属性，由密封定义（Seal Definition）（将 assignment 绑定到一个比特币 UTXO）和归属状态（Owned State）（包含被分配的数字财产）共同构成。每一次状态转换都会为接收方创建新的 Assignment。
了解更多关于状态转换的内容 →包含在合约模式中的一组操作和规则，用于规定合约状态可以如何被有效更新。RGB 中的业务逻辑以声明式的方式在模式中表达，并在客户端验证过程中由 AluVM 执行——从不上链。这与以太坊有本质区别：在以太坊中，业务逻辑作为字节码存储并在链上执行。
比特币上的 RGB 协议的核心密码学模型。与网络中每个节点都要验证每一笔交易不同，每个参与者只验证与自己相关的那部分合约历史——即从创世状态到当前资产归属的状态转换链。这些数据以 consignment（寄售包）的形式在相关方之间私下交换。一个紧凑的密码学承诺被锚定到比特币上，用于防止双花。
完整说明 →对某些数据应用哈希函数后得到的密码学对象。承诺具有两个基本属性：绑定性（Binding）——在计算上不可能找到两条产生相同承诺的不同消息；隐藏性（Hiding）——无法仅凭承诺本身还原出原始消息。在 RGB 中，对状态转换的承诺被锚定到比特币交易上，且不会暴露任何合约数据。
比特币上的 RGB 协议中，在各方之间传输、并接受客户端验证的数据包，也称寄售包。分为两种类型：合约 Consignment——由发行方在资产创建时提供，包含模式和 Genesis；转移 Consignment——由发送方提供给接收方，包含从 Genesis 到新的未花费 Assignment 的完整状态转换历史。Consignment 是私密的，在各方之间直接交换。
通过比特币上的 RGB 协议在各方之间建立并执行的一组数字权利。合约拥有由模式定义的活跃状态和业务逻辑——表现为所有权和执行权。只有模式的声明和验证脚本所允许的状态变更，在该合约范围内才是有效的。
一套规则，用于确保在一笔比特币交易中，能够以可证明的方式恰好登记一个承诺。RGB 支持两种 DBC 方案：Opret——将承诺嵌入 OP_RETURN 输出；Tapret——通过 taptweak 机制将承诺嵌入 Taproot 输出。两种方案都能确保承诺在该交易中可验证且唯一。
代表每个 RGB 合约起始状态的数据——即资产发行的那一刻。Genesis 由合约的模式规定，在客户端验证层面相当于比特币的创世区块。它定义了全部全局状态（代码、名称、供应量）以及初始的所有权分配。每一个 consignment 的历史都可以追溯到 Genesis。
RGB 合约状态中不归属于任何特定一方的公开属性——在 Genesis 时定义，并可根据模式规则选择性地更新。例如资产的代码、名称和总供应量。Global state 由所有与该合约交互的各方共享，这与归属于特定 UTXO 持有者的 Owned State 不同。
闪电网络用于在多个跳数之间无需信任地路由支付的机制。HTLC 锁定资金，这笔资金既可以通过揭示一个密码学秘密（支付原像）来认领，也可以在时间锁到期后由发送方收回。在 RGB 闪电通道中，每一笔被路由的支付都会在承诺交易中添加一个专属的 HTLC 输出，并附带相应的RGB 资产分配——也就是说，无论是通过秘密还是通过时间锁认领该 HTLC 输出，认领方都会同时获得聪（satoshi）以及分配给它的 RGB 资产。
了解 HTLC 在 RGB 中如何运作 →一个经过 base58 URL 编码的字符串，其中嵌入了付款方构造一次面向接收方的有效状态转换所需的全部数据。RGB 发票（Invoice）指定了资产、金额，以及接收方希望接收分配的 blind UTXO——但不会透露具体是哪一个 UTXO（出于隐私目的进行盲化处理）。Invoice 是比特币上的 RGB 协议中标准的付款请求格式。
比特币上的 RGB 协议中使用的一种 Merkle 树结构，用于将来自不同合约的多个状态转换承诺纳入同一笔比特币交易中。这是一项关键的可扩展性特性：成千上万笔涉及不同资产的 RGB 状态转换可以被打包进同一笔链上交易，每一笔只需承担极小一部分的交易手续费。
包含在 Assignment 中的那部分合约状态，承载着归属于某人所有权的数字财产。Owned state 的所有权由对应 Seal Definition 中引用的比特币 UTXO 的控制权决定。例如：由特定 UTXO 持有者拥有的代币余额，或分配给特定密钥的 NFT 媒体内容。
比特币上的 RGB 协议用于在链上锚定状态转换的两种承诺方案之一。Opret 将多协议承诺（MPC）嵌入一个比特币 OP_RETURN 输出中——这是一种可证明不可花费的输出，最多可以携带 80 字节的任意数据。另一种方案是 Tapret，使用 Taproot 输出代替。RGB 闪电通道同时支持这两种方案。
一个声明式模板，定义了 RGB 合约的结构——包括其状态变量、转换规则和验证逻辑。正如 docs.rgb.info 中所述，模式（Schema）相当于面向对象编程中的类（class）。它定义了哪些操作是有效的、合约使用哪些数据类型，以及状态可以如何变化。模式会被编译为二进制 .rgb 文件，并由钱包软件导入。目前官方支持五种标准模式：NIA、UDA、CFA、IFA、PFA。
查看支持的模式 →一种密码学原语——由 Peter Todd 提出——是对一条消息恰好承诺一次的承诺，且该承诺可向所有相关方可证明地公开。在比特币上的 RGB 协议中，每一次状态转换都绑定到一个比特币 UTXO。花费该 UTXO 会关闭该密封，使相关联的转换成为最终结果且不可篡改——从而在不需要任何链上合约数据的情况下，精确地防止了双花。
了解一次性密封条如何运作 →用户在本地验证并存储的、与一个或多个 RGB 合约相关的全部客户端数据集合。Stash 是用户 RGB 资产历史的私有数据库——相当于本地比特币钱包的 UTXO 集合，但针对的是 RGB 合约状态。与区块链数据不同，Stash 不会被网络复制，必须由用户自行备份。
比特币上的 RGB 协议中的主要合约操作——RGB 合约状态从一个所有者转移到另一个所有者的机制。一次状态转换会消耗已有的 Owned State（输入）并创建新的 Assignment（输出），并通过一次性密封条将该转换承诺到一个比特币 UTXO 上。从 Genesis 开始的转换历史构成了一个 DAG（有向无环图），由接收方在本地进行验证。
了解状态转换如何运作 →比特币的隔离见证第一版（SegWit v1）交易格式，于 2021 年 11 月通过 BIP341 和 BIP342 激活。比特币上的 RGB 协议使用 Taproot 输出来实现 Tapret 承诺方案——将状态转换承诺嵌入 Taproot 交易输出中，相较于一笔标准的 Taproot 交易，不会增加任何额外的链上占用。
属于同一个合约、在同一笔比特币见证交易中一起被承诺的一组 RGB 状态转换，即状态转换捆绑包。Transition bundle 与 MPC（多协议承诺）共同作用，使得多个合约的状态转换可以被打包进同一笔链上比特币交易——这是比特币上的 RGB 协议的一项关键可扩展性特性。
比特币未花费交易输出——由一个交易哈希和一个 vout 索引（outpoint）共同定义。UTXO 是比特币所有权的基本单位。在比特币上的 RGB 协议中，UTXO 同时也是RGB 资产所有权的锚点：控制一个 UTXO 就意味着控制通过一次性密封条分配给它的 RGB 资产。花费一个 UTXO 既会转移比特币，也会关闭对应的 RGB 密封，从而转移相关联的 RGB 资产。
为一个或多个 RGB 状态转换提供密封关闭操作的比特币交易。一笔见证交易（Witness transaction）包含一个 MPC（多协议承诺）树承诺——通过 Opret（OP_RETURN 输出）或 Tapret（Taproot 输出）实现。见证交易是 RGB 状态转换唯一的链上足迹；它不会透露其所承诺的合约数据的任何信息。
想更深入了解
比特币上的 RGB 协议？
阅读完整的技术规范，或逐层探索协议架构。