比特币上的 RGB 协议发布 RC11
比特币上的 RGB 协议发布了 v0.11.1 RC11，这是一次覆盖协议各个库的维护版本更新，收紧了验证逻辑中的两个具体行为。
要点速览
- RGB Protocol RC11 已在核心协议代码库打上标签：
rgb-consensus、rgb-schemas、rgb-ops、rgb-api，均位于 github.com/rgb-protocol。 - 本次更新包含两项修复：收紧了
rgb-consensus中多协议承诺证明的上限（由 0xaudron 发现并报告），以及修正了rgb-ops在比特币重组（reorg）后重新验证操作的方式。 rgb-schemas和rgb-api也随rgb-consensus与rgb-ops一同打上标签，以保持整个技术栈的版本号一致。rgb-strict-encoding、rgb-ascii-armor、rgb-strict-types、和rgb-aluvm也在 RC11 发布当天更新，各自遵循独立的版本节奏，仅包含维护性更新：MSRV 升级至 1.85.0、依赖项更新，以及针对 Rust 1.97 的 lint 修复。- 仍在运行 RC10 或更早版本的集成方与节点运营商，应尽快升级到 RC11。
RGB Protocol RC11 有哪些新变化？
「RC11」是 v0.11.1 系列的第十一个候选发布版本标签。
随着修复和改进不断叠加在同一个协议版本之上，各协议库会持续发布像这样编号的候选版本。RC11 收紧了核心验证逻辑中的两个具体行为。
修复了什么？
多协议承诺证明的更严格上限
RGB 通过多协议承诺（MPC）将其状态转换锚定到比特币上：多个协议共享同一个比特币输出，每个协议都被哈希进默克尔树的一个叶子节点，并通过自己的默克尔路径证明回根节点。树的宽度随着一起提交的协议数量增加而增加，树越宽，路径就越长，因此 RGB 的代码对路径长度设有一个硬性上限。
RC11 直接在表示默克尔路径的 MerkleProof 类型中，把这个上限从 32 个节点收紧到 31 个，这样限制就在构造和解码时被强制执行，而不再是在后续下游单独检查。
这个数字并非随意选定。事实上，代码库中的其他地方，树的深度被编码为一个上限为 31 的 5 位数值。这个编码限制意味着，一条长度恰好为 32 的路径在 Rust 中是结构上合法的，但一旦被强制转换为这个更窄的类型，就会立刻触发「panic」（程序崩溃）。这类差一错误（off-by-one bug）很容易在代码审查中被忽略，但一旦节点从对方发来的不可信寄售包中解码证明，就会变成实际问题。
在此感谢 0xaudron 发现并报告了这一问题。
无论如何，普通转账所使用的客户端验证并不受这个漏洞影响：这么长的路径在实践中根本不会出现，因为那需要数十个协议同时提交到同一个输出。而对于直接构造或解码 MPC 证明的代码来说，修复带来的实际效果是：一次针对畸形或恶意超大输入的理论性 panic，如今会变成一个普通的、可被捕获处理的验证错误。
比特币重组后正确的重新验证
RGB 依赖比特币来排序并最终确认状态转换：一项操作是否成立，取决于与之相关的见证交易，而链重组可能会暂时让这笔交易脱离主链。一旦发生这样的重组，节点就必须将受影响的操作（以及建立在其之上的所有内容）标记为无效，等到确认交易（原来那笔，或是由新寄售包携带的新交易）重新回到链上后，再把它标记回有效。
RC11 修复了这个流程后半部分的一个漏洞。此前，rgb-ops 是在整个转换束（即共享同一笔确认交易的一组操作）这个层级追踪失效状态。这种粒度意味着节点很容易搞不清一个束内到底哪些具体操作还需要重新验证。RC11 把追踪粒度下放到单个操作层面。
因此，当一个新的寄售包到达时，代码会将其中的每一项操作与此前已失效的操作集合进行比对；一旦匹配，该操作及建立在其之上的一切都会被一并重新验证。代码把这种模式称为「菱形链」：这是 RGB 基于 UTXO 的状态图中，依赖链在分支后又重新汇合时可能出现的一种形态。同一段代码现在还会在一个寄售包内所有操作都没有有效确认见证的情况下直接拒绝该寄售包，堵上了相关的另一个漏洞。
这次更新不影响比特币自身的安全保证，因为客户端验证仍然会拦截任何节点本应拒绝的状态。
这项修复真正的意义在于记账的准确性：如果不更新，节点本地关于「当前存在哪些状态」的记录，可能会与比特币链实际重新确认的情况脱节。而这一点，对任何运行节点基础设施的人都直接相关，因为正是这一层决定了最终展示给用户和应用的余额与合约状态。
RC11 的修复落在哪些代码库？
比特币上的 RGB 协议的代码库分布在 github.com/rgb-protocol 下维护的一组协议库中，每个库各司其职：
- rgb-consensus 承载 RGB 中与共识相关的关键代码和验证代码，包含了判断一项状态转换是否有效的规则。多协议承诺证明的上限就是在这里被收紧的。
- rgb-ops 建立在
rgb-consensus之上，提供应用程序用于验证和存储合约状态的非共识关键 API，也包括节点如何随时间追踪并重新验证操作。重组重新验证的修复就落在这里。 - rgb-schemas 是开发者用来发行资产的合约模式（schema）集合，而 rgb-api 则是钱包和桌面应用用来集成 RGB 的客户端库。两者都随
rgb-consensus与rgb-ops一同打上标签，以保持整个技术栈版本号一致。
同一天，rgb-strict-encoding、rgb-ascii-armor 和 rgb-strict-types 发布了 1.0.2 版本，rgb-aluvm 则发布了 0.11.1-rc.4 版本。它们各自遵循独立于上述四个代码库的版本节奏。这四个库都不包含功能性变更，更新内容仅涉及 MSRV 升级至 1.85.0、依赖项更新，以及针对 Rust 1.97 的 lint 修复。
是否应该升级到 RC11？
这两项修复都是在堵上 RGB 验证逻辑中的边界情况：一个位于承诺证明支持的最大尺寸边界处，另一个位于重组后无效操作的重新验证方式中。对大多数集成来说，两者都不会改变日常行为，但它们都处在任何 RGB 应用正确运行操作所必经的代码路径上。
任何基于比特币上的 RGB 协议进行构建的人——包括钱包后端、节点运营商、应用开发者——都应该将 rgb-consensus、rgb-schemas、rgb-ops 和 rgb-api 一并升级到 RC11，代码位于 github.com/rgb-protocol。
比特币上的 RGB 协议正在积极开发中
上述这类修复，都是 RGB 协议库持续、公开工作的一部分。代码、提交历史和公开的 issue，对任何想看的人都是可见的。对该协议感兴趣的外部开发者，欢迎查看本次修复所在的代码库——rgb-consensus 和 rgb-ops——并参与贡献。无论是报告一个问题、提交一个拉取请求，还是单纯关注协议的演进，任何形式的参与都很有价值。
发布说明
rgb-consensus、rgb-schemas、rgb-ops、rgb-api、rgb-strict-encoding、rgb-ascii-armor、rgb-strict-types、rgb-aluvm。
