RGB 协议 v0.11.2-rc.1：v0.11.1 之后的首个候选发布版本
比特币上的 RGB 协议有了一个正在测试中的新版本。 2026 年 10 月 9 日，五个核心库打上了 0.11.2-rc.1 标签，这是 v0.11.2 的首个候选发布版本；三个配套库则发布了 1.0.5，带来多项安全修复。v0.11.1 仍然是最新的稳定版本。
要点速览
- 0.11.2-rc.1 是一个测试版本。 v0.11.1 仍然是最新的稳定版本，共识规则没有任何变化。
- 五个核心库升级到 0.11.2-rc.1，三个配套库升级到 1.0.5，包含三项安全修复。
- @0xaudron 报告的最关键的漏洞已经修复，所有漏洞的测试现已公开。
- 主要变化：更轻的转账数据包、对外部服务器依赖更少的验证方式，以及统一存放合约数据的单一数据库。
- 使用旧版模式发行的 IFA 合约将失效。
0.11.1 与 0.11.2-rc.1：两个版本，同一套共识规则
现在，代码库中同时出现了这两个版本号。下表列出了各自的状态。
| 库 | 稳定版本 | 测试中 |
|---|---|---|
rgb-aluvm、rgb-consensus、rgb-ops、rgb-schemas、rgb-api |
0.11.1 | 0.11.2-rc.1 |
rgb-strict-encoding、rgb-ascii-armor、rgb-strict-types |
1.0.5 | 无 |
RGB 并没有唯一的「当前版本」。 每个项目都可以自由选择在其软件中使用哪个版本的库。和比特币核心（Bitcoin Core）一样，运行不同版本的节点可以同时工作，只要它们遵循同一套共识规则。在 0.11.1 和 0.11.2-rc.1 之间，共识规则保持不变。 两者的主要区别在于寄售包（consignment）的格式：基于 0.11.1 的软件无法读取新的 v1 寄售包（详见下文）。理论上，继续使用 0.11.1 的项目可以实现一个把 v1 寄售包转换为 v0 的转换器，从而保留现有代码。
v0.11.1 是这五个核心库的最新稳定版本。 基于 v0.11.1 的钱包、工具和指南依然有效。
0.11.2-rc.1 是一个候选发布版本。 软件项目会发布带有 -rc 后缀的候选发布版本，让开发者在稳定版本推出之前试用新代码。Rust 开发者用来下载库的工具 Cargo 默认会跳过 -rc 版本：一个要求 0.11.1 版本的项目会继续拿到 0.11.1，只有在明确指定时才会获取候选发布版本。
更高层的工具尚未使用 v0.11.2。 用于钱包开发的库 rgb-lib 以及 rgb-lightning-node 仍然停留在 v0.11.1 版本线上。依赖这些工具的钱包用户和应用开发者，目前无需做任何改动。
配套库的三项安全修复
合约数据以一串普通字节的形式到达 RGB 钱包，由其他人发送过来。在检查合约之前，钱包必须先把这些字节重新转换为结构化的值，例如名称、数量和列表。这一步称为解码，由三个配套库负责完成。由于这些字节来自另一方，即使面对攻击者刻意构造的数据，解码器也必须保持安全。1.0.5 版本修补了解码过程中的三个漏洞。
1. 限制预先分配的内存（rgb-strict-encoding 1.0.5）
每个经过编码的列表都以一个数字开头：即列表中元素的数量。
- 此前：为了节省时间，解码器一读到这个数字，就会为整个列表预留内存。攻击者可以利用这一捷径，伪造一个声明有数百万个元素、实际却几乎为空的文件。钱包或服务器打开这个文件时，就会为一个几乎为空的列表预留大量内存，足以构成拒绝服务（DoS）攻击。
- 现在：解码器最多只预先预留 64 KiB 内存，之后只为数据中实际存在的元素追加内存。
2. 声明的限制现在会被强制执行（rgb-strict-types 1.0.5）
RGB 的数据类型可以声明限制。例如，代币代码（ticker）可以被定义为 1 到 8 个字符，且只能来自一个固定的字母表。
- 此前：解码器会忽略这些限制，因此一个合约可以带着由符号组成、长达 255 个字符的代币代码，并且依然通过验证。
- 现在：对于超出声明长度的文本、字节序列、列表、集合和映射，以及包含声明字母表之外字符的文本，解码器都会拒绝。
3. 映射和集合只有一种有效编码（rgb-strict-types 1.0.5）
映射（map）是由键值对组成的集合，例如「代币编号 → 附件」。
- 此前：解码器接受任意顺序的键，甚至接受重复的键，因此同样的内容可以有好几种不同的编码。
- 现在：解码器要求键严格按升序排列且不得重复，因此每份内容只有一种有效编码。同样的规则也适用于集合（set）。
在同一次发布中，rgb-strict-types 还会拒绝指向不存在类型的类型定义；rgb-ascii-armor 1.0.5 则引入了修复后的 rgb-strict-encoding。
谁会获得这些修复？ 1.0.5 版本的库是常规的稳定版本。直接基于 0.11.1 核心库构建的项目，只需进行一次常规的依赖更新即可获得这些修复。0.11.2-rc.1 版本的库已经包含了这些修复。
已报告的漏洞：修复与公开测试
@0xaudron 报告了 RGB 库中的一系列漏洞，并为每个漏洞编写了一个可以复现问题的测试。这些测试现已公开在 rgb-tests 代码库中（RGB 库共享的测试套件）。
最关键的漏洞已经修复。 优先处理的，是可能影响已可用于主网的模式（Schema）的漏洞，以及可能被用于拒绝服务攻击的漏洞。@0xaudron 的八个测试中，有两个对应上文的第 2 项和第 3 项修复（声明的限制、映射的排序）。这两个测试现在会随着测试套件的其余部分，在每次代码变更时运行，一旦出现回归就会立即暴露。
其余六个测试处于开放状态，并且公开可见。 这些漏洞涉及：在特殊构造的输入下可能发生冲突的标识符、虚拟机的两条指令、枚举类型的比较，以及超大转账数据包的文本导出。每个测试都附有一段关于问题的简短说明，任何开发者都可以阅读、运行，并跟进修复工作。
0.11.2-rc.1 有哪些新内容？
0.11.2-rc.1 是一个候选发布版本：一个测试版本，发布的目的是让开发者试用新代码并报告问题。v0.11.1 仍然是稳定版本，下面的所有变化都不适用于基于 v0.11.1 构建的软件。
这个候选发布版本为五个核心库带来了七项主要变化，外加一组较小的改动。
1. 更轻的转账数据包
在 RGB 中，资产的发送方会把一个名为寄售包（consignment）的数据包交给接收方，由接收方在自己的设备上进行检查。rgb-ops 引入了一种新的寄售包格式：寄售包从 v0 升级为 v1。
- 此前：每个 v0 寄售包都包含合约完整的模式（Schema）：也就是包含资产规则、数据类型以及 AluVM 虚拟机脚本的模板。
- 现在：在 v1 寄售包中，模式不再随每一次转账一起传输。钱包只需导入一次模式，验证后保存下来；此后，每个寄售包只通过标识符来指明所用的模式。寄售包因此变得更小，验证器则基于已在本地设备上验证过的规则进行工作。
在模式的导入方面，这个版本用 SchemaDefinition 取代了 Kit。Kit 携带的信息不足以完成严格类型（strict types）的验证；SchemaDefinition 则可以在导入之前先验证这些类型。
新格式还会为历史中的每一步携带完整的比特币交易（即见证交易）。v0 寄售包仍然可以读取，并可转换为 v1。
2. 分两个阶段进行验证
检查一个寄售包涉及两类操作。第一类是确定性的计算：历史中的每一步是否都遵守了合约规则？另一类需要用到比特币区块链：每笔见证交易是否真的已在某个区块中得到确认？第二个问题的答案并不是完全确定的：在确认数较少时，区块链重组可能会改变结果。
- 此前：验证是一次性完成的单一操作。验证器在同一次运行中既检查合约规则，又在区块链上查找交易，因此从一开始就需要网络连接。
- 现在：在
rgb-consensus中，这两类操作被拆分为两个独立的阶段。第一阶段在没有网络连接的情况下运行，并返回寄售包中列出的所有见证交易。第二阶段在区块链上查找这些交易，并给出最终判定。
因此，钱包可以在联系任何服务器之前就拒绝无效的寄售包，并按照最适合自身配置的方式来组织区块链查询。v0.11.1 的单步验证方式仍然可用。
3. 用于已确认交易的紧凑证明
资产历史中的每一步都指向一笔比特币交易，验证器必须确认这笔交易确实存在于某个区块中。
- 此前：对于每一笔交易，验证器都要向索引器（indexer）查询。索引器是保存着一份可检索区块链副本的服务器。
- 现在：寄售包可以包含 SPV 证明：一小段数据，用来证明某笔交易被包含在某个特定区块中。有了这份证明，验证器只需要该交易被打包进的那个区块的区块头，而区块头可以由轻节点提供，无需完整的索引器。这一变化还提升了隐私：由于不再需要为每笔交易发出查询，索引器也就无法推断出哪些交易在转移 RGB 资产。如果某份证明未能通过验证，验证器会发出警告，并改回常规方式向索引器查询。
4. 对转账终端的更严格检查
每个寄售包都会声明它的终端（terminal）：也就是在最近一次转账中接收资产的输出。
- 此前：验证过程不会把声明的终端与寄售包的内容进行比对。
- 现在：如果某个终端与寄售包中任何未花费的分配（assignment）都不匹配，验证就会失败。对于目的地缺失或已被花费的数据包，接收方会收到一个明确的错误。现在，终端可以被视为由寄售包证明的新分配，值得信任。
5. 统一存放合约数据的单一数据库
- 此前：
rgb-ops把合约数据保存在三个独立的组件中，并且始终以文件形式存储：钱包在使用时把它们加载到内存（RAM）中，关闭时再写回文件。 - 现在：一个统一的存储层取代了这三个组件，其首个实现采用 SQLite——一种广泛使用的嵌入式数据库。用于读取旧文件的读取器仍然保留，以便迁移现有数据。
rgb-api 也做了同样的调整，包括它的命令行工具。
6. 一个用于从其他链跨链而来的资产的模式
rgb-schemas 新增了 Bridged Fungible Asset（BFA，跨链同质化资产）模式，并标注为尚未可用于生产环境。BFA 描述的是一种从另一条区块链转移过来的同质化资产：只有在原链上的对应事件得到确认之后，才能在 RGB 一侧铸造新的单位。rgb-consensus 新增了实现这一检查的合约指令，rgb-ops 则新增了用于确认 EVM 链上这些事件的组件。
7. IFA 模式中的销毁记录
IFA（Inflatable Fungible Asset，可增发同质化资产）是支持增发、销毁和链接操作的同质化资产模式。
- 此前：销毁的数量记录在单次操作的元数据中。
- 现在：每一次销毁都会记录在合约的全局状态中，并附上销毁原因。
由于这一变化，IFA 模式获得了新的模式标识符，使用旧版模式发行的 IFA 合约将会失效。IFA 模式从未达到可用于主网的状态：rgb-schemas 将其标注为尚未可用于生产环境，rgb-lib 也禁止在主网上发行 IFA 资产。rgb-lib 支持的其他模式依然有效。
8. 较小的改动
- 发票（invoice）可以携带两个新的可选字段：一个公钥和一个加密参数（
rgb-ops）。 - 以比特币核心（Bitcoin Core）作为数据源：
rgb-ops和rgb-api可以直接查询比特币核心节点，作为现有 Electrum 和 Esplora 选项之外的又一选择。 - Electrum 连接的一项修复（
rgb-ops）。此前：如果一笔交易报告的确认数超过了当前的区块链高度，就会导致计算错误。现在：该库能够正确处理这种情况。 - 命令行工具：
rgb-api中的命令行工具可以在没有索引器的情况下，利用存储中已有的证明来准备一笔转账。它的说明现在明确指出：仅用于测试和开发，切勿作为生产环境的钱包使用。 rgb-aluvm只是把依赖更新到了 1.0.5 版本的配套库。
是否应该升级？
- 钱包用户：无需任何操作。v0.11.1 仍然是稳定版本。
- 基于
rgb-lib或rgb-lightning-node进行开发的开发者：无需任何操作。这些工具尚未使用 v0.11.2。 - 直接基于 0.11.1 核心库进行开发的开发者：请更新依赖，以获得包含三项安全修复的 1.0.5 版配套库。
- 有意测试 0.11.2-rc.1 的开发者：需要做一些适配工作，因为为 0.11.1 编写的代码需要修改后才能在候选发布版本上运行。模式以新的格式导入，合约数据迁移到新的数据库层。
rgb-consensus中的部分编程接口改了名称，另一些则被移除。命令行工具会从一个空数据库开始运行，不包含早期版本保存的数据。IFA 模式和两个内部类型库也有了新的标识符，使用旧版模式发行的 IFA 合约不再有效。欢迎在各个代码库的 issue 跟踪器中反馈测试结果。
发布说明
完整的变更列表，可以在 GitHub 上查看每个库的发布说明。
核心库，0.11.2-rc.1：
rgb-aluvm0.11.2-rc.1rgb-consensus0.11.2-rc.1rgb-ops0.11.2-rc.1rgb-schemas0.11.2-rc.1rgb-api0.11.2-rc.1
配套库，1.0.5：
测试：rgb-tests 中针对 0.11.2-rc.1 的变更
在哪里可以找到代码
RGB 的开源代码主要分布在两个 GitHub 组织中：
- rgb-protocol 托管核心协议库，包括本次更新的八个库，以及
rgb-tests代码库。 - RGB-Tools 托管构建在这些库之上的更高层工具，例如用于钱包开发的
rgb-lib，以及用于在闪电网络上使用 RGB 资产的rgb-lightning-node。
