Lightning Network 筆記

關鍵資源：

• Lightning Network 白皮書
• Lightning Network 白皮書 - 中文版
• Lightning Labs
• Lightning Network 官方網站
• c-lightning 技術文件
• BOLT 規範
• bcongdon 的 Awesome Lightning Network
• Eltoo: Lightning 與 Off-Chain 合約的簡化更新機制
  • Eltoo: 比特幣的簡單 Layer2 協議

---

特殊計畫：

• Lightning Network Torch
• Bluewallet 市集

---

1. 比特幣的交易限制

• 不適合小額支付：

  • 交易速度慢（每秒 7 筆交易），即使在 SegWit 之後改善仍然有限。
  • 區塊大小限制以防止中心化。
  • 挖礦/共識演算法限制以避免分叉。
  • 高額交易手續費。
  • 可擴展性有限。

• 加速交易的解決方案：

  • SQL 用於中心化。
  • 側鏈，取決於採用程度和中心化。
  • 交易通道。

---

2. 多重簽名 (Multi-Sig) 交易

2.1 Pay-to-Multi-Signature (P2MS)

• BIP 11: P2MS

  • 於 2012 年 1 月實施。
  • 限制包括沒有明確的交易地址，市占率低（低於 1%）。
  • Script 包含多個公鑰，最多 3-of-3 簽署者。
  • 修改包括將 Tx scriptSigs 從 200 增加到 500 bytes。
  • 解鎖腳本的缺點。
  • 鎖定腳本格式：m {pubkey}...{pubkey} n OP_CHECKMULTISIG。

  Multi-Sig 範例：

  • 2-of-2： 資產託管服務。
  • 2-of-3： 帶有仲裁者的線上拍賣平台。

2.2 Pay-to-Script-Hash (P2SH)

• BIP 13: P2SH
  • 於 2012 年 4 月實施，P2SH 引入了一種處理複雜交易的新方法：
  • 利用贖回腳本來取代 P2MS 資料。
  • 提供以 ‘3’ 開頭的明確地址。
  • 將複雜性轉移到接收方。
  • 地址以 ‘3’ 開頭，減少交易手續費負擔。
  • 儲存空間由後續交易處理者管理。

地址前綴與腳本類型

前綴	鎖定腳本	地址開頭	範例地址
00	Pay to Public Key Hash (P2PKH)	1	1AKDDsfTh8uY4X3ppy1m7jw1fVMBSMkzjP
05	Pay to Script Hash (P2SH)	3	34nSkinWC9rDDJiUY438qQN1JHmGqBHGW7
6F	P2PKH (Testnet)	m/n	ms2qxPw1Q2nTkm4eMHqe6mM7JAFqAwDhpB
C4	P2SH (Testnet)	2	2MwSNRexxm3uhAKF696xq3ztdiqgMj36rJo

2.3 Segregated Witness (SegWit)

SegWit 引入了重大改進：

• 解決 P2PK、P2PKH、P2MS 和 P2SH 的交易延展性問題。
• 將區塊大小計算改為權重，允許區塊達到 1.8MB。
• 減少交易簽名的權重，使交易手續費減少近七倍。
• 新增 wp2pkh 和 wp2sh，納入交易版本控制以便未來升級。

SegWit 的關鍵 BIP：

• BIP 141： SegWit 的廣泛定義。
• BIP 142： 初始 SegWit 地址定義，後被 BIP 173 的 Bech32 地址取代。
• BIP 143： 新增交易版本控制，定義新的交易驗證（wp2pkh、wp2sh）。
• BIP 144： 定義符合 SegWit 的 P2P 網路。
• BIP 145： 描述 SegWit 網路的 getblock。
• BIP 173： 定義 SegWit 的 Bech32 地址格式，解決 Base58 的問題，如 QR code 空間消耗、大小寫語音辨識挑戰、性能問題和缺乏錯誤檢測。

3. 比特幣中的時間鎖

3.1 絕對時間鎖：nLockTime 和 CheckLockTimeVerify (CLTV)

• nLockTime：

  • 使用 UNIX/區塊時間的 off-chain 絕對時間鎖，由中本聰在比特幣 0.1 中引入。截至今年初，nLockTime 設為 0 的交易僅占所有交易的約 20%。

• CheckLockTimeVerify (CLTV)：

  • on-chain 絕對時間鎖，格式類似於 nLockTime。
  • 定義於 BIP65。
  • 允許資金僅在指定的未來時間點後才能被某方存取。
  • 使用案例包括託管服務、雙因素錢包、支付通道、發布資料的無需信任支付、向礦工費用證明犧牲、凍結資金，以及可能取代 nLockTime 欄位。

3.2 相對時間鎖：BIP68 和 BIP112

• Relative Locktime (BIP68)：

  • 引入共識強制的序列號作為相對時間鎖的格式。
  • 詳見 BIP68。

• CHECKSEQUENCEVERIFY (BIP112)：

  • 補充 BIP68，允許交易相對於輸入的年齡解鎖。
  • 詳見 BIP112。
  • 應用於帶有超時的託管、追溯失效、hash time-locked 合約、雙向支付通道和 Lightning Network。

• BIP113：

  • 定義與 CHECKSEQUENCEVERIFY 一起使用的新去中心化時間測量。

欲進一步了解比特幣的時間鎖，請參閱 Bitcoin’s Time Locks。

4. 交易延展性

• BIP 62：

  • 解決了九種交易延展性問題。更多資訊請見此處。

• BIP 66：

  • 強制執行 DER 編碼以對抗某些形式的交易延展性。詳情請見此處。

• SegWit：

  • 也透過改變交易資料的儲存和傳輸方式來解決交易延展性。

5. 支付通道的演進

1. Nakamoto High-Frequency Transactions (nSequence + nLockTime)：

   • 在比特幣 0.1 中引入，但容易受到礦工串謀的影響。

2. Spillman-style Payment Channels：

   • 由 Peter Todd 於 2013 年 4 月提出，在 BitcoinJ 中實作。

• 使用 nLockTime 防止礦工過早納入交易。
• 易受交易延展性影響，且不允許資金沿同一通道返回。
• 詳情：Bitcoin Wiki。

1. CLTV-style Payment Channels：

   • 隨 BIP 65 於 2014 年 10 月引入。
   • 具有特定到期時間的單向通道。
   • 抵抗 Spillman-style 通道中存在的延展性問題。
   • 需要新的 OP_CLTV 來實作。

2. Poon-Dryja Payment Channels (Lightning Network BOLT3)：

   • 由 Joseph Poon 和 Thaddeus Dryja 於 2016 年 4 月提出。
   • 允許雙向支付，沒有固定到期時間。
   • 論文：The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments。

3. Decker-Wattenhofer Duplex Payment Channels：

   • 由 ETH Zurich 的 Distributed Computing Group 於 2015 年 8 月提出。
   • 依賴 BIP 68 相對時間鎖。
   • 由兩個單向（Spillman-style）通道組成。

4. Decker-Russell-Osuntokun eltoo Channels：

   • 由 Christian Decker、Rusty Russell 和 Olaoluwa Osuntokun 於 2018 年 5 月引入。
   • 論文：eltoo: A Simple Layer2 Protocol for Bitcoin。

5. Hashed Time-Locked Contracts (HTLCs)：

   • HTLC 是 Lightning Network 運作的關鍵組件。
   • 除了時間鎖之外還使用 hashlock，實現無需信任的雙向支付通道。

6. Reaching The Ground With Lightning：

   • 這種方法詳見論文 Reaching The Ground With Lightning，探討 Lightning Network 框架內的實際實作和改進。

比特幣中支付通道的演進展示了持續努力提升區塊鏈技術的可擴展性、安全性和效率。這些發展中的每一項都為比特幣的 off-chain 交易能力的穩健性做出貢獻，最終形成今天 Lightning Network 中使用的複雜系統。

6. 輕量級節點

(本節目前為空，可能需要補充與 Lightning Network 或區塊鏈技術相關的輕量級節點內容。)

7. Lightning Network 設置與挑戰

7.1 單向通道

流程

• 在 A 和 B 雙方之間建立 wp2sh-address-AB。
• A 存入資金（Funding Transaction）作為抵押，以防止 B 潛逃。
• 設定未來的 nlocktime 以將資金返回給 A。
• 持續更新交易。
• 廣播最終交易記錄。

缺點

• 資金單向流動。
• 需要等待 nlocktime 才能贖回資金。

7.2 Revocable Sequence Maturity Contract (RSMC)

RSMC 促進可撤銷的相對時間鎖合約。更多資訊請見此詳細說明。

流程

• 生成 wp2sh 地址。
• 雙方向 Funding Transaction 貢獻資金。
• 設定與貢獻成比例的退款條件。

交易結構

• 對於每筆交易：
  • 更新新狀態，舊狀態失效。
  • 關閉通道的 sequence 設為 0。
  • 需完成 Commitment Transactions 才能釋放 funding transactions。

違約情況

• 如果 A 方違約：
  • A 的 commitment transaction 和退款金額立即支付給 B1，但有 sequence 延遲作為懲罰。
  • B 的交易不受影響。
• 懲罰的交易結構：
  • A 的 commitment transaction 立即支付給 B1。
  • 退款金額需要 sequence 延遲。
  • 使用 B1 的私鑰啟用懲罰交易。

特點

• 資金雙向流動。
• 無需等待贖回時間。
• 確保雙方都不會惡意行事。

7.3 Hash Time-Locked Contracts (HTLCs)

(本節目前為空，可能需要補充與 HTLC 及其在 Lightning Network 中作用相關的內容。)

挑戰

• 路由：
  • 中介機構扣留資金的風險。
  • 基於速度、穩定性和成本尋找最佳路徑。
  • 處理路由延遲和非活動（殭屍）節點。
• 抵押品：
  • 為一般用戶和運營商優化存款金額。
  • 為運營商計算存款部署的回報。
  • 動態手續費調整。
• 線上要求：
  • 雙方持續線上的不便和安全風險。
• 惡意行為者：
  • 需要 watchtower（客戶端和伺服器端）來防止欺詐。

8. 開發

Basis of Lightning Technology (BOLT)

BOLT 的完整列表（包括協議和格式）可在以下資源中找到：

• BOLT #0 到 #11

函式庫

• lightningnetwork/lnd： Lightning Network 節點的完整實作（Golang）。
• ElementsProject/lightning： 符合 C 語言的 Lightning Network 實作（C）。
• ACINQ/eclair： Lightning Network 的 Scala 實作，可在有或無 GUI 的情況下運作，並可通過 JSON-RPC API 存取（Scala）。
• 還有各種程式語言（如 Go、C++ 和 Rust）的其他實作。

Lightning Network 中的錢包類型

中心化 vs 去中心化錢包

• 中心化錢包：這些錢包由中心化實體控制。它們易於使用，但對私鑰和資金的控制較少。
• 去中心化錢包：相反，去中心化錢包讓用戶完全控制他們的金鑰和資金，符合區塊鏈技術的核心精神。

Lightning Network 中的 Watchtowers

Watchtower 在 Lightning Network 的安全性中扮演關鍵角色，監控通道並確保所有各方誠實行事。

選擇性支援功能

• HD 錢包：階層式確定性錢包允許簡化管理多個地址和金鑰。
• TOR 支援：通過 lightning-onion 確保隱私和安全。
• 修剪節點：這些節點僅下載部分區塊鏈以節省空間，適合儲存空間有限的用戶。

9. Lightning Network 現狀

• Lightning Network 瀏覽器：
  • 範例：1ML。
• 其他網路：討論 Liquid Network 等替代網路。

Cypherpunks Core 資源

• Lightning Network 資源彙編。
• 《精通比特幣》章節：第十二章 - 區塊鏈應用、第七章 - 進階交易腳本。

Rusty Russell 的編碼部落格

一系列涵蓋 Lightning Network 各個方面的資訊性部落格文章：

• 可撤銷交易
• Hashed Timelock Contracts (HTLCs)
• 通道合約
• Lightning Network 摘要

Bitmex Research 關於 Lightning Network

一系列深入探討 Lightning Network 各種技術和經濟方面的文章：

• 第 1 部分：討論路由問題、自動駕駛演算法的挑戰、圍繞大型 hub 的中心化以及線上要求。
• 第 2 部分：專注於交易手續費、抵押品優化以及用戶與平台提供者之間的動態。說明運行節點的成本以及交易手續費與交易量的經濟學。
• 第 3 部分：深入探討惡意行為的懲罰機制、關閉通道的不同方法，以及與「正義」交易相關的頻率和金額。
• 第 4 部分：涵蓋 watchtower 的功能以及 Static Channel Backups 等備份解決方案對穩定性和安全性的重要性。
• 第 5 部分：介紹 BitMEX 關於懲罰交易的研究，強調「正義」的發生與交易手續費並不直接相關。

結論

本文提供了 Lightning Network 內各種組件和當前研究的概述。從不同類型的錢包、watchtower 的重要性，到 Bitmex 的深入研究和 Rusty Russell 部落格的見解，涵蓋了對理解 Lightning Network 基礎設施和挑戰至關重要的廣泛主題。Lightning Network 代表了區塊鏈交易可擴展性和效率的重大進步,但也帶來了網路管理、安全和經濟方面的新複雜性和考量。

探索 Lightning Network 和以太坊上的狀態通道

EthFans - 狀態通道

Lightning Network 的主要限制

• Lightning Network 的限制，第 1 部分
• Lightning Network 的限制，第 2 部分

Lightning vs Raiden：Watchtower 模型

• Lightning vs. Raiden：Watchtower 能擴展嗎？第 1 部分：模型和運營成本
• Lightning vs Raiden：Watchtower 模型第 2 部分：Watchtower 中的隱私保護和可擴展性
• Lightning vs Raiden：Watchtower 模型第 3 部分：責任制和商業模式

初學者

• 第 1 部分：支付通道
• 第 2 部分：應用專屬狀態通道
• 第 3 部分：多跳交易/中央 Hub 通道
• 第 4 部分：分類帳通道和虛擬通道
• 第 5 部分：通用狀態通道

其他資源

• Lightning Network 路由：正和博弈中的隱私和效率
• StarksPay：當 Lightning Network 遇見 STARKs
• Lightning Network 作為比特幣的 TCP/IP 堆疊
• Lightning Network 很有前景但面臨各種問題
• 使用 Counterfactual 標準化狀態通道架構
• Raiden Network 中的動態調解費用
• Lightning Network 和以太坊中支付路徑的概念與願景

BitcoinMagazine - 理解 Lightning Network

• 第 1 部分：建立雙向比特幣支付通道
• 第 2 部分：建立網路
• 第 3 部分：完成拼圖並關閉通道

CSDN - 深入 Lightning Network 分析

• Lightning Network 概念的詳細說明，包括 nLockTime (CLTV) 和 Sequence number (CSV)、MicroPayment Channel、RSMC、Script Language and Engine、HTLC 和交易延展性。

簡單生活就是幸福生活 - Lightning Network 系列

• 一系列探討 Lightning Network 成長、設置指南和進階概念（如 Eltoo - 更新離線合約的機制）的部落格。

關鍵問題與考量

• Lightning Network 通道的 2-of-2 交易性質如何影響交易手續費，特別是在第三方可能參與最終支付的情況下？
• 「正義交易」所賦予的權力似乎很重要。這如何影響不當挪用資金的可能性，是否存在陷害個人的風險？
• 考慮到 Lightning Network 獨特的基礎設施和運作機制，智能合約如何在其上實作和執行？