閃電網絡中的 “洋蔥路由” 是什么 及其工作原理_ICE

原文作者：LORENZO  編譯：btcstudy

一個網絡中的計算機依據協議跟彼此交流。在這里，“協議” 指的是一套規則系統，指定了消息應該如何傳輸和解讀。閃電網絡協議中的支付消息傳輸部分由 BOLT#4 描述，也叫 “洋蔥路由協議（Onion Rounting Protocol）”。

洋蔥路由是一種先于閃電網絡 25 年誕生的技術。它也被用在 Tor 中，正是 “Tor” 這個名字（“The Onion Router”）的由來。閃電網絡使用的是一個稍微修改之后的版本，叫做 “基于來源的洋蔥路由”，縮寫是 “SPHINX”。在這篇文章中，我們就要講講洋蔥路由是怎么工作的。

世界上存在許多不同的通信協議，但因為閃電網絡是一個支付網絡，選擇一個盡可能少揭示正被轉發的支付的信息的協議，就是合理的。

如果閃電網絡使用跟互聯網一樣的協議，每一個中間人都會知道誰是支付的發送者、誰是接收者、整條路徑上的其他中間人是誰。洋蔥路由是一個好的選擇，因為其特性保證了中間節點：

只知道自己的上一個節點（誰給自己發來了消息）和下一個節點（要把消息轉發到哪里去）。

不知道整條路徑的長度；

不知道自己在路徑中的位置。

我們用包裹作為類比，解釋一下洋蔥路由是怎么工作的。

假設 Alice 要給 Dina 支付。首先，Alice 要為自己的支付找出一條可行的路徑：

Alice → Bob → Chan → Dina然后，她構造出一個 “洋蔥”。她要從 Dina 開始（從路徑的末端開始）。她把一個秘密消息（支付內容）放在一個發送給 Dina 的包裹中，并且使用一個只有她和 Dina 知道的密鑰來上鎖。現在，她把這個包裹放到另一個準備發送給 Chan 的包裹中，并且使用只有她和 Chan 知道的密鑰，給這個發送給 Chan 的包裹上鎖。對以此類推。

比特幣閃電網絡節點數量為33,351個:金色財經報道，1ML網站數據顯示，比特幣閃電網絡（LightningNetwork）的節點數量為33,351個，同比增長4.55%；通道數量為85,845個，同比增長2.3%；網絡容量為3,388.21BTC，同比增長1%。[2022/1/27 9:15:43]

Alice 把最終的洋蔥（包裹）發給路徑上的第一個中間人，Bob。Bob 使用自己的密鑰解鎖自己的包裹，然后看到下一個包裹是發送給 Chan 的。于是他把包裹轉發給 Chan。Chan 也一樣，解開包裹之后，把里面那個包裹轉發給 Dina。最后，Dina 打開屬于自己的包裹，發現其中的支付消息。

在洋蔥路由中，像 Bob 和 Chan 這樣的中間人，并不知道給 Dina 的信息的內容，也不知道整條支付路徑的長度。他們唯一知道的，就是給他們轉發這個包裹的人，以及下一個接收包裹的人。這保證了消息的隱私性和路徑的機密性。每一個中間人都只能觸及專門為 TA 制作的那一層消息。

在閃電網絡的基于來源的洋蔥路由中，發送者選擇支付路徑，并為這條路徑構造出完整的洋蔥，這可以被視為隱私漏洞（譯者注：接收者的網絡位置必須向發送者曝光）。別的路由方案比如 “盲化路由”（中文譯本），通過向發送者混淆部分支付路徑來解決這個問題。不過，在這篇文章中，我們專講 SPHINX。

現在，我們來了解一下洋蔥路由的規范。在一開始，我們需要定義這些東西：

發送者是 “最初節點”（Alice）；

接收者是 “最終節點”（Dina）；

支付路徑上的每一個中間節點都是一 “跳”（Bob 和 Chan）；

每一跳之間的通信信息，叫做 “跳的負載”。

一旦 Alice 選出了一條支付路徑，她就從 gossip 協議中獲得每一條支付通道的信息，以創建每一跳的負載，本質上這就是在告訴每一跳，如何為正在轉發的支付創建 HTLC（哈希時間鎖合約）。

開發者：比特幣閃電網絡上的大型支付通道可能會被惡意利用:比特幣閃電網絡的獨立開發者Joost Jager概述了一種利用微支付網絡的方法，這種方法可以輕易地以極低成本對閃電網絡通道造成損害。目前他正在努力尋找一個可能的解決方案。Jager稱，攻擊可以在wumbo通道上進行，這實際上允許閃電網絡上相互同意的各方之間進行更大的交易。Jager指出，wumbo通道可能會被利用，因為通道在任何時候都不能持有超過483個哈希和時間鎖定合約（HTLCs），不管它的容量有多大。因此，作惡者向自己發送483筆小額支付，并持有HTLCs，足以使一個通道癱瘓長達兩周。（Cointelegraph）[2020/9/23]

為了建立一個合適的 HTLC，每一跳都需要：

需要轉發的數額；

支付的秘密值；

繼續發送洋蔥的支付通道的 ID；

時間鎖的長度。

這些數據中的大部分，都來自 “通道更新” 消息，這樣的消息包含了關于路由手續費、事件所要求、支付通道 ID 的信息。需要轉發的總數額，是支付的數額加上后續每一跳所收取的手續費總和；而支付的秘密值則是由 Dina 計算出來并嵌進支付發票中的（由洋蔥消息告知路徑上的每一跳）。

Alice 從最終節點 Dina 開始。她在包裹中包含轉發數額、時間鎖時長數值、支付秘密值以及支付數額。注意，她不需要再加入通道 ID，因為 Dina 就是最終節點，不需要再將支付轉發給其他人。

乍看起來，提供轉發數額是多余的，因為這個數額跟支付數額是一樣的，但是，多路徑（multipath）支付會將支付總額通過多條路徑送達，那時候兩個數值就會不一致。

閃電網絡節點數量已達13766個:金色財經報道，據1ML.com數據，目前，支撐網絡的節點數量達到13766個，相較30天前數據，環比上漲2.89%；通道數量為36453，相較30天前數據，環比下降2%；閃電網絡承載能力目前為1061.24BTC，約合1108.79萬美元。[2020/9/10]

在 Chan 的負載中，Alice 加入 Chan 跟 Dina 的通道 ID。她還添加了轉發數額以及時間鎖數值。最后，Alice 創建給 Bob 的負載。Chan 為通過自己跟 Dina 的通道的支付收取 100 聰，因此，Alice 需要告訴 Bob 的轉發數額是支付額加上手續費。根據 Chan 的通道更新消息，時間鎖的數值也提高了 20（以區塊為單位）。最后，Alice 也要考慮 Bob 的手續費和時間鎖要求，給他一個時間鎖長度為 700040、價值為 100200 聰的 HTLC。

下一筆，Alice 通過為每一跳（包括最終節點）生成一個共享秘密值（shared secret），準備好洋蔥。這個共享秘密值可以由 Alice 和目標那一跳各自生成出來，辦法就是用自己的私鑰與對方的公鑰相乘。

共享秘密值對洋蔥路由來說是必要的，這讓 Alice 和每一跳可以推導出相同的密鑰。然后，Alice 使用這些密鑰來混淆洋蔥的每一層，而那一跳則使用密鑰來解開混淆。

為了保護 Alice 的隱私，她會為一個洋蔥創建一個一次性的會話密鑰，而不是使用自己的節點公鑰，以推導共享秘密值。她給第一跳使用這個會話密鑰，然后，對后續的每一跳，Alice 都將最新的密鑰乘以一個盲化因子，從而確定性地隨機化密鑰。這些用來創建共享秘密值密鑰，我們叫做 “臨時密鑰” 。

比特幣閃電網通道數量為36273個:金色財經報道，據1ML數據，當前比特幣閃電網絡節點數為12163個，過去30天內增加1.71%；通道數量為36273個，過去30天內增加0.80%；網絡容量達到955.79個BTC，過去30天內增加5%。[2020/4/20]

Bob、Chan 和 Dina，都需要跟 Alice 得到相同的秘密值，因此，他們需要知曉用在自己的會話中的臨時密鑰。Alice 只將第一個密鑰放到洋蔥中，以節約消息的體積。每一跳都計算下一個臨時密鑰，并將它嵌在給下一個節點的洋蔥中。各跳可以使用自己的公鑰和共享秘密值計算出 Alice 所用的盲化因子，從而確定下一個臨時密鑰。

如前所述，共享秘密值會被用來生成一些密鑰，Alice 和對應跳可以用這些密鑰對洋蔥做一些操作。我們來看看每一個密鑰的用途。

Rho key

Rho key 被 Alice 用來加密一層洋蔥；這樣會混淆負載的內容，使外人無法解讀。只有 rho key 的主人可以解密負載。這就是收到洋蔥的節點要做的事：使用跟 Alice 的共享秘密值推導出 rho key，然后解密洋蔥、閱讀內容。

Mu key

Alice 使用 mu key 來為每一個負載創建一個校驗和。她也會把校驗和交給接收洋蔥的那一跳。反過來，這一跳會使用 mu key 生成所收到的負載的校驗和，檢查是否與 Alice 給出的相匹配。這是為了檢查負載的完整性，驗證它沒有被篡改過。

Pad key

這個密鑰僅為 Alice 所用，用來生成隨機的 “垃圾” 數據。這些數據也是洋蔥的一部分，而且它跟支付路徑的長度、洋蔥已經通過多少跳無關，它讓洋蔥總是保持相同的體積，即使其某些內容需是無關緊要的。這就是洋蔥路由如何隱藏路徑長度的，實際上就是在保護發送者和接收者的隱私。

Um key

這個密鑰也用來檢查洋蔥內包含的數據的完整性，但僅在回傳錯誤時使用。沒錯，它叫做 “um” 是因為這是 “mu” 的倒寫。在支付出錯的情形中，發現錯誤的那一跳將使用 um key 創建一個校驗和，當前一個節點收到這個報錯時，也使用 um key 來驗證消息的完整性。

WordPress推出面向網絡文章發行人的閃電網絡應用程序:據coinjournal消息，WordPress推出閃電網絡應用程序（LApp），挑戰Blockstream。該LApp將實現在線內容的簡單透明獲利，而不會使許多發布商／發行人的收入依賴于廣告收入。這款LApp允許使用WordPress的發行人在用戶可以訪問其網站完整文章或博客文章之前要求使用閃電網絡小額支付比特幣，這似乎為許多基于網絡的發行人提供了一個很好的解決方案，這是因為這些發行人的收入通常完全控制在少數的大型廣告網絡上。[2018/3/28]

最終的洋蔥包裹看起來是這樣的：

現在，Alice 擁有了給每一跳的負載，以及給每一跳的共享秘密值。我們來看看 Alice 如何將這些信息轉化為最終的洋蔥。她先從最終節點開始，然后一步一步往回推。

她先創建一個空的、長為 1300 字節的域，這也是所有洋蔥負載的總長。然后，她使用 pad key創建一段長為 1300 字節的隨機串，這就是對任何一跳都沒用的垃圾。做這一步，是為了確保每一層洋蔥看起來都是一樣的，所以既無法看出路徑的總長（有多少跳），也看不出誰是發送者、誰是接收者。

然后，她給需要使用的負載創建一個校驗和，并放在負載的末尾。在給最終節點的消息中，校驗和全部為 0，以告知 Dina，她就是這個洋蔥的最終接收者。把校驗和添加到負載的末尾之后，Alice 就把負載（以及校驗和）放到垃圾的開頭，并刪去整條消息超過 1300 字節的部分，以保證整個消息的長度就是 1300 字節。

然后，Alice 使用 rho key 創建一個隨機字節串，并對上一步得到的洋蔥負載使用異或（XOR）運算，得到混淆后的負載。負載的原文可以通過對混淆文使用這個隨機字節串的 XOR 運算得到（譯者注：換言之，這里的 XOR 就是對稱加密的算法，而隨機字節串就是密鑰）。XOR 操作會逐比特對比洋蔥負載和（由 rho key 生成的）隨機字節串，僅當其中一個數據的比特是 1 時，才會輸出 1；這就得出了一個混淆后的負載。XOR 操作巧妙的地方在于，只要你得到了對的那個隨機字節串以及混淆后的負載，只需用兩者再次運行 XOR 操作，就可以得到混淆之前的負載。

因為收到洋蔥的節點可以推導出相同的 rho key，可以他們可以生成跟 Alice 一樣的隨機字節串。這就是沿路的各個節點可以解開混淆、讀到內容的辦法。

準備好一跳的混淆洋蔥后，Alice 就給下一個節點重復相同的步驟。關鍵區別在于，完成 Dina 的洋蔥之后，她就不再需要生成垃圾了。她只需在有用的負載和校驗和之后接上上一步所生成的混淆洋蔥，再剪去超過 1300 字節的部分。下面這個 GIF 演示了整個過程：https://youtu.be/FzedRXqZDyY

最后，Alice 拿到最終的混淆洋蔥并添加一個校驗和，這樣 Bob 就可以驗證這個洋蔥的完整性。然后，Alice 加入會話公鑰，這樣 Bob 就可以使用這個公鑰來計算共享秘密值。最后，她還要加上一個表示版本的字節，告知其它節點如何解讀其中的數據。對 BOLT#4 所描述的版本來說，版本字節應為 0。

為了發送這個洋蔥包裹，發送者創建一條 update_add_htlc 消息，包含下列字段：

通道 ID：這個消息所關乎的具體通道。

ID：這個 HTLC 的標識符。

數額：這個 HTLC 的價值。

支付哈希值：由支付的接收方創建。

過期時間：這個 HTLC 將在一定區塊之后過期。

洋蔥包裹：為這筆支付創建的洋蔥，也就是上面講到的東西。

額外的數據：用來指定額外的數據。

準備好消息后，Alice 就把消息發送個 Bob。收到消息后，Bob 就可以開始解碼屬于自己的洋蔥了。他先從洋蔥包裹中獲得會話密鑰，然后使用它推導出跟 Alice 的共享秘密值。

有了共享秘密值，Bob 生成 mu key，以驗證嵌在洋蔥包裹中、負載的校驗和。如果負載沒有被篡改過，校驗和應該能匹配上。

為了防止路徑中的其他節點知道路徑有多長，Bob 會在洋蔥包裹內增加一個 1300 字節長、充滿了 0 的字段。然后，Bob 從 rho key 中生成一個 2600 字節長的隨機字節串。Bob 使用這個隨機字節串，對填充了 0 的洋蔥負載作 “異或” 運算。

還記得我怎么跟你說混淆洋蔥負載的嗎？使用混淆后的洋蔥負載作為輸入，跟相同的字節串運行 “異或” 操作，就能得到混淆前的洋蔥負載。因為 Alice 和 Bob 使用相同的共享秘密值，生成了相同的 rho key，Bob 可以解開混淆。這樣做的額外好處是，它又將 1300 字節長的填充字符變成了隨機字節。

Bob 解開混淆的負載中包括了他這一跳的負載數據以及一個指紋。Bob 保存這個指紋，以便將它添加到發送給 Chan 的洋蔥包裹中。在 Bob 將屬于自己的負載從洋蔥消息中分離出來后，他將洋蔥包裹轉回 1300 字節的原始大小，并跟 Alice 一樣隨機化自己的會話密鑰。最后，Bob 加上版本字節、會話密鑰以及他準備放在洋蔥負載中的指紋，就通過 update_add_htlc 消息將洋蔥包裹轉發給 Chan。

這個過程會一直持續，直至消息送到最終節點，Dina。當 Dina 收到 update_add_htlc 消息時，她可以揣進到自己所生成的秘密值的哈希值，這說明這個 HTLC 就是要發給她的。因此，Dina 只需檢查指紋、解開洋蔥消息、揭曉屬于自己的負載。這個動圖演示了整個過程：https://youtu.be/NhHAE6m9L6A

我們介紹的是一個成功案例，也就是一切都按部就班的案例，但如果這個過程發生了一些錯誤，那就必須一路回傳一條消息，以通知所有節點出了問題。這個過程跟常規的洋蔥路由類似。發現一個錯誤的故節點需要從共享秘密值中推導出 um key，并使用它生成一個隨機字節串，然后使用異或運算來混淆返回的洋蔥包裹。

發現錯誤的節點將給支付路徑的上一個節點回傳一條消息。每一跳都使用 um key 和 ammag key 作相同的操作，直到發送者收到這個包裹。最后，發送者分別使用 ammag key 和 um key 解開包裹的混淆并驗證。

錯誤可能由洋蔥包裹、節點或通道引起。如果你經常使用閃電網絡，你可能遇到過這樣的錯誤，比如 “通道不可用” 或 “手續費不足”。

參考文獻

Mastering the Lightning Network

BOLT #4: Onion Routing Protocol

BTCStudy

個人專欄

閱讀更多

金色早8點

金色財經 子木

歐科云鏈

比推BitpushNews

-R3PO

深潮TechFlow

MarsBit

Biteye

肖颯lawyer

PANews

Odaily星球日報

Foresight News

Tags：ICEALIALICELICalice幣怎么樣ALINK幣alice幣前景ALICE價格

DAI