RGB 闪电网络路线图：从当前实现到接下来会发生什么

本文基于 Zoe Fatilbà 在 2026 年 5 月 12-13 日于意大利 Viareggio 举行的 Tuscany Lightning Summit 2026 上，关于 RGB 闪电网络路线图的演讲。

核心要点：

• 比特币上的 RGB 协议通过在每一笔通道交易——从开通到关闭——中添加一个 OP_RETURN 承诺，与闪电网络集成，完整继承闪电网络的所有保证机制。
• RGB 闪电通道始终同时承载聪和资产：聪的数量必须高于粉尘限额才能让输出保持可花费，但不需要在经济上有实质意义。
• rgb-lightning-node（RLN）是首个实现，构建在 rgb-lib 和一个 LDK 分支之上，提供 REST API，并通过 @rgb_lightning_bot 提供一个实时的 Regtest 演示。
• 路线图涵盖隐私改进（SPV 证明、Taproot 通道）、新的支付能力（多资产支付、BOLT12），以及安全关键性修复（动态手续费率、CPFP）。
• Zoe 邀请贡献者寻找一个适合新手的入门任务，参与到 RGB 的开发中来。

RGB 协议在闪电网络上是如何运作的？

比特币上的 RGB 协议通过客户端验证运作：资产数据永远不会接触链，只有转移的相关方才会验证相关的历史记录。

正如 Zoe 所说：

「我们的架构与点对点网络非常相似，你只需要验证与你相关的历史记录，不存在全局状态。」

链上的关键机制，是在比特币交易中添加一个OP_RETURN输出，用它来承诺一次RGB 状态转换，而不公开暴露任何资产数据。

要把这种方式带到 RGB 闪电网络上，需要将同样的原则应用到通道生命周期中的每一笔交易，从开通到关闭。

「我们只需要拿出每一笔闪电交易，从开通到关闭，给它加上一个 OP_RETURN 输出。这样做，我们就继承了闪电网络提供的所有保证，比如惩罚交易、HTLC 超时等等。」

这里有一个实际的限制：每当 RGB 资产需要跨通道移动时，承诺交易就必须包含一个HTLC输出。这一机制要求在发送资产的同时附带一笔比特币金额，以保持输出可花费。这些聪不需要在经济上有实质意义，但必须足够让所有承诺输出保持在粉尘限额以上。因此，RGB 通道始终同时承载聪和资产，这也确保了闪电网络的惩罚机制保持完整。

要了解更多关于闪电网络上的 RGB 协议的信息，请见相关页面。

RLN：首个支持 RGB 的闪电节点

rgb-lightning-node（RLN）是首个原生支持 RGB 的闪电节点。它构建在 rgb-lib 和一个 LDK（Lightning Development Kit）分支之上，扩展了标准的闪电技术栈以处理 RGB 资产：开通同时承载聪和 RGB 资产的通道、在网络中路由资产支付，并将链下 RGB 状态与通道状态保持同步管理。

它对外提供一个 REST API，任何应用都可以与它交互，而无需了解底层协议的细节。

开始使用：

git clone https://github.com/RGB-Tools/rgb-lightning-node

README 中包含了在 Regtest 上启动三个节点的说明。此外还有一个实时演示，通过运行在共享 Regtest 环境上的 Telegram 机器人 @rgb_lightning_bot 提供，让你可以免费领取测试网比特币和 RGB 资产，然后支付一笔闪电发票来获得一枚贴纸。

Zoe 对参与贡献的邀请说得很直接：

「给闪电节点加上 RGB 支持，其实没有那么难。我鼓励每一个想尝试的人都去做，因为人越多越好。」

LDK 需要做出哪些改动？

这个 LDK 分支需要对协议消息和交易构建逻辑做出针对性的修改，但差异相对较小，Zoe 鼓励任何感兴趣的人直接去阅读源码。这些修改更像是精准的手术，而不是根本性的重构。

这些改动可以分为两类：

• 交易着色：对于节点创建的每一笔交易（承诺交易、HTLC 交易和关闭交易），节点都会检查该通道是否承载 RGB 资产，如果是，就通过添加一个承诺相应 RGB 状态转换的 OP_RETURN 输出，为其「着色」。
• 修改后的 TLV 消息：这个 LDK 分支扩展了四种闪电网络消息：
  • open_channel——发起方声明寄售包可以在哪里下载
  • update_add_htlc——携带资产 ID 和金额，让路由沿途的所有节点都知道正在转移的是什么
  • channel_announcement——让节点可以公告某条通道支持哪种资产，用于 gossip 和路由
  • channel_update——中间节点公告它们愿意路由的 RGB 资产最大金额

在对手方这边，在创建注资交易之前，节点会下载并验证寄售包。如果无效，节点就会放弃这笔注资，确保双方都在任何链上操作发生之前，验证过资产历史。最近新增的一个功能，还允许通道发起方在开通时向对手方推送资产，这与标准闪电网络中的 push_msat 机制类似。

RGB 闪电网络的路线图上有什么？

Zoe 概述了三个领域的计划工作：RGB 核心协议、rgb-lib，以及 RLN。

协议

协议方面的两条主线是隐私和基础设施加固。

在隐私方面：SPV（简化支付验证，Simplified Payment Verification）证明让节点可以通过直接查询区块头来验证交易，而不需要把完整数据发送给索引服务。这种方式消除了转移模式泄露的一个重要来源。

与此同时，寄售包的创建方式也会得到改进，隐藏所有与接收方无关、或安全验证不需要的 RGB 输出，减少一次转移向第三方泄露的、与无关输出相关的信息。

在隐私之外，一个新的模式——BFA——正在开发中，用于通过销毁与桥接转换，让其他链上的资产桥接进入 RGB，为在别处发行的资产打开一条迁移路径。

此外，寄售包流式传输将优化移动端的内存占用：目前，完整的寄售包必须先加载进内存才能开始验证；计划中的方式会增量式地进行验证，并丢弃已经处理过的历史记录，让内存占用保持在有限范围内。

最后，剩下的几项工作是机构采用的前提条件：用正规的数据库存储替代目前的自定义文件格式、扩充文档和单元测试覆盖率，以及完成内部和外部审计。

rgb-lib

rgb-lib 是让应用开发者能够使用 RGB 的 Rust 库：它处理资产发行、转移、UTXO 管理以及寄售包的创建与验证，把协议的复杂性封装成一个简洁的 API。Python、Swift、Kotlin 和 Node.js 的绑定，让开发者无需编写 Rust 代码，就能构建 RGB 应用。目前的优先事项集中在可靠性和生态覆盖面上。

在可靠性方面：一套日志系统结合数据库事务，将确保失败时能够原子化地回滚状态，消除一整类不一致性错误。重组（reorg）检测目前还没有开始开发，但方案已经明确：在关闭时保存最后一次同步的区块哈希，重启时验证它是否仍在链上。如果一次重组影响了一笔已验证的转移，一个现有的 API 调用就可以回滚 RGB 状态。团队还计划支持 RBF（手续费替换，Replace-By-Fee）。

在生态覆盖面方面：团队正在积极改进 Node.js 绑定，使其达到一等支持水平。Bare 运行时绑定，将让 rgb-lib 得以集成进 Tether 的 Wallet Development Kit（WDK）。此外，WASM（WebAssembly）支持，将让 rgb-lib 能够在浏览器环境中运行。

代理服务——负责在发送方和接收方之间中转寄售包交换的链下服务——也会得到改进。团队正在加入基于公钥的接收方身份验证，确保只有合法的接收方才能接受一笔转移。此外，发送方将能够预先签名并把交易提交给代理。接收方随后就可以独立广播这笔交易，不需要等待发送方重新上线。

RGB Lightning Node（RLN）

RLN 的路线图涵盖多个维度：积极开发中的功能、安全修复、隐私改进，以及新的支付能力。

在基础设施方面，当前的工作集中在三条战线上：

• 通过HODL 发票实现与外部系统的原子交换
• 让节点变得更轻量，可以不依赖完整的 Bitcoin Core 连接更容易地运行
• 通过远程签名支持高可用部署，让远程主机可以在不持有资金签名权限的情况下运行节点

Zoe 特别指出了两项安全关键性事务。第一，动态手续费率：节点目前使用固定手续费率，这可能会影响通道关闭时的资金安全。第二，CPFP（子承父债，Child Pays For Parent）支持：节点已经使用了锚定输出，但当承诺交易以不足的手续费上链时，目前还无法为其加速手续费。

在隐私方面，有三项改进正在进行中：

• Taproot 通道将消除外部观察者目前检测出某条通道承载 RGB 资产的能力
• 动态盲化因子将取代目前的静态盲化因子——目前的静态方式会在通道被强制关闭时降低隐私性
• 通过闪电网络的点对点网络交换寄售包，而不是经由代理，将彻底消除代理带来的隐私影响

在支付能力方面，多资产通道和多资产支付都已列入路线图。多资产支付尤其值得关注：

「我没有 USDT，我只有比特币，但我想支付这笔发票。我可以找到一条路由，中间有一个兑换节点，即便我并不持有某种资产，我也能够用它来支付。」

因此，一个只持有 BTC 的用户，也可以支付一笔以 USDT 计价的发票，资产转换会在路由沿途自动完成。拼接（Splicing）将允许在一笔交易中，为一个原生比特币通道——一个只承载聪的标准闪电通道——添加 RGB 资产。

Zoe 还计划支持双向注资通道和 BOLT12——后者是任何想要参与的人都适合入手的第一个贡献点。

更长期的架构目标，是把 RGB 特有的 LDK 改动直接上游合并回去，从而不再需要维护一个独立分支。在达成这个目标之前，团队正在积极改进错误处理和测试覆盖率——尤其是针对惩罚交易，以及与标准闪电节点的兼容性。

如何参与

RGB 技术栈正在积极开发中，也向贡献者开放。正如 Zoe 在演讲中明确指出的，为闪电节点添加 RGB 支持所需的改动，比看起来要小。此外，团队已经标记出一些适合新贡献者入手的具体 issue，包括为 RLN 添加 BOLT12 支持。

如果你想探索代码、在本地搭建 Regtest 环境，或者提交一个 PR，这里是相关代码仓库：

• rgb-lightning-node：github.com/RGB-Tools/rgb-lightning-node
• rgb-lib：github.com/RGB-Tools/rgb-lib
• RGB protocol：github.com/rgb-protocol

以下是官方文档：

• 文档：docs.rgb.info

@rgb_lightning_bot 运行在一个共享的 Regtest 环境上，让你无需在本地搭建任何东西，就能领取测试网比特币和 RGB 资产，并支付一笔闪电发票。

如果你想参与最前沿的比特币基础设施建设，现在正是时候！

去看看这些代码仓库，找到 issue，提交 PR，参与进来！

---