比特幣系統提供了一個用於測試目的的替代鏈，稱為「測試網」（testnet），與被稱為「主網」（mainnet）的「正常」比特幣鏈形成對比。在測試網上，貨幣是「測試網比特幣」（tBTC），它是專門用於測試的無價值的比特幣副本。比特幣的每個功能都被精確複製，但這些錢沒有價值，所以您真的沒有什麼可失去的！

一些閃電網路錢包也可以在測試網上運行，允許您使用測試網比特幣進行閃電網路支付，而不會冒真實資金的風險。這是一種安全地試驗閃電網路的好方法。Alice 在本章中使用的 Eclair Mobile 就是支援測試網操作的閃電網路錢包的一個例子。

您可以從「測試網比特幣水龍頭」獲得一些 tBTC 來玩，它會按需免費發放 tBTC。以下是一些測試網水龍頭：

本書中的所有範例都可以用 tBTC 在測試網上精確複製，所以如果您想跟著做而不冒真實金錢的風險，可以這樣做。

正如我們在本節開頭提到的，Eclair 是一個「非託管」錢包，這意味著 Alice 獨自託管用於控制她比特幣的金鑰。這也意味著 Alice 有責任保護和備份這些金鑰。如果 Alice 失去了金鑰，沒有人可以幫助她恢復比特幣，它們將永遠失去。

與大多數比特幣錢包類似，Eclair Mobile 提供一個「助記詞」（有時也稱為「種子」或「種子短語」）供 Alice 備份。助記詞由 24 個英文單詞組成，由軟體隨機選擇，用作錢包生成金鑰的基礎。在行動裝置遺失、軟體錯誤或記憶體損壞的情況下，Alice 可以使用助記詞恢復 Eclair Mobile 錢包中的所有交易和資金。

當 Alice 選擇建立新錢包時，她將看到一個顯示她助記詞的螢幕，如 新錢包助記詞 中的螢幕截圖所示。

在 新錢包助記詞 中，我們故意模糊了部分助記詞，以防止本書讀者重複使用該助記詞。

Alice 需要小心地以一種防止盜竊但也避免意外遺失的方式儲存助記詞。正確平衡這些風險的推薦方法是將助記詞的兩份副本寫在紙上，每個單詞都編號——順序很重要。

一旦 Alice 記錄了助記詞，在她的螢幕上點擊「OK GOT IT」後，她將被出示一個測驗，以確保她正確記錄了助記詞。測驗將隨機詢問三到四個單詞。Alice 沒有預料到會有測驗，但由於她正確記錄了助記詞，她毫無困難地通過了。

一旦 Alice 記錄了助記詞並通過了測驗，她應該將每份副本儲存在單獨的安全位置，如上鎖的抽屜或防火保險箱。

Alice 初始化她的 Eclair Mobile 錢包後，她將看到一個簡短的教學，突出顯示使用者介面的各種元素。我們不會在這裡複製教學，但我們將在跟隨 Alice 嘗試購買一杯咖啡時探索所有這些元素！

Alice 可以透過幾種方式獲取比特幣：

所有這些方法都有不同程度的難度，許多會涉及支付費用。有些還需要 Alice 提供身份證明文件以符合當地銀行法規。然而，透過所有這些方法，Alice 將能夠收到比特幣。

假設 Alice 找到了當地的比特幣 ATM 並決定用現金購買一些比特幣。比特幣 ATM 的一個例子，由 Lamassu 公司製造的，如 Lamassu 比特幣 ATM 所示。這種比特幣 ATM 透過現金插槽接受法定貨幣（現金），並使用內建攝影機將比特幣發送到從使用者錢包掃描的比特幣地址。

要在她的 Eclair 閃電網路錢包中接收比特幣，Alice 需要向 ATM 出示 Eclair 閃電網路錢包中的比特幣地址。然後 ATM 可以將 Alice 新獲得的比特幣發送到這個比特幣地址。

要在 Eclair 錢包上看到比特幣地址，Alice 必須向左滑動到標題為 YOUR BITCOIN ADDRESS 的欄位（參見 Eclair 中顯示的 Alice 的比特幣地址），在那裡她會看到一個方形條碼（稱為 QR 碼）和下面的一串字母和數字。

QR 碼包含與下面顯示的相同的字母和數字字串，格式易於掃描。這樣，Alice 就不必輸入比特幣地址。在螢幕截圖（Eclair 中顯示的 Alice 的比特幣地址）中，我們故意模糊了兩者，以防止讀者無意中向這個地址發送比特幣。

Alice 將在 Eclair 錢包的 TRANSACTION HISTORY 標籤中看到來自 ATM 的交易。雖然 Eclair 會在幾秒鐘內檢測到比特幣交易，但比特幣交易需要大約一個小時才能在比特幣區塊鏈上「確認」。如您在 Alice 收到比特幣 中所見，Alice 的 Eclair 錢包在交易下方顯示「6+ conf」，表示該交易已收到所需的最少六次確認，她的資金現在可以使用了。

雖然在這個例子中 Alice 使用 ATM 獲得了她的第一筆比特幣，但即使她使用 獲取比特幣 中的其他方法之一，同樣的基本概念也適用。例如，如果 Alice 想銷售產品或提供專業服務以換取比特幣，她的客戶可以用他們的錢包掃描比特幣地址並用比特幣支付給她。

同樣，如果她為透過網際網路提供的服務向客戶開帳單，Alice 可以向她的客戶發送包含比特幣地址或 QR 碼的電子郵件或即時訊息，他們可以將資訊貼上或掃描到比特幣錢包中來支付給她。

Alice 甚至可以列印 QR 碼並將其貼在標牌上並公開展示以接收小費。例如，她可以在她的吉他上貼一個 QR 碼，在街頭表演時接收小費！^[5]

最後，如果 Alice 從加密貨幣交易所購買了比特幣，她可以（而且應該）透過將她的比特幣地址貼到交易所網站上來「提取」比特幣。然後交易所將直接把比特幣發送到她的地址。

向右滑動，Alice 進入 Eclair 的 LIGHTNING CHANNELS 部分。在這裡，她可以管理將她的錢包連接到閃電網路的通道。

讓我們在這裡回顧一下閃電網路通道的定義，以使事情更清楚一些。首先，「通道」這個詞是 Alice 的閃電網路錢包和另一個閃電網路錢包之間「財務關係」的隱喻。我們稱之為通道是因為它是 Alice 的錢包和這另一個錢包在閃電網路上（鏈下）相互交換許多支付的方式，而無需將交易提交到比特幣區塊鏈（鏈上）。

Alice 開啟通道連接的錢包或「節點」稱為她的「通道對等節點」。一旦「開啟」，通道可用於在 Alice 的錢包和她的通道對等節點之間來回發送許多支付。

此外，Alice 的通道對等節點可以透過其他通道將支付「轉發」到閃電網路的更遠處。這樣，Alice 可以將支付「路由」到任何錢包（例如 Bob 的閃電網路錢包），只要 Alice 的錢包可以找到一條由從一個通道跳到另一個通道組成的可行「路徑」，一直到 Bob 的錢包。

換句話說，Alice 需要一個或多個通道將她連接到閃電網路上的一個或多個其他節點。她不需要一個直接將她的錢包連接到 Bob’s Cafe 的通道來向 Bob 發送支付，儘管她也可以選擇開啟直接通道。閃電網路中的任何節點都可以用於 Alice 的第一個通道。節點連接越好，Alice 可以接觸到的人就越多。在這個例子中，由於我們還想示範支付路由，我們不會讓 Alice 直接向 Bob 的錢包開啟通道。相反，我們將讓 Alice 向一個連接良好的節點開啟通道，然後稍後使用該節點轉發她的支付，根據需要透過任何其他節點路由到達 Bob。

起初，沒有開啟的通道，所以如我們在 LIGHTNING CHANNELS 標籤 中看到的，LIGHTNING CHANNELS 標籤顯示一個空列表。如果您注意到，在右下角有一個加號（+），這是開啟新通道的按鈕。

「節點 URI」是識別特定閃電網路節點的統一資源識別碼（URI）。Alice 可以從她的剪貼簿貼上這樣的 URI，或掃描包含相同資訊的 QR 碼。節點 URI 的範例顯示為 節點 URI 作為 QR 碼 中的 QR 碼，然後顯示為文字字串。

雖然 Alice 可以選擇特定的閃電網路節點，或使用「隨機節點」選項讓 Eclair 錢包隨機選擇一個節點，但她將選擇 ACINQ 節點選項連接到 ACINQ 連接良好的閃電網路節點之一。

選擇 ACINQ 節點會稍微降低 Alice 的隱私，因為它會讓 ACINQ 能夠看到 Alice 的所有交易。它還會創建一個單點故障，因為 Alice 將只有一個通道，如果 ACINQ 節點不可用，Alice 將無法進行支付。為了一開始保持簡單，我們將接受這些權衡。在後續章節中，我們將逐步學習如何獲得更多獨立性並做出更少的權衡！

Alice 選擇 ACINQ 節點，準備在閃電網路上開啟她的第一個通道。

當 Alice 選擇一個節點來開啟新通道時，系統會詢問她想要為這個通道分配多少比特幣。在後續章節中，我們將討論這些選擇的影響，但現在 Alice 將把幾乎所有資金分配給通道。由於她必須支付交易費用來開啟通道，她將選擇一個略低於她總餘額的金額。^[6]

Alice 將她 0.020 BTC 總額中的 0.018 BTC 分配給她的通道，並接受預設費率，如 開啟閃電網路通道 所示。

一旦她點擊 OPEN，她的錢包就會構建開啟閃電網路通道的特殊比特幣交易，稱為「資金交易」。鏈上資金交易被發送到比特幣網路進行確認。

Alice 現在必須再次等待（參見 等待資金交易開啟通道），等待交易記錄在比特幣區塊鏈上。與她用來獲取比特幣的初始比特幣交易一樣，她必須等待六次或更多確認（大約一小時）。

一旦資金交易被確認，Alice 到 ACINQ 節點的通道就開啟、注資並準備就緒，如 通道已開啟 所示。

Bob 有一個簡單的銷售點（PoS）應用程式，供任何想要透過閃電網路用比特幣付款的客戶使用。正如我們將在下一章看到的，Bob 使用流行的開源平台 BTCPay Server，它包含電子商務或零售解決方案所需的所有組件，例如：

BTCPay Server 使安裝所有必要軟體、上傳圖片和產品價格以及快速啟動商店變得簡單。

在 Bob’s Cafe 的櫃檯上，有一台平板裝置顯示您在 Bob 的銷售點應用程式 中看到的內容。

Alice 從螢幕上選擇 Cafe Latte 選項，並被提供一張「閃電網路發票」（也稱為「付款請求」），如 Alice 拿鐵的閃電網路發票 所示。

Alice 選擇「掃描付款請求」選項，掃描平板螢幕上顯示的 QR 碼（參見 Alice 拿鐵的閃電網路發票），並被提示確認她的付款，如 Alice 的發送確認 所示。

Alice 按下 PAY，一秒鐘後，Bob 的平板顯示付款成功。Alice 完成了她的第一筆閃電網路支付！它快速、便宜且簡單。現在她可以享受她用比特幣透過快速、便宜且去中心化的支付系統購買的拿鐵了。從現在起，Alice 可以簡單地在 Bob 的平板螢幕上選擇一個項目，用她的手機掃描 QR 碼，點擊 PAY，然後在幾秒鐘內被端上咖啡，所有這些都不需要鏈上交易。

閃電網路支付對 Bob 來說也更好。他確信他會收到 Alice 拿鐵的錢，而不需要等待鏈上確認。將來，每當 Alice 想在 Bob’s Cafe 喝咖啡時，她可以選擇在比特幣網路或閃電網路上用比特幣付款。您認為她會選擇哪一個？

支付通道建立在 2-of-2 多重簽名地址之上。

總結來說，多重簽名地址是比特幣被鎖定的地方，需要多個簽名才能解鎖和花費。在閃電網路中使用的 2-of-2 多重簽名地址中，有兩個參與簽名者，「兩者」都需要簽名才能花費資金。

多重簽名腳本和地址在 多重簽章腳本 中有更詳細的解釋。

「承諾交易」是向每個通道夥伴支付其通道餘額並確保通道夥伴不必相互信任的交易。透過簽署承諾交易，每個通道夥伴「承諾」當前餘額，並讓另一個通道夥伴能夠隨時取回他們的資金。

透過持有已簽名的承諾交易，每個通道夥伴即使沒有另一個通道夥伴的合作也可以獲得他們的資金。這保護他們免受另一個通道夥伴的消失、拒絕合作或透過違反支付通道協議試圖欺騙的影響。

Alice 在前面範例中準備的承諾交易是她對多重簽名地址初始支付的退款。然而，更一般地說，承諾交易分割支付通道的資金，根據兩個通道夥伴各自持有的分配（餘額）向他們支付。起初，Alice 持有所有餘額，所以這是一個簡單的退款。但隨著資金從 Alice 流向 Bob，他們會交換代表新餘額分配的新承諾交易簽名，部分資金支付給 Alice，部分支付給 Bob。

假設 Alice 與 Bob 開啟一個容量為 100,000 聰的通道。 最初，Alice 擁有 100,000 聰，即通道中的全部資金。以下是支付通道協議的運作方式：

透過遵循這個協議，即使資金被發送到 Alice 只控制一把金鑰的 2-of-2 多重簽名地址，Alice 也不會放棄她 100k 聰的所有權。 如果 Bob 停止回應 Alice，她將能夠廣播她的承諾交易並取回她的資金。 她唯一的成本是鏈上交易的費用。 只要她遵循協議，這就是她開啟通道時的唯一風險。

在這次初始交換之後，每當通道餘額變化時都會創建承諾交易。換句話說，每次在 Alice 和 Bob 之間發送支付時，都會創建新的承諾交易並交換簽名。每筆新的承諾交易都編碼了 Alice 和 Bob 之間的最新餘額。

如果 Alice 想向 Bob 發送 30k 聰，兩人都會創建他們承諾交易的新版本，現在向 Alice 支付 70k 聰，向 Bob 支付 30k 聰。透過編碼 Alice 和 Bob 的新餘額，新的承諾交易是透過通道「發送」支付的方式。

現在我們理解了承諾交易，讓我們看看一些更微妙的細節。您可能注意到這個協議留下了一種讓 Alice 或 Bob 作弊的方式。

Alice 向 Bob 支付 30k 聰後持有多少筆承諾交易？她持有兩筆：原始的那筆向她支付 100k 聰，以及較新的那筆向她支付 70k 聰、向 Bob 支付 30k 聰。

在我們目前看到的通道協議中，沒有任何東西阻止 Alice 發布先前的承諾交易。作弊的 Alice 可以發布向她授予 100k 聰的承諾交易。 由於該承諾交易是由 Bob 簽署的，他無法阻止 Alice 傳輸它。

需要某種機制來防止 Alice 發布舊的承諾交易。現在讓我們找出如何實現這一點，以及它如何使閃電網路能夠在 Alice 和 Bob 之間無需任何信任的情況下運行。

因為比特幣是抗審查的，沒有人可以阻止某人發布舊的承諾交易。為了防止這種形式的作弊，承諾交易被構建為如果舊的被傳輸，作弊者可以受到懲罰。透過使懲罰足夠大，我們創造了強大的反作弊激勵，這使系統安全。

懲罰的運作方式是給被欺騙方一個機會來索取作弊者的餘額。因此，如果有人試圖透過廣播舊的承諾交易來作弊，在該交易中他們獲得的餘額比他們應得的更高，另一方可以透過同時拿走他們自己的餘額「和」作弊者的餘額來懲罰他們。作弊者失去一切。

讓我們再次經歷通道構建場景，添加懲罰機制來防止作弊：

有了強大的懲罰機制，Alice 不會想透過發布舊的承諾交易來作弊，因為她冒著失去全部餘額的風險。

現在我們理解了「為什麼」需要懲罰機制以及它將如何防止作弊，讓我們詳細看看它是「如何」運作的。

通常，承諾交易至少有兩個輸出，向每個通道夥伴支付。我們改變這一點，向其中一個支付添加「時間鎖延遲」和「撤銷秘密」。時間鎖防止輸出的所有者在承諾交易被包含在區塊中後立即花費它。撤銷秘密允許任何一方立即花費該支付，繞過時間鎖。

因此，在我們的範例中，Bob 持有一筆「立即」向 Alice 支付的承諾交易，但他自己的支付是延遲和可撤銷的。Alice 也持有一筆承諾交易，但她的是相反的：它立即向 Bob 支付，但她自己的支付是延遲和可撤銷的。

兩個通道夥伴各持有撤銷秘密的一半，所以他們都不知道整個秘密。如果他們分享自己的一半，那麼另一個通道夥伴就擁有完整的秘密，可以用它來行使撤銷條件。當簽署新的承諾交易時，每個通道夥伴透過將他們的撤銷秘密一半給另一方來撤銷先前的承諾。

我們將在 撤銷和重新承諾 中更詳細地檢查撤銷機制，在那裡我們將學習撤銷秘密如何構建和使用的細節。

簡單來說，只有當 Bob 提供他上一個承諾的撤銷秘密一半時，Alice 才簽署 Bob 的新承諾交易。只有當 Alice 給他上一個承諾的撤銷秘密一半時，Bob 才簽署 Alice 的新承諾交易。

每次新的承諾，他們都交換必要的「懲罰」秘密，使他們能夠透過使傳輸先前承諾變得無利可圖來有效地「撤銷」先前的承諾交易。本質上，他們在簽署新承諾時摧毀了使用舊承諾的能力。我們的意思是，雖然技術上仍然可以使用舊的承諾，但懲罰機制使這樣做在經濟上是不理性的。

時間鎖設定為最多 2,016 個區塊（大約兩週）。如果任何一個通道夥伴在未與另一個夥伴合作的情況下發布承諾交易，他們將不得不等待該區塊數（例如兩週）才能索取他們的餘額。另一個通道夥伴可以隨時索取他們自己的餘額。此外，如果發布的承諾之前已被撤銷，通道夥伴「也」可以立即索取作弊方的餘額，繞過時間鎖並懲罰作弊者。

時間鎖是可調整的，可以在通道夥伴之間協商。通常，對於較大容量的通道，時間鎖較長，對於較小的通道，時間鎖較短，以使激勵與資金價值保持一致。

對於通道餘額的每次新更新，都必須創建和保存新的承諾交易和新的撤銷秘密。只要通道保持開啟，為通道創建的所有撤銷秘密都需要保留，因為它們將來可能需要。幸運的是，秘密相當小，只有通道夥伴需要保留它們，而不是整個網路。此外，由於用於導出撤銷秘密的智慧導出機制，我們只需要儲存最新的秘密，因為先前的秘密可以從中導出（參見 作弊和懲罰的實踐）。

儘管如此，管理和儲存撤銷秘密是閃電網路節點更精細的部分之一，需要節點運營商維護備份。

如果 Bob 不回應，Alice 可以隨時關閉通道，索取她公平份額的餘額。 在鏈上發布「最後」的承諾交易後，Alice 必須等待時間鎖過期才能從承諾交易中花費她的資金。正如我們稍後將看到的，只要 Alice 和 Bob 都在線並合作以正確的餘額分配關閉通道，就有一種更簡單的方法來關閉通道而無需等待。但每個通道夥伴儲存的承諾交易充當故障保護，確保如果他們的通道夥伴有問題，他們不會失去資金。

通道夥伴可以同意向整個閃電網路宣布他們的通道，使其成為「公開通道」。為了宣布通道，他們使用閃電網路的 gossip 協議告訴其他節點通道的存在、容量和費用。

公開宣布通道允許其他節點使用它們進行支付路由，從而也為通道夥伴產生路由費用。

相比之下，通道夥伴可能決定不宣布通道，使其成為「未宣布」通道。

未宣布的通道仍然用於路由支付，但只有知道其存在的節點，或給予「路由提示」關於包含未宣布通道的路徑。

當使用 gossip 協議公開宣布通道及其容量時，宣布還可以包含有關通道的資訊（元資料），例如其路由費用和時間鎖持續時間。

當新節點加入閃電網路時，它們從對等節點收集透過 gossip 協議傳播的通道宣布，建立閃電網路的內部地圖。然後可以使用此地圖來查找支付路徑，將通道端到端連接在一起。

關閉通道的最佳方式是…​不要關閉它！ 開啟和關閉通道需要鏈上交易，這將產生交易費用。 因此，最好盡可能長時間保持通道開啟。 只要您在通道一端有足夠的容量，您就可以繼續使用通道進行和轉發支付。 但即使您將所有餘額發送到通道的另一端，您也可以使用通道從您的通道夥伴那裡接收支付。 這種在一個方向使用通道然後在相反方向使用它的概念稱為「再平衡」，我們將在另一章中更詳細地檢查它。 透過再平衡通道，它可以幾乎無限期地保持開啟，並用於基本上無限數量的支付。

然而，有時關閉通道是可取的或必要的。例如：

有三種方式可以關閉支付通道：

每種方法在不同情況下都是有用的，我們將在本章的下一節中探討。 例如，如果您的通道夥伴離線，您將無法遵循「好的方式」，因為沒有合作夥伴無法進行互相關閉。 通常，您的閃電網路軟體會根據情況自動選擇最佳的關閉機制。

發票最重要的部分是「支付雜湊」。當構建發票時，Bob 會這樣做支付雜湊：

沒有已知的方法可以找到 SHA-256 的逆（即從雜湊計算原像）。只有 Bob 知道值 r，所以它是 Bob 的秘密。但一旦 Bob 透露 r，任何擁有雜湊 H 的人都可以透過計算 SHA-256(r) 並看到它與 H 匹配來檢查 r 是否是正確的秘密。

只有當 r 完全隨機選擇且不可預測時，閃電網路的支付過程才是安全的。這種安全性依賴於雜湊函數不能被反轉或可行地暴力破解的事實，因此沒有人可以從 H 找到 r。

發票可以選擇性地包含其他有用的元資料，例如簡短的文字描述。如果使用者有多張發票要支付，使用者可以閱讀描述並被提醒發票是關於什麼的。

發票還可以包含一些「路由提示」，允許發送者使用未宣布的通道來構建到接收者的路徑。路由提示也可以用於建議公開通道，例如接收者知道有足夠入站容量來路由支付的通道。

如果發送者的閃電網路節點無法透過閃電網路發送支付，發票可以選擇性地包含一個鏈上比特幣地址作為備用。

閃電網路發票包含一個過期日期。由於接收者必須為每張發出的發票保留原像 r，讓發票過期是有用的，這樣這些原像就不需要永遠保留。一旦發票過期或被支付，接收者可以丟棄原像。

正如我們之前提到的，當構建支付通道時，通道夥伴可以選擇公開它，向整個閃電網路宣布其存在和細節。

通道宣布透過點對點「gossip 協議」傳播。gossip 協議是一種通訊協議，每個節點連接到網路中隨機選擇的其他節點，通常透過 TCP/IP。直接連接到您節點（透過 TCP/IP）的每個節點稱為您的「對等節點」。您的節點反過來是他們的對等節點之一。請記住，當我們說您的節點連接到其他對等節點時，我們不是指您有支付通道，而只是您透過 gossip 協議連接。

開啟通道後，節點可以選擇透過 channel_announcement 訊息向其對等節點發送通道的宣布。 每個對等節點驗證來自 channel_announcement 訊息的資訊，並驗證資金交易是否在比特幣區塊鏈上確認。 驗證後，節點會將 gossip 訊息轉發給其自己的對等節點，他們會將其轉發給他們的對等節點，依此類推，將宣布傳播到整個網路。 為了避免過度通訊，只有當節點之前尚未轉發該宣布時，才會轉發通道宣布。

gossip 協議還用於透過 node_announcement 訊息宣布有關已知節點的資訊。 為了轉發此訊息，節點必須至少有一個公開通道在 gossip 協議上宣布，再次是為了避免過度通訊流量。

支付通道有各種元資料，對網路的其他參與者有用。 這些元資料主要用於做出路由決策。 因為節點可能偶爾會更改其通道的元資料，這些資訊透過 channel_update 訊息共享。 這些訊息大約每天只會轉發四次（每個通道），以防止過度通訊。 gossip 協議還有各種查詢和訊息，用於最初同步節點與網路視圖，或在離線一段時間後更新節點的視圖。

閃電網路參與者的一個主要挑戰是，由 gossip 協議共享的拓撲資訊只是部分的。 例如，支付通道的容量透過 channel_announcement 訊息在 gossip 協議上共享。 然而，這些資訊不如兩個通道夥伴之間本地餘額方面的容量實際分配那麼有用。 一個節點只能轉發它在該通道內實際擁有（本地餘額）的比特幣數量。

雖然閃電網路本可以設計為共享通道的餘額資訊和精確拓撲，但由於以下幾個原因而沒有這樣做：

我們將在後面的章節中檢查 gossip 協議的細節。

現在，只需要知道 gossip 協議存在，並且它用於共享閃電網路的拓撲資訊。 這種拓撲資訊對於透過支付通道網路傳遞支付至關重要。

閃電網路上的支付沿著由連接一個參與者到另一個參與者的通道組成的「路徑」轉發，從支付來源到支付目的地。找到從來源到目的地路徑的過程稱為「路徑搜尋」。使用該路徑進行支付的過程稱為「路由」。

正如我們接下來將看到的，閃電網路目前使用「基於來源」的協議進行路徑搜尋，使用「洋蔥路由」協議進行支付路由。基於來源意味著支付的發送者必須找到一條穿過網路到達預期目的地的路徑。洋蔥路由意味著路徑的元素是分層的（像洋蔥一樣），每一層都加密，所以一次只能被一個節點看到。我們將在下一節討論洋蔥路由。

閃電網路使用類似於著名的 Tor（洋蔥路由器）網路的「洋蔥路由協議」。 閃電網路中使用的洋蔥路由協議稱為 SPHINX Mix Format，^[8]將在後面的章節中詳細解釋。

用於路由的支付封包稱為「洋蔥」。^[9]

讓我們用洋蔥的類比來跟隨路由支付。在從支付發送者（付款人）到支付目的地（收款人）的路線上，洋蔥沿著路徑從一個節點傳遞到另一個節點。發送者從中心向外構建整個洋蔥。首先，發送者為支付的（最終）接收者創建支付資訊，並用只有接收者可以解密的加密層對其加密。然後，發送者用路徑中「緊接最終接收者之前」的節點的指令包裹該層，並用只有該節點可以解密的層加密。

各層是用指令構建的，向後工作直到整個路徑被編碼在各層中。然後發送者將完整的洋蔥交給路徑中的第一個節點，該節點只能讀取最外層。每個節點剝掉一層，發現裡面的指令揭示路徑中的下一個節點，並將洋蔥傳遞下去。當每個節點剝掉一層時，它無法讀取洋蔥的其餘部分。它所知道的只是洋蔥剛從哪裡來和它要去哪裡，沒有任何關於誰是原始發送者或最終接收者的指示。

這種情況繼續，直到洋蔥到達支付目的地（收款人）。然後，目的地節點打開洋蔥，發現沒有更多層可以解密，可以讀取裡面的支付資訊。

閃電網路中使用的洋蔥路由協議具有以下特性：

洋蔥路由將在 洋蔥路由 中詳細檢查。

一旦支付的發送者找到了一條可能的跨網路路徑並構建了洋蔥，支付就會由路徑中的每個節點轉發。每個節點處理洋蔥的一層並將其轉發給路徑中的下一個節點。

每個中介節點收到一條稱為 update_add_htlc 的閃電網路訊息，其中包含支付雜湊和洋蔥。中介節點執行一系列步驟，稱為「支付轉發演算法」：

當然，如果檢測到錯誤，這些步驟會被中斷和中止，並向 update_add_htlc 訊息的發起者發送錯誤訊息。錯誤訊息也被格式化為洋蔥，並在入站通道上向後發送。

隨著錯誤在路徑上的每個通道向後傳播，通道夥伴移除待處理支付，以與開始相反的方式回滾支付。

雖然如果支付沒有快速結算，支付失敗的可能性很高，但節點永遠不應該在洋蔥帶著錯誤返回之前沿著不同的路徑發起另一次支付嘗試。如果兩次支付嘗試最終都成功，發送者將支付兩次。

在使用比特幣進行典型支付時，使用者收到一個比特幣地址（例如，掃描網頁上的 QR 碼，或在即時訊息或電子郵件中從朋友那裡收到）。然後他們使用比特幣錢包創建交易，將資金發送到這個地址。

在閃電網路上，支付的接收者創建發票。閃電網路發票可以被視為類似於比特幣地址。預期接收者將閃電網路發票作為 QR 碼或字元字串給發送者，就像比特幣地址一樣。

發送者使用他們的閃電網路錢包支付發票，複製發票文字或掃描發票 QR 碼。閃電網路支付類似於比特幣「交易」。

然而，使用者體驗有一些差異。比特幣地址是「可重用的」。比特幣地址永不過期，如果地址的所有者仍然持有金鑰，其中的資金始終可以存取。發送者可以向以前使用的地址發送任意數量的比特幣，接收者可以發布單一靜態地址來接收許多支付。雖然出於隱私原因這違背了最佳實踐，但它在技術上是可能的，實際上相當常見。

然而，在閃電網路中，每張發票只能用於特定支付金額的一次支付。您不能支付更多或更少，您不能重複使用發票，發票有內建的過期時間。在閃電網路中，接收者必須為每次支付生成一張新發票，預先指定支付金額。有一個例外，一種稱為 keysend 的機制，我們將在 Keysend 自發付款 中檢查。

要在比特幣網路上進行支付，發送者需要消耗一個或多個未花費的交易輸出（UTXO）。 如果使用者有多個 UTXO，他們（或者更確切地說是他們的錢包）將需要選擇使用哪個 UTXO。 例如，進行 1 BTC 支付的使用者可以使用單一價值 1 BTC 的輸出、兩個價值 0.25 BTC 和 0.75 BTC 的輸出，或四個各價值 0.25 BTC 的輸出。

在閃電網路上，支付不需要消耗輸入。相反，每次支付都會導致通道餘額的更新，在兩個通道夥伴之間重新分配。發送者將此視為將通道餘額從他們的通道一端「移動」到另一端，到他們的通道夥伴。閃電網路支付使用一系列通道從發送者路由到接收者。這些通道中的每一個都必須有足夠的容量來路由支付。

因為許多可能的通道和路徑可以用於進行支付，閃電網路使用者對通道和路徑的選擇在某種程度上類似於比特幣使用者對 UTXO 的選擇。

透過原子多路徑支付（AMP）和多部分支付（MPP）等技術，我們將在後續章節中回顧，多條閃電網路路徑可以聚合成單一原子支付，就像多個比特幣 UTXO 可以聚合成單一原子比特幣交易一樣。

要在比特幣網路上進行支付，發送者需要消耗一個或多個未花費的交易輸出（UTXO）。UTXO 只能完整花費；它們不能被分割和部分花費。因此，如果使用者希望花費 0.8 BTC，但只有 1 BTC 的 UTXO，他們需要花費整個 1 BTC UTXO，發送 0.8 BTC 給接收者，0.2 BTC 作為找零返回給自己。0.2 BTC 找零支付創建了一個新的 UTXO，稱為「找零輸出」。

在閃電網路上，資金交易花費一些比特幣 UTXO，創建一個多重簽名 UTXO 來開啟通道。一旦比特幣被鎖定在該通道內，它的一部分可以在通道內來回發送，而不需要創建任何找零。 這是因為通道夥伴只是更新通道餘額，只有在通道最終使用通道關閉交易關閉時才創建新的 UTXO。

在比特幣網路上，使用者支付費用給礦工，讓他們的交易被包含在區塊中。 這些費用支付給開採該特定區塊的礦工。 費用金額基於交易在區塊中使用的「位元組」大小，以及使用者希望該交易被開採的速度。 因為礦工通常會首先開採最有利可圖的交易，想要立即開採交易的使用者將支付每位元組「更高」的費用，而不著急的使用者將支付每位元組「更低」的費用。

在閃電網路上，使用者支付費用給其他（中介節點）使用者，以透過他們的通道路由支付。 為了路由支付，中介節點必須在他們擁有的兩個或更多通道中移動資金，以及為發送者的支付傳輸資料。通常，路由使用者會根據支付的「價值」向發送者收費，已建立最低「基本費用」（每次支付的固定費用）和「費率」（與支付價值成比例的按比例費用）。因此，價值較高的支付路由成本較高，形成流動性市場，不同使用者對透過其通道路由收取不同的費用。

在比特幣網路上，礦工是追求利潤的，通常會在區塊中包含盡可能多的交易，同時保持在稱為「區塊權重」的區塊容量內。

如果佇列中的交易（稱為 mempool）多於一個區塊可以容納的，他們會首先開採每單位（位元組）「交易權重」支付最高費用的交易。 因此，當佇列中有許多交易時，使用者必須支付更高的費用才能被包含在下一個區塊中，否則他們必須等到佇列中的交易較少。 這自然導致費用市場的出現，使用者根據他們需要將交易包含在下一個區塊中的緊迫程度來支付。

比特幣網路上的稀缺資源是區塊中的空間。比特幣使用者競爭區塊空間，比特幣費用市場基於可用區塊空間。閃電網路中的稀缺資源是「通道流動性」（通道中可用於路由的資金容量）和「通道連接性」（通道可以到達多少連接良好的節點）。閃電網路使用者競爭容量和連接性；因此，閃電網路費用市場由容量和連接性驅動。

在閃電網路上，使用者向路由其支付的使用者支付費用。在經濟學術語中，路由支付無非是向發送者提供和分配容量。自然，對相同容量收取較低費用的路由器將更有吸引力進行路由。因此，存在一個費用市場，路由器就透過其通道路由支付的費用相互競爭。

在比特幣網路上，每筆交易都在比特幣區塊鏈上公開可見。雖然涉及的地址是假名的，通常不與身份關聯，但它們仍然被網路上的每個其他使用者看到和驗證。 此外，區塊鏈監控公司大規模收集和分析這些資料，並將其出售給感興趣的各方，如私人公司、政府和情報機構。

另一方面，閃電網路支付幾乎完全私密。通常，只有發送者和接收者完全知道特定支付的來源、目的地和交易金額。此外，接收者甚至可能不知道支付的來源。因為支付是洋蔥路由的，路由支付的使用者只知道支付金額，他們無法確定來源或目的地。

總結來說，比特幣交易是公開廣播的，永久儲存。閃電網路支付在幾個選定的對等節點之間執行，有關它們的資訊只在通道關閉前私密儲存。創建與比特幣上使用的類似的大規模監控和分析工具在閃電網路上將困難得多。

在比特幣網路上，交易只有在被包含在區塊中後才結算，在這種情況下，它們被稱為在該區塊中「確認」。隨著更多區塊被開採，交易獲得更多「確認」並被認為更安全。

在閃電網路上，確認只對開啟和關閉鏈上通道有意義。一旦資金交易達到適當的確認數（例如 3 次），通道夥伴就認為通道已開啟。因為通道中的比特幣由管理該通道的智慧合約保護，支付在最終接收者收到後「即時」結算。 實際上，即時結算意味著支付只需要幾秒鐘即可執行和結算。與比特幣一樣，閃電網路支付是不可逆的。

最後，當通道關閉時，會在比特幣網路上進行交易；一旦該交易被確認，通道就被認為已關閉。

在比特幣網路上，使用者可以向另一個使用者發送他們擁有的任意數量的比特幣，沒有容量限制。理論上，單筆交易可以發送高達 2100 萬比特幣作為支付。

在閃電網路上，使用者只能發送其特定通道一側目前存在的比特幣數量給通道夥伴。例如，如果使用者擁有一個通道，其一側有 0.4 BTC，另一個通道一側有 0.2 BTC，那麼他們用一筆支付可以發送的最大金額是 0.4 BTC。無論使用者目前在其比特幣錢包中有多少比特幣，這都是真的。

多部分支付（MPP）是一項功能，在上述範例中，允許使用者組合其 0.4 BTC 和 0.2 BTC 通道，用一筆支付發送最多 0.6 BTC。MPP 目前正在閃電網路上測試，預計在本書完成時將被廣泛使用。有關 MPP 的更多詳情，請參見 多部分付款。

如果支付被路由，路由路徑上的每個路由節點都必須擁有容量至少與路由的支付金額相同的通道。對於支付路由通過的每個通道，這都必須成立。路徑中容量最低的通道設定了整個路徑容量的上限。

因此，容量和連接性是閃電網路中關鍵且稀缺的資源。

比特幣的費用結構與交易價值無關。 一筆 100 萬美元的交易與 1 美元的交易在比特幣上費用相同，假設類似的交易大小（以位元組計，更具體地說是 SegWit [隔離見證協議] 後的「虛擬」位元組）。 在閃電網路中，費用是固定基本費用加上交易價值的百分比。 因此，在閃電網路中，支付費用隨支付價值增加。 這些相反的費用結構創造了不同的激勵，並導致在交易價值方面的不同使用。 較高價值的交易在比特幣上會更便宜；因此，使用者會更傾向於用比特幣進行大額交易。同樣，在另一端，使用者會更傾向於用閃電網路進行小額交易。

在比特幣網路上，每筆交易最終都記錄在區塊鏈上的一個區塊中。 區塊鏈因此形成了自比特幣創建以來每筆交易的完整歷史，以及完全審計每一個存在的比特幣的方式。 一旦交易被包含在區塊鏈中，它就是最終的。 因此，不會出現爭議，在區塊鏈的特定點上，特定地址控制多少比特幣是明確的。

在閃電網路上，特定時間通道中的餘額只有兩個通道夥伴知道，只有在通道關閉時才對網路的其餘部分可見。 當通道關閉時，通道的最終餘額提交到比特幣區塊鏈，每個夥伴收到他們在該通道中的比特幣份額。 例如，如果開啟餘額是 Alice 支付的 1 BTC，Alice 向 Bob 支付了 0.3 BTC，那麼通道的最終餘額是 Alice 0.7 BTC，Bob 0.3 BTC。 如果 Alice 試圖透過向比特幣區塊鏈提交通道的開啟狀態來作弊，Alice 1 BTC，Bob 0 BTC，那麼 Bob 可以透過提交通道的真實最終狀態來報復，並創建一筆懲罰交易，給他通道中的所有比特幣。 對於閃電網路，比特幣區塊鏈充當法院系統。 像一個機器人法官，比特幣記錄每個通道的初始和最終餘額，如果其中一方試圖作弊，則批准懲罰。

當比特幣使用者向目標地址發送資金時，他們不需要知道接收者的任何資訊。接收者可能離線或線上，發送者和接收者之間不需要互動。互動是在發送者和比特幣區塊鏈之間進行的。在比特幣區塊鏈上接收比特幣是一種「被動」和「非同步」活動，不需要接收者的任何互動或接收者在任何時候都線上。比特幣地址甚至可以離線生成，永遠不會在比特幣網路上「註冊」。只有花費比特幣需要互動。

在閃電網路中，接收者必須線上才能在支付過期之前完成支付。 接收者必須運行一個節點或有人代表他們運行節點（第三方託管人）。準確地說，發送者和接收者的節點在支付時都必須線上，並且必須協調。接收閃電網路支付是發送者和接收者之間的「主動」和「同步」活動，沒有大部分閃電網路或比特幣網路的參與（除了中介路由節點，如果有的話）。

閃電網路的同步和始終線上的性質可能是使用者體驗中最大的差異，這經常讓習慣於比特幣的使用者感到困惑。

在比特幣網路上，最小單位是「聰」，不能再細分。閃電網路更靈活一些，閃電網路節點使用「毫聰」（千分之一聰）。這允許透過閃電網路發送微小的支付。單一毫聰支付可以透過支付通道發送，這個金額如此之小，應該恰當地被描述為「納米支付」。

當然，毫聰單位不能以這種精度在比特幣區塊鏈上結算。在通道關閉時，餘額四捨五入到最接近的聰。但在通道的生命週期內，數以百萬計的納米支付可以以毫聰級別進行。閃電網路突破了微支付障礙。

比特幣網路和閃電網路都使用相同的貨幣單位：比特幣。閃電網路支付使用與比特幣交易完全相同的比特幣。作為一個含義，因為貨幣單位相同，貨幣限制也相同：少於 2100 萬比特幣。在比特幣的 2100 萬總比特幣中，一些已經作為閃電網路支付通道的一部分分配給 2-of-2 多重簽名地址。

比特幣交易和閃電網路支付都是不可逆和不可變的。任何一個系統都沒有「撤消」操作或「退款」。作為任何一個的發送者，您必須負責任地行動，但同樣，作為接收者，您可以保證交易的最終性。

與比特幣一樣，閃電網路只要求使用者信任數學、加密，以及軟體沒有任何關鍵錯誤。無論是比特幣還是閃電網路都不需要使用者信任個人、公司、機構或政府。 因為閃電網路位於比特幣之上並依賴比特幣作為其底層基礎層，很明顯閃電網路的安全模型歸結為比特幣的安全性。這意味著閃電網路在大多數情況下提供與比特幣大致相同的安全性，只有在某些狹窄情況下安全性略有降低。

比特幣和閃電網路都可以由任何有網際網路存取和適當軟體（例如節點和錢包）的人使用。 任何一個網路都不要求使用者獲得第三方、公司、機構或政府的許可、審查或授權。政府可以在其管轄範圍內禁止比特幣或閃電網路，但不能阻止其全球使用。

比特幣和閃電網路都是由去中心化的全球志願者社群構建的開源軟體系統，在開放許可下提供。兩者都基於開放和可互操作的協議，作為開放系統和開放網路運行。全球、開放、自由。

本章以及本書大部分內容中的範例都使用命令列終端機。這意味著你在終端機中輸入命令並接收文字回應。此外，這些範例是在基於 Linux 核心和 GNU 軟體系統的作業系統上演示的，特別是最新的 Ubuntu 長期穩定版本（Ubuntu 20.04 LTS）。大多數範例可以在其他作業系統（如 Windows 或 macOS）上複製執行，只需對命令進行少量修改。作業系統之間最大的區別是安裝各種軟體函式庫及其先決條件的_套件管理器_。在給出的範例中，我們將使用 apt，這是 Ubuntu 的套件管理器。在 macOS 上，一個常用於開源開發的套件管理器是 Homebrew，透過命令 brew 存取。

在這裡的大多數範例中，我們將直接從原始碼建構軟體。雖然這可能相當具有挑戰性，但它給了我們最大的能力和控制權。如果遇到困難，你也可以選擇使用 Docker 容器、預編譯套件或其他安裝機制！

為了保持一致性，我們在所有命令列範例中使用 bash shell。雖然其他 shell 會以類似的方式運作，並且你可以在沒有它的情況下執行所有範例，但一些 shell 腳本是專門為 bash shell 編寫的，可能需要一些更改或自訂才能在其他 shell 中執行。為了一致性，你可以在 Windows 和 macOS 上安裝 bash shell，而它在大多數 Linux 系統上預設已安裝。

所有程式碼範例都可在本書的線上儲存庫中找到。由於儲存庫會盡可能保持更新，你應該始終在線上儲存庫中查找最新版本，而不是從紙本書或電子書中複製。

你可以訪問 GitHub 並選擇右側的綠色 Code 按鈕，以 ZIP 壓縮包的形式下載儲存庫。

或者，你可以使用 git 命令在本地電腦上建立儲存庫的版本控制複製品，從而讓你可以與後續更改保持同步，而不需要再次下載整個儲存庫。按照 Git 專案的說明下載並安裝 git。

要在你的電腦上建立儲存庫的本地副本，請按以下方式執行 git 命令：

你現在在一個名為 lnbook 的資料夾中擁有了本書儲存庫的完整副本。你會想要透過執行以下命令切換到新下載的目錄：

所有後續範例將假設你在這個資料夾內執行命令。

讓我們準備 bitcoind 容器。最簡單的方法是從 Docker Hub 拉取最新的容器：

或者，你可以從 code/docker/bitcoind/Dockerfile 中的本地容器定義自行建構容器。

在本地建構容器將使用較少的網路頻寬，但會使用更多的 CPU 時間來建構。我們使用 docker build 命令來建構它：

如你所見，bitcoind 啟動並挖掘 101 個模擬區塊以啟動區塊鏈。這是因為根據比特幣共識規則，新挖出的比特幣在經過 100 個區塊之前是不能花費的。透過挖掘 101 個區塊，我們使第一個區塊的 coinbase 可以花費。之後，每 10 秒挖掘 6 個新區塊，以保持區塊鏈向前推進。

目前沒有交易。但我們有一些測試比特幣已經被挖掘到錢包中，可以使用。當我們將一些閃電網路節點連接到這條鏈時，我們會發送一些比特幣到它們的錢包，這樣我們就可以在閃電網路節點之間開設一些閃電網路通道。

c-lightning 軟體發行版有一個 Docker 容器，但它設計用於在生產系統中執行 c-lightning 並與 bitcoind 節點一起執行。我們將使用一個稍微簡單的容器，配置為在演示目的下執行 c-lightning。

讓我們從本書的 Docker Hub 儲存庫拉取 c-lightning 容器：

或者，我們可以從你之前下載到名為 lnbook 目錄中的本書檔案建構 c-lightning Docker 容器。和之前一樣，我們將在 code/docker 子目錄中使用 docker build 命令。我們將使用標籤 lnbook/c-lightning 標記容器映像，如下所示：

我們的容器現在已建構並準備好執行。然而，在執行 c-lightning 容器之前，我們需要在另一個終端機中啟動 bitcoind 容器，因為 c-lightning 依賴於 bitcoind。我們還需要設定一個 Docker 網路，允許容器相互連接，就像它們位於同一個區域網路上一樣。

一旦設定了 Docker 網路，每次 Docker 啟動時（例如重新開機後），Docker 都會在我們的本地電腦上啟動該網路。因此，我們只需要使用 docker network create 命令設定一次網路。網路名稱本身並不重要，但它必須在我們的電腦上是唯一的。預設情況下，Docker 有三個名為 host、bridge 和 none 的網路。我們將把新網路命名為 lnbook 並像這樣建立它：

如你所見，執行 docker network ls 給我們一個 Docker 網路列表。我們的 lnbook 網路已建立。我們可以忽略網路 ID，因為它是自動管理的。

下一步是啟動 bitcoind 和 c-lightning 容器並將它們連接到 lnbook 網路。要在特定網路中執行容器，我們必須將 network 參數傳遞給 docker run。為了讓容器容易找到彼此，我們還將使用 name 參數給每個容器一個名稱。我們像這樣啟動 bitcoind：

你應該看到 bitcoind 啟動並開始每 10 秒挖掘區塊。讓它繼續執行並開啟一個新的終端機視窗來啟動 c-lightning。我們使用帶有 network 和 name 參數的類似 docker run 命令來啟動 c-lightning，如下所示：

c-lightning 容器啟動並透過 Docker 網路連接到 bitcoind 容器。首先，我們的 c-lightning 節點將等待 bitcoind 啟動，然後它將等待 bitcoind 挖掘一些比特幣到其錢包中。最後，作為容器啟動的一部分，一個腳本將向 bitcoind 節點發送一個 RPC 命令，建立一筆交易，用 10 個測試 BTC 為 c-lightning 錢包注資。現在我們的 c-lightning 節點不僅在執行，而且還有一些測試比特幣可以使用！

正如我們對 bitcoind 容器所演示的，我們可以在另一個終端機中向 c-lightning 容器發出命令，以提取資訊、開設通道等。允許我們向 c-lightning 節點發出命令列指令的命令稱為 lightning-cli。這個 lightning-cli 命令在此容器中也有別名 cli。要獲取 c-lightning 節點的資訊，請在另一個終端機視窗中使用以下 docker exec 命令：

我們現在有了第一個在虛擬網路上執行並與測試比特幣區塊鏈通訊的閃電網路節點。稍後在本章中，我們將啟動更多節點並將它們相互連接，以進行一些閃電網路支付。

在下一節中，我們還將看看如何直接從原始碼下載、配置和編譯 c-lightning。這是一個可選的進階步驟，將教你如何使用建構工具，並允許你對 c-lightning 原始碼進行修改。有了這些知識，你可以編寫一些程式碼、修復一些錯誤或為 c-lightning 建立外掛程式。

c-lightning 開發者提供了從原始碼建構 c-lightning 的詳細說明。我們將遵循 GitHub 上的說明。

這些安裝說明假設你在 Linux 或類似系統上使用 GNU 建構工具建構 c-lightning。如果不是這種情況，請在 Elements 專案儲存庫中查找適用於你作業系統的說明。

常見的第一步是安裝先決條件函式庫。我們使用 apt 套件管理器來安裝這些：

幾分鐘後和大量的螢幕活動之後，你將安裝好所有必要的套件和函式庫。許多這些函式庫也被其他閃電網路套件使用，並且是軟體開發的一般需求。

接下來，我們將從原始碼儲存庫複製最新版本的 c-lightning。為此，我們將使用 git clone 命令，它會在你的本地機器上複製一個版本控制的副本，從而讓你可以與後續更改保持同步，而不需要再次下載整個儲存庫：

我們現在在 lightning 子資料夾中有了 c-lightning 的副本，並且我們使用 cd（更改目錄）命令進入該子資料夾。

接下來，我們使用一組在許多開源專案中常見的_建構腳本_。這些建構腳本使用 configure 和 make 命令，讓 我們可以：

使用 help 選項執行 configure 將向我們顯示所有可用選項：

在本範例中，我們不需要更改任何預設值。因此，我們不帶任何選項再次執行 configure 以使用預設值：

接下來，我們使用 make 命令來建構 c-lightning 專案的函式庫、元件和可執行檔。這部分需要幾分鐘才能完成，並且會大量使用你電腦的 CPU 和磁碟。預期會聽到風扇的噪音！執行 make：

如果一切順利，你不會看到任何 ERROR 訊息阻止前述命令的執行。c-lightning 軟體套件已從原始碼編譯完成，我們現在準備安裝在前一步驟中建立的可執行元件：

要驗證 lightningd 和 lightning-cli 命令是否已正確安裝，我們將向每個可執行檔詢問其版本資訊：

版本由最新發布版本（v0.10.1）組成，後面是發布後的更改數量（34），最後是一個精確識別修訂版的雜湊值（fe86c11）。你可能會看到與前面顯示的不同版本，因為軟體在本書出版後會繼續發展。然而，無論你看到什麼版本，命令執行並以版本資訊回應的事實意味著你已成功建構 c-lightning 軟體。

我們可以從本書的 Docker Hub 儲存庫拉取 LND 範例 Docker 容器：

或者，我們可以在本地建構 LND 容器。該容器位於 code/docker/lnd。我們將工作目錄更改為 code/docker 並執行 docker build 命令：

我們的容器現在準備好執行了。與我們之前建構的 c-lightning 容器一樣，LND 容器也依賴於正在執行的 Bitcoin Core 實例。和之前一樣，我們需要在另一個終端機中啟動 bitcoind 容器，並透過 Docker 網路將 LND 連接到它。我們已經設定了一個名為 lnbook 的 Docker 網路，並將在這裡再次使用它。

和之前一樣，我們在一個終端機中啟動 bitcoind 容器，在另一個終端機中啟動 LND。如果你已經在執行 bitcoind 容器，則不需要重新啟動它。只需讓它繼續執行並跳過下一步。要在 lnbook 網路中啟動 bitcoind，我們像這樣使用 docker run：

接下來，我們啟動剛剛建構的 LND 容器。和之前一樣，我們需要將它附加到 lnbook 網路並給它一個名稱：

LND 容器啟動並透過 Docker 網路連接到 bitcoind 容器。首先，我們的 LND 節點將等待 bitcoind 啟動，然後它將等待 bitcoind 挖掘一些比特幣到其錢包中。最後，作為容器啟動的一部分，一個腳本將向 bitcoind 節點發送一個 RPC 命令，從而建立一筆交易，用 10 個測試 BTC 為 LND 錢包注資。

正如我們之前演示的，我們可以在另一個終端機中向容器發出命令，以提取資訊、開設通道等。允許我們向 lnd 守護程式發出命令列指令的命令稱為 lncli。同樣，在此容器中，我們提供了別名 cli，它以所有適當的參數執行 lncli。讓我們在另一個終端機視窗中使用 docker exec 命令獲取節點資訊：

我們現在在 lnbook 網路上執行了另一個閃電網路節點，並與 bitcoind 通訊。如果你仍在執行 c-lightning 容器，那麼現在有兩個節點在執行。它們還沒有相互連接，但我們很快就會將它們連接起來。

如果需要，你可以在同一個閃電網路上執行 LND 和 c-lightning 節點的任意組合。例如，要執行第二個 LND 節點，你可以使用不同的容器名稱發出 docker run 命令，如下所示：

在前面的命令中，我們啟動了另一個 LND 容器，命名為 lnd2。名稱完全由你決定，只要它們是唯一的。如果你不提供名稱，Docker 將透過隨機組合兩個英文單詞來構造一個唯一的名稱，例如「naughty_einstein」。這是我們撰寫這段文字時 Docker 為我們選擇的實際名稱。多有趣！

在下一節中，我們將看看如何直接從原始碼下載和編譯 LND。這是一個可選的進階步驟，將教你如何使用 Go 語言建構工具，並允許你對 LND 原始碼進行修改。有了這些知識，你可以編寫一些程式碼或修復一些錯誤。

在本節中，我們將從頭開始建構 LND。LND 是用 Go 程式語言編寫的。如果你想了解更多關於 Go 的資訊，搜尋 golang 而不是 go 以避免不相關的結果。因為它是用 Go 而不是 C 或 C++ 編寫的，所以它使用的「建構」框架與我們之前在 c-lightning 中看到的 GNU autotools/make 框架不同。不過不用擔心，安裝和使用 golang 工具非常容易，我們將在這裡展示每個步驟。Go 是一種適合協作軟體開發的出色語言，因為無論作者數量如何，它都能產生非常一致、精確且易於閱讀的程式碼。Go 專注且「極簡」，以一種鼓勵語言版本間一致性的方式。作為編譯語言，它也相當高效。讓我們開始吧。

我們將遵循 LND 專案文件中的安裝說明。

首先，我們將安裝 golang 套件和相關函式庫。我們嚴格要求 Go 版本 1.13 或更高版本。官方 Go 語言套件作為二進位檔案從 Go 專案分發。為方便起見，它們也被打包為 Debian 套件，可透過 apt 命令獲得。你可以按照 Go 專案的說明，或者如 GitHub 關於 Go 語言的 wiki 頁面所述，在 Debian/Ubuntu Linux 系統上使用以下 apt 命令：

透過執行以下命令檢查你是否安裝並準備好使用正確的版本：

我們有 1.13.4，所以我們準備好…​Go！接下來我們需要告訴任何程式在哪裡找到 Go 程式碼。這是透過設定環境變數 GOPATH 來完成的。通常，Go 程式碼位於使用者主目錄下一個名為 gocode 的目錄中。透過以下兩個命令，我們一致地設定 GOPATH 並確保你的 shell 將其添加到可執行 PATH 中。請注意，使用者的主目錄在 shell 中稱為 ~。

為了避免每次開啟 shell 時都必須設定這些環境變數，你可以使用你選擇的編輯器將這兩行添加到主目錄中 bash shell 配置檔案 .bashrc 的末尾。

與現今許多開源專案一樣，LND 的原始碼在 GitHub（www.github.com）上。go get 命令可以使用 Git 協定直接獲取它：

一旦 go get 完成，你將在 GOPATH 下有一個包含 LND 原始碼的子目錄。

LND 使用 make 建構系統。要建構專案，我們切換目錄到 LND 的原始碼，然後像這樣使用 make：

幾分鐘後，你將安裝好兩個新命令 lnd 和 lncli。嘗試它們並檢查它們的版本以確保它們已安裝：

你可能會看到與前面顯示的不同版本，因為軟體在本書出版後會繼續發展。然而，無論你看到什麼版本，命令執行並顯示版本資訊的事實意味著你已成功建構 LND 軟體。

讓我們從 Docker Hub 儲存庫拉取本書的 Eclair 容器：

或者，我們可以在本地建構容器。到目前為止，你幾乎是 Docker 基本操作的專家了！在本節中，我們將重複許多之前看到的命令來建構 Eclair 容器。該容器位於 code/docker/eclair。我們在終端機中首先將工作目錄切換到 code/docker 並發出 docker build 命令：

我們的映像現在準備好執行了。Eclair 容器也依賴於正在執行的 Bitcoin Core 實例。和之前一樣，我們需要在另一個終端機中啟動 bitcoind 容器，並透過 Docker 網路將 Eclair 連接到它。我們已經設定了一個名為 lnbook 的 Docker 網路，並將在這裡重複使用它。

Eclair 與 LND 或 c-lightning 的一個顯著區別是，Eclair 不包含單獨的比特幣錢包，而是直接依賴 Bitcoin Core 中的比特幣錢包。回想一下，使用 LND 時，我們透過執行交易從 Bitcoin Core 的錢包轉移比特幣到 LND 的比特幣錢包來為其注資。使用 Eclair 時，這個步驟是不必要的。執行 Eclair 時，Bitcoin Core 錢包直接用作開設通道的資金來源。因此，與 LND 或 c-lightning 容器不同，Eclair 容器不包含在啟動時將比特幣轉入其錢包的腳本。

和之前一樣，我們在一個終端機中啟動 bitcoind 容器，在另一個終端機中啟動 Eclair 容器。如果你已經在執行 bitcoind 容器，則不需要重新啟動它。只需讓它繼續執行並跳過下一步。要在 lnbook 網路中啟動 bitcoind，我們像這樣使用 docker run：

接下來，我們啟動剛剛建構的 Eclair 容器。我們需要將它附加到 lnbook 網路並給它一個名稱，就像我們對其他容器所做的那樣：

Eclair 容器啟動並透過 Docker 網路連接到 bitcoind 容器。首先，我們的 Eclair 節點將等待 bitcoind 啟動，然後它將等待 bitcoind 挖掘一些比特幣到其錢包中。

正如我們之前演示的，我們可以在另一個終端機中向容器發出命令，以提取資訊、開設通道等。允許我們向 eclair 守護程式發出命令列指令的命令稱為 eclair-cli。和之前一樣，在此容器中，我們提供了 eclair-cli 的有用別名，簡稱為 cli，它提供必要的參數。在另一個終端機視窗中使用 docker exec 命令，我們從 Eclair 獲取節點資訊：

我們現在在 lnbook 網路上執行了另一個閃電網路節點，並與 bitcoind 通訊。你可以在同一個閃電網路上執行任意數量和任意組合的閃電網路節點。任意數量的 Eclair、LND 和 c-lightning 節點都可以共存。例如，要執行第二個 Eclair 節點，你可以使用不同的容器名稱發出 docker run 命令，如下所示：

在前面的命令中，我們啟動了另一個名為 eclair2 的 Eclair 容器。

在下一節中，我們還將看看如何直接從原始碼下載和編譯 Eclair。這是一個可選的進階步驟，將教你如何使用 Scala 和 Java 語言建構工具，並允許你對 Eclair 的原始碼進行修改。有了這些知識，你可以編寫一些程式碼或修復一些錯誤。

在本節中，我們將從頭開始建構 Eclair。Eclair 是用 Scala 程式語言編寫的，使用 Java 編譯器編譯。要執行 Eclair，我們首先需要安裝 Java 及其建構工具。我們將遵循 Eclair 專案的 BUILD.md 文件中的說明。

所需的 Java 編譯器是 OpenJDK 11 的一部分。我們還需要一個名為 Maven 的建構框架，版本 3.6.0 或更高。

在 Debian/Ubuntu Linux 系統上，我們可以使用 apt 命令安裝 OpenJDK 11 和 Maven，如下所示：

透過執行以下命令驗證你是否安裝了正確的版本：

我們有 OpenJDK 11.0.7 和 Maven 3.6.1，所以我們準備好了。

Eclair 的原始碼在 GitHub 上。git clone 命令可以為我們建立一個本地副本。讓我們切換到主目錄並在那裡執行它：

一旦 git clone 完成，你將有一個名為 eclair 的子目錄，其中包含 Eclair 伺服器的原始碼。

Eclair 使用 Maven 建構系統。要建構專案，我們將工作目錄更改為 Eclair 的原始碼，然後像這樣使用 mvn package：

幾分鐘後，Eclair 套件的建構應該完成。然而，「package」操作也會執行測試，其中一些連接到網路，可能會失敗。如果你想跳過測試，請在命令中添加 -DskipTests。

現在，按照 GitHub 上的 安裝 Eclair 說明解壓縮並執行建構的套件。

恭喜！你已從原始碼建構了 Eclair，你準備好編寫程式碼、測試、修復錯誤並為這個專案做出貢獻！

為了使這個範例運作，我們將使用一個_容器編排_工具，作為名為 docker-compose 的命令提供。這個命令允許我們指定一個由多個容器組成的應用程式，並透過一起啟動所有協作容器來執行應用程式。

首先，讓我們安裝 docker-compose。https://docs.docker.com/compose/install[說明]取決於你的作業系統。

安裝完成後，你可以透過像這樣執行 docker-compose 來驗證安裝：

最常見的 docker-compose 命令是 up 和 down，例如 docker-compose up。

docker-compose 的配置檔案位於 code/docker 目錄中，名為 docker-compose.yml。它包含網路和四個容器中每個容器的規格。頂部看起來像這樣：

前面的片段定義了一個名為 lnnet 的網路和一個名為 bitcoind 的容器，該容器將附加到 lnnet 網路。這個容器與我們在本章開頭建構的相同。我們暴露了容器的三個埠，允許我們向它發送命令並監控區塊和交易。接下來，配置指定了一個名為「Alice」的 LND 容器。往下你還會看到名為「Bob」（c-lightning）、「Chan」（Eclair）和「Dina」（又是 LND）的容器規格。

由於所有這些不同的實作都遵循 BOLT 規範，並且已經過廣泛的互通性測試，因此它們可以毫無困難地一起工作來建構閃電網路。

在開始之前，我們應該確保沒有正在執行任何容器。如果新容器與已經執行的容器共用相同的名稱，它將無法啟動。根據需要使用 docker ps、docker stop 和 docker rm 來停止和刪除任何當前正在執行的容器！

啟動後，你會看到每個節點啟動並報告其進度時的整個日誌流。在你的螢幕上可能看起來相當混亂，但每個輸出行都以容器名稱為前綴，如前所示。如果你想只觀看一個容器的日誌，可以在另一個終端機視窗中使用帶有 f（follow）標誌和特定容器名稱的 docker-compose logs 命令：

我們的閃電網路現在應該正在執行。正如我們在本章前面章節中看到的，我們可以使用 docker exec 命令向正在執行的 Docker 容器發出命令。無論我們是使用 docker run 啟動容器還是使用 docker-compose up 啟動一堆容器，我們仍然可以使用 Docker 命令單獨存取容器。

支付演示包含在名為 run-payment-demo.sh 的 Bash shell 腳本中。要執行此演示，你必須在電腦上安裝 Bash shell。大多數 Linux 和類 Unix 系統（例如 macOS）都預裝了 bash。Windows 使用者可以安裝 Windows Subsystem for Linux 並使用像 Ubuntu 這樣的 Linux 發行版來在其電腦上獲得原生的 bash 命令。

讓我們執行腳本看看效果，然後我們將看看它內部是如何運作的。我們使用 bash 作為命令執行它：

如你從輸出中看到的，腳本首先獲取四個節點中每個節點的節點 ID（公鑰）。然後，它連接節點並從網路中每個節點到下一個節點建立一個 1,000,000 聰的通道。最後，它從 Dina 的節點發出一張 10,000 聰的發票，並從 Alice 的節點支付該發票。

該腳本中有很多內容需要回顧，但隨著你對底層技術的理解加深，越來越多的資訊將變得清晰。歡迎你稍後再回顧這個範例。

當然，你可以用這個測試網路做的事情遠不止三通道、四節點的支付。以下是一些實驗的想法：

在比特幣中，除非專門運行挖礦節點，否則硬體並不特別重要。 Bitcoin Core 節點軟體可以在任何滿足其最低要求的機器上運行，而且不需要在線才能接收付款——只有發送付款時才需要。 如果比特幣節點長時間離線，使用者只需重新啟動節點，一旦它連接到網路的其餘部分，它就會重新同步區塊鏈。

然而，在閃電網路中，使用者需要同時在線才能發送_和_接收付款。如果閃電網路節點離線，它就無法從任何人那裡接收任何付款，因此其開立的發票無法履行。 此外，離線節點的開放通道不能用於路由付款。你的通道合作夥伴會注意到你離線且無法聯繫你來路由付款。如果你太常離線，他們可能會認為與你通道中鎖定的比特幣是未充分利用的容量，並可能關閉這些通道。我們已經討論過協定攻擊的情況，即你的通道合作夥伴試圖透過提交較早的承諾交易來欺騙你。如果你離線且你的通道沒有被監控，那麼企圖的盜竊可能會成功，一旦時間鎖到期，你將沒有追索權。 因此，節點可靠性對閃電網路節點極為重要。

還有硬體故障和資料遺失的問題。在比特幣中，如果使用者備份了助記詞或私鑰，硬體故障可能是一個微不足道的問題。比特幣錢包和錢包中的比特幣可以很容易地從私鑰在新電腦上恢復。大多數資訊可以從區塊鏈重新下載。

相比之下，在閃電網路中，關於使用者通道的資訊，包括承諾交易和撤銷秘密，不是公開的，只儲存在個別使用者的硬體上。 因此，閃電網路中的軟體和硬體故障很容易導致資金損失。

硬體閃電網路節點主要有三種類型：

虛擬私人伺服器（VPS）和雲端運算服務，如 Microsoft Azure、Google Cloud、Amazon Web Services（AWS）或 DigitalOcean，價格相當實惠，可以非常快速地設定。閃電網路節點可以在這樣的服務上以每月 20 到 40 美元的價格托管。

然而，俗話說，「『雲端』只是別人的電腦。」使用這些服務意味著在別人的電腦上運行你的節點。這帶來了相應的優缺點。主要優點是便利性、效率、正常運行時間，甚至可能是成本。雲端運營商在很大程度上管理和運行節點，自動為你提供便利性和效率。他們提供出色的正常運行時間和可用性，通常比個人在家中可以達到的要好得多。如果你考慮到在許多西方國家僅運行伺服器的電費就約為每月 10 美元，然後加上網路頻寬的成本和硬體本身，VPS 產品在經濟上具有競爭力。最後，使用 VPS，你不需要在家裡為電腦騰出空間，也沒有電腦噪音或熱量的問題。 另一方面，有幾個顯著的缺點。在「雲端」運行的閃電網路節點總是比在你自己的電腦上運行的節點安全性和隱私性更低。此外，這些雲端運算服務非常集中化。在這些服務上運行的絕大多數比特幣和閃電網路節點位於維吉尼亞州、桑尼維爾、西雅圖、倫敦和法蘭克福的少數資料中心。當這些提供商的網路或資料中心出現服務問題時，它會影響所謂「去中心化」網路上的數千個節點。

如果你有可能和能力在家裡或辦公室的自己電腦上運行節點，那麼這可能比在雲端運行更可取。儘管如此，如果運行自己的伺服器不是一個選項，請務必考慮在 VPS 上運行一個。

如果你在家裡或辦公室有合理容量的網路連線，你當然可以在那裡運行閃電網路節點。任何「寬頻」連線都足以運行輕量級節點，快速連線也可以讓你運行比特幣完整節點。

雖然你可以在筆記型電腦上運行閃電網路節點（甚至比特幣節點），但很快就會變得煩人。這些程式會消耗你電腦的資源，需要 24/7 全天候運行。你的使用者應用程式，如瀏覽器或試算表，將與閃電網路背景服務競爭你電腦的資源。換句話說，你的瀏覽器和其他桌面工作負載會變慢。 當你的文書處理應用程式使你的筆記型電腦當機時，你的閃電網路節點也會當機，使你無法接收交易，並可能容易受到攻擊。此外，你永遠不應該關閉你的筆記型電腦。 所有這些加在一起導致的設定不是很理想。同樣的情況也適用於你日常使用的個人桌上型電腦。

相反，大多數使用者會選擇在專用電腦上運行節點。 幸運的是，你不需要一台「伺服器」級的電腦來做到這一點。 你可以在單板電腦上運行閃電網路節點，例如 Raspberry Pi 或迷你電腦（通常作為家庭影院電腦銷售）。 這些是通常用作家庭自動化中心或媒體伺服器的簡單電腦。 與電腦或筆記型電腦相比，它們相對便宜。 專用設備作為閃電網路和比特幣節點平台的優勢在於，它可以在你的家庭網路上持續、靜默且不引人注目地運行，藏在路由器或電視後面。 沒有人會知道這個小盒子實際上是全球銀行系統的一部分！

運行閃電網路節點至少需要以下條件：

當租用雲端伺服器時，在兩個運行階段之間更改配置通常很划算。在 IBD 期間（例如第一天）需要更快的 CPU 和更快的儲存。區塊鏈同步後，CPU 和儲存速度要求就低得多，因此可以將效能降級到更具成本效益的水平。

例如，在 Amazon 的雲端上，我們會在 IBD 期間使用 8-16 GB RAM、8 核心 CPU（例如 t3-large 或 m3.large）和更快的 400 GB SSD（1000+ 配置的每秒輸入/輸出操作數 [IOPS]），將其時間縮短到僅 6-8 小時。完成後，我們會將伺服器實例切換為 2 GB RAM、2 核心 CPU（例如 t3.small）和儲存改為通用 1 TB HDD。這大約與你在較慢的伺服器上運行整個時間的成本相同，但它會讓你在不到一天內啟動並運行，而不是必須等待將近一週的 IBD。

最受歡迎和完整的「助手」之一是 RaspiBlitz（RaspiBlitz 節點），這是由 Christian Rotzoll 建立的專案。它旨在安裝在 Raspberry Pi 4 上。RaspiBlitz 附帶推薦的硬體套件，你可以在幾個小時或最多一個週末內組裝完成。如果你參加你所在城市的閃電網路「黑客松」，你很可能會看到很多人在他們的 RaspiBlitz 設定上工作，交換技巧並互相幫助。你可以在 GitHub 上找到 RaspiBlitz 專案。

除了比特幣和閃電網路節點之外，RaspiBlitz 還可以安裝許多額外的服務，例如：

myNode 是另一個流行的開源「助手」專案，包含許多與比特幣相關的軟體。它易於安裝：你將安裝程式「刷入」SD 卡，然後從 SD 卡啟動你的迷你電腦。你不需要任何顯示器來使用 myNode，因為管理工具可以從瀏覽器遠端存取。如果你的迷你電腦沒有顯示器、滑鼠或鍵盤，你可以從另一台電腦甚至從你的智慧型手機管理它。安裝後，前往 http://mynode.local 並點擊兩下建立閃電網路錢包和節點。

除了比特幣和閃電網路節點之外，myNode 還可以選擇性地安裝各種額外的服務，例如：

以其 UX/UI 聞名（如 Umbrel 網頁介面 所示），Umbrel 提供了一種非常簡單且易於使用的方式來快速啟動和運行你的比特幣和閃電網路節點，特別是對於初學者。一個非常獨特的功能是 Umbrel 在 IBD 期間使用 Neutrino/SPV，這樣你可以立即開始使用你的節點。一旦 Bitcoin Core 在背景完全同步，它會自動切換並停用 SPV 模式。Umbrel OS 支援 Raspberry Pi 4，也可以安裝在任何基於 Linux 的作業系統上，或者在 macOS 或 Windows 上的虛擬機器中。你還可以連接任何支援 Bitcoin Core P2P、Bitcoin Core RPC、Electrum 協定或 lndconnect 的錢包。

不需要等待雨天—你可以直接前往 Umbrel 了解更多資訊。

除了比特幣和閃電網路節點之外，Umbrel 推出了 Umbrel App Store，你可以在其中輕鬆安裝額外的服務，例如：

Umbrel 目前仍處於測試階段，不被認為是安全的。

雖然最初不是作為安裝「助手」設計的，但電子商務和支付平台 BTCPay Server 有一個非常簡單的安裝系統，使用 Docker 容器和 docker-compose 來安裝比特幣節點、閃電網路節點和支付閘道，以及許多其他服務。它可以安裝在各種硬體平台上，從簡單的 Raspberry Pi 4（建議 4 GB）到迷你電腦或舊筆記型電腦、桌上型電腦或伺服器。

BTCPay Server 是一個功能齊全的自托管、自保管電子商務平台，可以與許多電子商務平台整合，例如 WordPress WooCommerce 等。完整節點的安裝只是電子商務平台安裝的一個步驟。 雖然最初是作為 BitPay 商業支付服務和 API 的功能對功能替代品開發的，但它已經超越了這一點，成為與電子商務相關的 BTC 和閃電網路服務的完整平台。對於許多賣家或商店來說，這是一個電子商務的一站式交鑰匙解決方案。

除了比特幣和閃電網路節點之外，BTCPay Server 還可以安裝各種服務，包括：

額外服務和功能的數量正在快速增長，因此前面的列表只是 BTCPay Server 平台上可用內容的一小部分。

你設定的一個關鍵選擇將是比特幣節點及其配置的選擇。Bitcoin Core，參考實作，是最常見的選擇，但不是唯一可用的選擇。一個替代選擇是 btcd，它是比特幣節點的 Go 語言實作。btcd 支援一些對運行 LND 閃電網路節點有用的功能，這些功能在 Bitcoin Core 中不可用。

第二個考慮因素是你是否會運行一個帶有區塊鏈完整副本（2021 年中約 350 GB）的_存檔_比特幣節點，還是一個只保留最近區塊的_修剪_區塊鏈。修剪的區塊鏈可以為你節省一些磁碟空間，但你仍然需要至少下載一次完整的區塊鏈（在 IBD 期間）。因此，它不會為你節省任何網路流量。使用修剪節點運行閃電網路節點仍然是一個實驗性功能，可能不支援所有功能。然而，許多人正在成功運行這樣的節點。

最後，你也可以選擇根本不運行比特幣節點。相反，你可以使用 Neutrino 協定以「輕量級」模式操作 LND 閃電網路節點，從其他人操作的公共比特幣節點檢索區塊鏈資訊。這樣運行意味著你在沒有提供任何回報的情況下從比特幣網路獲取資源。相反，你是在提供你的資源並為閃電網路社群做出貢獻。對於較小的閃電網路節點，與運行完整比特幣節點相比，這通常會減少網路流量。

請記住，操作比特幣節點允許你支援其他服務，除了閃電網路節點之外。這些其他服務可能需要存檔（非修剪）比特幣節點，通常無法在沒有比特幣節點的情況下運行。預先考慮你現在或將來可能想要運行的其他服務，以便對你選擇的比特幣節點類型做出明智的決定。

這個決定的底線是：如果你能負擔得起大於 500 GB 的磁碟，請運行完整的存檔比特幣節點。你將為比特幣系統貢獻資源，並幫助那些負擔不起這樣做的人。如果你負擔不起這麼大的磁碟，運行修剪節點。如果你連修剪節點的磁碟或頻寬都負擔不起，運行一個使用 Neutrino 的輕量級 LND 節點。

下一步是為你的節點選擇一個作業系統。絕大多數網路伺服器運行某種 Linux 變體。Linux 是網路的首選平台，因為它是一個強大的開源作業系統。然而，Linux 有一個陡峭的學習曲線，需要熟悉命令列環境。對於新使用者來說，它通常令人望而生畏。

最終，大多數服務可以在任何現代 POSIX 作業系統上運行，包括 macOS、Windows，當然還有 Linux。你的選擇應該更多地取決於你對作業系統的熟悉程度和舒適度以及你的學習目標。如果你想擴展你的知識並學習如何操作 Linux 系統，這是一個很好的機會，可以透過特定專案和明確目標來實現。如果你只想讓節點啟動並運行，就選擇你熟悉的。

如今，許多服務也以容器的形式提供，通常基於 Docker 系統。這些容器可以部署在各種作業系統上，抽象化底層作業系統。儘管如此，你可能仍然需要學習一些 Linux CLI 命令，因為大多數容器內部運行某種 Linux 變體。

對於那些習慣在桌面或智慧型手機上運行應用程式的人來說，應用程式總是有圖形使用者介面，即使它有時可能在背景運行。然而，比特幣和閃電網路節點應用程式非常不同。這些應用程式沒有內建的圖形使用者介面。相反，它們作為_無頭_背景服務運行，這意味著它們始終在背景操作，不直接與使用者互動。

這可能會給不習慣運行背景服務的使用者帶來一些困惑。你如何知道這樣的服務目前是否正在運行？你如何啟動和停止它？你如何與它互動？這些問題的答案取決於你使用的作業系統。現在我們假設你使用某種 Linux 變體，並在該環境下回答這些問題。

背景服務通常在特定的使用者帳戶下運行，以將它們與作業系統和彼此隔離。例如，Bitcoin Core 被配置為以使用者 bitcoin 運行。你需要使用命令列為你運行的每個服務建立一個使用者。

此外，如果你連接了外部驅動器，你需要告訴作業系統將使用者的主目錄重新定位到該驅動器。這是因為像 Bitcoin Core 這樣的服務會在使用者的主目錄下建立檔案。如果你將其設定為下載完整的比特幣區塊鏈，這些檔案將佔用數百 GB。在這裡，我們假設你已經連接了外部驅動器，並且它位於作業系統的 /external_drive/ 路徑上。

在大多數 Linux 系統上，你可以使用 useradd 命令建立新使用者，如下所示：

m 和 d 標誌建立使用者的主目錄，在本例中指定為 /external_drive/bitcoin。s 標誌分配使用者的互動式 shell。在本例中，我們將其設定為 /dev/null 以停用互動式 shell 使用。最後一個參數是新使用者的使用者名 bitcoin。

對於比特幣和閃電網路節點服務，「安裝」還包括建立所謂的_啟動腳本_，以確保節點在電腦啟動時啟動。背景服務的啟動和關閉由作業系統程序處理，在 Linux 中稱為 init 或 systemd。你通常可以在每個專案的 contrib 子目錄中找到系統啟動腳本。例如，如果你在使用 systemd 的現代 Linux 作業系統上，你會找到一個名為 bitcoind.service 的腳本，它可以啟動和停止 Bitcoin Core 節點服務。

以下是比特幣節點啟動腳本的範例，取自 Bitcoin Core 程式碼儲存庫：

作為 root 使用者，透過將腳本複製到 systemd 服務資料夾 /lib/systemd/system/ 來安裝腳本，然後重新載入 systemd：

你現在可以啟動和停止服務。先不要啟動它，因為我們還沒有配置比特幣節點。

要配置你的節點，你需要建立並引用一個配置檔案。按照慣例，這個檔案通常在 /etc 中建立，在一個以程式名稱命名的目錄下。例如，Bitcoin Core 和 LND 配置通常分別儲存在 /etc/bitcoin/bitcoin.conf 和 /etc/lnd/lnd.conf 中。

這些配置檔案是文字檔案，每行表達一個配置選項及其值。配置檔案中未定義的任何內容都假定為預設值。你可以透過兩種方式查看配置中可以設定的選項。首先，使用 help 參數運行節點應用程式將顯示可以在命令列上定義的選項。這些相同的選項可以在配置檔案中定義。其次，你通常可以在軟體的程式碼儲存庫中找到一個範例配置檔案，其中包含所有預設選項。

你可以在我們在 閃電網路節點軟體 中使用的每個 Docker 映像中找到一個配置檔案範例。例如，檔案 code/docker/bitcoind/bitcoind/bitcoin.conf：

該特定配置檔案將 Bitcoin Core 配置為作為 regtest 節點運行，並提供弱使用者名和密碼用於遠端存取，因此你不應該將其用於你的節點配置。然而，它用於說明配置檔案的語法，你可以在 Docker 容器中對其進行調整以試驗不同的選項。看看你是否可以使用 bitcoind -help 命令來理解每個選項在我們在 閃電網路節點軟體 中建構的 Docker 網路的環境下做什麼。

通常，預設值就足夠了，只需進行少量修改即可快速配置你的節點軟體。要使 Bitcoin Core 節點以最少的自訂運行，你只需要四行配置：

甚至 txindex 選項也不是嚴格必需的，儘管它將確保你的比特幣節點建立所有交易的索引，這是某些應用程式所必需的。運行閃電網路節點不需要 txindex 選項。

在同一伺服器上運行的 c-lightning 閃電網路節點也只需要在配置中添加幾行：

一般來說，最好盡量減少對這些系統的自訂。預設配置經過精心設計，以支援最常見的部署。如果你修改預設值，以後可能會導致問題或降低節點的效能。簡而言之，只在必要時修改！

在配置新應用程式時，網路配置通常不是問題。然而，像比特幣和閃電網路這樣的點對點網路對網路配置提出了一些獨特的挑戰。

在集中式服務中，你的電腦連接到某些公司的「大型伺服器」，而不是相反。你的家庭網路連線實際上是假設你只是他人提供的服務的消費者來配置的。但在點對點系統中，每個對等節點既消費也提供服務給其他節點。如果你在家裡運行比特幣或閃電網路節點，你就是在為網路上的其他電腦提供服務。你的網路服務預設未配置為允許你運行伺服器，可能需要一些額外配置才能讓其他人連接到你的節點。

如果你想運行比特幣或閃電網路節點，你需要讓網路上的其他節點能夠連接到你。這意味著需要啟用到比特幣埠（預設埠 8333）或閃電網路埠（預設埠 9735）的傳入 TCP 連線。雖然你可以在沒有傳入連線的情況下運行比特幣節點，但閃電網路節點不能這樣做。閃電網路節點必須從你的網路外部可被其他人存取。

預設情況下，你的家庭網路路由器不期望來自外部的傳入連線，事實上傳入連線是被阻擋的。你的網路路由器 IP 位址是唯一外部可存取的 IP 位址，你家庭網路內運行的所有電腦都共享該單一 IP 位址。這是透過一種稱為_網路位址轉換_（NAT）的機制實現的，它允許你的網路路由器充當所有外出連線的中介。如果你想允許傳入連線，你必須設定_埠轉發_，它告訴你的網路路由器特定埠上的傳入連線應該轉發到網路內的特定電腦。你可以透過變更網路路由器配置手動完成此操作，或者如果你的路由器支援，透過稱為_通用隨插即用_（UPnP）的自動埠轉發機制完成。

另一種替代埠轉發的機制是啟用洋蔥路由器（Tor），它提供一種虛擬私人網路覆蓋，允許傳入連線到_洋蔥位址_。如果你運行 Tor，你不需要進行埠轉發或啟用到比特幣或閃電網路埠的傳入連線。如果你使用 Tor 運行節點，所有流量都經過 Tor，不使用其他埠。

讓我們看看可以讓其他人連接到你的節點的不同方式。我們將按從最簡單到最困難的順序來看這些替代方案。

保護作業系統是一個超出本書範圍的廣泛話題。然而，我們可以建立一些基本原則。

為了保護你的作業系統，以下是一些需要考慮的首要事項：

這是最基本安全措施的列表。它絕不是詳盡無遺的。

你的閃電網路節點將公開一個遠端程序呼叫（RPC）API。這意味著你的節點可以透過發送到特定 TCP 埠的命令遠端控制。對該 RPC API 的存取控制是透過某種形式的使用者認證來實現的。根據你設定的閃電網路節點類型，這將透過 使用者名/密碼 認證或稱為認證 macaroon 的機制來完成。顧名思義，macaroon 是一種更複雜的 cookie 類型。與 cookie 不同，它經過加密簽名，可以表達一組存取 功能。

例如，LND 使用 macaroons 來授予對 RPC API 的存取權限。預設情況下，LND 軟體建立三個具有不同存取級別的 macaroons，稱為 admin、invoice 和 readonly。根據你複製並在 RPC 客戶端中使用的 macaroon，你可以擁有_唯讀_存取權、_發票_存取權（包括唯讀功能）或_管理員_存取權，這給你完全控制權。LND 中還有一個 macaroon bakery 功能，可以用非常精細的控制構建具有任意功能組合的 macaroons。

如果你使用使用者名/密碼認證模型，請確保選擇一個長而隨機的密碼。你不需要經常輸入這個密碼，因為它將儲存在配置檔案中。因此，你應該選擇一個無法猜測的密碼。你看到的許多範例包含選擇不當的密碼，人們經常將這些複製到他們自己的系統中，為任何人提供輕鬆的存取。不要這樣做！使用密碼管理器生成一個長的隨機字母數字密碼。由於某些特殊字元如 $?/!*\&%`"' 可能會干擾命令列，因此最好避免在 shell 環境中使用的密碼中使用這些字元。為避免問題，請堅持使用長的隨機字母數字密碼。

超過 12 個字元且隨機生成的純字母數字序列通常就足夠了。如果你計劃在閃電網路節點上存放大量資金，並且擔心遠端暴力攻擊，請選擇超過 20 個字元的密碼長度，使此類攻擊實際上不可行。

如 我們之前討論過的，閃電網路由一個_熱錢包_網路組成。你儲存在閃電網路錢包中的資金始終在線上。這使它們容易受到攻擊。因此，你不應該在閃電網路錢包中存放大量資金。大量資金應該保存在_不_在線上並且只能在鏈上交易的_冷_錢包中。

即使你一開始存放少量資金，隨著時間的推移，你可能仍然會發現閃電網路錢包中有大量資金。這是商店老闆的典型場景。如果你將閃電網路節點用於電子商務操作，你的錢包可能會經常收到資金，但很少發送資金。因此，你最終會同時遇到兩個問題。首先，你的通道會不平衡，本地餘額大於遠端餘額。其次，你的錢包中會有太多資金。幸運的是，你也可以同時解決這兩個問題。

讓我們看看一些可以用來減少熱錢包中暴露資金的解決方案。

如果你的閃電網路錢包餘額對你的風險承受能力來說變得太大，你將需要從錢包中「清掃」資金。你可以透過三種方式做到這一點：鏈上、鏈下和 Loop Out。讓我們在接下來的幾節中看看這些選項。

如果你有時間和技能，你應該在閃電網路測試網上測試一些基本的故障場景。在測試網上，你將學習到寶貴的經驗，而不會冒任何資金風險。你採取的任何自動化系統的步驟都將提高你的可用性：

監控你的節點是保持其運行的重要部分。你不僅需要監控電腦本身的可用性，還需要監控閃電網路節點軟體的可用性和正確運行。

有多種方法可以做到這一點，但大多數需要一些自訂。你可以使用通用的基礎設施監控或應用程式監控工具，但你必須專門自訂它們來查詢閃電網路節點 API，以確保節點正在運行、已與區塊鏈同步並連接到通道對等方。

Lightning.watch 提供一項專門的服務，提供閃電網路節點監控。它使用 Telegram 機器人來通知你任何服務中斷。這是一項免費服務，但你可以付費（當然是透過閃電網路）以獲得更快的警報。

隨著時間的推移，我們期望更多第三方服務提供專門的閃電網路節點監控，並透過微支付付費。也許這些服務及其 API 將標準化，並有一天被閃電網路節點軟體直接支援。

_瞭望塔_是一種將閃電網路協定違規的監控和懲罰解決外包的機制。

正如我們在前幾章中提到的，閃電網路協定透過懲罰機制來維護安全性。如果你的通道合作夥伴之一廣播舊的承諾交易，你的節點將需要行使撤銷條款並廣播懲罰交易以避免資金損失。但如果你的節點在協定違規期間處於離線狀態，你可能會損失資金。

為了解決這個問題，我們可以使用一個或多個瞭望塔來外包監控協定違規和發出懲罰交易的工作。瞭望塔設定有兩個部分：瞭望塔伺服器（或簡稱瞭望塔）監控區塊鏈，瞭望塔客戶端請求瞭望塔伺服器提供此監控服務。

瞭望塔技術仍處於早期開發階段，並未得到廣泛支援。然而，在以下段落中，我們列出了一些你可以嘗試的實驗性實作。

LND 軟體包含瞭望塔伺服器和瞭望塔客戶端。你可以透過添加以下配置選項來啟動瞭望塔伺服器：

你可以透過在配置中啟動 LND 的瞭望塔客戶端，然後使用命令列將其連接到瞭望塔伺服器來使用它。配置如下：

LND 的命令列客戶端 lncli 顯示以下用於管理瞭望塔客戶端的選項：

c-lightning 具有瞭望塔客戶端外掛程式所需的 API 掛鉤，儘管目前尚未實作此類外掛程式。

最後，一個流行的獨立瞭望塔伺服器是 The Eye of Satoshi（TEOS）。它可以在 GitHub 上找到。

一旦你的閃電網路節點啟動並運行，你就可以為其比特幣錢包注資，然後開始用這些資金開啟通道。

你必須謹慎選擇通道合作夥伴，因為你的節點發送付款的能力取決於你的通道合作夥伴是誰，以及他們與閃電網路其餘部分的連接程度。你還希望擁有多個通道，以避免單點故障。由於閃電網路現在支援多部分付款，你可以將初始資金分成幾個通道，並透過組合它們的容量來路由更大的付款。同時，避免讓你的通道太小。由於你需要支付比特幣交易費用來開啟和關閉通道，通道餘額不應該小到鏈上費用消耗其中很大一部分。一切都是關於平衡！

總結：

找到連接良好的節點的一種方法是向在閃電網路上銷售產品的熱門商家開啟通道。這些節點往往資金充足且連接良好。因此，當你準備好透過閃電網路在線上購買東西時，你可以直接向商家的節點開啟通道。商家的節點 ID 將在你嘗試購買東西時收到的發票中。這使得它很容易。

找到連接良好的節點的另一種方法是使用閃電網路瀏覽器（參見 閃電網路瀏覽器），如 1ML，並瀏覽按通道容量和通道數量排序的節點列表。不要選擇最大的節點，因為那會鼓勵中心化。選擇列表中間的節點，這樣你可以幫助它們成長。另一個需要考慮的因素可能是節點運營的時間跨度。運營超過一年的節點可能比一週前開始運營的節點更有信譽且風險更低。

在閃電網路的當前設計中，使用者更典型的是_先_獲取出站流動性，_然後_獲取入站流動性。 他們會透過與另一個節點開啟通道來做到這一點，通常他們會在能夠接收比特幣之前先能夠花費比特幣。 有三種典型的方式獲取入站流動性：

從實際和使用者體驗的角度來看，創建入站流動性是具有挑戰性的。入站流動性不會自動發生，所以你必須找到方法為你的節點建立它。支付通道的這種不對稱性也不直觀。在大多數其他支付系統中，你先收到付款（入站），然後才付款給其他人（出站）。

如果你是商家或為閃電網路付款出售服務，創建入站流動性的挑戰最為明顯。在這種情況下，你需要保持警惕，確保你有足夠的入站流動性來繼續接收付款。如果你的商店有買家激增，但他們實際上因為沒有更多入站容量而無法付款給你怎麼辦？

在未來，這些挑戰可以透過實作雙向資助通道來部分緩解，這種通道從雙方資助，提供平衡的入站和出站容量。這種負擔也可以透過更複雜的自動導航軟體來減輕，它可以根據需要請求並支付入站容量。

最終，閃電網路使用者需要對通道管理有策略且主動，以確保有足夠的入站容量來滿足他們的需求。

如本書前面所討論的，協作關閉_是關閉通道的首選方式。然而，有些情況下需要_強制關閉。

一些例子：

在閃電網路上進行交易和路由付款的過程中，入站和出站容量的組合可能會變得不平衡。

例如，如果你的通道合作夥伴之一頻繁透過你的節點路由付款，你將耗盡該通道的入站容量，同時也耗盡出站通道的出站容量。一旦發生這種情況，你就無法再透過該路由路由付款。

有很多方法可以重新平衡通道，每種方法都有不同的優缺點。一種方法是使用潛水艇交換（例如 Loop Out），如本章前面所述。另一種重新平衡的方法是簡單地等待以相反方向流動的路由付款。如果你的節點連接良好，當特定路由在一個方向上耗盡時，相同的路由在相反方向上就變得可用。其他節點可能會「發現」相反方向的該路由並開始將其用作其付款路徑的一部分，從而再次重新平衡資金。

重新平衡通道的第三種方法是故意創建一個_循環路由_，將付款從你的節點透過閃電網路發送回你的節點。透過在具有大量本地容量的通道上發送付款，並安排路徑使其在具有大量遠端容量的通道上返回你的節點，這兩個通道都將變得更加平衡。循環路由重新平衡策略的範例可以在 循環路由重新平衡 中看到。

大多數閃電網路節點實作都支援循環重新平衡，可以在命令列上或透過 Ride The Lightning（參見 Ride The Lightning）等網頁管理介面完成。

通道重新平衡是一個複雜的問題，是活躍研究的主題，在 重新平衡通道 中有更詳細的介紹。

Ride The Lightning（RTL）是一個圖形化網頁使用者介面，幫助使用者管理三個主要閃電網路節點實作（LND、c-lightning 和 Eclair）的閃電網路節點操作。RTL 是由 Shahana Farooqui 和許多其他貢獻者開發的開源專案。你可以在 GitHub 上找到 RTL 軟體。

RTL 網頁介面範例 顯示了 RTL 網頁介面的範例螢幕截圖，如專案儲存庫所提供。

Lightning Labs，LND 的製造商，提供了一個名為 lndmon 的基於網頁的圖形使用者介面來監控 LND 閃電網路節點的各種指標。lndmon 僅適用於 LND 節點。它是用於監控的唯讀介面，因此不允許你主動管理節點。它無法開啟通道或進行付款。在 GitHub 上找到 lndmon。

ThunderHub 是一個非常美觀的基於網頁的圖形使用者介面，類似於 RTL，但專屬於 LND。它可用於進行付款、重新平衡通道，並透過各種功能管理節點。

私鑰的所有權和控制權並不總是掌握在一個人手中。這就是事情變得有趣和複雜的地方。我們知道，不止一個人可以知道相同的私鑰，無論是透過盜竊還是因為原始金鑰持有者複製並交給其他人。這些人都是所有者嗎？從實際意義上說，他們是的，因為知道私鑰的任何人都可以在未經任何其他人批准的情況下花費比特幣。

比特幣還有多重簽名地址，在花費之前需要多個私鑰簽名（參見 多重簽章腳本）。從實際角度來看，多重簽名地址中的所有權取決於 K-of-N 方案中定義的法定人數（K）和總數（N）。1-of-10 多重簽名方案將允許 10 個（N）簽名者中的任何 1 個（K）花費鎖定在該地址中的比特幣金額。這類似於 10 個人擁有相同私鑰副本且任何人都可以獨立花費的場景。

還有一種_無人_擁有法定人數的情況。在閃電網路使用的 2-of-2 方案中，任何一方都不能在未獲得對方簽名的情況下花費比特幣。在這種情況下，誰擁有比特幣？實際上沒有人擁有所有權，因為沒有人擁有控制權。他們每個人擁有相當於決策中的投票權，但需要雙方投票。在比特幣和法律中，2-of-2 方案的一個關鍵問題（雙關語）是，如果其中一方無法聯繫，或者如果投票陷入僵局且任何一方拒絕合作，會發生什麼。

如果 2-of-2 多重簽名的兩個簽名者之一不能或不願意簽名，資金將變得無法花費。這種情況不僅可能意外發生（金鑰丟失），而且可以被任何一方用作一種勒索形式：「除非你把部分資金給我，否則我不簽名。」

閃電網路中的支付通道基於 2-of-2 多重簽名地址，兩個通道合作夥伴作為多重簽名中的簽名者。目前，通道只由兩個通道合作夥伴中的一個出資：當你選擇「開啟」一個通道時，你透過交易將資金存入 2-of-2 多重簽名地址。一旦該交易被挖掘並且資金在多重簽名中，如果沒有你的通道合作夥伴的合作，你就無法取回它們，因為你也需要他們的簽名來花費比特幣。

在下一節中，當我們研究如何開啟（創建）閃電網路通道時，我們將看到如何透過實施通道建構的公平協定來防止資金損失或兩個合作夥伴之間的任何勒索情況，借助預先簽名的交易來花費多重簽名輸出，以一種給予通道中對等方獨家能力花費其中一個輸出的方式，該輸出編碼了他們在通道中擁有的比特幣數量。

閃電網路上的每個節點都由一個_節點公鑰_標識。公鑰唯一標識特定節點，通常以十六進制編碼呈現。例如，René Pickhardt 目前運行一個閃電網路節點（ln.rene-pickhardt.de），由以下節點公鑰標識：

每個節點在首次初始化時生成一個根私鑰。私鑰始終保持私密（從不分享）並安全地儲存在節點的錢包中。從該私鑰，節點衍生出作為節點標識符並與網路分享的公鑰。由於金鑰空間非常龐大，只要每個節點隨機生成私鑰，它就會擁有唯一的公鑰，因此可以在網路上唯一標識它。

此外，每個節點還會公告可以聯繫到它的網路地址，以下幾種可能的格式之一：

網路地址標識符寫作 Address:Port，這與國際標準的網路標識符一致，例如在網頁上使用的。

例如，René 的節點公鑰為 02a1ceb...45ea7b8，目前公告其網路地址為 TCP/IP 地址：

節點公鑰和網路地址一起，以以下格式書寫，用 @ 符號分隔，如 NodeID@Address:Port。

所以 René 的節點的完整標識符將是：

前面的標識符通常編碼在 QR 碼中，如果使用者想要將他們自己的節點連接到由該地址標識的特定節點，可以更容易地掃描。

就像比特幣節點一樣，閃電網路節點透過「八卦」其節點公鑰和網路地址來公告它們在閃電網路上的存在。這樣，其他節點可以找到它們，並保持一個清單（資料庫），記錄所有它們可以連接並交換閃電網路 P2P 訊息協定中定義的訊息的已知節點。

為了讓 Alice 的節點連接到 Bob 的節點，她需要 Bob 的節點公鑰，或者包含公鑰、IP 或 Tor 地址和埠的完整地址。因為 Bob 經營一家商店，Bob 的節點地址可以從發票或網路上的商店支付頁面獲取。Alice 可以掃描包含地址的 QR 碼，並指示她的節點連接到 Bob 的節點。

一旦 Alice 連接到 Bob 的節點，他們的節點現在就是直接連接的對等方。

通道管理的閃電網路對等協定在 BOLT #2：通道管理的對等協定 中定義。在本章中，我們將更詳細地回顧 BOLT #2 的「通道建立」和「通道關閉」部分。

通道建立是透過 Alice 和 Bob 節點之間交換六個訊息實現的（每個對等方三個）：open_channel、accept_channel、funding_created、funding_signed、funding_locked 和 funding_locked。這六個訊息在 通道建立訊息流程 中以時序圖顯示。

在 通道建立訊息流程 中，Alice 和 Bob 的節點由圖表兩側的垂直線「A」和「B」表示。像這樣的時序圖顯示時間向下流動，訊息在兩個通訊對等方之間從一側流向另一側。線條向下傾斜以表示傳輸每個訊息所需的時間，訊息的方向由每條線末端的箭頭顯示。

通道建立涉及三個部分。首先，兩個對等方透過 Alice 發起 open_channel 請求和 Bob 透過 accept_channel 接受通道請求來溝通他們的能力和期望。

其次，Alice 構建資金和退款交易（我們將在本節稍後看到），並向 Bob 發送 funding_created。「退款」交易的另一個名稱是「承諾」交易，因為它承諾了通道中餘額的當前分配。Bob 透過 funding_signed 回覆必要的簽名。這種互動是保護通道和防止盜竊的_加密協定_的基礎。Alice 現在將廣播資金交易（鏈上）以建立和錨定支付通道。該交易需要在比特幣區塊鏈上得到確認。

一旦交易有足夠的確認（由 accept_channel 訊息中的 minimum_depth 欄位定義），Alice 和 Bob 交換 funding_locked 訊息，通道進入正常運作模式。

一旦 Alice 的節點收到 Bob 的 accept_channel 訊息，它就有了構建將通道錨定到比特幣區塊鏈的_資金交易_所需的資訊。正如我們在前幾章中討論的，閃電網路支付通道由 2-of-2 多重簽名地址錨定。首先，我們需要生成該多重簽名地址，以便我們可以構建資金交易（以及隨後描述的退款交易）。

資金交易將一定數量的比特幣（來自 open_channel 訊息的 funding_satoshis）發送到由 Alice 和 Bob 的 funding_pubkey 公鑰構建的 2-of-2 多重簽名輸出。

Alice 的節點構建如下所示的多重簽名腳本：

請注意，在實踐中，資金金鑰在放入見證腳本之前會確定性地_排序_（使用序列化壓縮格式公鑰的字典順序）。透過事先同意這種排序順序，我們確保雙方將構建相同的資金交易輸出，該輸出由交換的承諾交易簽名簽署。

此腳本編碼為 Pay-to-Witness-Script-Hash（P2WSH）比特幣地址，看起來像這樣：

Alice 的節點現在可以構建資金交易，將與 Bob 商定的金額（funding_satoshis）發送到 2-of-2 多重簽名地址。假設 funding_satoshis 是 140,000，Alice 正在花費一個 200,000 satoshi 的輸出並創建 60,000 satoshi 的找零。交易看起來會像 Alice 構建資金交易。

Alice _不廣播_這筆交易，因為這樣做會讓她的 140,000 satoshi 面臨風險。一旦花費到 2-of-2 多重簽名，如果沒有 Bob 的簽名，Alice 就無法取回她的錢。

使閃電網路成為可能的一個重要比特幣功能是構建和簽署交易但不廣播它們的能力。該交易在各方面都是_有效的_，但在它被廣播並在比特幣區塊鏈上確認之前，它不被承認，其輸出不能花費，因為它們尚未在區塊鏈上創建。我們將在閃電網路中多次使用這種能力，Alice 的節點在構建資金交易時使用這種能力：持有它並且尚未廣播它。

為了防止資金損失，Alice 在有辦法在出問題時獲得退款之前，不能將她的比特幣放入 2-of-2。本質上，她必須在進入這種安排之前計劃好「退出」通道。

考慮婚前協議的法律構造，也稱為「prenup」。當兩個人結婚時，他們的錢依法（取決於司法管轄區）綁定在一起。在結婚之前，他們可以簽署一份協議，指定如果他們透過離婚解除婚姻，如何分割他們的資產。

我們可以在比特幣中創建類似的協議。例如，我們可以創建一個退款交易，它的功能類似於婚前協議，允許雙方在他們的資金實際鎖定到多重簽名資金地址之前決定如何分配他們通道中的資金。

Alice 將在構建（但不廣播）資金交易後立即構建退款交易。退款交易將 2-of-2 多重簽名 花費回 Alice 的錢包。我們將這個退款交易稱為_承諾交易_，因為它承諾雙方通道合作夥伴公平分配通道餘額。由於 Alice 獨自為通道注資，她獲得全部餘額，Alice 和 Bob 都承諾用這筆交易退款給 Alice。

在實踐中，它比較複雜，我們將在後續章節中看到，但現在讓我們保持簡單，假設它看起來像 Alice 也構建退款交易。

在本章後面，我們將看到如何創建更多承諾交易以不同金額分配通道餘額。

現在，Alice 已經構建了 Alice 也構建退款交易 中顯示的兩個交易。但你可能想知道這是怎麼可能的。Alice 還沒有將資金交易廣播到比特幣區塊鏈。就網路上的每個人而言，該交易不存在。退款交易被構建為_花費_資金交易的其中一個輸出，即使該輸出也還不存在。如何花費尚未在比特幣區塊鏈上確認的輸出？

退款交易尚不是有效交易。要使其成為有效交易，必須發生兩件事：

請注意 Alice 是如何計算出 6da3c2...387710 作為資金交易雜湊的？如果資金交易被廣播，該雜湊將被記錄為資金交易的交易 ID。因此，資金交易的 0 輸出（2-of-2 地址輸出）將被引用為輸出 ID 6da3c2...387710:0。即使退款交易尚不存在，也可以構建為花費該資金交易輸出，因為 Alice 知道一旦確認其標識符將是什麼。

這意味著 Alice 可以透過引用尚不存在的輸出來創建鏈接交易，知道如果資金交易被確認，該引用將是有效的，使退款交易也有效。正如我們將在下一節中看到的，這種在廣播之前鏈接交易的「技巧」需要比特幣在 2017 年 8 月引入的一個非常重要的功能：隔離見證。

Alice 必須依賴在確認之前知道資金交易的交易 ID。但在 2017 年 8 月引入隔離見證（SegWit）之前，這不足以保護 Alice。由於交易的構建方式，簽名（見證）包含在交易 ID 中，第三方（例如 Bob）有可能廣播一個具有_可塑_（修改的）交易 ID 的替代版本交易。這被稱為_交易可塑性_，在 SegWit 之前，這個問題使得安全實作無限期生命週期的支付通道變得困難。

如果 Bob 可以在確認之前修改 Alice 的資金交易，並產生具有不同交易 ID 的副本，Bob 可以使 Alice 的退款交易無效並劫持她的比特幣。Alice 將任由 Bob 擺佈，需要他的簽名來釋放她的資金，並且很容易被勒索。Bob 無法竊取資金，但他可以阻止 Alice 取回資金。

SegWit 的引入使未確認的交易 ID 從第三方的角度變得不可變，這意味著 Alice 可以確定資金交易的交易 ID 不會改變。因此，Alice 可以確信，如果她獲得 Bob 對退款交易的簽名，她就有辦法收回她的錢。她現在有辦法在將資金鎖定到多重簽名之前實施比特幣版的「婚前協議」。

從 Bob 收到 funding_signed 訊息後，Alice 現在有了簽署退款交易所需的兩個簽名。她的「退出計劃」現在是安全的，因此她可以廣播資金交易而不用擔心資金被鎖定。如果出了什麼問題，Alice 可以簡單地廣播退款交易並取回她的錢，而無需 Bob 的任何進一步幫助。

Alice 現在將資金交易發送到比特幣網路，以便它可以被挖掘到區塊鏈中。Alice 和 Bob 都將監控這筆交易，並等待比特幣區塊鏈上的 minimum_depth 確認（例如六次確認）。

原則上，從 Alice 向 Bob 發送付款只是重新分配通道餘額的問題。在付款發送之前，Alice 有 140,000 satoshi，Bob 沒有。在 70,000 satoshi 付款發送後，Alice 有 70,000 satoshi，Bob 也有 70,000 satoshi。

因此，Alice 和 Bob 所要做的就是創建並簽署一個交易，將 2-of-2 多重簽名花費到兩個輸出，分別支付 Alice 和 Bob 他們對應的餘額。我們將這個更新的交易稱為_承諾交易_。

Alice 和 Bob 透過_推進通道狀態_來操作支付通道，透過一系列承諾。每個承諾更新餘額以反映流經通道的付款。Alice 和 Bob 都可以發起新的承諾來更新通道。

在 多個承諾交易 中我們看到幾個承諾交易。

多個承諾交易 中顯示的第一個承諾交易是 Alice 在為通道注資之前構建的退款交易。在圖中，這是承諾 #0。在 Alice 向 Bob 支付 70,000 satoshi 後，新的承諾交易（承諾 #1）有兩個輸出，分別支付 Alice 和 Bob 各自的餘額。我們包含了兩個後續的承諾交易（承諾 #2 和承諾 #3），分別代表 Alice 向 Bob 額外支付 10,000 satoshi 和然後 20,000 satoshi。

每個簽署且有效的承諾交易都可以被任一通道合作夥伴在任何時候用於關閉通道，透過將其廣播到比特幣網路。由於他們都有最新的承諾交易並且可以隨時使用它，他們也可以只是持有它而不廣播。這是他們公平退出通道的保證。

你可能想知道 Alice 和 Bob 怎麼可能有多個承諾交易，所有這些交易都試圖花費資金交易的同一個 2-of-2 輸出。這些承諾交易不是衝突的嗎？這不是比特幣系統旨在防止的「雙重花費」嗎？

確實是！事實上，我們依賴比特幣_防止_雙重花費的能力來使閃電網路運作。無論 Alice 和 Bob 構建和簽署多少承諾交易，只有其中一個可以真正得到確認。

只要 Alice 和 Bob 持有這些交易而不廣播它們，資金輸出就是未花費的。但如果一個承諾交易被廣播並確認，它將花費資金輸出。如果 Alice 或 Bob 試圖廣播多個承諾交易，只有其中一個會被確認，其他的將被拒絕為嘗試（且失敗的）雙重花費。

如果多個承諾交易被廣播，有許多因素會決定哪一個首先被確認：包含的費用金額、這些競爭交易的傳播速度、網路拓撲等。本質上它變成了一場結果不可預測的競賽。這聽起來不太安全。聽起來像是有人可以作弊。

讓我們更仔細地看看 多個承諾交易 中的承諾交易。所有四個承諾交易都已簽署且有效。但只有最後一個準確反映了最新的通道餘額。在這個特定場景中，Alice 有機會透過廣播一個較舊的承諾並讓它在比特幣區塊鏈上確認來作弊。假設 Alice 傳輸承諾 #0 並讓它確認：她將有效地關閉通道並獨自拿走所有 140,000 satoshi。事實上，在這個特定例子中，除了承諾 #3 以外的任何承諾都會改善 Alice 的狀況，並允許她「取消」至少部分反映在通道中的付款。

在下一節中，我們將看到閃電網路如何透過撤銷和懲罰機制解決這個問題——防止較舊的承諾交易被通道合作夥伴使用。還有其他方法可以防止傳輸較舊的承諾交易，例如 eltoo 通道，但它們需要對比特幣進行升級，稱為輸入重新綁定（參見 比特幣協定和比特幣腳本創新）。

比特幣交易不會過期，也不能被「取消」。一旦廣播，它們也不能被停止或審查。那麼我們如何「撤銷」另一個人持有的已經簽署的交易呢？

閃電網路中使用的解決方案是公平協定的另一個例子。不是試圖控制廣播交易的能力，而是有一個內建的_懲罰機制_，確保潛在作弊者傳輸舊承諾交易不符合其最佳利益。他們總是可以廣播它，但如果他們這樣做，很可能會損失金錢。

閃電網路協定的撤銷和懲罰機制有三個組成要素：

讓我們依次看看這三個要素。

Alice 和 Bob 持有略有不同的承諾交易。讓我們更詳細地看看 多個承諾交易 中的承諾 #2，如 承諾交易 #2 所示。

Alice 和 Bob 持有此交易的兩個不同變體，如 不對稱承諾交易 所示。

按照慣例，在閃電網路協定中，我們將兩個通道合作夥伴稱為 self（也稱為 local）和 remote，取決於我們從哪一側看。支付給每個通道合作夥伴的輸出分別稱為 to_local 和 to_remote。

在 不對稱承諾交易 中，我們看到 Alice 持有一個交易，支付 60,000 satoshi to_self（可以由 Alice 的金鑰花費），和 80,000 satoshi to_remote（可以由 Bob 的金鑰花費）。

Bob 持有該交易的鏡像，其中第一個輸出是 80,000 satoshi to_self（可以由 Bob 的金鑰花費），和 60,000 satoshi to_remote（可以由 Alice 的金鑰花費）。

使用不對稱交易允許協定輕鬆將_責任_歸咎於作弊方。確保_廣播_方必須始終等待的不變性確保「誠實」方有時間反駁索賠並撤銷他們的資金。這種不對稱性體現在每一方的不同輸出形式中：to_local 輸出始終被時間鎖定，不能立即花費，而 to_remote 輸出沒有時間鎖定，可以立即花費。

例如，在 Alice 持有的承諾交易中，支付給她的 to_local 輸出被時間鎖定 432 個區塊，而支付給 Bob 的 to_remote 輸出可以立即花費（參見 不對稱和延遲的承諾交易）。Bob 對承諾 #2 的承諾交易是鏡像的：他自己的（to_local）輸出被時間鎖定，Alice 的 to_remote 輸出可以立即花費。

延遲存在的一個原因是：允許_遠端_方在舊的（已撤銷的）承諾被另一個通道合作夥伴廣播時行使懲罰選項。接下來讓我們看看撤銷金鑰和懲罰選項。

延遲是在初始通道建構訊息流程中由 Alice 和 Bob 協商的，作為一個名為 to_self_delay 的欄位。為了確保通道的安全，延遲會根據通道容量進行調整——這意味著擁有更多資金的通道在承諾的 to_self 輸出中有更長的延遲。Alice 的節點在 open_channel 訊息中包含所需的 to_self_delay。如果 Bob 認為可以接受，他的節點在 accept_channel 訊息中包含相同的 to_self_delay 值。如果他們不同意，通道就會被拒絕（參見 shutdown 訊息）。

正如我們之前討論的，「撤銷」這個詞有點誤導，因為它暗示「已撤銷」的交易不能被使用。

事實上，已撤銷的交易可以被使用，但如果它被使用，而且它已經被撤銷，那麼通道合作夥伴之一可以透過創建懲罰交易來獲取所有通道資金。

運作方式是 to_local 輸出不僅被時間鎖定，而且在腳本中還有兩個花費條件：它可以在時間鎖定延遲後由 self 花費，或者_它可以由 _remote 使用此承諾的撤銷金鑰立即花費。

所以，在我們的例子中，每一方持有的承諾交易在 to_local 輸出中都包含一個撤銷選項，如 不對稱、延遲和可撤銷的承諾 所示。

commitment_signed 訊息的結構在 BOLT #2：對等協定，commitment_signed 中定義，如下所示：

Alice 的 commitment_signed 訊息給 Bob 提供了新承諾交易所需的簽名（Alice 在 2-of-2 中的部分）。

現在 Bob 有了新的承諾交易，他可以透過給 Alice 一個撤銷金鑰來撤銷先前的承諾，並用 Alice 的簽名構建新的承諾。

revoke_and_ack 訊息在 BOLT #2：對等協定，revoke_and_ack 中定義，如下所示：

讓我們更仔細地看看 Alice 和 Bob 之間的這種互動。

Alice 給 Bob 提供了創建新承諾的方法。作為回報，Bob 撤銷舊承諾以向 Alice 保證他不會使用它。只有當 Alice 有撤銷金鑰來懲罰 Bob 發布舊承諾時，她才能信任新的承諾。從 Bob 的角度來看，他可以安全地撤銷舊承諾，透過給 Alice 懲罰他的金鑰，因為他有新承諾的簽名。

當 Bob 用 revoke_and_ack 回應時，他給 Alice 一個 per_commitment_secret。這個秘密可以用來構建舊承諾的撤銷簽名金鑰，允許 Alice 透過行使懲罰來奪取所有通道資金。

一旦 Bob 將這個秘密給了 Alice，他_絕不能_再廣播那個舊承諾。如果他這樣做，他將給 Alice 機會透過獲取資金來懲罰他。本質上，Bob 給 Alice 讓他對廣播舊承諾負責的能力，實際上他已經撤銷了使用那個舊承諾的能力。

一旦 Alice 從 Bob 收到 revoke_and_ack，她可以確信 Bob 不能在不受懲罰的情況下廣播舊承諾。她現在有必要的金鑰來創建懲罰交易，如果 Bob 廣播舊承諾的話。

在實踐中，Alice 和 Bob 都必須監控作弊行為。他們監控比特幣區塊鏈，尋找與他們正在操作的任何通道相關的任何承諾交易。如果他們看到承諾交易在鏈上確認，他們將檢查它是否是最新的承諾。如果它是「舊的」承諾，他們必須立即構建並廣播懲罰交易。懲罰交易花費 to_local 和 to_remote 輸出_兩者_，關閉通道並將兩個餘額都發送給被欺騙的通道合作夥伴。

為了更容易讓雙方跟蹤過去撤銷承諾的承諾號碼，每個承諾實際上在鎖定時間和序列欄位中_編碼_承諾的號碼。在 協定中，這種特殊編碼被稱為_狀態提示_。假設一方知道當前的承諾號碼，他們能夠使用狀態提示輕鬆識別廣播的承諾是否是已撤銷的，如果是，哪個承諾號碼被違反，因為該號碼用於輕鬆查找撤銷秘密樹（shachain）中應該使用哪個撤銷秘密。

不是將狀態提示以明文編碼，而是使用_混淆的_狀態提示。這種混淆是透過首先將當前承諾號碼與使用雙方資金公鑰確定性生成的一組隨機位元組進行 XOR 來實現的。鎖定時間和序列中共有 6 個位元組（鎖定時間的 24 位元和序列的 24 位元）用於在承諾交易中編碼狀態提示，因此需要 6 個隨機位元組用於 XOR。為了獲得這 6 個位元組，雙方獲取發起者資金金鑰與回應者資金金鑰連接的 SHA-256 雜湊。在編碼當前承諾高度之前，整數與此狀態提示混淆器進行 XOR，然後編碼在鎖定時間的低 24 位元和序列的高 64 位元中。

讓我們回顧 Alice 和 Bob 之間的通道，並展示懲罰交易的具體例子。在 已撤銷和當前承諾 中，我們看到 Alice 和 Bob 通道上的四個承諾。Alice 向 Bob 進行了三筆付款：

每次承諾，Alice 都撤銷了先前（較舊的）承諾。通道的當前狀態和正確餘額由承諾 #3 表示。所有先前的承諾都已被撤銷，Bob 有必要的金鑰對它們發出懲罰交易，以防 Alice 試圖廣播其中之一。

Alice 可能有動機作弊，因為所有先前的承諾交易都會給她比她應得的更高比例的通道餘額。例如，假設 Alice 試圖廣播承諾 #1。該承諾交易將支付 Alice 70,000 satoshi 和 Bob 70,000 satoshi。如果 Alice 能夠廣播並花費她的 to_local 輸出，她實際上是透過回滾她對 Bob 的最後兩筆付款來從 Bob 那裡偷走 30,000 satoshi。

Alice 決定冒巨大風險，廣播已撤銷的承諾 #1，從 Bob 那裡偷走 30,000 satoshi。在 Alice 作弊 中，我們看到 Alice 的舊承諾，她將其廣播到比特幣區塊鏈。

如你所見，Alice 的舊承諾有兩個輸出，一個支付給她自己 70,000 satoshi（to_local 輸出），一個支付給 Bob 70,000 satoshi。Alice 還不能花費她的 70,000 to_local 輸出，因為它有 432 個區塊（3 天）的時間鎖。她現在希望 Bob 三天內不會注意到。

不幸的是對 Alice 來說，Bob 的節點正在勤奮地監控比特幣區塊鏈，看到一個舊承諾交易被廣播並（最終）在鏈上確認。

Bob 的節點將立即廣播懲罰交易。由於這個舊承諾被 Alice 撤銷，Bob 有 Alice 發送給他的 per_commitment_secret。他使用那個秘密為 revocation_pubkey 構建簽名。雖然 Alice 必須等待 432 個區塊，Bob 可以立即花費_兩個_輸出。他可以用他的私鑰花費 to_remote 輸出，因為它本來就是要支付給他的。他也可以用撤銷金鑰的簽名花費本來給 Alice 的輸出。他的節點廣播 作弊和懲罰 中顯示的懲罰交易。

Bob 的懲罰交易將 140,000 satoshi 支付到他自己的錢包，獲取了整個通道容量。Alice 不僅沒能作弊成功，她還在嘗試中失去了一切！

你可能注意到有一種特殊情況需要處理。如果 Alice 可以繼續花費她的餘額直到為零，她將處於可以透過廣播舊承諾交易關閉通道而不冒懲罰風險的位置：要麼已撤銷的承諾交易在延遲後成功，要麼作弊者被抓住但沒有後果因為懲罰是零。從博弈論的角度來看，在這種情況下嘗試作弊是免費的錢。這就是為什麼通道儲備金在起作用，所以潛在的作弊者總是面臨懲罰的風險。

通道關閉從兩個通道合作夥伴之一發送 shutdown 訊息開始。此訊息的內容如下所示：

假設 Alice 向 Bob 發送 shutdown 訊息以關閉他們的通道。Alice 將指定一個對應於她錢包比特幣地址的比特幣腳本。她告訴 Bob：讓我們創建一個關閉交易，將我的餘額支付到這個錢包。

Bob 將用他自己的 shutdown 訊息回應，表示他同意協作關閉通道。他的 shutdown 訊息包含他錢包地址的腳本。

現在 Alice 和 Bob 都有對方的首選錢包地址，他們可以構建相同的關閉交易來結算通道餘額。

假設通道沒有未完成的承諾或更新，並且通道合作夥伴已經交換了前一節中顯示的 shutdown 訊息，他們現在可以完成這個協作關閉。

通道的_資助者_（在我們的例子中是 Alice）首先向 Bob 發送 closing_signed 訊息。此訊息為鏈上交易提議交易費用，以及 Alice 對關閉交易的簽名（2-of-2 多重簽名）。closing_signed 訊息如下所示：

當 Bob 收到這個訊息時，他可以用自己的 closing_signed 訊息回覆。如果他同意費用，他只需返回相同的提議費用和他自己的簽名。如果他不同意，他必須提議不同的 fee_satoshis 費用。

這種協商可能會繼續進行來回的 closing_signed 訊息，直到兩個通道合作夥伴同意費用。

一旦 Alice 收到一個 closing_signed 訊息，其費用與她在上一條訊息中提議的相同，協商就完成了。Alice 簽署並廣播關閉交易，通道就關閉了。

協作關閉交易看起來類似於 Alice 和 Bob 商定的最後一個承諾交易。然而，與最後一個承諾交易不同，它的輸出中沒有時間鎖或懲罰撤銷金鑰。由於雙方合作產生此交易並且他們不會進行任何進一步的承諾，因此此交易中不需要不對稱、延遲和可撤銷的元素。

通常，此協作關閉交易中使用的地址是為每個被關閉的通道新生成的。然而，雙方也可以_鎖定_一個「交付」地址，用於發送他們協作結算的資金。在 open_channel 和 accept_channel 訊息的 TLV 命名空間內，雙方可以自由指定「預先關閉腳本」。通常，此地址從駐留在冷儲存中的金鑰衍生。這種做法有助於增加通道的安全性：如果通道合作夥伴以某種方式被入侵，那麼駭客就無法使用他們控制的地址協作關閉通道。相反，如果未使用指定的預先關閉地址，未受損的誠實通道合作夥伴將拒絕在通道關閉上合作。此功能有效地創建了一個「閉環」，限制資金從給定通道流出。

Alice 廣播 協作關閉交易 中顯示的交易來關閉通道。

一旦這個關閉交易在比特幣區塊鏈上確認，通道就關閉了。現在，Alice 和 Bob 可以隨意花費他們的輸出。

比特幣腳本足夠靈活，有數十種方法可以實作具有原子性、無需信任操作和多跳安全性屬性的公平協定。選擇特定的實作取決於隱私、效率和複雜性之間的某些權衡。

目前在閃電網路中用於路由的公平協定稱為雜湊時間鎖定合約（HTLC）。HTLC 使用雜湊原像作為解鎖付款的秘密，正如我們在本章的金幣範例中看到的。付款的接收者生成一個隨機秘密數字並計算其雜湊。雜湊成為付款的條件，一旦秘密被揭示，所有參與者都可以兌換他們收到的付款。HTLC 提供原子性、無需信任操作和多跳安全性。

另一種提議的路由實作機制是_點時間鎖定合約_（PTLC）。PTLC 也實現原子性、無需信任操作和多跳安全性，但具有更高的效率和更好的隱私。PTLC 的高效實作依賴於一種名為 _Schnorr 簽名_的新數位簽章演算法，預計將於 2021 年在比特幣中啟用。

閃電網路的目的是實現_鏈下_交易，這些交易與鏈上交易一樣被信任，因為沒有人可以欺騙。沒有人可以欺騙的原因是，在任何時候，任何參與者都可以將他們的鏈下交易放到鏈上。每筆鏈下交易都準備好隨時提交到比特幣區塊鏈。因此，如果有必要，比特幣區塊鏈充當爭議解決和最終結算機制。

任何交易都可以隨時上鏈的事實正是所有這些交易可以保持在鏈下的原因。如果你知道你有追索權，你可以繼續與其他參與者合作，避免鏈上結算和額外費用的需要。

在以下所有範例中，我們將假設這些交易中的任何一筆都可以隨時上鏈。參與者將選擇將它們保持在鏈下，但除了鏈上挖礦交易產生的較高費用和延遲外，系統的功能沒有區別。無論所有交易都在鏈上還是鏈下，範例的工作方式都相同。

在我們的金幣範例中，Alice 有一份由託管執行的合約，如下所示：

哇，這看起來很複雜！不過別擔心，我們會一步一步地分析並簡化它。

目前在閃電網路中使用的比特幣腳本相當複雜，因為它針對鏈上空間效率進行了優化，這使它非常緊湊但難以閱讀。

在以下章節中，我們將專注於腳本的主要元素，並呈現與閃電網路中實際使用的略有不同的簡化腳本。

HTLC 的主要部分在 在比特幣腳本中實作的 HTLC（BOLT #3） 的第 10 行。讓我們從頭開始建構它！

HTLC 的核心是雜湊，如果接收者知道付款原像，就可以進行付款。Alice 將付款鎖定到特定的付款雜湊，Bob 必須出示付款原像才能領取資金。比特幣系統可以透過對 Bob 的付款原像進行雜湊並將結果與 Alice 用於鎖定資金的付款雜湊進行比較來驗證 Bob 的付款原像是否正確。

HTLC 的這部分可以在比特幣腳本中實作如下：

Alice 可以建立一筆交易輸出，支付 50,200 聰，使用上面的鎖定腳本，將 <H> 替換為 Dina 提供的雜湊值 0575...f6b3。然後，Alice 可以簽署這筆交易並提供給 Bob：

Bob 在知道 Dina 的秘密之前無法花費這個 HTLC，因此花費 HTLC 取決於 Bob 完成一路到 Dina 的付款。

一旦 Bob 有了 Dina 的秘密，Bob 可以用包含秘密原像值 R 的解鎖腳本來花費這個輸出。

解鎖腳本與鎖定腳本結合將產生：

比特幣腳本引擎將如下評估此腳本：

Alice 現在將把 HTLC 擴展到整個網路，使其到達 Dina。

在 在網路中傳播 HTLC 中，我們看到 HTLC 從 Alice 傳播到 Dina。Alice 給了 Bob 一個 50,200 聰的 HTLC。Bob 現在可以建立一個 50,100 聰的 HTLC 並給 Chan。

Bob 知道 Chan 在不廣播秘密的情況下無法兌換 Bob 的 HTLC，此時 Bob 也可以使用秘密來兌換 Alice 的 HTLC。這是一個非常重要的點，因為它確保了 HTLC 的端對端_原子性_。要花費 HTLC，需要揭示秘密，然後這使得其他人也可以花費他們的 HTLC。要麼所有的 HTLC 都可以花費，要麼所有的 HTLC 都不能花費：原子性！

因為 Alice 的 HTLC 比 Bob 給 Chan 的 HTLC 多 100 聰，如果這筆付款完成，Bob 將賺取 100 聰作為路由費。

Bob 沒有承擔風險，也不信任 Alice 或 Chan。相反，Bob 信任簽名的交易加上秘密將可以在比特幣區塊鏈上兌換。

同樣，Chan 可以向 Dina 擴展 50,000 聰的 HTLC。他沒有冒任何風險，也不信任 Bob 或 Dina。要兌換 HTLC，Dina 必須廣播秘密，Chan 可以用它來兌換 Bob 的 HTLC。Chan 也將賺取 100 聰作為路由費。

一旦 Dina 從 Chan 收到 50,000 聰的 HTLC，她現在可以獲得付款了。Dina 可以簡單地將這個 HTLC 提交到鏈上，並透過在花費交易中揭示秘密來花費它。或者，Dina 可以透過將秘密給 Chan 來更新與 Chan 的通道餘額。沒有理由產生交易費用並上鏈。因此，Dina 將秘密發送給 Chan，他們同意更新他們的通道餘額以反映 50,000 聰的閃電網路付款給 Dina。在 Dina 在鏈下結算 Chan 的 HTLC 中，我們看到 Dina 將秘密給 Chan，從而履行 HTLC。

注意 Dina 的通道餘額從 50,000 聰變為 100,000 聰。Chan 的通道餘額從 200,000 聰減少到 150,000 聰。通道容量沒有改變，但 50,000 聰從 Chan 這邊移動到 Dina 這邊。

Chan 現在有了秘密並且已經付給 Dina 50,000 聰。他可以這樣做而沒有任何風險，因為秘密允許 Chan 兌換 Bob 的 50,100 聰 HTLC。Chan 可以選擇將該 HTLC 提交到鏈上並透過在比特幣區塊鏈上揭示秘密來花費它。但是，像 Dina 一樣，他寧願避免交易費用。所以，他將秘密發送給 Bob，這樣他們就可以更新他們的通道餘額以反映從 Bob 到 Chan 的 50,100 聰閃電網路付款。在 Chan 在鏈下結算 Bob 的 HTLC 中，我們看到 Chan 將秘密發送給 Bob 並收到付款作為回報。

Chan 已經付給 Dina 50,000 聰，並從 Bob 那裡收到 50,100 聰。所以 Chan 的通道餘額多了 100 聰，這是他作為路由費賺取的。

Bob 現在也有了秘密。他可以用它來花費 Alice 的鏈上 HTLC。或者，他可以透過在與 Alice 的通道中結算 HTLC 來避免交易費用。在 Bob 在鏈下結算 Alice 的 HTLC 中，我們看到 Bob 將秘密發送給 Alice，他們更新通道餘額以反映從 Alice 到 Bob 的 50,200 聰閃電網路付款。

Bob 從 Alice 收到 50,200 聰，並付給 Chan 50,100 聰，所以他從路由費中多了 100 聰的通道餘額。

Alice 收到秘密並已結算 50,200 聰的 HTLC。秘密可以用作_收據_來證明 Dina 為該特定付款雜湊收到了付款。

最終的通道餘額反映了 Alice 付款給 Dina 以及在每一跳支付的路由費，如 付款後的通道餘額 所示。

有一個陷阱。你注意到了嗎？

如果 Alice、Bob 和 Chan 如 付款後的通道餘額 所示建立 HTLC，他們面臨著雖小但不可忽視的損失風險。任何知道秘密的人都可以兌換（花費）那些 HTLC。起初只有 Dina 知道秘密。Dina 應該只花費 Chan 的 HTLC。但 Dina 可以同時花費所有三個 HTLC，甚至在一筆花費交易中！畢竟，Dina 比任何人都先知道秘密。同樣，一旦 Chan 知道秘密，他應該只花費 Bob 提供的 HTLC。但如果 Chan 也花費 Alice 提供的 HTLC 呢？

這不是_無需信任的_！它未能通過最重要的安全特性。我們需要修復這個問題。

HTLC 腳本必須有一個額外的條件，將每個 HTLC 綁定到特定的接收者。我們透過要求與每個接收者的公鑰匹配的數位簽章來做到這一點，從而防止任何其他人花費該 HTLC。由於只有指定的接收者能夠產生與該公鑰匹配的數位簽章，只有指定的接收者才能花費該 HTLC。

讓我們再次查看帶有此修改的腳本。Alice 給 Bob 的 HTLC 被修改為包含 Bob 的公鑰和 OP_CHECKSIG 運算子。

這是修改後的 HTLC 腳本：

要兌換這個 HTLC，Bob 必須出示包含 Bob 私鑰簽名以及秘密付款原像的解鎖腳本，如下所示：

解鎖和鎖定腳本結合起來由腳本引擎評估，如下所示：

如你所見，這稍微複雜了一些，但現在我們已經修復了 HTLC 並確保只有預期的接收者才能花費它。

讓我們看看到目前為止 HTLC 腳本的第一部分：

如果我們在前面的符號表示中看這個，看起來 OP_ 運算子佔用了最多的空間。但事實並非如此。比特幣腳本以二進位編碼，每個運算子代表一個位元組。同時，我們用作付款雜湊占位符的 <H> 值是一個 32 位元組（256 位元）的值。你可以在 Bitcoin Wiki: Script 或 《精通比特幣》附錄 D「交易腳本語言運算子、常數和符號」 中找到所有比特幣腳本運算子及其二進位和十六進位編碼的列表。

用十六進位表示，我們的 HTLC 腳本看起來像這樣：

在十六進位編碼中，OP_SHA256 是 a8，OP_EQUALVERIFY 是 88。這個腳本的總長度是 34 位元組，其中 32 位元組是雜湊。

正如我們之前提到的，閃電網路中的任何參與者都應該能夠將他們持有的鏈下交易放到鏈上，如果他們需要強制執行他們對資金的索取權。要將交易上鏈，他們必須向礦工支付交易費用，這些費用與交易的位元組大小成正比。

因此，我們希望找到方法來最小化交易的鏈上「權重」，盡可能優化腳本。一種方法是在 SHA-256 演算法之上添加另一個雜湊函數，一個產生更小雜湊的函數。比特幣腳本語言提供了 OP_HASH160 運算子，它對原像進行「雙重雜湊」：首先用 SHA-256 對原像進行雜湊，然後用 RIPEMD160 雜湊演算法對結果雜湊再次進行雜湊。RIPEMD160 產生的雜湊是 160 位元或 20 位元組——更加緊湊。在比特幣腳本中，這是一種非常常見的優化，用於許多常見的地址格式。

所以，讓我們改用這種優化。我們的 SHA-256 雜湊是 057596...69f6b3。用 RIPEMD160 再次進行雜湊給我們結果：

Alice 可以計算 Dina 提供的付款雜湊的 RIPEMD160 雜湊，並在她的 HTLC 中使用較短的雜湊，Bob 和 Chan 也可以這樣做！

用十六進位編碼，這是：

其中 OP_HASH160 是 a9，OP_EQUALVERIFY 是 88。這個腳本只有 22 位元組長！我們從每筆在鏈上兌換 HTLC 的交易中節省了 12 位元組。

有了這個優化，你現在可以看到我們如何得出 在比特幣腳本中實作的 HTLC（BOLT #3） 第 10 行所示的 HTLC 腳本：

到目前為止，我們研究了 HTLC 的「雜湊」部分以及如果每個人都合作並在付款時在線，它會如何運作。

如果有人離線或不合作會發生什麼？如果付款無法成功會發生什麼？

我們需要確保一種「優雅失敗」的方式，因為偶爾的路由失敗是不可避免的。有兩種失敗方式：合作式和帶時間鎖退款。

合作失敗相對簡單：HTLC 由路由中的每個參與者解除，從他們的承諾交易中移除 HTLC 輸出而不改變餘額。我們將在 通道操作與支付轉發 中詳細研究這是如何運作的。

讓我們看看如何在沒有一個或多個參與者合作的情況下逆轉 HTLC。我們需要確保如果其中一個參與者不合作，資金不會簡單地_永遠_鎖定在 HTLC 中。這會給某人勒索另一個參與者資金的機會：「如果你不付我贖金，我就讓你的資金永遠被鎖住。」

為了防止這種情況，每個 HTLC 腳本都包含一個與時間鎖連接的退款條款。還記得我們最初的託管合約嗎？「Bob 在合約簽署後有 24 小時出示秘密。如果 Bob 在此時間前沒有提供秘密，Alice 的存款將由託管服務退還。」

帶時間鎖的退款是確保_原子性_的腳本的重要部分，使整個端對端付款要麼成功，要麼優雅失敗。沒有需要擔心的「半支付」狀態。如果失敗，每個參與者都可以與他們的通道夥伴合作解除 HTLC，或者單方面將帶時間鎖的退款交易上鏈以取回他們的錢。

要在比特幣腳本中實作這個退款，我們使用一個特殊的運算子 O⁠P⁠_⁠C⁠H⁠E⁠C⁠K⁠L⁠O⁠C⁠K⁠T⁠I⁠M⁠E​V⁠E⁠R⁠I⁠F⁠Y，簡稱 OP_CLTV。這是腳本，如之前在 在比特幣腳本中實作的 HTLC（BOLT #3） 第 13 行所見：

OP_CLTV 運算子採用一個到期時間，定義為此交易有效的區塊高度。如果交易時間鎖與 <cltv_expiry> 設定不同，腳本評估失敗，交易無效。否則，腳本繼續而不輸出到堆疊。記住，VERIFY 後綴意味著此運算子不輸出 TRUE 或 FALSE，而是停止/失敗或繼續而不產生堆疊輸出。

本質上，OP_CLTV 作為「守門人」，如果比特幣區塊鏈上還沒有達到 <cltv_expiry> 區塊高度，就阻止腳本繼續進行。

OP_DROP 運算子簡單地丟棄腳本堆疊上最頂端的項目。這在開始時是必要的，因為有一個來自前面腳本行的「剩餘」項目。在 OP_CLTV _之後_這是必要的，以從堆疊頂部移除 <cltv_expiry> 項目，因為它不再需要。

最後，一旦堆疊被清理，應該還剩下一個公鑰和簽名，OP_CHECKSIG 可以驗證它們。正如我們在 簽名綁定：防止 HTLC 被盜 中看到的，這是必要的，以確保只有資金的合法所有者才能領取它們，透過將此輸出綁定到他們的公鑰並要求簽名。

當 HTLC 從 Alice 擴展到 Dina 時，每個 HTLC 中的帶時間鎖退款條款有_不同的_ cltv_expiry 值。我們將在 洋蔥路由 中更詳細地看到這一點。但足以說明的是，為了確保有序地解除失敗的付款，每一跳需要等待的退款時間略有不同。每跳之間時間鎖的差異稱為 cltv_expiry_delta，由每個節點設定並向網路公告，我們將在 八卦協定與通道圖 中看到。

例如，Alice 將第一個 HTLC 的退款時間鎖設定為當前 + 500 個區塊的區塊高度（「當前」是當前區塊高度）。Bob 然後將 HTLC 給 Chan 的時間鎖 cltv_expiry 設定為當前 + 450 個區塊。Chan 將時間鎖設定為從當前區塊高度的當前 + 400 個區塊。這樣，Chan 可以在 Bob 獲得他提供給 Chan 的 HTLC 退款_之前_獲得他提供給 Dina 的 HTLC 的退款。Bob 可以在 Alice 可以獲得她提供給 Bob 的 HTLC 退款之前獲得他提供給 Chan 的 HTLC 的退款。遞減的時間鎖防止競爭條件並確保 HTLC 鏈從目的地向源頭反向解除。

Alice 和 Bob 之間（以及任何一對通道夥伴之間）的訊息流程如 通道夥伴之間 HTLC 承諾的訊息流程 所示。

Alice 希望 Bob 接受一個價值 50,200 聰的 HTLC 以轉發給 Dina。為此，Alice 必須向 Bob 發送此 HTLC 的詳細資訊，包括付款雜湊和金額。Bob 還需要知道將其轉發到哪裡，這是我們在 洋蔥路由 中詳細討論的內容。

要添加 HTLC，Alice 透過向 Bob 發送 update_add_htlc 訊息來開始我們在 通道夥伴之間 HTLC 承諾的訊息流程 中看到的流程。

Alice 向 Bob 發送 update_add_HTLC 閃電網路訊息。此訊息定義在 BOLT #2: Peer Protocol, update_add_HTLC，如範例 9-1 所示。

收到的資訊足以讓 Bob 建立新的承諾交易。新的承諾交易有相同的兩個輸出 to_self 和 to_remote 用於 Alice 和 Bob 的餘額，以及一個代表 Alice 提供的 HTLC 的_新_輸出。

我們已經在 在支付通道網路上路由 中看到了 HTLC 的基本結構。提供的 HTLC 的完整腳本定義在 BOLT #3: Transactions, Offered HTLC Output，如 提供的 HTLC 輸出腳本 所示。

有三種方法可以領取此輸出。嘗試閱讀腳本，看看你能否弄清楚（記住，它是一種基於堆疊的語言，所以事情看起來是「倒過來的」）。

Bob 現在有了必要的資訊來將此 HTLC 腳本作為額外輸出添加並建立新的承諾交易。Bob 的新承諾將在 HTLC 輸出中有 50,200 聰。該金額將來自 Alice 的通道餘額，因此 Alice 的新餘額將是 19,800 聰（70,000 – 50,200 = 19,800）。Bob 將此承諾建構為暫定的「承諾 #3」，如 Bob 帶 HTLC 輸出的新承諾 所示。

現在 Bob 有了新的簽名承諾，他需要確認它並撤銷舊承諾。他透過發送 revoke_and_ack 訊息來做到這一點，正如我們之前在 支付通道 中看到的。作為提醒，該訊息顯示在 revoke_and_ack 訊息 中。

Bob 發送 per_commitment_secret，允許 Alice 建構撤銷金鑰來建立花費 Bob 舊承諾的懲罰交易。一旦 Bob 發送了這個，如果他發布「承諾 #2」，他就冒著懲罰交易和失去所有資金的風險。因此，舊承諾實際上被撤銷了。

Bob 實際上已經將通道狀態向前推進，如 Bob 已撤銷舊承諾 所示。

儘管 Bob 有一個新的（簽名的）承諾交易和裡面的 HTLC 輸出，他還不能認為他的 HTLC 已成功設定。

他首先需要讓 Alice 撤銷她的舊承諾，因為否則，Alice 可以將她的餘額回滾到 70,000 聰。Bob 需要確保 Alice 也有一個包含 HTLC 的承諾交易，並且已經撤銷了舊承諾。

這就是為什麼，如果 Bob 不是 HTLC 資金的最終接收者，他還不應該透過在與 Chan 的下一個通道上提供 HTLC 來轉發 HTLC。

Alice 已經建構了一個包含新 HTLC 的鏡像新承諾交易，但它還沒有被 Bob 簽署。我們可以在 Alice 帶 HTLC 輸出的新承諾 中看到它。

正如我們在 支付通道 中描述的，Alice 的承諾是 Bob 的鏡像，因為它包含用於撤銷和懲罰執行舊承諾的非對稱、延遲、可撤銷結構。Alice 的 19,800 聰餘額（扣除 HTLC 值後）是延遲的和可撤銷的。Bob 的 70,000 聰餘額可以立即兌換。

接下來，commitment_signed 和 revoke_and_ack 的訊息流程現在重複，但方向相反。Bob 發送 commitment_signed 來簽署 Alice 的新承諾，Alice 透過撤銷她的舊承諾來回應。

為了完整起見，讓我們快速審查這輪承諾/撤銷發生時的承諾交易。

讓我們假設 Bob 繼續這個鏈條，並與 Chan 設定一個 50,100 聰的 HTLC。過程將與我們剛才在 Alice 和 Bob 之間看到的完全相同。Bob 將向 Chan 發送 update_add_htlc，然後他們將在兩輪中交換 commitment_signed 和 revoke_and_ack 訊息，將他們的通道推進到下一個狀態。

接下來，Chan 將與 Dina 做同樣的事情：提供 50,000 聰的 HTLC，承諾和撤銷，等等。然而，Dina 是 HTLC 的最終接收者。Dina 是唯一知道付款秘密（付款雜湊的原像）的人。因此，Dina 可以立即與 Chan 履行 HTLC！

Dina 可以透過向 Chan 發送 update_ful&#x2060;fill_&#x200b;htlc 訊息來結算 HTLC。update_fulfill_htlc 訊息定義在 BOLT #2: Peer Protocol, update_fulfill_htlc，如下所示：

這是一個非常簡單的訊息：

當 Chan 收到此訊息時，他會立即檢查 payment_preimage（讓我們稱之為 R）是否產生他提供給 Dina 的 HTLC 中的付款雜湊（讓我們稱之為 H）。他這樣雜湊它：

如果結果 H 與 HTLC 中的付款雜湊匹配，Chan 可以跳一支小舞來慶祝。這個期待已久的秘密可以用來兌換 HTLC，並將沿著支付通道鏈一路傳回給 Alice，解決作為這筆付款給 Dina 一部分的每個 HTLC。

讓我們回到 Alice 和 Bob 的通道，看看他們如何解開 HTLC。為了達到那裡，讓我們假設 Dina 向 Chan 發送了 update_fulfill_htlc，Chan 向 Bob 發送了 update_fulfill_htlc，Bob 向 Alice 發送了 update_fulfill_htlc。付款原像已經一路傳回給 Alice。

當 Bob 向 Alice 發送 update_fulfill_htlc 時，它將包含 Dina 為她的發票選擇的相同 payment_preimage。該 payment_preimage 已經沿付款路徑向後傳播。在每一步，channel_id 將不同，id（HTLC ID）可能不同。但原像是相同的！

Alice 也會驗證從 Bob 收到的 payment_preimage。她會將其雜湊與她提供給 Bob 的 HTLC 中的 HTLC 付款雜湊進行比較。她還會發現這個原像與 Dina 發票中的雜湊匹配。這是 Dina 已被付款的證明。

Alice 和 Bob 之間的訊息流程如 HTLC 履行訊息流程 所示。

Alice 和 Bob 現在都可以從承諾交易中移除 HTLC 並更新他們的通道餘額。

他們建立新的承諾（承諾 #4），如 HTLC 被移除，餘額在新承諾中更新 所示。

閃電網路使用_源路由_，這意味著付款路徑由發送者選擇和指定，而且只有發送者。在這個例子中，Alice 給 Dina 的秘密信件將等同於一筆付款。為了確保信件到達 Dina，Alice 將建立一條從她到 Dina 的路徑，使用 Bob 和 Chan 作為中間人。

讓我們看看 Alice 如何使用這條路徑而不向中間人 Bob 和 Chan 透露資訊。

Alice 首先給 Dina 寫一封秘密信件。然後她將信件密封在信封內並在外面寫上「給 Dina」（見 Dina 的秘密信件，密封在信封中）。信封代表用 Dina 的公鑰加密，只有 Dina 可以打開信封並閱讀信件。

Dina 的信件將由 Chan 交給 Dina，Chan 在「路徑」中緊鄰 Dina 之前。所以，Alice 把 Dina 的信封放進一個寫給 Chan 的信封裡（見 Chan 的信封，包含 Dina 密封的信封）。Chan 唯一能讀到的是目的地（路由指示）：「給 Dina」。將此密封在寫給 Chan 的信封中代表用 Chan 的公鑰加密，只有 Chan 可以讀取信封地址。Chan 仍然無法打開 Dina 的信封。他只能看到外面的指示（地址）。

現在，這封信將由 Bob 交給 Chan。所以 Alice 把它放進一個寫給 Bob 的信封裡（見 Bob 的信封，包含 Chan 密封的信封）。和以前一樣，信封代表加密給 Bob 的訊息，只有 Bob 可以讀取。Bob 只能讀取 Chan 信封的外面（地址），所以他知道要把它送給 Chan。

現在，如果我們可以透過信封（用 X 光！）我們會看到信封一個套一個嵌套，如 嵌套的信封 所示。

Alice 現在有一個信封，外面寫著「給 Bob」。它代表一個只有 Bob 可以打開（解密）的加密訊息。Alice 現在透過把這個發送給 Bob 來開始這個過程。整個過程如 發送信封 所示。

如你所見，Bob 從 Alice 那裡收到信封。他知道它來自 Alice，但不知道 Alice 是原始發送者還是只是轉發信封的人。他打開它發現裡面有一個信封寫著「給 Chan」。由於這是寫給 Chan 的，Bob 無法打開它。他不知道裡面是什麼，不知道 Chan 是收到一封信還是另一個要轉發的信封。Bob 不知道 Chan 是否是最終收件人。Bob 將信封轉發給 Chan。

Chan 從 Bob 那裡收到信封。他不知道它來自 Alice。他不知道 Bob 是中間人還是信件的發送者。Chan 打開信封發現裡面有另一個信封寫著「給 Dina」，他無法打開。Chan 將它轉發給 Dina，不知道 Dina 是否是最終收件人。

Dina 從 Chan 那裡收到一個信封。打開它她發現裡面有一封信，所以現在她知道她是這條訊息的預期收件人。她閱讀這封信，知道沒有中間人知道它從哪裡來，也沒有其他人讀過她的秘密信件！

這就是洋蔥路由的本質。發送者將訊息包裹在層次中，精確指定它將如何路由，並防止任何中間人獲得有關路徑或有效載荷的任何資訊。每個中間人剝離一層，只看到轉發地址，除了路徑中的前一跳和下一跳外什麼都不知道。

現在，讓我們看看閃電網路中洋蔥路由實作的細節。

從 在支付通道網路上路由 我們知道 Alice 將透過 Bob 和 Chan 向 Dina 發送 50,000 聰的付款。此付款透過一系列 HTLC 傳輸，如 從 Alice 到 Dina 的 HTLC 付款路徑 所示。

正如我們將在 八卦協定與通道圖 中看到的，Alice 能夠建構這條到 Dina 的路徑，因為閃電網路節點使用閃電網路八卦協定向整個閃電網路宣布它們的通道。在初始通道公告後，Bob 和 Chan 各自發送了額外的 channel_update 訊息，包含他們對付款路由的路由費和時間鎖預期。

從公告和更新中，Alice 知道關於 Bob、Chan 和 Dina 之間通道的以下資訊：

在實踐中，還會交換其他資訊，例如通道將承載的最大（htlc_maximum_msat）和最小（htlc_minimum_msat）HTLC，但這些在洋蔥路由建構期間不像前面的欄位那樣直接使用。

Alice 使用此資訊來識別以下詳細路徑的節點、通道、費用和時間鎖，如 從八卦的通道和節點資訊建構的詳細路徑 所示。

Alice 已經知道她自己到 Bob 的通道，因此不需要此資訊來建構路徑。另請注意，Alice 不需要 Dina 的通道更新，因為她有 Chan 對該路徑中最後一個通道的更新。

Alice 可以使用兩種可能的格式來傳達給每一跳的資訊：一種稱為_跳資料_的遺留固定長度格式和一種更靈活的基於類型-長度-值（TLV）的格式稱為_跳有效載荷_。TLV 訊息格式在 類型-長度-值格式 中有更詳細的解釋。它透過允許隨意向協定添加欄位來提供靈活性。

Alice 將從路徑的末端向後建構跳資料：Dina、Chan，然後是 Bob。

我們已經提到，「跳」節點都不知道路徑有多長，或者他們在路徑中的位置。這怎麼可能？

如果你有一組方向，即使是加密的，難道不能透過查看你在方向列表中的_位置_來判斷你離開始或結束有多遠嗎？

洋蔥路由中使用的技巧是始終為每個節點使路徑（方向列表）長度相同。這透過在每一步保持洋蔥封包相同的長度來實現。

在每一跳，跳有效載荷出現在洋蔥有效載荷的開頭，後面跟著_看起來像是_ 19 個更多的跳有效載荷。每一跳都將自己視為 20 跳中的第一跳。

當每一層被「剝離」時，會在洋蔥有效載荷的末尾添加更多填充資料（本質上是垃圾），這樣下一跳得到相同大小的洋蔥，並且再次成為洋蔥中的「第一跳」。

洋蔥大小是 1,366 位元組，結構如 洋蔥封包 所示：

Sphinx 作為混合網路封包格式的一個獨特特性是，不是為路由中的每一跳包含一個獨特的會話金鑰，這會大大增加混合網路封包的大小，而是使用一種巧妙的_盲化_方案在每一跳確定性地隨機化會話金鑰。

在實踐中，這個小技巧允許我們保持洋蔥封包盡可能緊湊，同時仍然保留所需的安全屬性。

這是包裹洋蔥的過程，接下來概述。當我們用真實世界的例子探索每一步時，回到這個列表。

對於每一跳，發送者（Alice）重複相同的過程：

接下來，Alice 重複這個過程。計算新金鑰，洋蔥有效載荷被移動（丟棄更多垃圾），新的跳有效載荷被添加到前面，整個洋蔥有效載荷用下一跳的 rho 位元組流加密。

對於最終跳，步驟 #3 中包含的明文指示上的 HMAC 實際上_全為零_。 最終跳使用此信號來確定它確實是路由中的最終跳。 或者，有效載荷中包含的表示「下一跳」的 short_chan_id 全為零也可以使用。

請注意，在每個階段，mu 金鑰用於在_加密的_（從處理有效載荷的節點的角度）洋蔥封包上生成 HMAC，以及在移除單層加密的封包內容上生成 HMAC。 這個外部 HMAC 允許處理封包的節點驗證洋蔥封包的完整性（沒有位元組被修改）。 內部 HMAC 然後在前面描述的「移動和加密」例程的逆過程中被揭示，這作為下一跳的_外部_ HMAC。

作為提醒，洋蔥是從路徑的末端開始包裹的，即 Dina，最終節點或接收者。然後路徑反向建構一直回到發送者 Alice。

Alice 從一個空的 1,300 位元組欄位開始，即固定長度的_洋蔥有效載荷_。然後，她用從 pad 金鑰生成的偽隨機位元組流「填充」填充洋蔥有效載荷。

這如 用隨機位元組流填充洋蔥有效載荷 所示。

Alice 現在將 Dina 的跳有效載荷插入 1,300 位元組陣列的左側，將填充向右移動並丟棄任何溢出的內容。這在 添加 Dina 的跳有效載荷 中視覺化。

另一種看法是 Alice 測量 Dina 跳有效載荷的長度，將填充向右移動以在洋蔥有效載荷的左側建立相等的空間，並將 Dina 的有效載荷插入該空間。

向下一行我們看到結果：1,300 位元組的洋蔥有效載荷包含 Dina 的跳有效載荷，然後是填充位元組流填充其餘空間。

接下來，Alice 混淆整個洋蔥有效載荷，使得_只有 Dina_可以讀取它。

為此，Alice 使用 rho 金鑰生成一個位元組流（Dina 也知道這個）。Alice 在洋蔥有效載荷的位元和從 rho 建立的位元組流之間使用按位互斥或（XOR）。結果看起來像一個 1,300 位元組長度的隨機（或加密的）位元組流。這一步如 混淆洋蔥有效載荷 所示。

XOR 的一個屬性是，如果你做兩次，你會得到原始資料。正如我們將在 Bob 去混淆他的跳有效載荷 中看到的，如果 Dina 使用從 rho 生成的位元組流應用相同的 XOR 操作，它將揭示原始洋蔥有效載荷。

因為只有 Alice 和 Dina 有 rho 金鑰（從 Alice 和 Dina 的共享秘密派生），只有他們可以做到這一點。實際上，這為 Dina 的眼睛加密了洋蔥有效載荷。

最後，Alice 為 Dina 的有效載荷計算基於雜湊的訊息認證碼（HMAC），使用 mu 金鑰作為其初始化金鑰。這如 為 Dina 的跳有效載荷添加 HMAC 完整性校驗和 所示。

在 為 Chan 包裹洋蔥 中，我們看到用於將 Chan 的跳有效載荷包裹在洋蔥中的步驟。這些是 Alice 用來包裹 Dina 跳有效載荷的相同步驟。

Alice 從為 Dina 建立的 1,300 洋蔥有效載荷開始。前 65（或更少）位元組是 Dina 的混淆有效載荷，其餘是填充。Alice 必須小心不要覆蓋 Dina 的有效載荷。

接下來，Alice 需要找到將在此跳前置到路由封包的臨時公鑰（在最開始為每一跳生成）。

記住，Sphinx 不是為每一跳包含一個唯一的臨時公鑰（發送者和中間節點在 ECDH 操作中使用它來生成共享秘密），而是使用單個臨時公鑰，在每一跳確定性地隨機化。

在處理封包時，Dina 將使用她的共享秘密和公鑰來派生盲化因子（b_dina），並使用它來重新隨機化臨時公鑰，與 Alice 在初始封包建構期間執行的操作相同。

Alice 為 Chan 的有效載荷添加內部 HMAC 校驗和，並將其插入洋蔥有效載荷的「前面」（左側），將現有有效載荷向右移動相同的量。 記住，該方案中實際上使用了_兩個_ HMAC：外部 HMAC 和內部 HMAC。 在這種情況下，Chan 的_內部_ HMAC 實際上是 Dina 的_外部_ HMAC。

現在 Chan 的有效載荷在洋蔥的前面。當 Chan 看到這個時，他不知道之前或之後有多少有效載荷。它看起來總是像 20 跳中的第一跳！

接下來，Alice 用從 Alice-Chan rho 金鑰生成的位元組流 XOR 混淆整個有效載荷。只有 Alice 和 Chan 有這個 rho 金鑰，只有他們可以產生位元組流來混淆和去混淆洋蔥。 最後，正如我們在前面的步驟中所做的，我們計算 Chan 的外部 HMAC，這是她用來驗證加密洋蔥封包完整性的。

在 為 Bob 包裹洋蔥 中，我們看到用於將 Bob 的跳有效載荷包裹在洋蔥中的步驟。

好了，現在這很容易了！

從包含 Chan 和 Dina 跳有效載荷的洋蔥有效載荷（混淆的）開始。

獲取從前一跳生成的盲化因子派生的此跳的會話金鑰。 將前一跳的外部 HMAC 作為此跳的內部 HMAC 包含。 在開頭插入 Bob 的跳有效載荷，並將其他所有內容向右移動，從末尾丟棄一個 Bob 跳有效載荷大小的塊（反正是填充）。

用來自 Alice-Bob 共享秘密的 rho 金鑰 XOR 混淆整個內容，使得只有 Bob 可以解開這個。

計算外部 HMAC 並將其貼在 Bob 跳有效載荷的末尾。

最終洋蔥有效載荷準備好發送給 Bob 了。Alice 不需要再添加任何跳有效載荷。

Alice 為洋蔥有效載荷計算 HMAC，用校驗和以密碼學方式保護它，Bob 可以驗證。

Alice 添加一個 33 位元組的公開會話金鑰，每一跳將使用它來生成共享秘密和 rho、mu 和 pad 金鑰。

最後 Alice 在前面放置洋蔥版本號（目前為 0）。這允許洋蔥封包格式的未來升級。

結果可以在 洋蔥封包 中看到。

洋蔥封包作為 update_add_htlc 訊息的一部分發送。如果你回憶一下 update_add_HTLC 訊息，在 通道操作與支付轉發 中，我們看到 update_add_htlc 訊息的內容如下：

你會記得這個訊息是由一個通道夥伴發送給另一個通道夥伴，要求他們添加 HTLC。這就是 Alice 將如何要求 Bob 添加 HTLC 來付款給 Dina。現在你理解了最後一個欄位 onion_routing_packet 的目的，它是 1,366 位元組長。它是我們剛剛建構的完全包裹的洋蔥封包！

Alice 將向 Bob 發送 update_add_htlc 訊息。讓我們看看這個訊息將包含什麼：

正如我們在 通道操作與支付轉發 中看到的，Bob 將把 HTLC 添加到承諾交易中，並與 Alice 更新通道的狀態。

Bob 將如下解開他從 Alice 收到的洋蔥：

現在 Bob 已經生成了共享金鑰並驗證了 HMAC，他可以開始解開洋蔥封包內的 1,300 位元組洋蔥有效載荷。目標是讓 Bob 檢索自己的跳有效載荷，然後將剩餘的洋蔥轉發到下一跳。

如果 Bob 提取並移除他的跳有效載荷，剩餘的洋蔥將不是 1,300 位元組，它會更短！所以下一跳會知道他們不是第一跳，並能夠檢測路徑有多長。為了防止這種情況，Bob 需要添加更多填充來重新填充洋蔥。

Bob 以與 Alice 略有不同但遵循相同一般原則的方式生成填充。

首先，Bob _擴展_洋蔥有效載荷 1,300 位元組，並用 0 值填充它們。現在洋蔥封包是 2,600 位元組長，前半部分包含 Alice 發送的資料，後半部分包含零。這個操作如 Bob 將洋蔥有效載荷擴展 1,300（零填充）位元組 所示。

這個空白空間將被混淆並透過 Bob 用來去混淆他自己跳有效載荷的相同過程變成「填充」。讓我們看看這是如何運作的。

接下來，Bob 將從 Alice-Bob 共享金鑰生成 rho 金鑰。他將使用 ChaCha20 演算法用這個金鑰生成 2,600 位元組流。

接下來，Bob 用按位 XOR 操作將 2,600 位元組的 rho 位元組流應用到 2,600 位元組的洋蔥有效載荷。

前 1,300 位元組將透過此 XOR 操作被去混淆，因為它是 Alice 應用的相同操作，而 XOR 是對合的。所以 Bob 將_揭示_他的跳有效載荷，後面跟著一些看起來被打亂的資料。

同時，將 rho 位元組流應用到添加到洋蔥有效載荷的 1,300 個零將把它們變成看似隨機的填充資料。這個操作如 Bob 去混淆洋蔥，混淆填充 所示。

記住，每一跳都包含一個內部 HMAC，然後它將成為_下一跳_的外部 HMAC。 在這種情況下，Bob 提取內部 HMAC（他已經用外部 HMAC 驗證了加密封包的完整性），並將其放在一邊，因為他將把它附加到去混淆的封包上，以允許 Chan 驗證他加密封包的 HMAC。

現在 Bob 可以從洋蔥前面移除他的跳有效載荷，並左移剩餘的資料。來自後半 1,300 位元組填充的等於 Bob 跳有效載荷的資料量現在將移入洋蔥有效載荷空間。這如 Bob 移除跳有效載荷並左移其餘部分，用新填充填補空白 所示。

現在 Bob 可以保留前半 1,300 位元組，並丟棄擴展的（填充）1,300 位元組。

Bob 現在有一個 1,300 位元組的洋蔥封包要發送到下一跳。它幾乎與 Alice 為 Chan 建立的洋蔥有效載荷相同，除了最後 65 位元組左右的填充是 Bob 放的，會有所不同。

Bob 現在將洋蔥有效載荷複製到洋蔥封包中，附加 Chan 的外部 HMAC，使用橢圓曲線乘法操作重新隨機化會話金鑰（與發送者 Alice 做的方式相同），並附加一個新的版本位元組。

要重新隨機化會話金鑰，Bob 首先使用他的節點公鑰和他派生的共享秘密計算他這一跳的盲化因子：

有了這個生成的，Bob 現在透過使用他的會話金鑰和盲化因子執行 EC 乘法來重新隨機化會話金鑰：

session_key_chan 公鑰然後將被附加到洋蔥封包的前面，供 Chan 處理。

Bob 的跳有效載荷包含為 Chan 建立 HTLC 所需的指示。

在跳有效載荷中，Bob 找到 short_channel_id、amt_to_forward 和 cltv_expiry。

首先，Bob 檢查他是否有具有該短 ID 的通道。他發現他與 Chan 有這樣的通道。

接下來，Bob 確認出站金額（50,100 聰）小於入站金額（50,200 聰），因此 Bob 的費用預期得到滿足。

同樣，Bob 檢查出站 cltv_expiry 小於入站 cltv_expiry，給 Bob 足夠的時間在有違約時領取入站 HTLC。

Bob 現在建構並發送給 Chan 的 HTLC，如下：

Chan 重複與 Bob 完全相同的過程：

當 Dina 從 Chan 收到 update_add_htlc 訊息時，她從 payment_hash 知道這是給她的付款。她知道她是洋蔥中的最後一跳。

Dina 按照與 Bob 和 Chan 完全相同的過程來驗證和解開洋蔥，除了她不建構新填充也不轉發任何東西。相反，Dina 用 update_fulfill_htlc 回應 Chan 以兌換 HTLC。update_fulfill_htlc 將沿路徑向後流動直到到達 Alice。所有 HTLC 都被兌換，通道餘額被更新。付款完成！

failuremsg 定義在 BOLT #4: Onion Routing, Failure Messages。

失敗訊息由兩位元組 failure code 後跟適用於該失敗類型的資料組成。

failure_code 的頂部位元組是一組可以組合（用二進位 OR）的二進位標誌：