圖片
圖片
圖片
在上一篇文章裡，我們詳細解釋了支付通道的運作，以及多種保證支付安全發生的方法。不過，這些功能，還不足以支撐一個可用的支付通道網絡：即使我們很確定在每個通道內每個參與者都是誠實守信的，也沒法保證通過多個通道來支付同樣是安全的。這就是我們需要“HTLC（哈希-時間鎖-合約）” 這種智能合約的原因。在本文中，我們會講解HTLC 工作的方式，並使用一個例子來展示多跳支付是如何在閃電網絡中實現的。
H = Hash(R)
哈希時間鎖合約（HTLC）
HTLC 的結構並不復雜，但非常高效。它使我們可以創建具有明確“過期時間” 的支付。你可能也猜得到，HTLC 合約由兩部分組成：哈希驗證和過期驗證。
我們先從哈希值（hash）開始。要創建一筆帶有HTLC 的支付事務，你先要生成一個秘密數值R，然後計算出其哈希值。任何詞語、任何數字都可以充當這個秘密值，因為，對哈希函數來說，它們都是一堆數據的組合，沒有什麼分別。
# 檢查公開R 的人是否為事務最初的接收者
這個哈希值H 會放在事務輸出的鎖定腳本中。如此，只有知道H 所對應的秘密值的人才能使用這個輸出。而R 就是所謂的“原像（preimage）”。
HASH160
EQUAL IF
HTLC 的第二部分是過期時間的驗證。如果秘密值沒有及時地公開，這筆支付就用不了了，發送者會收回所有的資金。
CHECKSIG ELSE
我們來考慮一個發給某人的HLTC 支付事務：
CHECKLOCKTIMEVERIFY # 檢查所提供的R 是否為H 的原像
CHECKSIG ENDIF
# 檢查時間鎖是否已終止
# 檢查請求返回資金的是不是事務最初的發送者
在正確的R（哈希值H 的原像）公開之後，我們進入IF 流程，進一步驗證提供R 的是不是這筆支付事務一開始的支付對象。在花費這個輸出時，接收方只需提供一個非常簡單的解鎖腳本：CHECKLOCKTIMEVERIFY如果解鎖腳本所提供的R 是錯的，我們跳轉入ELSE 流程，首先驗證時間鎖解鎖了沒有。如果時間鎖已然解鎖，發送者就可以收回所有的資金。收回資金這個操作的解鎖腳本也差不多，唯一的區別在於，為了進入ELSE 流程，需要提供一個錯誤的秘密值：CHECKSEQUENCEVERIFY當然，這只是HTLC 的一個非常基礎的實現，代表著一個普通的時間鎖支付。你可以在腳本中加入任意多的其它條件，比如說，在IF 流程中移除公鑰驗證，這樣只要知道秘密值R 的人都可以使用這個輸出；也可以在其中加入多簽名限制，要求提供多個預設私鑰的簽名才能解鎖。
多說一句，在這個案例中，我們使用的操作碼是
圖片
圖片
圖片描述
圖片
圖片描述
圖片描述
圖片描述
- 逐步分解閃電網絡中的支付路由 -
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。
最後，Bob 使用秘密值R 獲得了和Alice 通道中的1.003 btc。於是通道內的餘額變成了：Bob 擁有3.003 btc，Alice 擁有0.997。
清除故障
這樣一個流程下來，Alice 就給Eric 支付了1 btc，無需在彼此間另開一個直接相連的通道。整個支付鏈條中，也沒有人需要信任另一個人，而且他們還因為中介服務賺到了0.001 btc。即使支付在某個環節卡住了，也沒有人會遭受損失，因為資金還鎖在那裡，時間過了就可以取回。
圖片
圖片
圖片描述
圖片描述
圖片描述
圖片
重新路由
圖片
圖片描述
圖片
圖片描述
圖片
圖片
圖片描述
圖片描述
圖片描述
- 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 個區塊來確認交易。如果交易所能使用閃電網絡，那用戶就能即時轉入資金、參與套利。交易所也不再需要冷錢包來存儲資金，極大地降低了盜竊風險。
鏈接
結論
（完）
鏈接
Lightning network in depth, part 1: Payment channels
“Mastering bitcoin” — Andreas M. Antonopoulos
Lightning network whitepaper
Segregated witness for dummies
（完）
原文鏈接:
https://medium.com/softblocks/lightning-network-in-depth-part-2-htlc-and-payment-routing-db46aea445a8
原文鏈接:
翻譯: 阿劍
