作者：Peter Todd

来源：https://petertodd.org/2025/fake-channels-and-rgb-lightning

关于闪电网络协议，一个反直觉的事情是：转发你的支付的路径上的中间通道，没必要是 “真的” 通道。如果 Alice 想要给 David 支付比特币，通过路径 Alice ↔ Bob ↔ Charlie ↔ David ，那么无论 Bob 与 Charlie 之间的闪电通道是真的 —— 锁定了比特币的真实通道 —— 还是假的，都不重要！实际上，对 Alice 来说，甚至连 David 收到的是不是比特币也不重要。对她来说重要的是，David 接受了支付（揭晓了原像）；如果他不揭晓原像，Alice 绝不会平白无故付钱给他。

同样地，如果是 Alice 要从 David 这里 接收 比特币支付，通过 David ↔ Charlie ↔ Bob ↔ Alice 路径，那么 Alice 也不在乎 David 支付给 Charlie 的是不是真的比特币，Charlie 给 Bob 是什么也不重要。她关心的只是 —— 无论如何，Bob 已被说服，要发送真正的比特币给她。

现有的闪电网络协议确实保证了公开的通道对应于有效的 UTXO 。但这样做的 理由 仅仅是为了对抗 DoS 攻击：一定要有 某些 方法来限制人们可以广播的通道数量。将闪电通道 UTXO 与 gossip 公告绑定，恰好是我们（当前）选择的办法。

使用客户端验证 token 的闪电通道

闪电支付可以通过公开的 “假通道” 来安全地路由，这个事实，对于建立在比特币之上的闪电网络，一直只是个理论话题。它曾被当成一种在相互信任的双方之间建立通道时降低流动性要求的方法。但这样的想法从未实现过。

然而，对于建立客户端验证的 token 上的闪电通道来说，那就大大不同了。

回顾一下，客户端验证的 token 使用 “RGB” 这样的协议、将比特币网络当成一种纯粹的抗重复花费机制：比特币协议只是用来保证给定的一个钱币只有一份历史。而这份历史的 有效性 是由客户端（用户自己）验证的。因此，如果 Alice 想给 Bob 一个代表 1 美元的前保持（基于 RGB 协议），她只需说服 Bob 这个钱币是真实的，办法是给 Bob 这个钱币的完整历史（从创建她手上这个钱币的交易，一路追溯到其创世输出）。

因为这个历史并不是全局的，客户端验证具有极大的可扩展性潜能。我曾经在这篇博客中解释过，一种客户端验证的 token 可以用字面意义上每秒数十亿笔交易的总吞吐量。但是，这些交易依然是一种链内交易，也就是依然需要时间来确认；而闪电交易可以是近乎即时的。

因此，RGB 和 “Taproot Assets” 都在开发交易客户端验证 token 的闪电通道。

这就回到了 “假” 通道的问题：虽然可能需要几 MB 的交易数据来证明你手上的一个 RGB token 是真实地，如果你将这个 token 用在一条闪电通道中，你 不需要 知道任何其他人的闪电通道中的 RGB token 是不是真实的！只要有证据证明你的通道是真实地、完全自主保管地，就够了；如果其他人被骗去接受假的钱币，那也不是你的问题。

Taproot Asset “宇宙”

这就带来了一个有趣的问题：Taproot Asset 协议中的 “资产宇宙（Universes）”，真是必要的吗？这一设计背后的想法是，轻客户端将 —— 不是自己验证，而是 —— 信任第三方 “宇宙” 来为他们想要交易的资产执行钱币验证。这些宇宙，被预期知晓一种资产的所有交易（最起码是绝大部分的交易），并且会创建巨大的、签过名的默克尔树，来承诺给定一个区块高度时刻的所有有效钱币。

如果标准的 “轻” 钱包只使用闪电通道，只需下载几 MB 的数据，就能完全客户端验证自己的钱币，而无需依赖任何第三方。因为中间的闪电通道是否真实并不重要，请客户端甚至可以基于 gossip 消息，自行构造路线（例如，使用一种稀缺性证据的抗 DoS 机制）。

（完）