tp錢包|閃電網絡：技術原理和最新進展

1. 閃電網絡現狀

Layer2 一直是行業關注的熱點，特別是今年 zkRollup 等項目。也可能是因為 Rollup 的敘事以及與以太坊生態的應用開發結合等，Rollup 可能已經成為了 Layer2 的代名詞。

然而 OG 級別的 Layer2 解決方案——閃電網絡在很多時候可能被忽視了。從去年開始，包括技術底層和應用生態方面，都已經有了不錯的發展，特別是在推特通過集成 Cash App 來支持閃電網絡之后。

閃電網絡的目前通道累積的比特幣容量約為 3792 個，從去年 4 月的 1000 個 BTC 左右的容量規模有了較快增長。

不過如果對比以太坊上各類“錨定”的比特幣，閃電網絡的規模距離 WBTC（28萬個）、 hBTC（3萬8千個）、renBTC（6千6百個）等仍有不小差距。

但從用戶數量上，閃電網絡的發展可能還會比較讓人值得期待。根據 Arcane Research 的統計和預估，在 Cash App 等應用的幫助下，估計會有超過 8 千萬的用戶已開始使用閃電網絡。

與之對應的，閃電網絡作為一個快速的支付網絡，交易量在 2021 年也有了快速增長。

2. 閃電網絡的技術原理

閃電網絡的思想和其他 Layer2 技術類似，也是將交易執行和結算分離，即把交易執行放在鏈外執行，以提高執行的效率；最終結算的時候，再將最終狀態上鏈。

這個原理和狀態通道（支付通道）類似，而閃電網絡在技術上利用了 HTLC 和 RSMC 等技術來實現了支付通道的連接，來形成了支付網絡。

如果將上述各種技術以迭代的關系來展開，閃電網絡的技術可以有以下遞進的關系：

支付通道（單向）：2-2 多簽、時間鎖

支付通道（雙向）：在之前基礎上，增加 RSMC

支付網絡（閃電網絡）：在之前基礎上，增加 HTLC（哈希時間鎖合約）

單向支付通道

單向支付通道的實現非常簡單。只需要付款方（例如 Alice 付給 Bob）存入到一個 Alice 和 Bob 共同持有的 2-2 多簽地址即可。

準備退款合約

但在此之前， Bob 需要先給 Alice 簽署一份退款合約（沒有發布上鏈的交易信息），從鏈下傳遞消息給 Alice 持有（此時 Alice 未簽名，即只有 Bob 的簽名）。

這個退款合約約定了退款的日期，即此日期后，Alice 可以解鎖 Alice 存在雙簽地址中的全部存款。這樣保護了 Alice，防止 Bob 不配合后續流程而導致 Alice 資金被鎖死。

存款上鏈

拿到 Bob 的退款合約后， Alice 此時可放心的將資金轉入到雙方的多簽地址中，發布在比特幣主網上。待主網交易確認后，即可進行下一步操作。

支付通道中付款

此時 Alice 可多次通過支付通道，以不斷更新通道內雙方余額的方式向 Bob 付款。

具體的付款方式是，Alice 從鏈下將存款合約發送給 Bob（只需要 Alice 簽名信息即可，因為 Bob 在需要時可自行添加自己的簽名來解鎖多簽交易）；而這個合約的輸出內容，即 UTXO 的輸出信息，則是 Alice 和 Bob 在該筆交易后分別的通道內余額。

Alice 通過不斷簽署新的合約，來完成通道的內付款（狀態更新）。

通道關閉/結算

整個通道是有時限的，因為 Alice 持有了一個退款合約。在到期后，Alice 可發布到主網上取走通道內的全部資金。所以，Bob 必須在 Alice 發布前將包含最新的通道狀態的合約，發布上鏈，完成整個的結算。

可以看到，支付通道只與主網發生了兩筆交易，分別對應到通道的開始（存款）和關閉（結算）。中間的多次付款都不需要全局的共識和鏈上手續費，效率高、成本低。

但是，單向通道存在一些問題：

只能單向 Alice -> Bob。因為如果需要 Bob 付款，Bob 會選擇性的把自己余額最大的那個合約信息廣播上鏈，從而抵賴掉 Bob 的付款信息。

總時間有限。因為退款合約的時間鎖限制，到期后就得通道關閉。

雙向：RSMC

雙向狀態通道在單向支付通道的雙簽基礎上，需要增加使用 RSMC，即 Revocable Sequence Maturity Contract

原理是：

雙方各自產生 Revocation Key（Alice 和 Bob 的分別記作 AliceR、BobR）

雙方通過不斷互換合約來“刷新”狀態

“刷新”時，利用 Revocation Key 來“撤銷”（作廢）掉上一個狀態

將 Revocation Key 交給對方（Alice 將 AliceR 交給 Bob）

雙方同時需要新生成一個 Revocation Key （AliceR' 和 BobR'）

存款前

和單向支付通道在存款前類似，Alice 也需要先持有 Bob 的“退款合約”。但在基于 RSMC 的雙向通道中，這個被稱為是“提交”（commit）。

存款

Alice 和 Bob 雙方互持 Revocation Key 之后，即可分別存入資金到 2-2 多簽地址中，進行存款上鏈的交易。

與退款合約類似的，Bob 對該“提交”合約也已簽名；不同之處在于，輸出腳本解鎖條件為，Alice 在若干區塊后可解鎖或者 Bob 在提供了 AliceR 的信息后解鎖。

交易

具體的過程可由付款方先發給對方 Revocation Key（收款方沒有動機去撤銷掉收款的交易）

例如 state 1 -> state 2 是 Alice 付款給 Bob

那么 Alice 先出示 AliceR

Bob 再出示 BobR

雙方可刪除上一筆交易

閃電網絡

RSMC 解決了兩方間的雙向支付通道問題。但如果涉及到多人，直接從雙簽（2-2多簽）擴展到多簽的方式并不具有大規模的可擴展性。但可以基于兩方的支付通道上，增加更多技術來將多個支付通道連接起來，形成可支付的閃電網絡。

最典型的實現支付通道連接的技術，是 HTLC（Hash Time Lock Contract）。

原理是在 RSMC 之上，收款人要新創建一個自己持有且待傳遞的 R。

1.收款人 Carol 根據 R 計算出 H。 H = Hash(R)，即 R 是 H 的原像

2.收款人 Carol 將 H 交給付款人 Alice，由付款人 Alice 增加在 UTXO 的輸出解鎖條件中

合約形式的解鎖條件也變為下圖的形式。下圖的例子中，Bob 只要向 Alice 揭示 R 即可付款（更新通道內的狀態）

3.正向的傳播 H ，例如，從 Alice 和 Bob 的通道內先用 H 更新合約；然后 Bob 和 Carol 的狀態通道也類似的使用 H 來更新。

但是在傳遞過程中，需要確保前一段付款人可收回退款的時間，要晚于后一段付款人的可收回退款時間。例如，下圖例子中的 Alice 給 Bob 的付款可在 17:00 后收回，而 Bob 給 Carol 的付款可在 16:00 （早于17:00）收回。

4.反向的消除，例如收款人 Carol 通過揭示 R 來向 Bob 收款（Bob 驗證 H=Hash(R) 之后，Bob 和 Carol 即可更新雙方間的通道狀態）

因此，閃電網絡實際上是通過傳遞 R 來實現連接多個狀態通道的收付款。同時也會利用 Tor 等技術來網絡信息的隱匿，即中間人不知道實際的連接起點和終點。

3. BOLT

閃電網絡的核心技術原理還是相對比較簡單的，但是如果要真正用在實際環境中，還需要考慮各種異常情況以設計和約定好相應的處理方法。

例如，上文提到的超時時間該如何設置？如何避免節點知曉全部路徑以防止其與路徑上的其他節點串通？中間付款失敗時如何處理？以及是否有更優的技術實現來替代原像的傳遞等等。

在基于比特幣腳本等有限的可編程能力的情況下，這些規范尤為重要。

BOLT 協議就是閃電網絡對各種層面上通信和應用處理的一個全面的協議，用來解決上述問題。

和網絡通信協議 TCP/IP 以及區塊鏈 IBC 協議等等類似，BOLT 協議包括了各個層面上的多種子協議。包括：

網絡連接層

消息層

P2P 層

路由層

支付層

其中的一些實現也可以替換，例如，Bolt 11 原定義的是通過 HTLC 的原像與哈希的方式來生成和傳遞 invoice，但也可以改用 PTLC（點時間鎖合約）。

4. 一些比較重要的改進

PTLC

PTLCs（Point Time Locked Contracts，點時間鎖合約）從 2018 年左右開始討論用于改進 HTLC。為什么？HTLC 在應用到閃電網絡中具有是需要將原像傳遞給發送方。

HTLC 用于閃電網絡可能存在的問題

這樣會存在一些問題，例如支付路徑上的某兩個不直接連接的節點相互串通，則可能會存在繞過中間節點，占用原本屬于中間的手續費。

例如，下圖中 Mallory 和 Mike 是兩個串通好的惡意節點。Mike 在向通道支付了 1 BTC 并拿到原像后，直接交給了 Mallory；Mallory 則進一步用該原像向上游獲取了 1.1 BTC（假設中間環節的所有手續費是 0.1 BTC）。至此，Mike 和 Mallory 相當于同謀用 1 BTC 的成本獲取了 1.1 BTC 的收益，而他倆中間環節的節點手續費則被侵占，且通道資金處于鎖定狀態，要到超時后才能恢復正常。

PTLC 原理

上述問題在于 HTLC 傳遞的原像在路徑上唯一，因此解決的辦法也可以針對性的進行設計。PTLC 采用了橢圓曲線的不可逆和可同態計算的特性，這樣使得秘密在傳遞的每一段上都需要和前一段有關。

PTLC 流程

在 PTLC 下，以 Alice -> Bob -> Carol 的付款流為例：

Carol 生成一個秘密值 $z$ ，并把 $z * G$ 交給 Alice。

其中 $G$ 是橢圓曲線上的一個點

Alice 不能通過 $z * G$ 來反推出 $z$

Alice 生產兩個隨機數 $x$ 和 $y$

Alice 生成一個付款合約給 Bob，解鎖條件是 Bob 能揭示 $(x + z) * G$ 對應的“私鑰”，即$(x + z)$ 。合約里的 $(x + z) * G$ 可通過$x * G + z * G$ 計算出來

Alice 把 $y$ 交給 Bob。

Bob 生成一個付款合約給 Carol，解鎖條件是 Carol 能揭示 $(x + y + z) * G$ 的”私鑰“， $(x + y + z)$。合約里的 $(x + y+ z) * G$ 可通過 $(x + z) * G + y * G$ 計算出來

Alice 把 $(x+y)$ 交給 Carol。即 Carol 知道$(x+y)$，但不知道 $x$ 或 $y$ 的具體值

Carol 通過 $(x+y)+z = (x+y+z)$ ，給 Bob 展示該值，解鎖第 5 步 Bob 的付款

Bob 得知了 $(x+y+z)$ 之后，通過 $(x+y+z) - y$ 計算出 $(x + z)$ ，并向 Alice 展示，以解鎖第 3 步的付款合約。

最后， Alice 通過計算 $(x + z) - x$ 得到 $z$，作為自己的支付證明。

也就是，通過同態運算和在付款流程中的每一個環節中增加隨機數的方式，確保了每一個環節不可被繞過。

Taproot 支持 PTLC 的實現

Taproot 升級中的 Schnorr 簽名也給 PTLC 帶來了可能，通過使用 Schnorr 聚合簽名的部分和適配器簽名（partial and adaptor signatures）來實現。

重復使用收款碼：Keysend

閃電網絡根據 BOLT 11 必須要 invoice。在實際應用時，閃電網絡有一個“痛點”在于：收款人要先展示一個一次性的“收款碼”（invoice），付款人才能付款，而且每次收付款都必須更換。

這樣對于商戶希望能長期穩定的收款、線上用戶希望能收到打賞來說太不方便了。

“Keysend” 希望實現的效果類似微信長期收款碼：只需知道我的公鑰，就可以給我無限次支付了，而無需每次生成一個 invoice。

Keysend 原理

Keysend 的實現原理是：支付者選出原像，然后使用洋蔥消息封裝它，然后路由給接收者。洋蔥封裝后的數據沿著一條路徑轉播，但完整的路徑對路徑上任一轉發該支付的節點都是不可知的。因為，數據是在沿著這個路徑達到最終目的地的過程中，被路徑上的一個一個節點逐步解封的。

目前大多數閃電網絡實現（包括 LND 和 c-lightning）都實現了 Keysend。

不只是支付

Keysend 還可以支持多種應用。Keysend 可以通過在封裝支付信息的洋蔥數據包中加入額外的信息，來支持聊天（例如 Sphinx Chat）和川流式支付應用（如 Podcasting 2.0、Breez）等。

穩定幣等其他資產：Taro

閃電網絡在支付的使用上仍然有一個沒能很好回答的問題：為什么要用比特幣來支付？如果一個 Bitcoin 長期支持者要用閃電網絡，那么 TA 可能很難真的愿意用寶貴的比特幣去支付；而對于閃電網絡有極大希望去“破圈”的、unbanked 人群，比特幣的高波動率可能也會比較難以接受。

Lightning Labs 在 2022 年 4 月宣布的 Taro 可能會解決這一問題。

“bitcoinize the dollar”。Taro 計劃在比特幣網絡上利用 Taproot 技術來支持閃電網絡使用穩定幣來支付。

Taro 原理

Taro 的原理是，基于 Taproot，允許在現有的 UTXO 輸出中嵌入任意類型的元數據。

Sparse Merkle Sum Tree

Taro 在記錄賬戶狀態數據時，使用了稀疏 Merkle 總和樹（Sparse Merkle Sum Tree）。

首先看稀疏 Merkle 樹（SMT）。這種二叉樹結構和普通 Merkle 樹的區別是將所有可能取值作為葉子節點。也就是通過這種方式，SMT 對所有可能的數據進行了“索引”，便于進行非存在性證明。

例如，key 的空間范圍是 256 位 bit 的，即總共可能有 $2^{256}$ 個 key。如果用二叉樹的左分支表示 0、右分支表示 1，也就是需要一個 256 層的二叉樹在葉子節點上表示所有可能的 key。如果將這個樹用作狀態樹，即葉子節點上的 key 都是所有可能的賬戶地址。 也因為這種形式，SMT 會非?！跋∈琛?，畢竟對于全部賬戶地址集合來說，有狀態的賬戶屬于極少數。

另外，SMT 也具有插入順序無關等特性，因為數據元素已經固定好位置。

使用 Taproot，連接現有閃電網絡

Taro 將稀疏 Merkle 總和樹的樹根做 Hash 后，作為 UTXO 的 Taproot 樹的一個葉子節點。因此，Taro 可以利用 Taproot 交易對 Taro 資產的狀態進行更新。

而這個交易只要在閃電網絡的開始和結束這兩個通道內完成即可。例如下圖中，只需要 Alice 和 Bob 以及 Carol 和 Dave 之間通過 Taproot 方式維護了 Taro 的狀態即可。開始和結束這兩段可以使用 Taro 定義穩定幣（L-USD）來結算，而中間的連接部分可以對應的將穩定幣轉換成閃電網絡中對應的 BTC。

因此，Taro 可以完全利用現有的閃電網絡基礎設施。

5. 其他改進

Eltoo：不需要懲罰機制，讓閃電網絡增強至更通用意義下的“L2”

閃電網絡的整體流程是遵循著“存款（建立通道）-> 閃電網絡交易（更新通道狀態）->退款/結算（結束通道）” 的流程。

與之對應的是閃電網絡遵循的是類似 Fraud Proof 的方式，在狀態更新時引入懲罰機制來保證參與者都更新正確的狀態。而且為了確保能提交正確的合約，閃電網絡節點必須存儲大量的通道狀態合約，以確保遇到欺詐情況時可以有“證據”可用。

Eltoo 及其基本原理

是否有可能改進？Eltoo（與“L2”同音）可以認為是一個對閃電網絡的一個增強，允許任意一個后面的狀態來替代之前的任意一個狀態。

這樣，結算交易可以和存款交易同時簽名，這樣可以不需要依賴懲罰機制（不過 Eltoo 仍然可以使用懲罰機制）。

Eltoo 實現機制

Eltoo 在白皮書中是計劃通過一次軟分叉，引入一個新的簽名哈希類型（sighash flag） SIGHASH_NOINPUT 。這個新的簽名哈希類型可以允許簽名來提交一個交易而無需在交易輸入中指定交易 ID。

這也就是允許在前一筆交易被發布在比特幣主網上之前，后一筆交易可以先簽名。

在 2019 年， SIGHASH_ANYPREVOUT 和 SIGHASH_ANYPREVOUTANYSCRIPT 替代了SIGHASH_NOINPUT ， 并且在 2021 年 7 月被合并至了 BIP118 中。

其他效果

除了不需要懲罰機制以降低存儲要求外，Eltoo 可以讓閃電網絡成為對節點支持更好的“L2”。比如：

可以讓三方或更多方建立同一個通道，也就是類似通道工廠的概念。

可以對節點宕機恢復更容錯，避免例如一個閃電網絡節點突然從宕機等錯誤中恢復時，可能會收發不正確的狀態信息等情況。

Wumbo：增大額度

Wumbo 可以讓節點運營者接入到更大的channel中。在 Wumbo 以往只能限制到 0.1677 BTC。而 Wumbo channels 支持一些大的路由節點，可突破該限制，支持大額度的支付。

MPP：多路徑支付

Submarine Swaps：從主鏈上實時充值

從 atomic swap 衍生而來。支持 LN 的 channel 可以自動重新從 Layer1 上充值。

Watchtowers、Multiplexer：節點不在線時替代處理：

因為閃電網絡的懲罰機制和時間有效性等特性，閃電網絡節點最好時刻在線以避免遭遇欺詐情況時的損失。

Watchtowers 機制是第三方的節點來檢測是否有惡意交易發生。這樣即使當事方節點不在線，Watchtowers 也可以幫他來廣播公平的交易。

另外，除了解決節點不在線時的爭議處理，對于節點作為收款方，BottlePay 在 4 月份也宣布了一個 Multiplexer（多路復用器）的產品，主要用來解決收款方宕機等問題。

OP_CTV

目前比較有爭議的 CheckTemplateVerify 軟分叉提議，可以地幫助閃電網絡的通道創建和關閉，提高閃電網絡的的效率和流動性。

其他的一些遺留問題

通道堵塞攻擊

通道堵塞攻擊（Channel jamming attacks）是一種 DoS 攻擊。攻擊者通過在閃電網絡通道上給自己支付，以低成本的占用正常的支付通道。

該問題在 2015 年提出后，目前仍然沒有公認的較好解決辦法。

參考資料：

A Technical Introduction to The Lightning Network, Andrews M. Antonopoulos

MIT Course: Cryptocurrency Engineering and Design, Tadge Dryja

The State of Lightning Volume 2, Arcane Research

Payment Points Part 1: Replacing HTLCs, Nadav Kohen

Keysend payments explained, VOLTAGE

Announcing Taro: A New Protocol for Multi-Asset Bitcoin and Lightning, Ryan Gentry

Taro Documents, Lightning Labs

What’s a Sparse Merkle Tree?, Kelvin Fichter

Eltoo, River Financial

Eltoo, Bitcoin Optech

解釋 CHECKTEMPLATEVERIFY：比特幣最新的爭議性軟分叉提案, BTCStudy

日?？捎玫拈W電網絡：閃電網絡將如何與 Web 整合, BTC Study

==

歡迎加入鴕鳥區塊鏈Telegram社群

中文社區 https://t.me/tuoniaox

英文社區 https://t.me/tuoniaoGroup