RGB 协议 v0.11.1 更新：核心库去掉 RC 标签
RGB 协议 v0.11.1 由多个开源代码库构建而成，软件开发者用这些库来发行资产、构建钱包和验证交易。 其中五个核心库现已打上 v0.11.1 标签，去掉了整个 RC 周期中一直带着的候选发布版本后缀；同一天，三个配套库也更新了各自文档的构建方式。
要点速览
- 五个核心库（
rgb-aluvm、rgb-consensus、rgb-ops、rgb-schemas、rgb-api）现已升级到 0.11.1，不再标记为测试版本（2026 年 9 月 16 日）。 rgb-ops现在查询比特币交易时只需发送一次请求，而不是两次，感谢 @Jainakin 的贡献。rgb-aluvm移除了两项从未真正可用、并可能导致程序崩溃的功能。- 三个配套库（
rgb-strict-encoding、rgb-ascii-armor、rgb-strict-types）升级到 1.0.4，更新了各自文档的构建方式。
RGB 协议 v0.11.1 有哪些变化？
这五个库，正是目前在主网上运行 RGB 协议的那些库。软件项目通常会先发布一系列「候选发布版本」（带有 -rc 后缀和编号的测试版本），最后才发布一个其他开发者可以放心使用的版本。在最近的候选发布周期中，这五个库的版本标签一直带着这个后缀；自 2026 年 9 月 16 日起，五个库都改为使用不带 -rc 的正式 0.11.1 标签。
同一天，三个配套库更新了各自文档的构建方式，其中两个库在 docs.rs 上的文档构建问题也得到了修复。
更新了什么？
三个配套库的文档构建更新
RGB 的代码库使用 Rust 编写，其参考文档会自动发布在 docs.rs 上——这是一个直接根据源代码生成文档的网站。
rgb-strict-encoding、rgb-ascii-armor 和 rgb-strict-types 发布了 1.0.3 版本，调整了文档的构建方式。然而，它们的文档在 docs.rs 上仍然构建失败：在 rgb-strict-encoding 和 rgb-strict-types 中，docs.rs 的配置会把一个额外的构建参数应用到它们的每一个依赖项上，导致依赖链更下游的构建失败。
因此，1.0.4 版本移除了这个参数，并调整了项目自动化流水线中文档的构建方式。现在，rgb-strict-encoding 和 rgb-strict-types 的文档已经重新出现在 docs.rs 上。 rgb-ascii-armor 1.0.4 则引入了修复后的 rgb-strict-encoding，并采用了同样的流水线调整。
通俗地说： docs.rs 在发布一个库的文档之前，必须先按照该库提供的额外指令编译它的代码。这一次，其中一条指令超出了库本身的范围，延伸到了依赖链中的每一个外部库。一个位于好几层之下的密码学库在这条指令下无法编译，于是整个构建失败，文档也就无法显示。现在，这个问题已经解决。
五个核心库打上正式的 v0.11.1 标签
rgb-aluvm、rgb-consensus、rgb-ops、rgb-schemas 和 rgb-api 都在 9 月 16 日打上了 0.11.1 标签，去掉了此前一直带着的候选发布版本后缀。除了版本标签本身，其中一些库在内部也有变化：
rgb-aluvm是 RGB 用来运行和检查合约逻辑的虚拟机。它移除了一项功能和一个指令集，这两者实际上并不可用，一旦被触发还可能导致程序崩溃。它还移除了三个不再需要的外部代码库（paste、curve25519-dalek、getrandom）。rgb-ops改变了通过 Esplora（一个比特币区块链查询服务）查询见证交易的方式。见证交易是关闭一次性密封条、并携带 RGB 操作承诺的比特币交易。现在每笔交易只需发送一次请求，而不是两次，在同一次调用中同时检查交易本身及其是否已确认。如果请求返回的数据格式错误，或者报告的确认高度为零（这不是一个有效值），该库现在会明确将其标记为错误。这项修复由 @Jainakin 贡献。- 在
rgb-aluvm、rgb-consensus和rgb-ops中，负责把数据转换为可存储、可在网络上传输的格式的代码，改为依赖rgb-strict-encoding自带的工具，而不再依赖另一个外部库；同时还应用了针对 docs.rs 的文档构建修复。在rgb-aluvm和rgb-consensus中，密码学库secp256k1升级到了 0.33.1。五个库现在都在自动化流水线中使用与 docs.rs 相同的配置来构建文档。 - 每个库也把内部依赖更新到了新版本：所依赖的其他核心库现在指向 0.11.1，配套库则指向 1.0.4。
- 五个代码库还更新了各自的安全策略文档。
这些变更落在哪些代码库？
比特币上的 RGB 协议的核心库在 github.com/rgb-protocol 下维护，每个库各司其职：
rgb-aluvm是虚拟机，本质上就是运行和检查合约逻辑的引擎，RGB 用它来进行合约验证。被移除的功能和依赖清理都落在这里。rgb-consensus承载 RGB 的核心验证规则，也就是判断某个状态转换是否被允许的代码。rgb-ops建立在rgb-consensus之上，提供应用程序日常用来检查和存储合约数据的工具。查询比特币交易数据的修复就落在这里。rgb-schemas是开发者用来发行资产的模板集合，而rgb-api是钱包和其他应用用来接入 RGB 的库。rgb-strict-encoding、rgb-ascii-armor和rgb-strict-types是获得文档构建更新的三个配套库，现已升级到 1.0.4。
是否应该升级？
任何基于比特币上的 RGB 协议进行构建的人，都应该升级到新版本：rgb-aluvm、rgb-consensus、rgb-ops、rgb-schemas 和 rgb-api 升级到 0.11.1；rgb-strict-encoding、rgb-ascii-armor 和 rgb-strict-types 升级到 1.0.4。
为什么去掉 -rc 后缀很重要？
Rust 开发者使用一个名为 Cargo 的工具来下载项目所需的库。Cargo 会把带有 -rc 标记的版本视为测试版本，除非按完整名称明确指定，否则会跳过它们。 在这次发布之前，如果开发者只是简单地写上 rgb-consensus = "0.11.1"，就会收到报错，因为当时还不存在这个不带后缀的版本号；要使用这个库，必须写出完整的测试版本名称 rgb-consensus = "0.11.1-rc.11"。现在正式的 0.11.1 标签已经发布，这种简单的写法就能正常工作了。
随着 1.0.4 版本的发布，rgb-strict-encoding 和 rgb-strict-types 的文档也重新出现在 docs.rs 上。
比特币上的 RGB 协议正在积极开发中
上述这类更新，都是 RGB 协议库持续、公开工作的一部分。代码、提交历史和公开的 issue，对任何想看的人都是可见的。对该协议感兴趣的外部开发者，欢迎查看本次变更所在的代码库——rgb-aluvm 和 rgb-ops——并参与贡献。
任何形式的参与都很有价值，无论是报告问题、提出代码修改建议，还是只是关注协议的演进。
在哪里可以找到代码
RGB 的开源代码主要分布在两个 GitHub 组织中：
- rgb-protocol 托管核心协议库，包括本次更新的五个库，以及三个配套库。
- RGB-Tools 托管构建在这些库之上的更高层工具，例如用于钱包开发的
rgb-lib，以及用于在闪电网络上使用 RGB 资产的rgb-lightning-node。
