跳至主要內容
進階

Zero-Conf Channels 零確認通道

了解零確認通道如何讓用戶在 funding 交易確認前就開始使用通道,實現即時的閃電網路體驗。

10 分鐘

什麼是零確認通道?

零確認通道(Zero-Conf Channels,也稱為 Turbo Channels)允許在 funding 交易 尚未被區塊鏈確認時就開始使用通道。這意味著用戶可以在開通道後立即發送和接收支付, 而不需要等待典型的 3-6 個區塊確認。

安全警告: 零確認通道存在雙花風險。只有當你信任通道對手不會雙花 funding 交易時才應使用。 通常只適用於與 LSP 或已知可信節點開設的通道。

工作原理

標準通道開設流程:

時間線:
T0      T1             T2              T3
│       │              │               │
▼       ▼              ▼               ▼
開始    Funding TX     等待確認        通道可用
協商    廣播           (3-6 區塊)
        │              │               │
        └──────────────┴───────────────┘
              約 30-60 分鐘

────────────────────────────────────────────

零確認通道流程:

時間線:
T0      T1
│       │
▼       ▼
開始    Funding TX 廣播 + 通道立即可用!
協商
        │
        └─────> 立即可以發送/接收支付

優勢:從開始到可用只需幾秒鐘

信任模型

接受方風險低

如果 Alice 開通道給 Bob,Bob 接受零確認:

  • • Bob 不提供任何資金
  • • 如果 Alice 雙花,Bob 只損失通道
  • • Bob 收到的支付可能失效

開啟方風險高

如果通道開啟者嘗試雙花自己的 funding tx:

  • • 可以「撤銷」已開的通道
  • • 可以取回 funding 中的資金
  • • 任何透過通道路由的支付都會失效

SCID Alias

零確認通道需要 SCID Alias 功能,因為真正的 Short Channel ID 要等到 funding tx 確認後才能確定:

Short Channel ID (SCID) Structure:

Standard SCID (after confirmation):
┌──────────────┬──────────────┬──────────────┐
│ Block Height │ TX Index     │ Output Index │
│ (3 bytes)    │ (3 bytes)    │ (2 bytes)    │
└──────────────┴──────────────┴──────────────┘
Example: 700000x1234x0

Zero-conf issue:
• Unconfirmed tx has no block height
• Cannot calculate real SCID

SCID Alias solution:
• Use temporary alias SCID
• Format: randomly generated 8-byte identifier
• Feature bit: option_scid_alias (bit 46/47)

After channel confirmation:
• Can still use alias to reference channel
• Can also use real SCID
• For private channels, alias hides block info

Option Zero Conf

option_zeroconf negotiation:

Feature bit: option_zeroconf (bit 50/51)

Flow:
1. Both parties announce option_zeroconf in init message
2. Opener requests zero-conf in open_channel/open_channel2
3. Acceptor agrees in accept_channel/accept_channel2

Message structure changes:
open_channel2:
  ...
  channel_type:
    - option_zeroconf
    - option_scid_alias
    - option_anchors_zero_fee_htlc_tx
  ...

Conditions for accepting zero-conf:
• Acceptor trusts opener not to double-spend
• Usually only with known LSP or partners
• Can set node whitelist

LSP 使用場景

零確認通道最常見的應用是 LSP(Lightning Service Provider)為用戶即時開通道:

LSP Instant Channel Opening:

1. User's first incoming payment
   ┌──────────┐         ┌──────────┐         ┌──────────┐
   │  Sender  │ ──────> │   LSP    │ ──────> │   User   │
   └──────────┘         └────┬─────┘         └──────────┘
                             │
                             │ User has no channel!
                             │ LSP opens zero-conf channel
                             ▼
   Process:
   1. LSP creates funding tx (LSP funds)
   2. LSP broadcasts funding tx
   3. Channel created immediately (zero-conf)
   4. Payment routed to user via new channel
   5. User receives payment instantly!

Security:
• LSP provides funding, won't double-spend itself
• User can trust the LSP
• Even if LSP double-spends, user only loses recent payment

2. JIT (Just-In-Time) Channels
   • Only open channel when needed
   • Saves block space
   • Improves user experience

Phoenix 錢包實例

ACINQ 的 Phoenix 錢包是零確認通道最成功的實現之一:

工作流程

  1. 用戶安裝 Phoenix,生成節點
  2. 用戶創建收款發票(此時沒有通道)
  3. 發送方支付發票
  4. ACINQ 節點攔截支付
  5. 即時開啟零確認通道
  6. 通過新通道轉發支付
  7. 用戶收到款項(總耗時 < 10 秒)

費用模型

Phoenix 從收款金額中扣除開通道費用(約 1%),包括鏈上交易手續費和服務費。

安全最佳實踐

對於節點運營者

  • • 只與可信節點使用零確認
  • • 維護白名單
  • • 設定最大零確認金額
  • • 監控雙花嘗試

對於用戶

  • • 只與知名 LSP 使用零確認
  • • 理解資金在確認前有風險
  • • 大額交易等待確認
  • • 不要轉發零確認通道的大額支付

實現狀態

LND 已支援

LND v0.15+ 支援 option_zeroconf 和 option_scid_alias。

Eclair 已支援

Eclair 全面支援,Phoenix 錢包廣泛使用此功能。

Core Lightning 已支援

CLN 支援零確認通道,可通過配置啟用。

LDK 已支援

Lightning Dev Kit 支援零確認,被多個錢包採用。

相關資源

下一步: 了解 通道堵塞 問題以及可能的解決方案。

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