高級
Watchtower Protocol 瞭望塔協議
深入了解閃電網路瞭望塔的技術實現,包括協議細節、資料結構和隱私考量。
12 分鐘
瞭望塔協議概述
瞭望塔協議定義了客戶端和瞭望塔服務器之間的通訊方式。 協議設計需要平衡安全性、隱私和效率。
BOLT 13 草案: 瞭望塔協議尚未完全標準化。不同實現可能有不同的協議細節, 但核心概念相似。
核心資料結構
Watchtower Data Structures: Justice Transaction Blob: Encrypted data sent from client to watchtower: Plaintext contents: • sweep_address: Destination for penalty funds • revocation_key: Revocation private key • to_local_delay_key: Delayed payment private key • to_remote_key: Remote payment private key (optional) Or directly contains: • Pre-signed Justice Transaction Locator: For matching breach transactions on blockchain: locator = txid[:16] (first 16 bytes) Design considerations: • Long enough to avoid collisions • Short enough to save storage • Doesn't reveal full txid (privacy) Encryption Key: Blob encrypted using txid: encryption_key = SHA256(breach_txid) Encryption schemes: • ChaCha20-Poly1305 • AES-GCM (alternative) Result: • Watchtower cannot read blob contents • Can only decrypt when breach tx appears • Breach tx txid is the decryption key
協議訊息
Client-Watchtower Communication:
Session Establishment:
Client Watchtower
| |
|---- CreateSession ---------------->|
| { |
| blob_type, |
| max_updates, |
| reward_address (optional) |
| } |
| |
|<--- CreateSessionReply ------------|
| { |
| session_id, |
| accepted / rejected, |
| fee_rate |
| } |
State Update:
Client Watchtower
| |
|---- StateUpdate ------------------>|
| { |
| session_id, |
| seq_num, |
| locator, |
| encrypted_blob |
| } |
| |
|<--- StateUpdateReply --------------|
| { |
| code: ACCEPTED / REJECTED, |
| last_applied |
| } |
Delete Session:
DeleteSession {
session_id
}
Used to clean up resources after channel closes 瞭望塔處理流程
Watchtower Monitoring and Response:
Monitoring Phase:
For each new block:
for each tx in block:
locator = tx.txid[:16]
if locator in database:
# Possible breach!
blob = database.get(locator)
key = SHA256(tx.txid)
try:
justice_data = decrypt(blob, key)
broadcast_justice_tx(justice_data, tx)
except DecryptionError:
# False positive (locator collision)
continue
Building Justice Transaction:
Using decrypted data:
1. Identify breach commitment tx outputs
• to_local output (delayed)
• to_remote output
• HTLC outputs
2. Build spending transaction
• Sign using revocation private key
• Set appropriate fee rate
• Send to sweep_address
3. Broadcast Justice Transaction
• Use highest fee rate
• Monitor for confirmation 隱私保護
Privacy Design: What Watchtower Does NOT Know: [X] Client identity (can use Tor) [X] Channel counterparty [X] Channel capacity [X] Normal transaction activity [X] Fund amounts (until breach occurs) [X] Blob contents (until breach occurs) What Watchtower DOES Know: [O] Client has Lightning channels [O] Frequency of channel state updates [O] Approximate number of channels (by session count) [O] Full transaction when breach occurs Further Privacy Enhancements: 1. Use multiple watchtowers Distribute trust, no single point of knowledge 2. Add fake updates Obscure real activity patterns 3. Delay updates Batch send, hide real-time activity 4. Tor connection Hide IP address
獎勵機制
Altruistic 模式
瞭望塔免費提供服務。所有懲罰資金歸客戶端。 適合個人運行的瞭望塔。
Reward 模式
瞭望塔從懲罰資金中獲得部分獎勵。 激勵第三方提供可靠服務。
Reward Transaction Structure:
Justice Transaction with Reward:
Inputs:
Breach commitment transaction outputs
Outputs:
[0] Watchtower reward: X sats
to: reward_address (provided by watchtower)
[1] Client balance: remainder - fees
to: sweep_address (provided by client)
Reward Ratio Negotiation:
• Fixed amount
• Percentage
• Composite model 可靠性考量: 選擇瞭望塔時考慮其在線率、響應時間和聲譽。 使用多個瞭望塔增加可靠性。
相關資源
- • LND Watchtower Client
- • 瞭望塔概述
- • 懲罰交易
下一步: 了解 通道堵塞 問題及其防禦。
已複製連結