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

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

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

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

組裝洋蔥

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

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

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

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

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

建構跳的負載

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

爲了建立一個合適的 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。

共享祕密值與密鑰生成

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

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

爲了保護 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

這個密鑰僅爲 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

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。