作者：Lorenzo
來源：https://www.voltage.cloud/blog/how-async-payments-on-lightning-network-work
原文出版於 2023 年 10 月。BOLT12 規範已經於 2024 年 9 月合併到 BOLT 。
引言
閃電網絡旨在成為一種擴大比特幣交易吞吐量的解決方案。不過，隨著我們更深地瞭解閃電網絡的細節，我們就會發現依然需要加強的部分。其中一個顯著的方面是 “異步支付” 的概念 —— 這個特性，如果能夠交付，會極大地改善支付流程和用戶體驗。
傳統的鏈上比特幣支付之所以極為簡單，就因為它有異步特性。我們用一個例子來解釋：假設 Alice 想讓 Bob 教自己彈吉他，要付錢；Alice 打開 Bob 的社交媒體個人主頁，看到 Bob 附在個人介紹中的一個比特幣地址；要發送支付給 Bob，Alice 只需複製這個地址、粘貼到自己的比特幣錢包軟件的收款方地址中，然後點擊 “發送” 按鈕，就可以了。這筆交易會在網絡中排隊，然後被比特幣網絡的區塊鏈確認。當 Bob 打開自己的錢包軟件時，就會發現多了一筆錢，來自 Alice 。
但是，如果 Alice 要通過閃電網絡給 Bob 支付，用戶體驗就不同了。在支付的時候，發送方和接收方都必須在線、交換信息。
雖然不能說絕對完美，但這裡的差別，為我們解釋閃電網絡中的同步支付和異步支付，打下了基礎。
閃電網絡支付概述
為了理解異步支付的概念，先理解支付在閃電網絡中如何實現，是很有幫助的。
在閃電網絡中，如果 Alice 要給 Bob 發送支付，她必須先跟 Bob 請求一張發票。這意味著 Bob 必須主動打開自己的閃電錢包、為 Alice 的支付生成一張發票。跟傳統的比特幣地址不同，閃電網絡發票是一次性的。多次支付同一張發票可能會讓發送者丟失資金。
（譯者注：儘管比特幣地址可以複用，但地址複用是個壞習慣，會損害地址主人的隱私性；重複支付發票會給發送者帶來風險，是因為在一次支付完成後，確保該支付安全性的哈希原像就已暴露，不是收款方的中間節點也可能領取第二次支付；也正因此，複用發票對收款方來說也不安全。）
在獲得 Bob 的發票之後，Alice 使用自己的閃電錢包，根據發票中的信息發送支付。在背後，她的支付穿越了一連串的閃電通道，直至到達 Bob 的節點（由 Bob 的閃電錢包控制）。收到支付後，Bob 的節點要回傳一條收據。這條收據保證了每個中間節點都能得到手續費，並且 Alice 也能得到保證：支付已經成功。如果（在支付送達的時候） Bob 的節點離線了（沒有回傳收據），這筆支付就懸在半空、無法完成。雖然閃電網絡協議保證了沒有人會遭遇資金損失，但也帶來一個用戶體驗挑戰，因為要保證連續在線的狀態，是很難做到的，尤其是在移動設備上。
總而言之，閃電網絡支付面臨兩個同步性障礙：
- 接收方必須應邀生成發票；
- 在支付方發送支付時，接收方必須在線。
處理異步支付
異步支付的效果
在閃電網絡內實現異步支付，意味著即使接收方不在線，支付也能發起。一箇中間節點會安全地扣住支付，並僅在接收方重新連接到網絡、能夠接收支付時送達。
簡單方法
乍看起來，讓閃電支付變成異步，是很容易的。發票交互問題可以通過讓 Bob 的節點提前生成許多發票、存放在第三方服務端、服務端響應請求交付發票來解決。而支付確認問題可以通過讓支付轉發路徑的最後一個節點暫時扣住支付、等待 Bob 節點上線來解決。
然而，這些方法有許多問題。最明顯的一個問題是，這會在一個設計目標是免信任的支付系統中引入信任。接收方必須信任自己的發票 “保管者” 會提供誠實的服務。另一個問題是，發票會過期。最後，因為支付懸在半空，整條支付轉發路徑上的所有節點，都必須鎖住一部分的流動性，直到 Bob 回到線上或者發票過期。這是壞的效果，因為轉發節點需要高效運營自己的流動性，而讓自己的流動性鎖定不確定的時間是低效的。
我們可以做得更好嗎？
回到 2021 年，Matt Corallo 提出，一項妥協可以提升異步支付。這需要使用 “LNURL”，然後發送者和接收者都需要使用閃電網絡服務商（LSP）。他建議使用 LNURL 以異步地生成發票。這些發票可以攜帶一個標籤，來提醒發送者，接收者連接到了某個 LSP，但當前並不在線。然後，發送者發送一筆帶有很長超時時間的支付指令給自己的 LSP，要求 TA 扣住支付，直至收到某一條信息。
這個收到支付的 LSP 並不立即轉發支付，從而，為這筆未完成的支付而 “鎖定” 的資金就只有發送者自己的資金。然後，發送者讓接收者的 LSP 在接收方回到線上時，給自己的 LSP 發送消息。然後，發送者就可以安全地下線。當接收者回到線上，TA 的 LSP 就發送消息給支付方的 LSP，觸發支付的轉發。
使用這種策略，在任何時間都不需要第三方託管。這意味著資金不可能被盜；而且技術上來說，LSP 也不能被定義為監管意義上的託管商。而且，一旦 BOLT 12 規範完成，它就可以替代 LNURL 。這將使異步支付更少依賴於外部服務端（而 LNURL 會依賴）。
LNURL 方法的問題在於，用戶依然需要信任第三方來提供發票。不能保證這些服務供應商不會複用發票，從而允許 LSP 盜竊資金。改善這一點的一種辦法是使用 PTLC 。這樣一來，發送者和 LNURL 服務商必須合謀，才能竊取資金。但發送者沒有理由做這樣的事。
雖然在信任關係上沒有一種解決方案是完美的，但相比上面的簡單方法，這些都是更好的處理方法。Matt 的建議依賴於對 LNURL 服務商的信任，而且支付已然過期，就像簡單方法一樣。
結論
在嘗試讓比特幣支付更快捷、更高效的競賽中，閃電網絡已顯現出自己是佼佼者。不過，雖然有此潛能，當前閃電支付的同步特性，彰顯了用戶體驗上的差距。
傳統的比特幣支付簡單又靈活，支付的發送方和接收方無需同時聯網。相反，閃電支付需要雙方同時在線，產生了潛在的使用障礙。
粗疏的解決方案，比如依賴第三方發票保管商和節點暫緩轉發策略，會在一個致力於免信任性的系統中引入信任。Matt Corallo 在 2021 年提出的建議，利用了 LNURL 和閃電網絡服務商，提供了一個有前景的基礎。它儘可能減少了鎖定的流動性、趕走了第三方託管商，而且有望跟即將到來的 BOLT12 規範相配合。不過，與 LNURL 有關的信任問題依然讓人顧慮。PTLC 這樣的創新會增加額外的安全性。
在閃電網絡中實現異步支付的冒險已經開始，各種擬議的解決方案都讓我們越加接近無縫而且免信任的支付體驗。
（完）
