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

原文作者：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 的包裹上鎖。對以此類推。

閃電網絡節點數量已達16791個:金色財經報道，據1ML.com數據，目前，支撐網絡的節點數量達到16791個，相較30天前數據，環比上漲5.83%；通道數量為38022，相較30天前數據，環比上漲4.7%；閃電網絡承載能力目前為1084.79BTC，約合5626.91萬美元。[2021/2/18 17:27:47]

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

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

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

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

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

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

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

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

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

閃電網絡節點數量約為11881個:金色財經報道，據1ML數據顯示，當前比特幣閃電網絡節點數為11881個，過去30天內增加2.88%；通道數量為35814個，過去30天內下降1.2%；網絡容量達到903.85個BTC，過去30天內上升1%。[2020/3/19]

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

需要轉發的數額；

支付的秘密值；

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

時間鎖的長度。

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

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

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

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

動態 | Lightning Labs聯合創始人計劃推出閃電網絡技術書籍:8月28日，Lightning Labs聯合創始人兼首席技術官Olaoluwa Osuntokun宣布計劃推出閃電網絡技術書籍《Mastering the Lightning Network》，將于2020年第四季度發布。[2019/8/29]

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

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

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

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

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

動態 | 閃電網絡節點數量達9434個:據1ML.com數據顯示，閃電網絡節點數量呈持續上升趨勢。目前，支撐網絡的節點數量達到9434個，在過去的30天中上漲了4.78%，而通道數量為31209個，在過去的30天中下降了9.2%。閃電網絡承載能力目前為825.83個BTC，約合965.95萬美元。[2019/8/8]

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 來驗證消息的完整性。

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

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

動態 | 閃電網絡容量兩日內增加10BTC:據btcmanager報道，統計數據顯示，閃電網絡的容量在7月8日僅為40 BTC，而7月10日則為51.72 BTC（超過3.3萬美元）。閃電網絡容量從30 BTC增至40 BTC花費了一周時間，卻僅用兩天便從40 BTC增加到超過50 BTC。閃電網絡中的節點數量為2719，其間創建了8951個通道用于傳輸比特幣。大約2000個節點擁有活動的通道，過去24小時內打開了182個新的通道。[2018/7/11]

她先創建一個空的、長為 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：ALILICALICEICEALIXSLICEalice幣還有長期價值嗎flokiceo幣發行價

中幣下載