理解閃電網絡：如何構建閃電網絡？什麼是哈希時間鎖？

閱讀本文需 7 分鐘

本文繼《理解閃電網絡：構建比特幣的雙向支付通道》後繼續闡釋閃電網絡如何是構建的。

原文來源：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（相對時間鎖）。

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