跳至主要內容
高級

洋蔥路由

深入理解閃電網路的洋蔥路由機制，如何在多跳支付中保護發送方和接收方的隱私。

15 分鐘

什麼是洋蔥路由？

洋蔥路由（Onion Routing）是閃電網路保護支付隱私的核心機制。 它確保每個中間節點只知道自己的「前一跳」和「後一跳」， 無法得知完整的支付路徑、發送方或接收方。

核心概念： 就像剝洋蔥一樣，每個節點剝開一層加密，只能看到給自己的指令和下一層加密的封包。

洋蔥封包結構

Onion Packet (1366 bytes):

• version (1 byte): 0x00
• public_key (33 bytes): session public key
• hop_payloads (1300 bytes):
  - hop 1 payload (encrypted)
  - hop 2 payload (encrypted)
  - ...
  - padding to 1300 bytes
• hmac (32 bytes): integrity verification

加密流程

發送方使用 Sphinx 混合格式加密，每一跳使用不同的共享密鑰： 

Encryption Process:

1. Generate session_key
2. Compute shared secret for each hop:
   shared_secret[i] = SHA256(ECDH(session_key, node_pubkey[i]))

3. Encrypt from last hop backwards:

   Innermost layer (receiver Carol):
     payload_carol = [amt, cltv, payment_secret]
     encrypt(payload_carol, key_carol)

   Middle layer (Bob):
     payload_bob = [amt, cltv, next_channel]
     + encrypted inner layer
     encrypt(all, key_bob)

   Outermost layer (Alice's next hop):
     payload = [amt, cltv, next_channel]
     + all encrypted inner layers
     encrypt(all, key_hop1)

每跳 Payload

TLV Payload Format (modern):

hop_payload:
├── amt_to_forward (type 2): forward amount (msat)
├── outgoing_cltv_value (type 4): outgoing CLTV
├── short_channel_id (type 6): next channel ID
│   (optional for final hop)
├── payment_data (type 8): payment data
│   ├── payment_secret (32 bytes)
│   └── total_msat (8 bytes)
└── other optional TLVs...

Non-final hop example:
{
  amt_to_forward: 100000,
  outgoing_cltv_value: 700000,
  short_channel_id: 123x456x0
}

Final hop example:
{
  amt_to_forward: 100000,
  outgoing_cltv_value: 700000,
  payment_data: {
    payment_secret: 0x...,
    total_msat: 100000
  }
}

解密與轉發

Node Processing Onion Packet:

1. Extract public_key from packet
2. Compute shared secret:
   shared_secret = SHA256(ECDH(node_privkey, public_key))

3. Verify HMAC
4. Decrypt first layer of hop_payloads
5. Read own payload
6. Remove own payload, shift remaining content left
7. Pad tail to maintain length
8. Update public_key (elliptic curve blinding)
9. Compute new HMAC
10. Forward to next hop

Elliptic Curve Blinding:
new_pubkey = old_pubkey * SHA256(shared_secret)

隱私保護

發送方隱私

中間節點不知道誰發起支付。可能是前一跳，也可能是更早的節點。

接收方隱私

中間節點不知道誰是最終接收方。可能是下一跳，也可能是更後的節點。

路徑隱私

中間節點不知道完整路徑長度（因為封包長度固定）。

金額隱私

只知道自己這一跳的轉發金額，不知道總金額。

錯誤回報

當支付失敗時，錯誤需要安全地回報給發送方： 

Failure Packet Structure:

failure_packet:
├── hmac (32 bytes): integrity verification
├── length (2 bytes)
├── error_code (2 bytes): error type
├── data_length (2 bytes)
└── data: additional error info

Each hop encrypts backwards:
Carol finds error -> encrypt -> Bob
Bob receives -> re-encrypt -> Alice

Alice tries decrypting with each hop's key:
1. Decrypt with hop1 key -> fail
2. Decrypt with hop2 key -> fail
3. Decrypt with hop3 key -> success! Error from hop3

常見錯誤碼

Node Errors:
0x400F: temporary_node_failure
0x4010: permanent_node_failure
0x4011: required_node_feature_missing

Channel Errors:
0x1007: temporary_channel_failure
0x1008: permanent_channel_failure
0x1009: required_channel_feature_missing
0x100A: unknown_next_peer

Update Suggested Errors:
0x100B: amount_below_minimum
0x100C: fee_insufficient
0x100D: incorrect_cltv_expiry
0x100E: expiry_too_soon

Final Node Errors:
0x400D: incorrect_or_unknown_payment_details
0x400E: incorrect_payment_amount
0x400F: final_incorrect_cltv_expiry

Route Blinding

Route Blinding 進一步增強接收方隱私，隱藏最後幾跳： 

Blinded Path Structure:

Receiver Carol creates blinded path:
1. Choose introduction node
2. Blind subsequent node IDs
3. Provide blinded_payloads

Sender sees:
Alice -> ... -> Intro -> [blinded] -> [blinded]
                  ^
             public         unknown

In blinded path:
• Each hop only knows next blinded point
• Sender cannot identify real receiver
• Introduction node knows first hop, not destination

Trampoline 路由

Trampoline 允許輕客戶端外包路由計算： 

Trampoline Routing:

Traditional routing:
Alice -> B -> C -> D -> E -> Carol
(Alice needs full network topology)

Trampoline routing:
Alice -> [Trampoline1] -> [Trampoline2] -> Carol
         |                 |
     T1 routes to T2   T2 routes to Carol

Advantages:
• Light clients don't need full network graph
• Reduced resource consumption
• Still preserves privacy (Trampoline doesn't know sender)

Disadvantages:
• Need to trust Trampoline node availability
• Fees may be higher

隱私限制

已知的隱私弱點：

  • 相同的 payment_hash 出現在所有跳（可被關聯）
  • 金額和 CLTV 的遞減模式可推測位置
  • 時間相關性（支付通過各節點的時間）
  • 網路拓撲資訊公開

下一步： 了解 發票格式 如何編碼支付請求資訊。

已複製連結
已複製到剪貼簿