原文作者：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