理解閃電網路：如何構建閃電網路？什麼是雜湊時間鎖？

免責宣告：本文旨在傳遞更多市場資訊，不構成任何投資建議。文章僅代表作者觀點，不代表火星財經官方立場。

小編：記得關注哦

原文標題：《科普 | 理解閃電網路，Part-2：構建網路》

原文來源：Bitcoin Magazine

原文作者: AARON VAN WIRDUM

原文編譯: 閔敏 & 阿劍

在上一篇文章中，Alice 和 Bob 建立了一個雙向的支付通道。現在，Alice 想要給一個第三方 Carol 支付 1 btc。

一般來說，Alice 和 Carol 需要在彼此之間開設一個支付通道。但實際上並不需要。因為 Bob 和 Carol 之間已經有了一個通道，所以 Alice 可以透過 Bob 給 Carol 支付。

具體來說，Alice 可以給 Bob 支付 1 btc，而 Bob 再支付 1 btc 給 Carol。

但是，Alice 實際上並不信任 Bob，或者 Carol 並不信任 Bob。她擔心把錢給 Bob 之後，Bob 不會給 Carol；又或者，他把錢給了 Carol，但 Carol 謊稱自己壓根沒見到錢，而 Alice 也不知道該找哪個來追責。

因此，Alice 希望能保證，僅當 Bob 給了 Carol 1 btc，自己才需要給 Bob 支付 1 btc。

當 Alice 要給 Carol 支付 1 btc 時，她讓 Carol 先生成一個秘密值（一個隨機的數字串）並把對應的雜湊值發給她。Alice 也告訴 Carol 可以用這個秘密值跟 Bob 交換 1 btc。

與此同時，Alice 把從 Carol 處得到的雜湊值發給 Bob，並告訴 Bob 如果 Bob 能提供對應於這個雜湊值的原始值，她就會給 Bob 1 btc（這個原始值當然只有 Carol 擁有）。

所以 Bob 找到 Carol，用 1 btc 換來了 Carol 的初始值。

然後，Bob 找回 Alice，提供這個初始值。Alice 因此知道了 Bob 一定給過錢了，也就是 Carol 肯定已經收到了 1 btc，於是就把錢給了 Bob。

皆大歡喜。

幾乎，啊，幾乎是皆大歡喜。

在這種「過家家」的情形下，中間人 Bob 還是需要新人 Alice 和 Carol。Bob 必須相信 Carol 給他的是一個真正有用的值（不然錢都給了就拿不回來了），而且要相信 Alice 真的會給他 1 btc，假如他能提供對應於雜湊值的原像的話。

這時候，我們就需要雜湊時間鎖合約（HTLC）啦。

雜湊時間鎖合約

雜湊時間鎖可以讓 Alice 和 Bob 用秘密值來交換 btc（當然 Bob 和 Carol 也需要這個，但我們先按下不提）。

為了使用雜湊時間鎖，Alice 要將 1 btc 傳送至一個新的多籤地址，而非直接傳送給 Bob。這個地址中鎖定的 btc 可以透過兩種方式解鎖。

第一種方式是 Bob 將自己的簽名和秘密值一起傳送至該地址。

第二種方式是 Alice 將自己的簽名傳送至該地址。但是，這個方式存在 CLTV 時間鎖限制：Alice 必須等待一段時間（例如兩週）才能簽署並廣播交易取走這個 btc。

也就是說，Bob 有兩週時間來建立一個包含簽名和秘密值的交易，並廣播該交易，將多籤地址上的 btc 傳送給自己。這樣一來，這筆交易就有了保證。只要 Bob 能提供秘密值，他就能取走 Alice 的 btc：在比特幣網路公開廣播該交易可以讓 Alice 看到它。

如果 Bob 沒有在規定時限內提供秘密值，Alice 就可以取回她的 btc。就這麼簡單。

再說回網路，因為這是雜湊時間鎖合約真正發揮作用的地方。

如上文所述，不僅 Alice 和 Bob 之間有雜湊時間鎖合約，Bob 和 Carol 之間也有。因此，如果 Carol 向 Bob 索要 btc，Bob 也可以從 Carol 那裡取得秘密值。這些在區塊鏈上都是可見的。

因此，如果發生這種情況，Bob 也一定可以從 Alice 那裡拿到 1 btc。Bob 可以將從 Carol 那裡拿到的秘密值在鏈上公開，傳送至他與 Alice 的雜湊時間鎖合約，然後取走多籤地址上的 1 btc。這兩個狀態通道有效地關聯了起來。

最後要強調的一點是，Bob 必須在有效期內從 Carol 那裡拿到秘密值，否則 Alice 就有可能取回多籤地址上的 1 btc。如果等 Alice 取回 1 btc 之後 Bob 才從 Carol 那裡拿到了秘密值，Bob 就會被卡在中間進退兩難。因此，Bob 和 Carol 的雜湊時間鎖合約必須比 Alice 和 Bob 的先到期（例如，前者的時限可以設成 10 天，而非兩週）。這就是為什麼雜湊時間鎖合約需要 CheckLockTimeVerify（絕對時間鎖）而非 CheckSequenceVerify（相對時間鎖）。

最後還有一個問題需要解決：要保證閃電網路的可用性，所有這些必須在鏈下完成。具體是如何實現的將在本系列第三篇文章中揭曉。