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

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

報告：受益于Cash App和Chivo，過去一年閃電網絡支付額增長逾400%:4月14日消息，根據市場分析公司Arcane Research發布的報告，過去一年閃電網絡上發生的支付數量翻了一番，而這些支付的總價值（以美元計算）翻了兩番。該報告警告稱，用于衡量閃電網絡采用情況的熱門公共指標（最常見的是TVL）低估了其網絡規模，因為它們無法計算私有通道和不可見節點。此外，這些指標并不能反映現實世界中閃電網絡的使用情況，而明確查看支付量可以更清楚地了解閃電網絡的實際應用情況。

支付激增的部分原因是最近獲得閃電網絡訪問權限的用戶數量大幅增加。這是通過薩爾瓦多的Chivo Wallet和美國支付應用程序CashApp等應用程序實現。

Arcane Research估計，在2021年8月，大約100000名用戶可以使用閃電支付。截至今年3月，超過8000萬人能夠通過閃電網絡進行支付，這表明有很大的潛在用戶群。

報告發現，大約50%的支付金額來自個人之間的直接交易，也就是點對點（P2P）交易。近三分之一的支付金額來自交易所充值和提現，其余20%來自通過某種形式利用供應商進行的購買交易。（Cointelegraph）[2022/4/14 14:23:39]

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

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

比特幣閃電網節點數量為18606個:據1ML數據，當前比特幣閃電網絡節點數為18606個，過去30天內增加7.83%；通道數量為40936個，過去30天內增加6.8%；網絡容量達到1167.97個BTC，過去30天內增加7%。[2021/3/31 19:31:11]

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

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

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

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

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

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

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

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

需要轉發的數額；

支付的秘密值；

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

時間鎖的長度。

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

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

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

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

在 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 使用這些密鑰來混淆洋蔥的每一層，而那一跳則使用密鑰來解開混淆。

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

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

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

動態 | 報告：2019年比特幣閃電網絡容量提高了62%:1月16日消息，CoinGecko最近發布的報告顯示，2019年比特幣閃電網絡容量提高了62%，從1月初的526枚BTC上漲到12月月初的854枚BTC。報告還顯示，閃電的網絡容量在2019年5月達到峰值，當時網絡容量超過1100枚BTC。（AMBCrypto ）[2020/1/16]

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

Um key

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

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

現在，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：ALICEALIICELICalice幣創始人ALISICEBRKalice幣百倍幣

XLM