作者：Roy Sheinfeld

來源：https://medium.com/breez-technology/the-past-present-and-future-of-offline-payments-1ddb46054e11

對(duì)閃電網(wǎng)絡(luò)，愛之深者責(zé)之切。我和 Ben Carman 都如此。在最近一篇 Stacker 帖子（中文譯本）中，Ben 將流動(dòng)性和離線支付列為閃電網(wǎng)絡(luò)最影響用戶體驗(yàn)、阻礙自主保管的方面。這似乎只是另一種 “未來怎么不像我們想的那樣” 的抱怨。我們承諾會(huì)作出會(huì)飛的汽車，但我們只得到了互聯(lián)網(wǎng)奇跡。一切都很神奇，但沒有人覺得開心。

但是，看得更仔細(xì)一些，Ben 其實(shí)說對(duì)了一些東西。我一直在討論閃電網(wǎng)絡(luò)的用戶體驗(yàn)，好幾年了，也包括離線支付的困難。我甚至在 2019 年就為離線支付問題提出了一個(gè)解決方案（我下文會(huì)解釋為什么我們從未實(shí)現(xiàn)它）。

這可能會(huì)讓人覺得，我們承諾的未來永遠(yuǎn)也不會(huì)來了，但開發(fā)閃電網(wǎng)絡(luò)就像登山。登山者自始至終看不到山頂在哪，直到他們真的到達(dá)山頂。他們甚至常常連下一段山脊在哪也看不見。計(jì)劃路線當(dāng)然很重要，但大多數(shù)時(shí)候你只能關(guān)心下一步踏在哪兒。但功夫不負(fù)有心人。就像在山頂俯瞰萬(wàn)物是對(duì)所有攀登努力的獎(jiǎng)賞，更光明的未來貨幣也將是我們一點(diǎn)一點(diǎn)打造這個(gè)網(wǎng)絡(luò)的獎(jiǎng)賞。這也是閃電網(wǎng)絡(luò)從一個(gè)想法變成一個(gè)持續(xù)運(yùn)行的比特幣支付網(wǎng)絡(luò)的原因，也是我們走向未來的方式。

- 與登山相似的另一點(diǎn)是，沒人能獨(dú)來獨(dú)往（圖源：Sylvain Mauroux） -

因?yàn)殡x線支付是一個(gè)長(zhǎng)期存在的使用體驗(yàn)挑戰(zhàn)，我們要回顧一下問題出在哪里、當(dāng)前有什么技術(shù)可以處理這個(gè)問題，以及未來還有什么可能。（我會(huì)在后續(xù)文章中討論 Ben 提出的另一個(gè)問題 —— 通道流動(dòng)性。）

問題

只體驗(yàn)過法幣、鏈上比特幣和托管式錢包可能不會(huì)意識(shí)到 “離線支付” 的困難。法幣和托管式錢包通過完全控制用戶的資金來解決這個(gè)問題。銀行/托管商 從其他用戶的 銀行/托管商 處接收 資金/借條，也在自己的用戶要求的時(shí)候發(fā)送 資金/借條。如果用戶從頭到尾都沒有真正保管過自己的資金，那他們?cè)诓辉诰€就無關(guān)緊要。只有真正控制資金的人才需要在線。至于鏈上比特幣，發(fā)送者只需要接收者的地址就可以了。

自主保管的閃電錢包面臨更大的挑戰(zhàn)，因?yàn)橐还P交易所涉及的兩方都需要同時(shí)在線。接收者需要給發(fā)送者提供一個(gè)閃電發(fā)票；發(fā)送者需要?jiǎng)?chuàng)建支付，接收者也要在線簽名確認(rèn)支付。這種安排回復(fù)了用戶對(duì)自己的錢的控制權(quán)，但也可能成為用戶體驗(yàn)中的痛點(diǎn)。

過去：試錯(cuò)階段

在 Norgay 和 Hillary 最終成功以前，有記錄的攀登珠穆朗瑪峰的嘗試共有 11 次。Breez 應(yīng)對(duì)離線支付問題的第一次嘗試叫做 “Connect to pay”，它會(huì)提醒發(fā)送者通知收款者，支付即將發(fā)送，收款者應(yīng)該把閃電錢包應(yīng)用打開。這背后的用戶體驗(yàn)理念類似于打電話：讓雙方都同時(shí)專注于同一件事情。但是，不需要操心過程就能收到支付的心理預(yù)期實(shí)在是太根深蒂固了。沒辦法，這是我們都想要的體驗(yàn)，差一點(diǎn)都不行。（人們甚至不喜歡打電話。他們編了歌曲來嘲笑它。）

我們的下一個(gè)想法要更加復(fù)雜一些，我們稱之為 “Lightning Rod”。這個(gè)想法是使用 “暫緩兌付發(fā)票”，讓發(fā)送者和接收者之間的一個(gè)路由節(jié)點(diǎn)中斷支付，直到接收者回到線上。因此，它很像 Zeus 的 Zaplocker。

雖然 Lightning Rod 可以工作，我們從未讓它進(jìn)入實(shí)際使用，因?yàn)闀壕弮陡栋l(fā)票對(duì)路由節(jié)點(diǎn)來說是不可擴(kuò)容的。他們的資金會(huì)被凍結(jié)。當(dāng)一個(gè)路由節(jié)點(diǎn)扣住一筆支付時(shí)，基本上相當(dāng)于給接收方提供一筆免息貸款。但死水必腐。通過在路由中凍結(jié)流動(dòng)性來解決異步支付問題，只會(huì)讓流動(dòng)性問題惡化。

我們遇上了一座對(duì)的山，但選擇了錯(cuò)誤的路線。

現(xiàn)狀：現(xiàn)有的提供離線支付的方法

好消息是，處理離線支付的技術(shù)在不斷進(jìn)步?，F(xiàn)有的方法中沒有一個(gè)是十全十美的，但每一種都在某個(gè)地方很有用。

LNURL-Withdraw

第一種是 “LNURL-Withdraw”。接收者可以掃描一個(gè) QR 碼或者輸入一個(gè) URL、指示自己的 app 請(qǐng)求來自一個(gè)發(fā)送者的資金。舉個(gè)例子，希望從某個(gè)交易所取出資金的用戶可以隨時(shí) “拉取” 自己的資金，而不是讓交易所 “推送” 給自己（他們可能不在線）。

這種辦法由兩個(gè)重大缺點(diǎn)。第一，它要求發(fā)送者擁有一個(gè)節(jié)點(diǎn)，運(yùn)行在一個(gè)持續(xù)在線的服務(wù)端上，所以對(duì)非托管的移動(dòng)客戶端和網(wǎng)頁(yè)客戶端來說，是不合適的。其次，“拉取” 模式僅在一種非常具體的情形中才有用 —— 你知道自己有錢可取。舉個(gè)例子，它很難用在自發(fā)的打賞中。

Breez SDK 方法：利用移動(dòng)端的通知

手機(jī)通知是另一種支持離線支付的方法。在 iOS 和 Android 系統(tǒng)中，觸發(fā)通知甚至可以給客戶端 app 足夠多的 CPU 時(shí)間來收取支付。使用手機(jī)通知來處理進(jìn)入的支付，不需要接收方主動(dòng)介入，也為這種同時(shí)性難題提供了一種自然的、不擾人的解決方案。這也是為什么我們?cè)?Breez SDK 中添加了一個(gè)新特性，使用推送通知來協(xié)助離線支付。這對(duì) SDK 的用戶來說是一種重大的用戶體驗(yàn)提升，而且只要求開發(fā)者付出少量工作。

Breez SDK 的方法是這樣工作的：首先，開發(fā)者創(chuàng)建一個(gè) webhook，互聯(lián)網(wǎng)服務(wù)商可以在一筆支付還在路由中的時(shí)候調(diào)用它。只要一筆支付將這個(gè) LSP 作為觸達(dá)接收者的最后一跳，這個(gè) LSP 就可以通過 webhook 調(diào)用一次通知分發(fā)服務(wù)（Notification Delivery Service，NDS），然后 NDS 會(huì)給用戶的手機(jī)發(fā)送一條推送通知，并且?guī)в兄噶睢＿@只需要開發(fā)者做一些跑腿工作（建立一個(gè) NDS），但結(jié)果是更好的用戶體驗(yàn)，因?yàn)橛脩舨恍枰獙?app 保持在后臺(tái)以接收支付。它也讓移動(dòng)端用戶可以使用一種靜態(tài)的地址（例如 Lightning address、LNURL-Pay 和 BOLT12）來接收支付。

手機(jī)通知是一項(xiàng)提升，但不是萬(wàn)靈丹。首先，它只能用在移動(dòng)設(shè)備上；而且，要是設(shè)備關(guān)機(jī)了，或者用戶禁用了通知，那就沒法工作。而且，谷歌和蘋果可以通過改變他們的操作系統(tǒng)處理通知的方式來削弱其作用。這就是為什么我們需要一種內(nèi)置在閃電網(wǎng)絡(luò)協(xié)議中的解決方案。

未來：在閃電網(wǎng)絡(luò)協(xié)議中開發(fā)異步支付

更高級(jí)的離線支付背后的想法很簡(jiǎn)單：讓支付變成異步的。因?yàn)橥瑫r(shí)性問題對(duì)自主保管的移動(dòng)端和網(wǎng)頁(yè)端用戶影響最大，而現(xiàn)實(shí)中幾乎所有這些用戶都會(huì)通過 LSP 連接到閃電網(wǎng)絡(luò)，那么，為什么不利用這些永遠(yuǎn)在線的 LSP、在發(fā)送者或接收者離線時(shí)同步支付呢？

LSP 可以通過攔截 HTLC，適時(shí)地分解支付流，這就消除了同時(shí)性問題，或者說，將問題轉(zhuǎn)移到了 LSP 層面 —— 對(duì)他們來說這個(gè)問題并不存在。一切將從嵌入發(fā)票中的一條消息開始：它表示接收者不在線，但連接到了一個(gè) LSP。發(fā)送者將支付以及一條消息發(fā)送給自己的 LSP，讓后者扣住它，在一段很長(zhǎng)的超時(shí)窗口內(nèi)等待進(jìn)一步的指令。然后，發(fā)送者給接收者的 LSP 發(fā)送消息，請(qǐng)求 TA 在接收方回到線上時(shí)通知自己的 LSP（即依然扣住支付的那一個(gè)）。這時(shí)候，怎么做就取決于 LSP 了。當(dāng)接收方回到線上時(shí)，他的 LSP 會(huì)給發(fā)送者的 LSP 發(fā)送信號(hào)、請(qǐng)求完成支付。

這種模式并不會(huì)犧牲網(wǎng)絡(luò)在整體上的流動(dòng)性，因?yàn)槲ㄒ粫?huì)被凍住流動(dòng)性的節(jié)點(diǎn)就只有發(fā)送者自己的 LSP，這也是用戶實(shí)際上希望的。（譯者注：一定程度上，本就使用 LSP 的發(fā)送者，因?yàn)榭赡芙?jīng)常不在線，而且只有跟 LSP 一條通道，本身就無法為網(wǎng)絡(luò)的整體流動(dòng)性作貢獻(xiàn)。）

雖然聽起來很簡(jiǎn)單，但這種辦法需要更多的技術(shù)投入才能理想工作：靜態(tài)發(fā)票、洋蔥消息、盲化路由、蹦床支付，還有 PTLC。它是復(fù)雜的，但希望深入了解的讀者可以看看我在 Honeybadger 2023 上的演講。雖然一些閃電實(shí)現(xiàn)已經(jīng)支持其中一些特性，但要讓整個(gè)網(wǎng)絡(luò)都采用它們需要時(shí)間，而采用率決定了互通性。

未來何時(shí)會(huì)來？

明天太陽(yáng)還會(huì)升起，但今天已有光明。我的意思是，我們已經(jīng) 擁有不同、可用的辦法來處理閃電網(wǎng)絡(luò)中的離線支付，而不需要犧牲保管特性，每一種都適合不同的應(yīng)用場(chǎng)景。LNURL-Withdraw 已經(jīng)可以在一些商業(yè)環(huán)境中使用了，而新的 Breez SDK 特性則為移動(dòng)端用戶啟用了離線支付。

這很酷！我們不是一直都有這些東西，但至少現(xiàn)在已經(jīng)有了。我們已經(jīng)生活在昨天的未來中！

基于協(xié)議的解決方案還在開發(fā)中。許多實(shí)現(xiàn)，比如 Eclair、LDK、lndk 和 Core Lightning 都在所需特性的開發(fā)上取得了進(jìn)展（沒錯(cuò)，我看著你呢 lnd）。一旦實(shí)現(xiàn)，異步支付就會(huì)帶來巨大的用戶體驗(yàn)提升。這是值得追求的未來。

我確信，在我們到達(dá)那里之后，又會(huì)有其它挑戰(zhàn)出現(xiàn)，需要我們的關(guān)注、挑戰(zhàn)我們的耐心，但永遠(yuǎn)不要忘記，我們已經(jīng)攀登了多高。

（完）

熱點(diǎn)：支付