閃電網路（Lightning Network）是什麼？
閃電網路是比特幣最具討論度的 Layer 2 擴容方案之一，其背後的主要思想是設計一種支付協議，可用於比特幣所面臨可擴展性問題的鏈下解決方案。究竟比特幣面對的問題是什麼？閃電網路又要解決什麼問題?這邊用一個輕鬆的例子，簡單介紹。
以比特幣的交易速度來說，每秒只能處理2~7筆交易，想像一下用比特幣進行支付，就像需要去銀行排隊轉帳一樣，一但交易量暴增，豈不是要在銀行等到白了頭？這種支付方式明顯難以接受。
而閃電網路就像行動支付，你可以把一部分的錢存到行動支付，與任何支援的商家或個人快速地進行轉帳。某一天夜深人靜，阿平跟阿菜兩人無聊，決定比賽，用行動支付互相轉帳，每筆只轉一塊錢，看誰轉的比較多。如果是傳統的銀行模式，兩人可能排隊排一夜只能玩個幾次，還需要花手續費，根本沒辦法玩。透過行動支付一個晚上下來可以轉上千次，最終結果是阿菜比阿平手速快，一塊險勝。
而結算時行動支付會替他們去銀行排隊，然後跟櫃台說 : 「阿平帳戶餘額 -1，阿菜帳戶餘額 +1」。讀到這就能大致了解閃電網路解決方案的基本邏輯了。
重點來了，「閃電網路」要如何運作才能保證資產能夠在無信任的前提之下進行交易，並保障交易能夠安全的回到比特幣主鏈上確認呢？以下就來介紹幾項閃電網路的關鍵技術的概念。
閃電網路之前：單向支付渠道 (One-Directional Payment Channel)
在閃電網絡出現之前，單向支付渠道的概念已經存在了一段時間了，但應用有限。Alice 向 Bob 開啟了一個單向支付渠道，在這渠道中 Alice 有 10 BTC，Alice 可以向 Bob 支付鏈下交易，但這個渠道是單向的，也就是說 Bob不能通過相同的渠道支付給 Alice。
假如 Bob 在接收到 1 顆比特幣後：
- 可以選擇關閉渠道，將交易廣播至主鏈，讓礦工做確認，即可從 Alice 那獲得 1 顆比特幣。
- 或者，Bob 知道日後 Alice 會繼續支付比特幣給他，選擇讓通道繼續開著。
問題來了，Bob 擁有最後的簽名與廣播權，如果 Bob 是個無賴，讓通道一直開著，Alice 就永遠沒辦法結算，10 BTC 就會被被綁架在這個支付渠道中。所以一般而言，支付渠道都會搭配一個配套措施「時間鎖」。
時間鎖 CheckSequenceVerify（CSV）
所謂的時間鎖就是，在創建通道時會先約定好一個時間，時間一到，通道就必須強制關閉，有兩人簽名的交易將會上鏈做交易確認，沒有簽名的餘額，會被返回給原持有人。
Alice 和 Bob 在創建時，約定好在 1000 個區塊後，通道必須關閉。所以 Bob 必須要在時間到之前，簽名並廣播交易，才能拿到 Alice 給他的 1 顆比特幣。如果 Bob 遲遲不簽名廣播，一但約定時間到，Bob 將一毛錢也拿不到。
閃電網路：雙向支付渠道 (Bi-Directional Payment Channel)
單向支付渠道之所以簡單，是因為交易是單向的，只允許兩個人中的其中一個人發送交易，另一個人廣播交易，不會有信任問題，但應用場景相對有限。
有鑑於單向渠道在應用上的不足，閃電網路想要打造的是無信任的雙向支付渠道，讓渠道的雙方能夠自由進行交易。那麼閃電網路要如何避免交易雙方產生信任問題，實現雙向支付渠道呢？
所謂的信任問題包括：
- 雙向支付渠道代表雙方都必須有部分資金在渠道，那資產會不會被捲款?
- 如何保證最終結算不會有誤？
- 支付渠道是 P2P 網路，沒有驗證機制，誰來保護帳本？
RSMC 可撤銷順序成熟度合約 (Revocable Sequence Maturity Contract)
RSMC 其實就是資金池，打開支付渠道時，雙方將資產放入這個資金池中，封起來各自用一把鑰匙鎖上，交易時不會真的動用到該筆資金，而是用合約的方式紀錄兩人在資金池裡的剩餘資產，等到關閉通道時，才會打開這個資金池做結算。
雙向支付通道如何運作？
從頭到尾，涉及的雙方只需要與比特幣區塊鏈進行兩次互動。一次打開支付渠道而另一次是關閉渠道，在這之間發生的所有其他交易都不直接與主鏈接觸，這意味著，只有在雙方都同意並簽名的狀態下，交易才會被確認。
假設 Alice 和 Bob 打算頻繁進行交易，雙方同意開闢雙向支付通道，並約定好在 1000 個區塊後強制結算。Alice 和 Bob 必須先在鏈上開啟一個多重簽名錢包，才能開闢雙向支付通道。
此時雙方會各自生成一組 Secret Key (鑰匙) 以及 Hash (鎖頭)，Hash 會交給對方，Secret Key 自行保管。在開闢雙向支付渠道後，Alice 和 Bob 每次支付都像簽一次合約，在簽新合約之前會廢棄掉舊合約，要注意的是當舊合約作廢的同時彼此將取得對方舊合約的 Secret Key，而合約的內容就是關於如何重新分配資金池的資產。
共同簽名錢包裡的錢只能在三個條件下解鎖：
- 鎖定時間到了
- 任何一方通過對方的 Secret Key 從他們設置的多重簽名錢包中解鎖資金
- 合約有雙方簽名，且其中一方廣播
要注意的是，如果一方決定關閉支付渠道並廣播交易，廣播的那一方將不得不等待到交易簽名時設置的預定時間到，才能收到他那部分的資金。
閃電網路會不會有人作惡？
例如：閃電網路中的其中一位參與者廣播對於自己有利的舊合約來進一步圖利，而非依照正常程序廣播最新的合約。
此時，上述的兩個值得注意的點就派上用場
- 當舊合約作廢的同時彼此將取得對方舊合約的 Secret Key
- 如果一方決定關閉支付渠道並廣播交易，廣播的那一方將不得不等待到交易簽名時設置的預定時間才能收到他那部分的資金
假如 Alice 企圖廣播舊合約惡意結算關閉通道，依照上述閃電網路的機制，Bob 與 Alice 都擁有對方舊合約的 secret key，且 Alice 必須等到預定的時間到，才能拿到舊合約中 Alice 的那份 BTC，所以 Alice 只要廣播舊合約，Bob 即可在 Alice 等待的時間中使用舊合約的 secret key 將 Alice 的那份 BTC 取走，這樣一來 Alice 不但沒有成功廣播對他有利的舊合約，還為他的惡意行為付出代價。
讀到這邊，我們就把雙向支付通道的運作方式全都說完了。接下來要介紹的是，雙向支付通道如何編織成為支付網路。
閃電網路的支付網路
現在，除了 Alice 和 Bob 之間有支付通道之外，Bob 也和 Carol 開了支付通道。Alice 如果要向 Carol 支付 1 顆比特幣，該怎麼做呢？
Alice 可以選擇直接跟 Carol，建立一個支付渠道，但是這樣做對 Alice 跟 Carol 來說，必須在主鏈上建立多重簽名錢包還要打幣，不僅麻煩而且又需要額外成本。相信大家都想到解決方法了，Alice 只要透過現有的支付通道，先把 1 BTC 打給 Bob，Bob 在將 1 BTC 打給 Carol，這樣就可以在不用負擔額外成本的情況下完成交易了。但是，這同時也存在幾個信任問題。
- Bob 不老實，拿了 Alice 的 BTC 之後私吞，不交給 Carol。
- Carol 拿了錢，卻跟 Alice 說他沒拿到錢。
如何解決這部分的信任問題，就要仰賴閃電網路的另一項核心技術「HTLCs」。
HTLCs 哈希時間鎖合約 (Hash Time-Locked Contracts)
要解決上述的信任問題就必須做到兩點:
- Alice 要確定 Carol 本人確實有收到比特幣
- 必須確定 Bob 不會拿走這筆比特幣
還記得我們之前介紹過的公鑰與私鑰吧，HTLCs 就是用同樣的概念下去延伸，我們把鑰匙想成私鑰，鎖頭就是公鑰。假設 Alice 需要付給 Carol 1 個 BTC，收款方 Carol 會創建一個Value (鑰匙) 和對應的哈希值 (鎖頭)，然後把鎖頭交給 Alice。
這裡就是這個技術的精華。
” 只要拿得出鑰匙就代表他是 Carol “
” 只有 Carol 擁有鑰匙，換言之，只有 Carol 能夠打開鎖頭 “
在這個前提下，Alice 和 Bob 提出一份合約，如果 Bob 在 3 天內（Lock time = 3 day），提供哈希值對應的 Value，Alice 就給 Bob 1.0001 BTC，超過 3 天，BTC 原路返回給 Alice。
Carol 也同樣跟 Bob 簽訂一個合約，只要 Carol 提供哈希值對應的 Value，就必須給 Carel 1 BTC。
於是，Carol 向 Bob 提供 Value，從 Bob 那獲得了 1 BTC。Bob 將這個 Value 交給 Alice，從 Alice 那獲得了 1.0001 BTC，這當中的價差 0.0001 BTC 就給 Bob 作為手續費。
閃電網路的優勢
閃電網路致力於比特幣可擴展性問題的鏈下解決方案。如果成功，可能會大幅減少比特幣區塊鏈的負載，增加比特幣的實際應用可能。
通過使用雙向支付渠道，閃電網路可以實現近乎即時且極低成本的交易。
閃電網路的侷限性
與鏈上交易不同，如果接收方處於離線狀態，沒辦法做交易確認，無法進行支付。
網路的參與者可能需要定期監控支付渠道，以保證他們的資金安全。
閃電網路較難支援大額付款。閃電網路交易時有時需要仰賴中間人，舉個例子，閃電網路中存在 Alice、Bob 和 Carol 三人，Alice 要發送 1 BTC 的交易給 Carol ，這中間需要經過 Bob，如果 Bob 的餘額不足 1 BTC ，這筆交易便無法順利完成，因此交易金額會受限於中間人的資產餘額。
閃電網路的實用性取決於網路大小，若使用人數不足，閃電網路便難以發揮其價值。越多的人加入，閃電網路才會更加健全且完善，流動性也才能隨之提升。
*本文由 AMIS 首席科學家 – 陳昶吾博士協助審閱。
