作者：Roy Sheinfeld，Breez 聯合創始人兼首席執行官翻譯：善歐巴，金色財經

就像我這樣的狂熱支持者，沒有人比我們更愛批評閃電網路。我也是Ben Carman一樣的人。他在最近的一篇Stacker News文章中強調了流動性和離線支付如何阻礙閃電網路的使用者體驗，進而阻止人們進行自我託管。這似乎只是另一個抱怨，抱怨未來沒有兌現它的承諾。我們曾經被承諾會飛的汽車，最後卻只得到了網路奇蹟。一切都令人驚嘆，但沒人滿意。

然而，仔細觀察，Ben說得有道理。多年來，我一直在談論閃電網路的UX，包括離線支付的挑戰。我們甚至在2019年就提出了離線支付問題的解決方案（我將在下面解釋為什麼我們從未實施它）。

我們可能覺得所承諾的未來永遠遙不可及，但建立閃電網路就像攀登一座山。登山者只有站在山頂，才能真正看到山頂。他們甚至經常看不到下一個山脊。規劃登山很重要，但大部分時間你只是專注於下一個落腳點。但這些步驟會累積。就像登頂後的景色是所有努力的回報一樣，建立網路一步一步地，我們將迎來一個更光明的金融未來。這就是閃電網路從一個想法發展成為一個功能性比特幣支付網路的方式，這也是我們將到達目的地的方式。

由於離線支付是一個長期存在的使用者體驗挑戰，讓我回顧一下這個問題從何而來，目前有哪些技術可以解決這個問題，以及即將出現的情況。

問題

只體驗過法定貨幣、鏈上比特幣或託管錢包的人可能甚至不知道「離線支付」是一回事。法定貨幣和託管錢包透過控制用戶的資金來解決這個問題。銀行/託管人從其他用戶的銀行/託管人接收資金/欠條，並在用戶要求時發送資金/欠條。如果用戶從未真正保管過資金，那麼他們是否在線上並不重要。只有那些真正控制金錢的人才需要上網。對於鏈上比特幣，發送者只需要接收者的地址。

自我託管閃電網路更具挑戰性，因為交易雙方需要同時上線。收件者需要向寄件者發送發票，寄件者需要發起付款，收件者必須簽署。這種安排恢復了使用者對自己資金的控制權，但也可能為使用者體驗帶來痛苦。

過去：嘗試與錯誤

在諾爾蓋和希拉蕊最終成功之前，有記錄的11 次攀登珠穆朗瑪峰的嘗試。 Breez 破解離線付款的第一次嘗試稱為“Connect to Pay”，它促使發送者在付款即將完成時通知接收者，以便接收者打開他們的閃電應用程式。基本的使用者體驗理念類似於電話：讓雙方同時忙於同一件事。但無需有意識的努力即可獲得付款的能力實在是太根深蒂固了。這是我們都期望的使用者體驗，沒有什麼比這更好的了。 （人們甚至不喜歡打電話。他們唱關於它的歌。）

我們的下一個想法，我們稱之為Breez，更加複雜。這個想法是使用HODL 發票讓發送者和接收者之間的路由節點攔截付款，直到接收者可用。因此，這很像宙斯的紮普洛克的想法。

儘管Breez有效，但我們從未將其投入生產，因為HODL 發票無法針對路由節點進行擴展。他們佔用資金。當路由節點持有一筆交易時，它基本上是向接收者提供無息貸款。流動性必須流動。透過在途中凍結非同步支付來解決非同步支付問題只會加劇流動性問題。

我們在正確的山上，但走錯路線了。

現況：支持線下支付的現有手段

好消息是，技術已經發展到可以處理離線支付。現有的方法都不是完美的解決方案，因為它們都有權衡，但每種方法都有不同的用途。

LNURL-提款

第一個是LNURL-Withdraw。收件人可以掃描二維碼或輸入URL，指示其應用程式向寄件者請求資金。例如，想要從交易所提取資金的用戶可以在方便時「提取」資金，而不是在離線時由交易所推送。

這種方法有兩個主要缺點。首先，它要求發送者有一個在永久在線的伺服器上運行的節點，因此它不適合非託管行動或Web 用戶端。其次，「拉動」模型僅適用於用戶知道他們有資金可以兌換的非常具體的用例。例如，很難自發性地給某人小費。

Breez SDK 方法：利用行動通知

行動通知是支援離線支付的另一種方式。在iOS 或Android 中觸發行動通知甚至可以為客戶端應用程式提供足夠的CPU 時間來接收付款。使用行動通知來處理收款不需要接收者的積極參與，並且為同時性問題提供了自然、非侵入性的解決方案。這就是為什麼我們在Breez SDK 中加入了一項新功能，以方便使用推播通知進行離線支付。對於SDK 用戶來說，這是一個重大的使用者體驗改進，只需要開發人員做一點工作。

Breez SDK 方法的工作原理如下：首先，開發人員會建立一個Webhook，LSP 可以在付款過程中呼叫該Webhook。一旦付款到達作為收款人之前最後一跳的LSP，LSP 就會透過Webhook 呼叫通知傳送服務(NDS)，NDS 會向用戶的手機發送帶有說明的推播通知。開發人員需要以設定NDS 的形式進行一些跑腿工作，但結果是更好的用戶體驗，因為用戶不需要將應用程式保留在前台即可接收付款。它還使行動用戶能夠使用靜態地址（例如閃電地址、LNURL-Pay 或BOLT12）接收付款。

行動通知是一種改進，但不是萬能藥。顯然，它們僅適用於移動設備，如果設備關閉或用戶禁用了所需的通知，則這種方法將不起作用。此外，谷歌或蘋果可能會透過改變作業系統處理通知的方式來抵消其有效性。這就是為什麼我們需要一個內建在閃電協定中的解決方案。

未來：將非同步支付建置到閃電網路中

下一階段離線支付背後的想法很簡單：讓支付非同步。由於同時性問題對自助行動和網路用戶的影響最為嚴重，而且幾乎所有此類用戶都透過LSP 連接到閃電網絡，為什麼不利用其始終在線的LSP 在發送者或接收者離線時同步支付呢？

LSP可以透過攔截HTLC來及時分解支付流，從而消除了同時性問題，或者更確切地說，將其轉移到LSP層面，這對LSP來說沒有問題。這一切都始於發票中嵌入的一條訊息，指示收件人離線但已連接到LSP。發送方將付款連同訊息一起發送到自己的LSP，以將其保留較長的到期時間，以等待進一步的指示。然後，寄件者向收件人的LSP 發送訊息，要求其在收件人重新上線時提醒自己的LSP（仍持有付款）。此時，基本上由LSP 決定。當接收者重新上線時，他們的LSP 會向發送者的LSP 發送訊號以轉發付款。

這種模型不會損害網路的整體流動性，因為唯一可以凍結資金的節點是發送者自己的LSP，這是用戶真正想要的。

雖然表面上看起來很簡單，但要讓這種方法達到最佳效果，就需要更多技術支援：靜態發票、洋蔥訊息、盲路、中繼跳躍支付（trampoline payments），最終還有支付通道狀態更新(PTLC)。這些技術確實複雜，但如果你想深入了解，可以觀看我2023 年在Honeybadger 大會上的分享。目前一些閃電網路應用程式已經支援了部分功能，但要使其在整個網路實現互通，讓所有用戶都能享受最佳體驗，還需要一段時間。

未來何時到來？

明天太陽當然會升起，但今天已經很燦爛了。我的觀點是，我們已經有了不同的、功能性的方式來處理閃電網路上的離線支付而不放棄託管，每種方式都適合不同的用例。 LNURL-Withdraw 已經適用於一些商業環境，新的Breez SDK 功能可以實現行動裝置的離線支付。

這很酷！我們並不總是這樣，但現在我們有了。我們已經生活在昨天的未來。

基於協定的解決方案仍在進行中。許多實現，如Eclair、LDK、lndk 和Core Lightning（是的，我正在看你的lnd）正在實現這一目標所需的功能方面取得進展。一旦實施，非同步支付將帶來巨大的使用者體驗改進。這是一個值得追求的未來。

當我們到達那裡時，我確信還會有其他挑戰需要我們的關注並考驗我們的耐心，但我們永遠不要忘記我們已經攀登了多高。