[Fiber] 比特币闪电网络的钱包与支付研究

中文 Layer 2 开发与技术讨论
1

根据闪电网络的协议要求，当两个节点之间要实现转账时，必须要求两个节点同时在线，这个过程就好比是节点之间通过 “签订合同” 来实现财产转移，而不是一方向另一方的 “银行卡” 里转账。

签订合同的过程：

  • 收付双方协商支付金额
  • 收款方通过一个密钥生成支票
  • 将支票告知付款方
  • 付款方通过向支票发起付款请求
  • 收款方收到付款请求后公开密钥
  • 付款方收到密钥后完成付款

闪电网络的支付效率非常高，但两个节点都得同时在线的要求着实也限制了网络的使用场景，对于习惯了传统区块链随时随地就能完成转账操作的用户来说，上手闪电网络必定会有诸多不习惯的地方。对于发展了很多年的闪电网络来说，已经逐渐就此问题形成了两种不同的解决思路：一个是弱化去中心化特性的引入 LSP 服务商的方式，另一种是比特币侧链与闪电网络进行原子交换的方式。

比特币侧链是一个完整的区块链，不存在闪电网络中点对点转账还需要双方同时在线的情况，并且链上运行智能合约，具备一定的可编程性，具有代表性的就是 Liquid 和 Stacks。这类侧链需要用户把 BTC 打入到特定合约中，再通过跨链桥在对应侧链上 1:1 铸造映射代币，然后通过原子交换的方式与闪电网络之间实现非托管级别的转账，当资金来到侧链上时，就完全脱离了闪电网络的束缚了。

本次只着重分析闪电网络 LSP 服务商的方式。

闪电网络钱包

当设计一个闪电网络钱包的时候，可能很多开发者的想法就是做一个钱包 UI 然后再把闪电网络节点运行时塞进去就行，但仅仅这样就够了吗？答案肯定是不够的，当一个技术小白拿起这款钱包时，他会遇到各种各样的问题，包括但不限于：

  1. 闪电网络拓扑结构复杂，同步拓扑结构耗时不说，每次支付都要进行极其耗时的节点寻路操作，体验糟糕
  2. 刚拿到钱包时，钱包里根本没有资金用于创建通道
  3. 向一串犹如乱码一样的支票代码付款，新手用户根本不知道这是在干嘛
  4. 收款方如果恰巧不在线，支付操作都无法进行下去
  5. 不在线期间，无法完成收款

如果闪电网络钱包不解决以上问题，那闪电网络想要普及开来就会非常困难。所幸，随着闪电网络的发展和 LSP 服务商角色的出现，以上问题在一定程度上基本都得到了解决。

目前主流的闪电网络钱包主要分为以下三大类：

全托管类钱包

将用户资金托管到 LSP 服务中，不存在收付款操作中要求的收付双方同时在线的要求，也不要求在本地运行闪电网络节点，还可以轻松整合各类金融服务，比如与法币系统做结合，直接实现 BTC 与法币之间的自由兑换，最大程度降低用户的使用门槛，是用户使用量最大的类别。

代表性钱包有：

  • Wallet of Satoshi
  • Strike

半托管类钱包

资金安全仍由用户自己负责，但会通过 LSP 服务为钱包注入更多便利性。这类钱包中会运行轻量级的闪电网络节点，不维护全网路由状态，付款操作中的节点路由功能会由 LSP 服务辅助提供，收款操作会通过 LSP 截流 HTLC 为钱包上线提供缓冲时间，此外 LSP 还会为钱包的通道创建提供初始流动性。

代表性钱包有：

  • Phoenix Wallet
  • Breez Wallet

自托管类钱包

最本真的闪电网络钱包，允许用户自己选择可以连接的比特币节点或闪电网络节点，所有操作都由钱包自己完成，无第三方提供辅助服务。面向高级玩家，提供最硬核的用户体验，所以这类钱包无需为用户体验妥协去中心化与安全特性。

代表性钱包有：

  • Zeus Wallet
  • Blue Wallet

为什么引入 LSP 就能解决那么多复杂的问题？在介绍 LSP 之前我需要先讲解一下 LNURL、HTLC 截流 和 Trampoline 蹦床路由。

LNURL

LNURL 全名为 Lightning Network URL，以下是 Glow 网页版钱包（基于 Breez 钱包 SDK 开发）的闪电网络收款截图，我们看到其收款地址是：[email protected]

image
image1844×1124 151 KB

熟悉闪电网络的朋友都知道，闪电网络是没有特定的收款地址的，每次要收款时都需要生成带有金额的收款支票，而付款方就直接向这个支票进行付款，所以这种域名式的收款方式一定是基于闪电网络而构建的应用层协议。

LNURL 协议背后是基于 LSP 运作的：

  1. 每个 LSP 维护一个特定的域名，比如 Breez 钱包维护 breez.tips 主域名，钱包按照协议要求将 LNURL 地址转换为 https 请求地址，例如 https://breez.tips，而 yellowelephant4762 则表示钱包的 ID
  2. 付款方通过 LNURL 地址向收款方付款，付款金额可由付款方指定，付款请求和付款金额被 LSP 服务接收，LSP 服务唤醒接收方的钱包并生成对应金额的收款发票
  3. LSP 将收款方的发票返回给付款方钱包，然后付款方向发票付款

从向 “发票” 付款转而向 “地址” 付款，LNURL 显著降低了使用闪电网络的认知门槛，这算是一个不小的进步，不过我在前文中提到了 唤醒 一词，如果 LSP 未能成功唤醒钱包呢？这里其实是有两种不同的收款方钱包离线场景：

生成发票时收款方钱包离线

按照闪电网络 BOLT11 协议，收款节点需要创建发票，并将发票告知付款方才能完成支付，但此时收款节点下线，于是 LSP 尝试通过收款节点来自行创建发票便走不通了，那是否可以让 LSP 代为创建发票呢？可以，不过需要解决几个问题：

  • 发票的 payment_hash 该如何生成？
  • 如何让付款方节点知道这个发票是要路由到收款方节点的，并且路由过程必须经过 LSP 的节点？

针对第一个问题，最简单的做法是每个 LSP 所管理的钱包需要预先生成一批 payment_hash 并存放到 LSP 中，这样即使钱包不在线，LSP 也能找到有效的 payment_hash；针对第二个问题，将发票中的目的节点改为钱包的轻节点并且routing_hint 这个字段设置为 LSP 的节点，这样付款节点在构造路由时会将目标节点设置为收款钱包的节点，而且路由中的倒数第二个节点一定是 LSP 的节点。

路由 HTLC 时收款方钱包离线

HTLC 路由时，要求路由表中的所有节点必须保持在线，但偏偏最后一个收款不在线，不过由于 HTLC 消息的隐私性，路由途中的节点并不知道整个路由表结构，因此路由会毫无阻碍地进行下去。当 HTLC 路由到 LSP 的节点时，通过 payment_hash 就能判断此 HTLC 是否是关联着自己管理的钱包，如果是且钱包不在线，那么这个 HTLC 就会暂时停留在 LSP 节点中，这就是接下来要讲的 HTLC 截流。

HTLC 截流

HTLC 消息在闪电网络节点中传播的时候，每一个经过的节点都能从 HTLC 中看到自己的上游节点和下游节点，就正常情况来说，当闪电网络节点发现下游节点无法到达时就会报错然后退出路由，但这种情况在 LSP 服务商所管理的节点群中时常发生，因为收款方的钱包软件可能无法唤醒，这样其内部的节点自然也就无法被触及。

当 LSP 服务器的节点明确了自己收到的 HTLC 的下一跳确实是自己所管理的钱包，而钱包又无法被唤醒时，节点会暂时保存这个 HTLC 知道其过期为止，如果再次期间收款方的钱包成功上线，那 LSP 服务就会释放该 HTLC 并顺利完成消息路由。

所以通俗地说，LSP 服务器所管理的那群闪电网络节点是经过改造的，目前 HTLC 截流并不是一个标准的协议，但它确确实实的解决了 “异步支付” 的问题，所以也成为了事实上的标准。最新推出的 BOLT12 标准就是从该标准演化而来，是专门用于支持 “异步支付” 场景而设计的，它能直接将异步支付功能从原先的应用层下放到协议层。

Trampoline 蹦床路由

蹦床路由解决的是轻节点没有完整网络拓扑结构的问题。为了最大程度优化钱包的支付体验，闪电网络的节点寻路操作在网络拓扑结构复杂的情况下是需要着重优化的，简单的说，就是讲路由寻路过程从钱包端移动到 LSP 端，通过 LSP 服务器强大的算力来为钱包快速计算出最佳路由结构。

过程也很简单，付款钱包构建一个下一跳能直接路由到 LSP 节点的带有蹦床请求的 HTLC 消息，当 LSP 节点正常解析 HTLC 后，发现自己看到了一个蹦床请求，于是凭借自己强大的算力和完整的网络拓扑图，生成包含剩余路由信息的 HTLC 消息并继续转发给下一跳节点。

蹦床路由是可以嵌套的，理论上一个完整的路由过程是可以经历多个蹦床节点的。不过貌似目前蹦床路由仍是事实上的标准。

LSP 总结

其实在了解完 LNURL、HTLC 截流和 Trampoline 蹦床路由后，基本对 LSP 服务商对闪电网络生态的贡献和价值就有了最基本的价值判断了。

LSP 和其配套的协议在不改变闪电网络最基本的运行协议的基础上，极大的提升了闪电网络的使用体验，并且这是在没有过多影响去中心化特性与安全特性的前提下达成的，它是闪电网络走向大众并推广普及的重要一环。

我们这里总结一下 LSP 通过哪些方式降低了闪电网络的使用门槛：

  1. 为新装钱包提供初始流动性
  2. 使用 LNURL 域名简化支付流程
  3. 通过钱包唤醒与异步支付优化支付体验
  4. 通过蹦床路由提升钱包使用流畅度和操作响应速度

当以上目标都达到后，你家奶奶下载了闪电网络钱包后都知道该怎么用了，这就是降低使用门槛的目的，也是闪电网络发展了这么多年后的成果。

思考：Fiber 该怎么做？

Fiber 是基于标准的闪电网络协议构建的，所以与比特币闪电网络生态有极强的相关性，考虑到 Fiber 最终一定会需要与闪电网络交互，所以为 Fiber 引入 LSP 服务商必不可少。LSP 除了可以将其对闪电网络的作用完全复刻到 Fiber 生态中之外，还可以无缝实现让 BTC 在闪电网络和 Fiber 网络中自由流动。

考虑到 Fiber 相对于闪电网络有如下优势：

  • 天生支持多代币模式
  • 未来将实现的可编程性
  • 相对优秀的 WASM 运行时环境

于是，通过 LNURL 和 LSP 实现 Fiber 钱包和闪电网络钱包之间的无缝转账，将 BTC 从闪电网络无感的转移到 Fiber 网络中，再配以 Fiber 网络的可编程性所催生出来的各种 DApp 与 WASM 运行时所提供的便利性，实现 Bridgeless 级别的 BTC → CKB 的跨链，我认为这会成为 BTCFi 时代的重要玩法之一，因为这是闪电网络级别的玩法，而不是传统侧链的玩法。

10 Likes
CKB Ecosystem Biweekly Update
2

知识密度比较大，需要有一定闪电网络的知识背景才能看明白

2 Likes
3

Thanks for sharing this! I found the article really insightful, especially the explanation of how LSPs reduce UX friction for Lightning-style payment channels.

One reflection I had while reading is that it reinforces how important Fiber’s positioning is. Fiber already feels more naturally aligned with pay-as-you-use services, streaming payments, and repeated merchant relationships, rather than simply being a replacement for everyday payment apps like Alipay or WeChat Pay.

Compared with normal wallet transfers, Lightning-style payment channels have a very different mental model: reachability matters, balance does not always equal spendable amount because outbound liquidity matters, and opening a channel does not automatically create enough inbound liquidity to receive.

In scenarios where there is already an ongoing service relationship — starting a session, authorizing a budget or payment flow, using the service, and settling based on actual usage — the channel model feels much more natural. In that context, LSP-like infrastructure still matters, but it supports reliability and adoption on top of a user experience that already fits how channels work.

1 Like
4

You’re right, building LSP is the most valuable movement for us in my point of view, especially when we achieve our programmability feature in Fiber.
Using LSP in a totally same protocol with how currently Lightning Network does, this can make Fiber fully connectable to it and pull up the most possibility of transferring BTC to CKB ecosystem, you know, Bridgelessly.
Whatever will build upon Fiber, the LSP matters the most than everything for an ultimate UX goal.

5

WatchTower：资金安全的瞭望塔

作为本篇研究的补充，我将系统性地讲解一下 “瞭望塔（WatchTower）” 对闪电网络的意义以及它在闪闪电网络拓扑结构中的位置。

WatchTower 本身是直接集成在闪电网络节点中的一个功能模块，但绝大多数用户是没有条件去运行它的，比如闪电网络轻节点或者 WASM 版本的 Fiber 就没有此功能，因此这类用户只能将资金安全的监控需求外包给第三方 WatchTower 服务商，在现实状况下，一般都由 LSP 服务商负责提供。

为什么闪电网络一定得需要 WatchTower？

原因是因为闪电网络本身的协议特性决定的：

  1. 闪电网络的通道本质上不是物理意义上的通道，而是两个节点互相维护一个记录着各自视角下的通道资金账本的区块链交易

  2. 每一次账本变动双方节点都会就变动后的账本达成一致并各自生成需要互相签名确认的交易，这意味着单个节点保存着所有代表历史账本状态的老旧交易集合，即历史通道状态集合

  3. WatchTower 的意义就在于帮助节点监控对手节点是否拿着历史交易去关闭通道

为什么 WatchTower 可以独立于节点运行？

原因是因为在闪电网络中，通道的运行与监控在功能逻辑上是解耦的：

  1. 通道在开启状态下的每次账目变更都会在链下生成代表账本状态的交易数据，其中有针对自己作弊时能愿意主动上交全部资金的承诺

  2. 当通道状态更新之后，代表旧有状态的交易就会因为双方交换了承诺而实质上作废，因为对手此时已具备能让自己强制兑现承诺的能力

  3. 任意一方都能将对手所有的旧有交易和惩罚交易一起上传到 WatchTower 中，持续监控对手是否想要使用旧有交易关闭通道，一旦监控到，就立即释放惩罚交易，罚没对手全部资金

  4. 理论上，WatchTower 和通道是并行工作的：通道产生旧状态，WatchTower 监控旧状态

LSP 已经为闪电网络钱包用户提供了众多服务，自然也会将 WatchTower 资金安全监控服务也囊括在内，对于自己完全不信赖第三方服务商而需要独立运行 WatchTower 的用户来说，必定是硬核用户，对于绝大多数用户来说，便利性永远是第一考虑因素。

但值得令人尊敬的是，用户是有选择的：选择 LSP 只是因为看中方便，而不是因为没有其他选择可选。这也正能体现出比特币生态在安全与包容这两个维度上所做的努力，是值得我们认可的。

1 Like