作者：Matt Corallo

来源：https://lightningdevkit.org/blog/the-challenges-of-developing-non-custodial-lightning-on-mobile/

闪电网络应用的开发并不容易。虽然走向托管模式可以简化流程，但也意味着牺牲用户的隐私性、审查抗性和自主性，也就完全站到了比特币精神的反面。因此，许多公司和项目已经开始（或者重新定向）将开发的重心从托管应用转为非托管的应用。

障碍

钱包想要添加使用闪电网络的特性，有一些基本的要求，比如通过一个闪电网络客户端实现连接到闪电网络、同步链上交易、开启和关闭闪电通道。而在开发移动端时，开发者会面临额外的技术挑战：

流动性

通过闪电网络接收支付时，如果接收方的通道不平衡，交易就要推迟才能完成。比如说，某人有 5 万聪的收款额度（inbound liquidity，也即你的通道对手在通道中的余额），但希望收取 10 万聪的支付。在闪电交易发起之前，TA 必须先获得额外的收款额度：需要在扣减掉通道保证金和锚点输出 —— 都是用来提高安全性的机制 —— 的价值之后，依然能够收取这 10 万聪的支付。这就要通过链上交易来实现，因此要付出链上确认手续费。

此外，这样的链上交易可能要等待几个区块才能被确认。这可不是什么好的用户体验 —— 想象一下，你得为一次支付（或者收款）提前准备，并且要等待 30 ~ 60 分钟。

“零确认通道” 提供了一部分的解决方案，允许用户即时收取闪电支付。零确认通道让客户端在链上交易等待确认的期间信任自己的通道对手，通常是应用的供应商或者其合作伙伴，在链上交易确认之后就恢复为常规的闪电通道安全模式（免信任）。虽然在速度上有所帮助，零确认通道要求一定程度的信任，也确实是一种取舍。

“闪电网络服务商（LSP）” 可以通过自动化的通道和流动性管理，提前为用户提供流动性。LSP 会提供比眼下即将到达的支付的价值更大的流动性，而不是提供恰好等量的流动性，以保证通道能继续接收未来的支付。如果用户将获得多笔支付，那最好避免每一笔闪电交易都需要一笔链上交易才能成功。

LSP 并不希望支付太多的链上手续费，但很难预测用户收发交易有多频繁、额度有多大。因此，应当为给定的一条通道锁定多少资金没有明晰的答案。LSP 必须决定自己要投入多少资金、使用这些资金的代价是多大。可以是激进风格（锁定大量资金），也可以是保守风格（锁定少量资金）。最终，这些决策会产生一个 “压缩比”，即，为使交易顺利成功，需要为（平均）一笔闪电交易发起多少笔链上交易。一些非常保守的 LSP 会得到一个接近于 1 的压缩比，只为用户节约了相对较少的手续费，但使用闪电网络而非链上交易几乎总是可以获得一些好处。

虽然预测压缩比的合适数值依然是一个重大挑战，今天的绝大部分解决方案都提供了一些压缩信息，允许我们了解和优化。因为这个理由，相比于链上交易，部署闪电通道、低成本地接收即时交易，是值得的，即使你的闪电交易没有那么地频繁。我们预期会这会随着时间的推移逐渐变好。

收款唤醒

闪电通道需要节点（或者更具体一点，他们的密钥）在线，以交换签名、完成支付，这就意味着用户必须呆在手机旁边，而且手机有网络服务。收款唤醒很关键，因为悬在半空不完成的交易对闪电网络不好 —— 转发这笔支付的沿途节点都必须为此锁定一部分资金，直到接收者上线收取支付。

iOS 和 Android 操作系统可以帮助解决这个问题：允许在收到通知时运行少量的代码，即使相关的应用程序并没有打开。不过，假设一个应用并不常用，或者设备处在低电量状态，这时候，通知将不会获得任何 CPU 时间，从而支付会被卡住，直到用户打开 app。

人们投入了大量精力，希望让发送者和接收者能够异步完成支付，但一个协议草案还在开发中（编者注：该链接指向一个归档网站，已经失效。被归档的比特币开发者邮件组帖子的中文译本见此处）。可以在此处找到更详细的解释。

实时备份

这是非常难搞的问题，出现在一个用户不得不重新安装一个应用，或者弄丢手机的时候。用户除了需要一个种子词，还需要原有闪电通道的最新状态数据，这样才能可靠地找回资金。

每当用户收取或发送支付，闪电通道的状态就会改变，所以备份必须经常更新到服务器上。虽然一些设备使用 Google Drive 或 iCloud，但这些协议都是异步的，导致数据经常脱离同步。云同步方法可以很好地让存在客户端本地的数据脱敏，但如果设备丢失，可能无法可靠地找回全部资金。

实时在线同步的高级办法让用户可以在多个设备上开启同一个钱包。这也会给闪电网络应用带来挑战，因为两个设备同时运行可能导致资金丢失。

保护隐私的支付路由

另一个常常被讨论的问题是闪电网络中的支付路由。这并不容易，因为寻路者必须在闪电网络中有一些流动性历史。

最常用的方法是依赖于一个服务端来发现路径，但这个服务端就能看到用户的支付历史，因此会削弱用户的隐私性。这可能还会给依赖于这样的服务的应用带来长期的监管担忧。

不依赖于服务器，客户端就需要下载完整的闪电网络图谱。这可能会很慢，而且会影响设备的性能。最糟糕的是，闪电网络图谱自身还不足以为实现可靠的支付提供足够的信息，可能交易要花很多时间来完成，或者根本无法完成（译者注：闪电网络图谱仅能提供关于网络中的通道的基本信息，比如大小和转发费率，但各通道的余额分布是瞬息万变的）。

为了实现更高的支付成功率，客户端必须发送大量支付，这可以通过 “侦测（假支付）” 来做到。侦测会补充客户端视角下的网络图谱的数据，并建立起网络中流动性的历史。虽然这提供了一种解决方案，侦测还必须连贯地进行，也就是客户端要 7 * 24 小时在线。可以由 LSP 来做这件事，然后给客户端提供结果。此外，信息不太好在 LSP 之间迁移，所以每一个 LSP 都要做自己的侦测。

保护隐私的区块获取

为了让用户看到自己的交易历史和余额，比特币和闪电网络钱包需要连接到比特币节点、下载区块链。每一个区块都包含大量的数据，所以在移动设备上下载完整的区块链是不显示的，它有带宽限制。

最常见的解决方案是连接到一个使用 Electrum 或 Esplora 的服务器来获得区块链数据。为了获得相关的信息，客户端必须提供自己的地址列表，这就会暴露交易的历史和余额。

很难在不牺牲隐私性的前提下获得区块链数据。解决办法之一是使用 “致密区块过滤器”，它会从某一个全节点处下载数据，而且只下载一部分区块。虽然致密区块过滤器提供了更好的隐私性（相比 Electrum 服务器），而且比下载完整的的区块更加高效，但依然算不上完美。致密区块过滤器同步起来比较慢，而且依然需要可观的带宽，所以许多钱包软件都不愿作这个取舍。

第三个选择，称为 “隐私信息检索”，更面向未来。这种方法对客户端来说很高效，但对服务端来说很昂贵。

结论

为了让非托管的闪电网络应用能在移动设备上工作并保护隐私，要克服许多障碍，但依然是可行的。这需要一个专注于移动端的闪电网络客户端实现、一套开发者工具箱，以及由一个 LSP（或应用供应商）所运行的基础设施。这些都不需要牺牲用户的隐私性和自主性，尽管在某一些设计中，确实要牺牲。

（完）