Eltoo 通道機制
理解 Eltoo 協議設計與閃電網路升級機制。
Eltoo 通道機制：閃電網路的狀態管理革新
Eltoo（發音為 "ell-too"）是閃電網路通道管理的一種提議機制，旨在解決當前 LN 實現中的一些技術挑戰。這個名字來自「Layer 2」的比特幣愛好者社群的幽默命名創意。本文將深入分析 Eltoo 的設計原理、與傳統 LN 通道的比較、以及其實現所需的比特幣腳本升級。
當前閃電通道的問題
懲罰模型的複雜性
目前閃電網路使用的通道管理機制基於「懲罰模型」（Penalty Model）：
- 狀態欺騙風險：通道參與者可能嘗試發布舊的通道狀態
- 懲罰機制：如果一方作弊，另一方可以「懲罰」作弊者，沒收其資金
- 複雜的安全假設：參與者必須監控區塊鏈以發現作弊行為
這種設計雖然安全性高，但帶來了複雜性：
# 當前 LN 通道的懲罰邏輯概念
class LNChannelPenalty:
def __init__(self, channel_state):
self.state = channel_state # 當前通道狀態
self.local_balance = channel_state.local_balance
self.remote_balance = channel_state.remote_balance
def handle_breach(self, breached_state, breaker_pubkey):
"""
處理作弊行為：實施懲罰
"""
# 計算懲罰：獲得作弊者的全部資金
penalty_amount = (
breached_state.local_balance +
breached_state.remote_balance
)
# 廣播懲罰交易
penalty_tx = self.create_penalty_tx(
breaker_pubkey,
penalty_amount
)
# 等待確認
self.broadcast_and_wait(penalty_tx)
# 懲罰完成後，通道關閉狀態管理的困難
在懲罰模型下，通道參與者必須：
- 持續監控：隨時監控區塊鏈上是否有舊狀態被發布
- 保存所有舊狀態：需要保存通道的完整歷史以應對作弊
- 處理多個 UTXO：每個狀態對應一個獨立的commitment交易
這導致：
- 錢包必須維護大量歷史數據
- 恢復過程複雜且容易出錯
- 資源需求隨使用時間增長
Eltoo 的設計原理
核心概念：狀態序列覆蓋
Eltoo 採用了一種完全不同的方法：最新的通道狀態優先。
┌─────────────────────────────────────────────────────────────┐
│ Eltoo 核心思想 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 懲罰模型： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 舊狀態發布 → 另一方可以懲罰 │ │
│ │ 狀態 N: 發布 → 被發現 → 資金被沒收 │ │
│ │ 狀態 N+1: 新狀態 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Eltoo 模型： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 舊狀態被新狀態覆蓋 │ │
│ │ 狀態 N: 發布 → 被狀態 N+1 覆蓋 → 無效 │ │
│ │ 狀態 N+1: 最新狀態 → 有效 │ │
│ │ 狀態 N+2: 更新的狀態 → 覆蓋 N+1 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 結果： │
│ - 不需要保存舊狀態 │
│ - 不需要持續監控區塊鏈 │
│ - 只需要知道「最新的狀態」 │
│ │
└─────────────────────────────────────────────────────────────┘為什麼叫 Eltoo
Eltoo 的名稱來自錨定輸出（OP_CHECKTEMPLATEVERIFY 或 OP_CTV）的比特幣改進提案 BIP-119。雖然 Eltoo 最終不需要 CTV，但這個名字在設計早期被採用並沿用至今。
Eltoo 的技術實現
狀態序列
Eltoo 使用遞增的序列號來標識通道狀態：
# Eltoo 狀態結構
class EltooState:
def __init__(self, sequence_number, local_balance, remote_balance):
self.sequence = sequence_number # 狀態序列號
self.local_balance = local_balance
self.remote_balance = remote_balance
self.update_public_keys = {
"local": generate_key(),
"remote": generate_key()
}
def to_script(self):
"""生成 Eltoo 狀態腳本"""
return f"""
OP_IF
# 路徑 1: 序列號檢查 + 延遲 + 雙方簽名
<self.sequence> OP_CHECKSEQUENCEVERIFY OP_DROP
{self.update_public_keys['local']} OP_CHECKSIG
OP_IF
{self.update_public_keys['remote']} OP_CHECKSIG
OP_ENDIF
OP_ELSE
# 路徑 2: 相對時間鎖 + 單方簽名（結算）
144 OP_CSV OP_DROP
{self.update_public_keys['local']} OP_CHECKSIG
OP_ENDIF
"""覆蓋機制
Eltoo 的核心機制是使用比特幣的 SIGHASH_ANYPREVOUT（APO）簽名類型：
┌─────────────────────────────────────────────────────────────┐
│ Eltoo 覆蓋機制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ SIGHASH_ANYPREVOUT 特性： │
│ - 簽名不綁定到特定的 UTXO │
│ - 同一個簽名可以用於多個不同的輸出 │
│ - 新狀態的簽名「覆蓋」舊狀態的輸出 │
│ │
│ 實際運作： │
│ │
│ 狀態 N 交易： │
│ Input: 通道 UTXO │
│ Output: {balance_A} → A, {balance_B} → B │
│ 簽名: SIGHASH_ANYPREVOUT │
│ │
│ 狀態 N+1 交易： │
│ Input: 同一個通道 UTXO（！） │
│ Output: {balance_A'} → A, {balance_B'} → B │
│ 簽名: SIGHASH_ANYPREVOUT │
│ │
│ 區塊鏈驗證： │
│ - 兩筆交易都引用同一個 UTXO │
│ - Bitcoin Core 會接受「序列號更大的那個」 │
│ - 較舊的交易被「覆蓋」 │
│ │
└─────────────────────────────────────────────────────────────┘更新公鑰
Eltoo 為每個狀態生成一對「更新公鑰」（Update Keys）：
class EltooChannel:
def __init__(self, initial_balances):
self.states = {}
self.current_sequence = 0
# 生成初始狀態
self.add_state(initial_balances)
def add_state(self, balances):
"""添加新的通道狀態"""
self.current_sequence += 1
# 生成新的更新公鑰對
local_update_key = generate_key()
remote_update_key = generate_key()
state = {
"sequence": self.current_sequence,
"balances": balances,
"local_update_key": local_update_key,
"remote_update_key": remote_update_key,
# 生成settlement key（用於最終結算）
"settlement_key": generate_settlement_key(
local_update_key,
remote_update_key
)
}
self.states[self.current_sequence] = state
return state結算流程
Eltoo 的通道關閉（結算）過程非常簡單：
class EltooSettlement:
def __init__(self, final_state):
self.final_state = final_state
def create_settlement_tx(self, channel_utxo):
"""
創建結算交易
使用 SIGHASH_ANYPREVOUT，簽名不綁定特定輸出
"""
tx = {
"version": 2,
"input": {
"outpoint": channel_utxo,
"sequence": self.final_state["sequence"],
"sig": generate_anyprevout_sig(
self.final_state["settlement_key"],
self.final_state["balances"]
)
},
"output": [
{"amount": self.final_state["balances"]["local"],
"address": "local_address"},
{"amount": self.final_state["balances"]["remote"],
"address": "remote_address"}
]
}
return tx
def broadcast_settlement(self, tx):
"""廣播結算交易"""
# 由於使用 ANYPREVOUT，這個交易可以
# 覆蓋任何之前的 commitment 交易
broadcast_to_network(tx)Eltoo 與 LN 懲罰模型的比較
安全模型比較
| 特性 | LN 懲罰模型 | Eltoo |
|---|---|---|
| 狀態處理 | 保存所有舊狀態 | 只保存最新狀態 |
| 監控需求 | 需要持續監控區塊鏈 | 可選監控 |
| 懲罰機制 | 有懲罰交易 | 無懲罰，舊狀態自然失效 |
| 數據存儲 | 隨使用時間增長 | 恆定大小 |
| 恢復複雜度 | 高 | 低 |
資金效率
Eltoo 可以提供更好的資金效率：
┌─────────────────────────────────────────────────────────────┐
│ 資金效率比較 │
├─────────────────────────────────────────────────────────────┤
│ │
│ LN 懲罰模型： │
│ - 每個 commitment 交易都是獨立的 │
│ - 雙方都需要預留資金作為「擔保」 │
│ - 關閉通道時，無法立即使用資金 │
│ │
│ Eltoo： │
│ - 只有最新的狀態有效 │
│ - 不需要預留擔保資金 │
│ - 可以立即結算並使用資金 │
│ │
│ 結果： │
│ - Eltoo 通道的實際吞吐量可能更高 │
│ - 資金_lock時間減少 │
│ │
└─────────────────────────────────────────────────────────────┘實現複雜度
| 組件 | LN 懲罰模型 | Eltoo |
|---|---|---|
| 比特幣腳本 | 較複雜 | 較簡單 |
| 簽名處理 | 標準 BIP-69 | 需要 ANYPREVOUT |
| 狀態管理 | 需要保存歷史 | 只需要當前狀態 |
| 離線處理 | 需要 Watchtower | 可選 |
| 錢包實現 | 成熟 | 需要新開發 |
實現 Eltoo 所需的比特幣升級
SIGHASH_ANYPREVOUT
Eltoo 的核心依賴比特幣的 SIGHASH_ANYPREVOUT（APO）簽名類型。
這個簽名類型允許簽名「不綁定」到特定的 UTXO，而是只綁定到輸出本身。這使得新的交易可以「覆蓋」舊的交易，因為它們可以花費同一個 UTXO。
比特幣腳本升級需求：
OP_CHECKSIG 的升級版本，允許 ANYPREVOUT：
升級前：
OP_CHECKSIG # 標準簽名驗證
升級後：
OP_CHECKSIGVERIFY # 可選的 ANYPREVOUT 模式
（通過 SIGHASH 標誌啟用）當前狀態
截至 2025 年，SIGHASH_ANYPREVOUT 仍然是一個比特幣改進提案（BIP），尚未激活。社區正在積極討論這個提案：
- 支持者：認為這將極大改善 LN 和其他 L2 解決方案
- 反對者：擔心可能引入新的攻擊向量
- 討論：需要足夠的礦工信號支持才能激活
Eltoo 的實作準備
模擬環境測試
在比特幣主網上實現 Eltoo 之前，應該在測試環境中進行全面測試：
class EltooSimulator:
def __init__(self):
self.channel = None
self.blockchain = []
def test_basic_update(self):
"""測試基本的狀態更新"""
# 1. 創建初始狀態
self.channel = EltooChannel({"local": 1_000_000, "remote": 0})
# 2. 創建第一次更新
self.channel.add_state({"local": 800_000, "remote": 200_000})
# 3. 創建第二次更新
self.channel.add_state({"local": 600_000, "remote": 400_000})
# 4. 模擬區塊鏈廣播最新狀態
latest_tx = self.create_settlement_tx(self.channel.states[3])
self.blockchain.append(latest_tx)
# 5. 驗證舊狀態被覆蓋
old_tx = self.create_settlement_tx(self.channel.states[2])
assert not self.is_valid(old_tx), "舊狀態應該無效"
def test_dispute_scenario(self):
"""測試爭議場景"""
# 1. 創建通道並進行多次更新
# 2. 一方試圖發布舊狀態
# 3. 驗證新狀態覆蓋舊狀態
pass安全性測試
需要進行以下安全性測試：
- 狀態覆蓋測試：確保新狀態確實覆蓋舊狀態
- 簽名有效性測試：確保只有有效簽名才能覆蓋
- 時序攻擊測試：測試各種時間相關的攻擊場景
- 離線場景測試：一方離線時的行為
Eltoo 的應用場景
閃電網路通道
Eltoo 最直接的應用是作為 LN 通道管理機制的替代：
- 新通道：可以直接使用 Eltoo 創建
- 現有通道遷移：複雜，需要雙方協調
- 混用模式：可以同時支持舊版和新版通道
雙向支付通道
Eltoo 的簡單性使其非常適合雙向支付場景：
┌─────────────────────────────────────────────────────────────┐
│ Eltoo 雙向通道 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 優勢： │
│ - 簡化的關閉流程 │
│ - 更低的資金 Lock 要求 │
│ - 更容易的狀態恢復 │
│ │
│ 適用場景： │
│ - 經常雙向支付的用戶（如商家-顧客） │
│ - 長期穩定關係 │
│ - 需要快速結算的場景 │
│ │
└─────────────────────────────────────────────────────────────┘其他 L2 應用
Eltoo 的設計原則也可以應用於其他比特幣 L2 解決方案：
- BitVM：樂觀 Rollup 實現
- Statechains：比特幣狀態通道
- Drivechain：側鏈提議
挑戰與限制
比特幣升級依賴
Eltoo 需要比特幣腳本升級才能實現。這意味著：
- 不確定性：升級可能永遠不會激活
- 時間跨度：即使激活，也需要數年時間才能被廣泛採用
- 生態過渡：現有 LN 節點需要升級
與現有 LN 的兼容性
Eltoo 與當前 LN 實現不完全兼容：
- 無法直接通信：需要新的協議消息
- 路由兼容性：可以與舊節點路由
- 錢包升級：需要錢包開發者支持
經濟激勵
Eltoo 的經濟模型需要進一步驗證：
- 監控激勵：如果不需要監控，如何激勵 watchtower
- 離線懲罰：離線時如何保護資金
- 誠實行為：如何確保雙方誠實
結論
Eltoo 代表了比特幣 L2 解決方案狀態管理的重要創新。通過使用「最新狀態優先」的設計，它簡化了通道管理，減少了資金 Lock 時間，並降低了錢包的實現複雜度。
然而，Eltoo 目前仍處於研究和提案階段。其實現依賴比特幣腳本的升級（SIGHASH_ANYPREVOUT），這是一個尚未激活的 BIP。
對於比特幣開發者和愛好者來說，理解 Eltoo 的設計原理可以幫助評估比特幣 L2 的未來發展方向。即使 Eltoo 本身可能需要數年才能部署，其設計理念已經影響了其他 L2 解決方案的設計。
相關資源
- Eltoo 論文：https://blockstream.com/eltoo.pdf
- BIP-118（SIGHASH_ANYPREVOUT）：https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
- Eltoo 實現討論：https://github.com/LN-Japan/ln-eltoo
相關文章
- 閃電網路 Channels 詳解 — 深入理解 HTLC、通道狀態與流動性管理。
- 閃電網路支付實戰：LNURLw 完整教學 — 深入理解 LNURLw 標準，包含 Channels.open()、Invoice.create() 等實際操作流程。
- 閃電網路路由機制完全指南 — 深入解析閃電網路的路由演算法、費用計算、流動性管理與隱私保護機制。
- HTLC 深度解析 — 哈希時間鎖定合約詳解
- Taproot Channels 閃電升級 — Taproot 如何提升閃電網路的隱私與效率。
延伸閱讀與來源
這篇文章對您有幫助嗎？
請告訴我們如何改進：
0 人覺得有帮助
評論
發表評論
注意：由於這是靜態網站，您的評論將儲存在本地瀏覽器中，不會公開顯示。
目前尚無評論，成為第一個發表評論的人吧！