在闪电网络上验证 RGB 资产

阅读前说明：
本演示旨在本地 Regtest 环境中逐步验证 rgbldkd 与 rgbdex.net 的集成，不修改任何生产代码。

Stash Labs 团队已成功验证了 RGB 资产在闪电网络上原生运行的完整端到端演示，基于 Bitlight Labs 的 rgbldkd 节点实现。本文记录了我们验证的内容、系统的架构设计，以及沿途获得的关键协议洞察。

验证内容

通过 13 个顺序步骤，我们演示了一个 RGB20 代币的完整生命周期——从在 regtest 比特币链上发行，通过同时承载 BTC 和 RGB 资产的闪电通道开设，到使用 Hold Invoice 实现 BTC 与 RGB 代币之间的原子交换。每个步骤都由 React 前端调用 Node.js 代理服务器驱动，代理服务器将命令转发到运行在 Docker 中的两个 rgbldkd 节点（Alice 和 Bob）。

全部 13 个步骤均通过验证：

#	步骤	状态	验证说明
01	检查节点	✅	Alice 和 Bob 两个 `rgbldkd` 节点正常运行；成功获取节点 ID（secp256k1 公钥）
02	挖掘 101 个区块	✅	Regtest coinbase 成熟度确认；挖掘 101 个区块使第 1 个区块的奖励可花费
03	为 Alice 注资 BTC	✅	向 Alice 的闪电钱包发送 1 BTC；通过 `wallet/sync` 确认余额
04	为 Alice 注资 RGB UTXO	✅	准备 0.01 BTC UTXO 作为 RGB 合约发行的 Genesis Seal
05	导入发行者模板	✅	`RGB20-Simplest-v0` AluVM 字节码通过二进制上传导入 Alice 的节点
06	发行 RGB20 合约	✅	发行 1,000,000 TTK；返回 `contract_id` 和 `asset_id`；承诺锚定在链上
07	分享合约给 Bob	✅	从 Alice 导出 Consignment，Bob 验证并导入——完全链下完成
08	为 Bob 注资 BTC	✅	向 Bob 的钱包发送 0.05 BTC；用于后续 Hold Invoice 支付
09	连接对等节点	✅	Alice → Bob 通过 Docker 内部网络建立 Noise Protocol TCP 连接
10	开设 RGB 闪电通道	✅	创建双资产 Funding TX：一个输出中包含 2,000,000 sats + 500,000 TTK
11	确认通道	✅	达到 6 个区块确认；双方收到 `ChannelReady` 事件
12	RGB 闪电支付	✅	Alice 通过闪电网络即时向 Bob 发送 100 TTK；无需区块确认
13	Hold Invoice 交换	✅	Bob 通过 HTLC 锁定 10,000 sats；Alice 交付 200 TTK；释放原像完成结算

系统架构

演示环境完全运行在单台主机上：

┌────────────────────────────────────────────────────────────┐
│                        主机 (macOS)                         │
│                                                             │
│  ┌──────────────┐     ┌───────────────────────────────┐    │
│  │  浏览器       │     │    Docker 网络 172.18.0.0/24   │    │
│  │  :5173 Vite  │     │                               │    │
│  └──────┬───────┘     │  bitcoind       172.18.0.2    │    │
│         │ HTTP        │  esplora        172.18.0.3    │    │
│  ┌──────▼───────┐     │  rgb-node-alice 172.18.0.4    │    │
│  │ server.mjs   │◄────►  rgb-node-bob   172.18.0.5    │    │
│  │  :3000 代理   │     │                               │    │
│  └──────────────┘     └───────────────────────────────┘    │
└────────────────────────────────────────────────────────────┘

组件	技术	角色
`bitcoind`	Bitcoin Core 24.0.1, Regtest	本地测试链，BTC 转账，区块挖掘
`esplora`	Bitlight 定制 Esplora	区块链索引器，通过 Electrum 协议为 `rgbldkd` 提供 UTXO 同步
`rgb-node-alice/bob`	`bitlightlabs/rln-ldk-node`	RGB+LDK 融合节点，管理 BTC 钱包、RGB 资产和闪电通道
`server.mjs`	Node.js HTTP（无框架）	代理：CORS 处理、二进制文件中转、复合操作
Vite + React	React 18 + Tailwind CSS	向导式 UI，每步一组 API 调用

代理服务器（server.mjs）解决了两个基本的浏览器限制：rgbldkd 不设置 Access-Control-Allow-Origin 头，二进制 consignment 数据无法从浏览器直接流式传输。代理处理两者，向前端呈现简洁的 REST 接口。

逐步详解

步骤 1–4：基础准备

步骤 1 — 检查节点 查询两个节点的 node_id（secp256k1 公钥），该 ID 同时作为后续 Noise Protocol 握手的闪电网络 P2P 身份标识。

步骤 2 — 挖掘 101 个区块 创建初始比特币 coinbase 成熟度。比特币要求 coinbase 输出经过 100 次确认后才能花费；挖掘 101 个区块使第一个区块的奖励可用。Docker bitcoind-init 容器在启动时自动处理此操作。

步骤 3 — 为 Alice 注资 BTC 向 Alice 的 rgbldkd 钱包发送 1 BTC。节点内部使用 BDK（Bitcoin Dev Kit）并通过 Esplora 同步——必须显式调用 wallet/sync，因为节点不会被动监听。

步骤 4 — 为 Alice 注资 RGB UTXO 是一个关键的准备步骤。RGB 协议使用一次性密封（Single-Use Seals）：资产所有权被承诺到特定的 UTXO 上。当该 UTXO 被花费时，RGB 状态转移就会发生。这要求 RGB 和 BTC 钱包独立管理 UTXO，因此 Alice 在发行代币之前需要一个资金为 0.01 BTC 的专用 RGB 地址。

步骤 5–7：RGB20 代币发行与分发

步骤 5 — 导入发行者模板 加载一个 .issuer 二进制文件——编译后的 AluVM 字节码——到 Alice 的节点中。AluVM 是 RGB 的虚拟机；合约逻辑在每个接收者的机器上本地执行，从不在链上执行。RGB20-Simplest-v0 模板是一个精简的 RGB20 实现，非常适合演示。

步骤 6 — 发行 RGB20 合约 创建 1,000,000 个 TTK 代币：

json

{
  "issuer_name": "RGB20-Simplest-v0-rLosfg",
  "contract_name": "TestToken",
  "ticker": "TTK",
  "precision": 0,
  "issued_supply": "1000000"
}

在内部，节点消耗步骤 4 的 UTXO 作为 Genesis Seal，构建创世状态（Alice 拥有全部 1M TTK），生成全局唯一的 contract_id，并使用 Tapret 或 OP_RETURN 将密码学承诺嵌入比特币交易中。链上不会广播任何新的数据结构来表示代币——链上只出现一个承诺哈希。

步骤 7 — 分享合约给 Bob 通过 Consignment 机制完全在链下将合约分发给 Bob 的节点。代理服务器原子性地编排三个调用：

Alice 导出 consignment_key
代理从 Alice 下载二进制 consignment zip
代理上传到 Bob

Bob 独立地将完整的合约历史与比特币区块链进行验证。如果每个锚定的承诺都在已确认的交易中找到，Bob 就接受该合约。Alice 无法伪造这段历史——验证完全在 Bob 这一端进行。

步骤 8–11：带 RGB 资产的闪电通道

步骤 8 — 为 Bob 注资 BTC 给 Bob 0.05 BTC，用于后续原子交换的支付端。

步骤 9 — 连接对等节点 使用 Noise Protocol（BOLT #8）在 Alice 和 Bob 之间建立闪电 P2P TCP 连接。由于 P2P 发生在容器之间，连接使用 Docker 内部 IP（172.18.0.5:9735）。

步骤 10 — 开设 RGB 闪电通道 是 RGB 与闪电网络在单个 Funding Transaction 中结合的关键步骤：

json

{
  "channel_amount_sats": "2000000",
  "push_to_counterparty_msat": "50000000",
  "rgb": {
    "asset_id": "<asset_id>",
    "asset_amount": "500000",
    "color_context_data": "http://172.18.0.4:8500/api/v1/rgb/consignments/{txid}?format=zip"
  }
}

BTC 端遵循标准 LDK：一个 2-of-2 多签 Funding Output，包含 2M sats，向 Bob 推送 50K sats 作为初始出站流动性。RGB 端将 500,000 TTK 所有权绑定到同一个 Funding Transaction 输出。color_context_data URL 告诉 Bob 从哪里下载 RGB Consignment，以便在接受通道之前独立验证 Alice 的代币所有权。

步骤 11 — 确认通道 挖掘足够的区块以达到 BOLT #2 要求的 6 次确认阈值。演示使用双重确认策略：首先等待节点事件队列中的 ChannelReady 事件，如果事件已被消费（例如页面刷新后），则回退到轮询 /channels API。

步骤 12：RGB 闪电支付

通道开设后，Alice 向 Bob 即时支付 100 TTK，无需区块确认：

json

{
  "asset_id": "<asset_id>",
  "asset_amount": "100",
  "btc_carrier_amount_msat": "3000000"
}

这里的关键设计洞察：RGB 代币无法在闪电网络中独立路由——它们没有毫聪面额。每笔 RGB 闪电支付必须搭载在一个小额 BTC HTLC（"载体"）上。3,000 sat 载体激活 HTLC 路由路径；RGB 状态更新与之一起在链下协议层传输。支付在毫秒内完成，没有链上足迹。

步骤 13：Hold Invoice 原子交换

这是演示中最精巧的功能——使用 Hold Invoice 实现的 BTC ↔ RGB 代币交换。交换内容：Bob 支付 10,000 sats，Alice 交付 200 TTK。

工作原理

① Alice 创建 Hold Invoice

Alice 在本地生成一个随机的 32 字节 preimage 并计算 paymentHash = SHA256(preimage)。她创建一个锁定到 paymentHash 的 10,000 sats Hold Invoice，但不透露原像。

preimage = random_bytes(32)       // Alice 保密
paymentHash = SHA256(preimage)    // 发布在 invoice 中

② Bob 支付 invoice（HTLC 锁定）

Bob 发送支付。他的 10,000 sats 现在被锁定在 HTLC 中：

HTLC 条件：揭示 x 使得 SHA256(x) == paymentHash
→ 资金锁定，Bob 在到期前无法单方面取消

这是"承诺"阶段。Bob 的资金已锁定，但 Alice 还没有收到。

③ Alice 向 Bob 发送 200 TTK

看到 HTLC 已锁定，Alice 现在通过同一闪电通道向 Bob 发送 RGB 支付。这是标准的 RGB 闪电支付，立即结算。

④ Alice 通过揭示原像领取 BTC

json

{
  "payment_hash": "<paymentHash>",
  "preimage": "<preimage>",
  "claimable_amount_msat": "10000000"
}

Alice 调用 claim_for_hash，广播原像，HTLC 结算——她收到 10,000 sats。

最终状态：

Alice: +10,000 sats,  -200 TTK
Bob:   -10,000 sats,  +200 TTK

生产环境的 rgb-lightning-node 协议在不需要 DLC 或跨链协调的情况下实现了真正的密码学原子性。它通过循环闪电路由实现：Maker 同时是路由的起点和终点，Taker 位于中间作为转换点，单个 payment_hash 同时锁定两端。当 Maker 在目的地揭示原像时，入站和出站两端同时结算——原子性由路由拓扑本身保证，不需要任何额外的协议层。

关键协议洞察

RGB 的客户端验证模型

传统链上代币	RGB
所有转账公开可见	只有交易双方知道转账历史
合约状态存在链上	合约状态存在于接收者本地
全节点验证	接收者本地验证
所有数据永久上链	链上只有承诺（哈希）

这种设计赋予 RGB 三个重要特性：隐私性（转账历史不全局可见）、可扩展性（无需每笔转账都有链上数据）和主权性（你独立验证自己的资金）。

一次性密封（Single-Use Seals）

每个 RGB 状态转移都绑定到一次 UTXO 花费。当 UTXO 被花费时，密封被"打破"——RGB 转移不可逆地执行。这在协议层面防止了双花，无需维护 RGB 交易的全局账本。

Consignment 作为证明包

当你收到 RGB 资产时，你收到的是一个 Consignment：从创世交易到当前状态的完整审计轨迹。你在本地将这条轨迹与比特币交易进行验证。发送者无法操纵这段历史——所有 RGB 承诺都锚定在任何人都可以独立验证的已确认比特币区块中。

BTC 作为 RGB 的闪电载体

RGB 代币无法原生存在于闪电网络的 HTLC 路由中（没有 msat 值）。每笔 RGB 闪电支付中的 btc_carrier_amount_msat 字段是"载体" RGB 状态更新通过通道所需的最小 BTC 量。BTC 载体和 RGB 负载一起传输；如果 BTC HTLC 失败，RGB 转移也失败。

开源参考

完整的验证演示代码可在 rgbstashlabs/rgb-ldk-verify-demo 获取。它包含完整的 Docker 基础设施、代理服务器和 React 前端。开发者可以在任何装有 Docker 的 macOS 或 Linux 机器上本地运行完整的 13 步流程。

闪电网络上的 RGB 资产代表了比特币可编程层最重要的能力扩展之一。在链下通道内发行、转移和交换自定义资产的能力——配合比特币的安全保障和客户端隐私——为一类新的闪电网络原生 DeFi 应用打开了大门，而这些应用不需要一条单独的区块链。

在闪电网络上验证 RGB 资产 ​

验证内容 ​

系统架构 ​

逐步详解 ​

步骤 1–4：基础准备 ​

步骤 5–7：RGB20 代币发行与分发 ​

步骤 8–11：带 RGB 资产的闪电通道 ​

步骤 12：RGB 闪电支付 ​

步骤 13：Hold Invoice 原子交换 ​

工作原理 ​

关键协议洞察 ​

RGB 的客户端验证模型 ​

一次性密封（Single-Use Seals） ​

Consignment 作为证明包 ​

BTC 作为 RGB 的闪电载体 ​

开源参考 ​

在闪电网络上验证 RGB 资产

验证内容

系统架构

逐步详解

步骤 1–4：基础准备

步骤 5–7：RGB20 代币发行与分发

步骤 8–11：带 RGB 资产的闪电通道

步骤 12：RGB 闪电支付

步骤 13：Hold Invoice 原子交换

工作原理

关键协议洞察

RGB 的客户端验证模型

一次性密封（Single-Use Seals）

Consignment 作为证明包

BTC 作为 RGB 的闪电载体

开源参考