進階
Channel Announcements 通道公告
了解閃電網路的通道公告機制，節點如何向網路廣播通道資訊以供路由使用。
10 分鐘
什麼是通道公告？
通道公告（Channel Announcement）是閃電網路 gossip 協議的核心訊息類型。 當兩個節點開設公開通道後，它們會向網路廣播通道的存在， 讓其他節點可以通過這個通道進行路由支付。
公開 vs 私有： 只有公開通道會發送 channel_announcement。 私有通道不公告，但仍可通過發票路由提示使用。
Gossip 訊息類型
Three Main Gossip Message Types 1. node_announcement Purpose: Announce node existence and connection info Sender: Node itself Contents: • signature: node signature • features: supported features • timestamp • node_id: node public key • rgb_color: node color • alias: node alias (max 32 bytes) • addresses: IP/Tor address list 2. channel_announcement Purpose: Announce channel existence Sender: Both channel parties co-sign Contents: See detailed structure below 3. channel_update Purpose: Update channel routing parameters Sender: One channel party Contents: • signature: sender's signature • short_channel_id: channel ID • timestamp • channel_flags: direction and status • cltv_expiry_delta: CLTV delta • htlc_minimum_msat: minimum HTLC • fee_base_msat: base fee • fee_proportional_millionths: proportional fee • htlc_maximum_msat: maximum HTLC
channel_announcement 結構
channel_announcement Detailed Structure ┌───────────────────────┬──────────┬────────────────────────┐ │ Field │ Size │ Description │ ├───────────────────────┼──────────┼────────────────────────┤ │ node_signature_1 │ 64 bytes │ Node 1 signature │ │ node_signature_2 │ 64 bytes │ Node 2 signature │ │ bitcoin_signature_1 │ 64 bytes │ Bitcoin key 1 sig │ │ bitcoin_signature_2 │ 64 bytes │ Bitcoin key 2 sig │ │ features │ var │ Feature bit vector │ │ chain_hash │ 32 bytes │ Blockchain identifier │ │ short_channel_id │ 8 bytes │ Channel short ID │ │ node_id_1 │ 33 bytes │ Node 1 pubkey │ │ node_id_2 │ 33 bytes │ Node 2 pubkey │ │ bitcoin_key_1 │ 33 bytes │ Bitcoin pubkey 1 │ │ bitcoin_key_2 │ 33 bytes │ Bitcoin pubkey 2 │ └───────────────────────┴──────────┴────────────────────────┘ Signature Verification: Signed data: SHA256(SHA256( features || chain_hash || short_channel_id || node_id_1 || node_id_2 || bitcoin_key_1 || bitcoin_key_2 )) Must verify: • All 4 signatures valid • node_id corresponds to active node • bitcoin_key corresponds to funding tx output • Funding tx confirmed and unspent
公告流程
Channel Announcement Sequence Alice Bob | | | [Channel open complete, waiting] | | | | [Funding tx gets enough confirms] | | | |---- announcement_signatures ------>| | short_channel_id | | node_signature | | bitcoin_signature | | | |<--- announcement_signatures -------| | short_channel_id | | node_signature | | bitcoin_signature | | | | [Both combine into channel_announcement] | | | [Broadcast channel_announcement] | | [Broadcast channel_update (dir 0)] | | [Broadcast channel_update (dir 1)] | Confirmation Requirements: • Standard: 6 confirmations • Configurable: minimum_depth parameter • Zero-conf channels don't send announcement (private)
鏈上驗證
Receiving Node Verification Steps 1. Signature Verification Verify 4 signatures: • node_signature_1 by node_id_1 • node_signature_2 by node_id_2 • bitcoin_signature_1 by bitcoin_key_1 • bitcoin_signature_2 by bitcoin_key_2 2. On-Chain Verification Use short_channel_id to find funding tx: • Block height -> block • Transaction index -> transaction • Output index -> output Verify: • Output exists and unspent • Output is P2WSH 2-of-2 multisig • Script uses bitcoin_key_1 and bitcoin_key_2 • Pubkeys in correct order (lexicographic) 3. Store in Routing Graph • Add channel to local graph • Record both nodes • Wait for channel_update to get routing params
channel_update
channel_update Fields channel_flags bits: • bit 0 (direction): 0=node_1->node_2, 1=node_2->node_1 • bit 1 (disabled): 0=enabled, 1=disabled Each channel needs two channel_updates: • Direction 0: sent by node_1, describes node_1->node_2 params • Direction 1: sent by node_2, describes node_2->node_1 params Routing Parameter Meanings: cltv_expiry_delta: CLTV delta required per hop htlc_minimum_msat: Minimum accepted HTLC amount htlc_maximum_msat: Maximum accepted HTLC amount fee_base_msat + fee_proportional_millionths: Routing fee = base + (amount * proportional / 1,000,000) Update Triggers: • Periodic updates (stay active) • Parameter changes • Channel enable/disable • Peer node status changes
Gossip 傳播
洪泛傳播
節點收到有效的 gossip 訊息後，轉發給所有對等節點。 訊息最終傳播到整個網路。
去重機制
使用 short_channel_id 和 timestamp 去重。 只接受更新的訊息，忽略舊的或重複的。
查詢同步
新節點可以使用 gossip_queries 請求歷史訊息。 按區塊範圍或 SCID 範圍查詢。
過期清理
2 週未更新的 channel_update 可能被視為過期。 注資交易被花費的通道會被移除。
私有通道處理
Private Channels (Unannounced)
Private Channel Behavior:
• No channel_announcement sent
• No channel_update to gossip
• Does not appear in network routing graph
But can still be used:
• Direct payments to peer
• Receive payments via invoice route hints
Invoice Route Hints:
BOLT 11 invoice 'r' tag:
route_hints:
- pubkey: entry node pubkey
short_channel_id: channel ID (can use alias)
fee_base_msat: fee
fee_proportional_millionths: fee
cltv_expiry_delta: CLTV delta
Sender uses this info to construct final hop 網路健康： 定期發送 channel_update 表示通道仍然活躍。 長時間沒有更新的通道可能被其他節點忽略。
相關資源
下一步： 了解 Sphinx 封包 如何實現洋蔥路由的隱私。
已複製連結