乾貨| 閃電網絡深入解讀（上）：支付通道
在上一篇文章裡，我們詳細解釋了支付通道的運作，以及多種保證支付安全發生的方法。不過，這些功能，還不足以支撐一個可用的支付通道網絡：即使我們很確定在每個通道內每個參與者都是誠實守信的，也沒法保證通過多個通道來支付同樣是安全的。這就是我們需要“HTLC（哈希-時間鎖-合約）” 這種智能合約的原因。在本文中，我們會講解HTLC 工作的方式，並使用一個例子來展示多跳支付是如何在閃電網絡中實現的。
哈希時間鎖合約（HTLC）
HTLC 的結構並不復雜，但非常高效。它使我們可以創建具有明確“過期時間” 的支付。你可能也猜得到，HTLC 合約由兩部分組成：哈希驗證和過期驗證。
我們先從哈希值（hash）開始。要創建一筆帶有HTLC 的支付事務，你先要生成一個秘密數值R，然後計算出其哈希值。任何詞語、任何數字都可以充當這個秘密值，因為，對哈希函數來說，它們都是一堆數據的組合，沒有什麼分別。
H = Hash(R)
這個哈希值H 會放在事務輸出的鎖定腳本中。如此，只有知道H 所對應的秘密值的人才能使用這個輸出。而R 就是所謂的“原像（preimage）”。
HTLC 的第二部分是過期時間的驗證。如果秘密值沒有及時地公開，這筆支付就用不了了，發送者會收回所有的資金。
我們來考慮一個發給某人的HLTC 支付事務：
# 檢查所提供的R 是否為H 的原像HASH160
如果解鎖腳本所提供的R 是錯的，我們跳轉入ELSE 流程，首先驗證時間鎖解鎖了沒有。如果時間鎖已然解鎖，發送者就可以收回所有的資金。收回資金這個操作的解鎖腳本也差不多，唯一的區別在於，為了進入ELSE 流程，需要提供一個錯誤的秘密值：
當然，這只是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 來支付網費。金融智能合約和交易。金融合約對時延是極度敏感的，而且通常需要許多計算。把大多數負擔移到了區塊鏈外，我們就有機會能創建非常複雜的事務以及合約，而無需把這些都記錄到區塊鏈上。跨鏈支付。如果使用不同共識規則的區塊鏈使用同一種哈希函數，就有可能使用閃電網絡來跨鏈支付。參與者無需信任任何人，也無需使用中介。隱私。在閃電網絡中，事務比起在比特幣區塊鏈上要更加隱秘，因為支付鏈條的參與者並不知道交易的發起方和目的地。
結論
我們已經講完了閃電網絡。在下一篇文章中，我會告訴你如何使用HTLC 來執行一次跨鏈的原子互換，用btc 交換ltc。
鏈接
Lightning network in depth, part 1: Payment channels“Mastering bitcoin” — Andreas M. AntonopoulosLightning network whitepaperSegregated witness for dummies
（完）
（文內有許多超鏈接，可點擊左下”閱讀原文“ 從EthFans 網站上獲取）
原文鏈接:
https://medium.com/softblocks/lightning-network-in-depth-part-2-htlc-and-payment-routing-db46aea445a8
作者:Magomed Aliev
翻譯:
阿劍
APP 
