乾貨 | 閃電網絡深入解讀（下）：HTLC 與支付路由

在上一篇文章里，我們詳細解釋了支付通道的運作，以及多種保證支付安全發生的方法。不過，這些功能，還不足以支撐一個可用的支付通道網絡：即使我們很確定在每個通道內每個參與者都是誠實守信的，也沒法保證通過多個通道來支付同樣是安全的。這就是我們需要 “HTLC（哈希-時間鎖-合約）” 這種智能合約的原因。在本文中，我們會講解 HTLC 工作的方式，並使用一個例子來展示多跳支付是如何在閃電網絡中實現的。

哈希時間鎖合約（HTLC）

HTLC 的結構並不複雜，但非常高效。它使我們可以創建具有明確 “過期時間” 的支付。你可能也猜得到，HTLC 合約由兩部分組成：哈希驗證和過期驗證。

我們先從哈希值（hash）開始。要創建一筆帶有 HTLC 的支付事務，你先要生成一個 秘密數值 R，然後計算出其哈希值。任何詞語、任何數字都可以充當這個秘密值，因為，對哈希函數來說，它們都是一堆數據的組合，沒有什麼分別。

1 H = Hash(R)

這個哈希值 H 會放在事務輸出的鎖定腳本中。如此，只有知道 H 所對應的秘密值的人才能使用這個輸出。而 R 就是所謂的 “原像（preimage）”。

HTLC 的第二部分是過期時間的驗證。如果秘密值沒有及時地公開，這筆支付就用不了了，發送者會收回所有的資金。

我們來考慮一個發給某人的 HLTC 支付事務：

在正確的 R（哈希值 H 的原像）公開之後，我們進入 IF 流程，進一步驗證提供 R 的是不是這筆

1 <sig> <secret R>

如果解鎖腳本所提供的 R 是錯的，我們跳轉入 ELSE 流程，首先驗證時間鎖解鎖了沒有。如果時間鎖已然解鎖，發送者就可以收回所有的資金。收回資金這個操作的解鎖腳本也差不多，唯一的區別在於，為了進入 ELSE 流程，需要提供一個錯誤的秘密值：

1 <sig> <wrong secret>

當然，這只是 HTLC 的一個非常基礎的實現，代表着一個普通的時間鎖支付。你可以在腳本中加入任意多的其它條件，比如說，在 IF 流程中移除公鑰驗證，這樣只要知道秘密值 R 的人都可以使用這個輸出；也可以在其中加入多簽名限制，要求提供多個預設私鑰的簽名才能解鎖。

多說一句，在這個案例中，我們使用的操作碼是 CHECKLOCKTIMEVERIFY，這個操作碼使用絕對數值來定義時間鎖，意思就像：“這個輸出在區塊 #546212 之前是無法動用的”。而在閃電網絡中，還用上了另一種時間鎖，更 “靈活” 的一種：CHECKSEQUENCEVERIFY，它用到的是相對數值，意思近於：“這個輸出，在使用它的事務上鏈之後的 1000 個區塊內，是無法使用的”（譯者註：這裡的數值都是例子，實踐中當然可以使用別的數值）。

閃電網絡案例

現在，我們終於講解完所有元素了，可以嘗試理解閃電網絡運作的全景了。

我們假設現在閃電網絡有 5 個參與者：Alice、Bob、Carol、Diana 和 Eric，他們各自有一個支付通道相連，而每個通道的每一邊都有 2 btc 的餘額可用。現在，我們嘗試讓 Alice 通過通道鏈條給 Eric 支付。

– 一系列相連的雙向支付通道，組成了閃電網絡，可以轉介 Alice 對 Eric 的支付 –

假設 Alice 現在要給 Eric 支付 1 btc。但是，如我們所見，他們並無直接的通道相連，而開設通道需要時間和金錢。幸運的是，Alice 連接着閃電網絡，可以在一系列 HTLC 合約的幫助下完成間接支付。我們一步一步拆開來看。

– 逐步分解閃電網絡中的支付路由 –

Eric 生成了一個秘密值 R，並把其哈希值發給了 Alice（他不會把 R 展示給其他人）
Alice 使用這條哈希值創建了一個 HTLC，而時間鎖設置成未來 10 個區塊，輸出的數額是 1.003 btc。這額外的 0.003 btc 是給支付通道鏈條中間方的手續費。那麼，Alice 現在用 HTLC 鎖住了 1.003 btc，而 HTCL 的具體條件以大白話表述如下：“Alice 會給 Bob 支付 1.003 btc，只要他能在 10 個區塊內交出秘密值 R，否則這些錢會返回給 Alice”。他們之間的通道的餘額也會因為這筆承諾事務而發生這般變化，現在 Bob 在通道內擁有 2 btc，Alice 有 0.997 btc，還有 1.003 btc 鎖在 HTLC 裡面
到了 Bob 這裡，他可以隨意處置 Alice 的承諾事務（這筆 HTLC 事務是通過他們之間的通道來發送的）。他在自己跟 Carol 的通道中創建了一個 HTLC 輸出，數額是 1.002，時間鎖設定為 9 個區塊，使用了跟 Alice 所提供的同樣的哈希值。Bob 知道 Carol 如果想獲得這筆錢，就不得不找出秘密數值 R 來解鎖這個 HTLC，而一旦她這麼做了，他就會知道這個 R，因此也能解鎖 Alice 的 HTLC，拿到 1.003 btc。如果 Carol 沒法找到這個秘密值 R，Bob 和 Alice 都能在時間鎖解鎖后拿回自己的錢。注意，Bob 發送的資金數額比自己能夠得到的數額小 0.001 btc，這就是他收取的手續費數額。Bob 和 Carol 在通道內的餘額變成：Carol 擁有 2btc， Bob 擁有 0.998 btc，還有 1.002 btc 鎖在 HTLC 中
Carol 獲得 Bob 發出的承諾事務之後，也如法炮製，在與 Diana 的通道中創建一個 HTLC，使用的哈希值與 Bob 提供的無二，時間鎖設置為 8 個區塊，數額為 1.001 btc。如果 Diana 能在 8 個區塊以內揭示這個秘密數值 R，就能解鎖這個 HTLC，獲得 1.001 btc，相應地，Carol 也會知道這個秘密數值，解鎖 Bob 給她的 HTLC，獲得 1.002 btc，賺得 0.001 btc。Carol 和 Diana 通道內的餘額變成：Diana 擁有 2btc、Carol 擁有 0.999 btc，還有1.001 btc 鎖在 HTLC 裡面
最終，當 Diana 將一個 HTLC（使用同一個哈希值作為鎖）通過通道發送給 Eric 時，她把數值設為 1 btc，時間鎖設為 7 個區塊。Diana 和 Eric 的通道內餘額變成：Eric 擁有 2btc、Diana 擁有 1 btc，還有1 btc 鎖在 HTLC 裡面
現在，我們來到了這個連鎖支付的終點。Eric 擁有這個秘密值 R，這個 R 的哈希值用在了所有的 HTLC 承諾事務中。Eric 可以解鎖 Diana 發給他的 HTLC，獲得 1 btc；而 Eric 取回資金之後，Diana 也會知道這個 R。Diana 與 Eric 的通道內餘額會變成：Eric 擁有 3 btc，Diana 擁有 1 btc。
Diana 收到這個秘密之後，也拿來解鎖 Carol 發給她的 HTLC，獲得 1.001 btc 的同時也向 Carol 公開了秘密值。他們通道內的餘額變成了：Diana 擁有 3.001 btc，Carol 擁有 0.999 btc。
Carol 收到秘密值 R 之後，解鎖了 Bob 發過來的 1.001 btc，因此 Bob 也知道了這個秘密值。他們通道內的餘額變成了：Carol 擁有 3.002 btc 和 Bob 擁有 0.998 btc
最後，Bob 使用秘密值 R 獲得了和 Alice 通道中的 1.003 btc。於是通道內的餘額變成了：Bob 擁有 3.003 btc，Alice 擁有 0.997。

這樣一個流程下來，Alice 就給 Eric 支付了 1 btc，無需在彼此間另開一個直接相連的通道。整個支付鏈條中，也沒有人需要信任另一個人，而且他們還因為中介服務賺到了 0.001 btc。即使支付在某個環節卡住了，也沒有人會遭受損失，因為資金還鎖在那裡，時間過了就可以取回。

清除故障

在我們這個例子中，整個流程都是很平滑、沒有阻礙的，但在現實生活就像所謂的 “墨菲定律”：如果某種壞事可能發生，那這種壞事就一定會發生。於是我們要考慮閃電網絡的 “保護” 機制。

從實踐來看，支付鏈條越長，最終無法交付資金的概率就越大：某些參與者可能會關閉通道，或者某些節點會掉線。我們來考慮兩種可能的出錯情形。

通道故障

先考慮一種情形：我們假設資金已經達到了目的地，但在秘密數值一路返回到支付起點的過程中，某個參與者拒絕合作或者無法配合。假設是 Bob。

– 因為一個通道關閉，資金無法交付 –

當 Diana 收到了秘密值時，就立即取回了資金，並把秘密值暴露給了 Carol。Carol 也想從 Bob 發出的 HTLC 裡面拿回資金，但 Bob 沒有響應，為了避免風險，她關閉了通道，將自己手上的最後一筆承諾事務（也即 Bob 之前發出的、帶有 HTCL 輸出的事務）廣播到了比特幣網絡中，而且，因為她知道秘密值，所以能取回資金。此時，Bob 還有三天時間可以從 Alice 處拿回自己的錢（因為 Carol 的事務已經上鏈，Bob 可以很容易地知道 R 的數值）。否則，等時間鎖一解鎖，Alice 就可以收回資金。

可以看出，即使某個參與者因為某種原因離開了網絡，TA 自己是唯一一個可能損失資金的人，而其他人的資金都是安全的。

重新路由

在第二種情形中，我們假設資金無法到達目的地，也是因為某個參與者出了錯。假設是 Carol。

第一種也是最明顯的解決方法是，等待 HTLC 的時間鎖過期，然後各參議者各自拿回自己的資金。

– 支付路徑中的某個節點沒有響應 –

但如果 Alice 就是着急支付，該怎麼辦呢？當然，Alice 可以通過另一條路徑發起新的支付，不需要死等資金返回，但要是 Carol 突然之間又回來了，跟 Bob 把鏈條續上了呢？那 Alice 不就發送了兩倍資金了嗎？

– Alice 如果使用另一條路徑 –

這是否意味着，但凡出現了支付失敗的情形，都應該乖乖等時間鎖超時，然後再發起新的一筆支付呢？

好在，要避免這種等待，我們可以 “取消” 這一次的支付。Diana（收款方）要發送等量的一筆資金給 Alice，也使用跟原來一樣的哈希值，也可以使用另一條路徑。現在，如果 Carol 重新上線並參與中介，那麼資金會走完一個環路，這就意味着那筆原來失敗的支付被抵消了，Alice 可以安全地使用另一個路徑來支付了。

– Alice “取消” 了舊的支付，新的支付現在可以安全地發送了 –

支付數額

你可以也注意到了，當 Alice “取消” 其第一筆支付時，現在的確是可以安全地發起新的一次支付了，但這並沒有改變一個事實：她的第一筆支付的資金現在仍然是鎖定的，而她可能沒有足夠的錢來發起第二次支付了。這就是為什麼在使用閃電網絡時，用 HTLC 來支付時資金額度應該更小。因為承諾事務不會上鏈，數額可以分割成多個很小的額度。這樣，無論什麼時候一個路徑不通了，都只有一小部分資金會被凍結（就是最後發送的那一筆）。

傳輸協議

閃電網絡的另一個非常重要的特點是：有關這個路徑的所有信息都是完全匿名的。也就意味着對於任何一個參與者來說，TA 都只知道跟自己有關的這部分，比如，對於 Carol 來說，這筆支付就像是 Bob 在給 Diana 轉賬，她不知道 Bob 會從 Alice 處收到資金，也不知道 Diana 會繼續轉賬給 Eric。

閃電網絡使用 Sphinx 多重加密協議。在使用閃電網絡時，Alice 會為網絡的每一部分都做一層加密，從支付路徑的末端開始。她使用 Eric 的公鑰為 Eric 加密了消息。這條加密消息會被嵌套在給 Diana 的消息里，並用 Diana的公鑰對整個消息再做一次加密。再然後，這條給 Diana 的消息又會嵌套在給 Carol 的消息里，也用 Carol 的公鑰對整個消息再做一次加密。如此不斷重複，得出可以交給下一個人的消息。這樣一來，Bob 只能解密消息的最外一層，得到本意發給他的內容；然後把消息轉給 Carol；Carol 也是如此。每經過一個人，都只會公開絕對必要的消息：支付的數額、傭金的數額、時間鎖的內容，等等。

為了讓人不能從消息的長度中推測鏈條的長度，消息的長度都是一樣的，總是像有 20 個人參與這個鏈條一樣。每個人，包括最後一個，得到的都是同樣大小的圖像，都以為除了自己以外還有 20 個夥伴。

閃電網絡的好處和應用場景

當然，閃電網絡的好處並不像很多人以為的那樣，只有可擴展性一項。我們想想閃電網絡到底帶來了哪些可能。

即時交易。使用閃電網絡時，事務幾乎是即時完成的。所以用比特幣來買咖啡就變得可行了
交易所套利。當前，從一個交易所轉出資金並轉入另一個交易所是很不方便的，需要等待 3 至 6 個區塊來確認交易。如果交易所能使用閃電網絡，那用戶就能即時轉入資金、參與套利。交易所也不再需要冷錢包來存儲資金，極大地降低了盜竊風險。
小額支付。比特幣區塊鏈的手續費對小額支付來說太高了。很難想象誰會願意支付 0.001 btc 就為了轉賬同等數量乃至更少的金額。有了閃電網絡，你就可以即時轉移任意大小的金額，舉個例子，你可以按 MB 來支付網費。
金融智能合約和交易。金融合約對時延是極度敏感的，而且通常需要許多計算。把大多數負擔移到了區塊鏈外，我們就有機會能創建非常複雜的事務以及合約，而無需把這些都記錄到區塊鏈上。
跨鏈支付。如果使用不同共識規則的區塊鏈使用同一種哈希函數，就有可能使用閃電網絡來跨鏈支付。參與者無需信任任何人，也無需使用中介。
隱私。在閃電網絡中，事務比起在比特幣區塊鏈上要更加隱秘，因為支付鏈條的參與者並不知道交易的發起方和目的地。