---
title: "狀態通道"
description: "狀態通道讓固定參與者在鏈下交換已簽署的狀態更新，同時保留在鏈上強制執行最新有效結果的途徑。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 狀態通道

> 僅供教育參考，不構成投資或安全建議。如果金鑰、最新狀態資料、監控能力或提交鏈上回應的能力不可用，通道資金可能損失。

<a id="answer"></a>

## 直接答案

狀態通道是一種協定：一組固定參與者先在區塊鏈上鎖定資產或建立可強制執行的規則，再於鏈下交換經過認證的狀態更新。區塊鏈無須處理每次更新；參與者關閉通道或出現分歧時，它充當最終裁決者。

每次接受的更新都承諾於特定通道、應用狀態或資金分配，以及單調遞增的輪次編號或 nonce 等排序值。依據通道規則，較新的有效狀態取代較舊狀態。支付通道是較窄的類型，狀態主要記錄餘額；通用狀態通道還可表示遊戲步驟、交易或其他確定性的應用資料。

狀態通道可提供低延遲、避免將完整交易歷史公開上鏈的隱私，以及一般更新無須逐次支付基礎層費用等優點。但這些優點有前提：單次工作階段的參與者和資金通常固定；每位參與者都須保留執行最新狀態所需的證據；發生爭議時，基礎鏈還必須可用且費用可負擔。

<a id="mechanism"></a>

## 運作原理

1. **開啟並注資。** 參與者約定身分、應用規則、挑戰時長和初始分配，把資金鎖入鏈上裁決合約，或從已注資通道衍生新通道。注資交易在保障通道期間不能作為一般錢包餘額支出。
2. **交換已簽署狀態。** 參與者計算下一個有效狀態，並交換支援該狀態所需的簽章或協定訊息。狀態綁定唯一通道識別碼和遞增排序值，防止另一通道或更早輪次的簽章被悄然替換進來。
3. **保存執行資料包。** 錢包或節點保存最新受支援狀態、簽章、待處理條件式轉帳，以及協定要求的撤銷資訊或秘密材料。助記詞或許能恢復金鑰，但不一定能恢復持續變化的鏈下資料。
4. **繼續鏈下更新。** 大量更新無須基礎層交易即可發生，但轉帳仍受容量限制：單向可傳送金額不能超過目前分配和協定儲備允許的範圍。經多個支付通道路由時，每一跳都會增加流動性和在線性依賴。
5. **盡量合作關閉。** 參與者簽署最終結果，並提交協定要求的最小鏈上交易。合作關閉通常避免挑戰競速，且比單方面關閉更快或更便宜。
6. **將爭議升級到鏈上。** 若參與者失聯或提交過時狀態，另一方提交可執行證據。裁決合約套用協定的排序、逾時和狀態轉換規則。不同設計並不相同：有些允許用新狀態挑戰舊狀態；閃電網路式通道使用承諾和撤銷規則，而非通用的最高 nonce 競賽。
7. **期限後最終結算。** 相關挑戰期或時間鎖到期後，參與者領取結果。在所有輸出都解決之前，軟體可能需要監控鏈、應對重組，並為時間敏感交易提高費用。

<a id="example"></a>

## 範例

Alice 和 Bob 各以 `5 ETH` 開啟一個簡單的雙邊支付通道，因此通道控制 `10 ETH`。雙方共同簽署的開啟狀態是輪次 `0`：若此時結算，Alice 獲得 `5 ETH`，Bob 獲得 `5 ETH`。

隨後 Alice 向 Bob 支付 `1 ETH`。雙方驗證狀態轉換並簽署輪次 `1`，其中 Alice 分得 `4 ETH`，Bob 分得 `6 ETH`。之後 Bob 向 Alice 支付 `2 ETH`；輪次 `2` 分配給 Alice `6 ETH`、Bob `4 ETH`。合作運作時，只有注資操作和最終結算需要進入基礎鏈。

假設 Bob 後來提交輪次 `1`。在以最高輪次裁決的設計中，Alice 必須在挑戰期限前提交獲得完整支援的輪次 `2`。提交成功後，合約會拒絕較舊結果並依輪次 `2` 結算。若她遺失輪次 `2`、無法使用簽署金鑰、沒有支付費用所需的基礎資產，或離線超過期限，協定無法推斷雙方的私有歷史。因此，可執行結果可能不同於雙方實際同意的最新更新。

此例僅用於說明概念。真實協定會精確定義支援狀態所需的簽章、有效狀態轉換、條件式付款的解決方式，以及適用的鏈上呼叫和期限。不要只依據這組簡化算術轉移資金。

<a id="risks"></a>

## 風險與控制

- **舊狀態結算。** 保存最新且完整的執行資料包，並測試恢復流程。只有在理解相容監視塔會收到哪些資料和權限後，才使用它。
- **錯過挑戰窗口。** 在所有輸出最終確定前監控正確的鏈。設定期限時，應務實預留故障、重組、壅塞和人工回應時間。
- **費用與壅塞風險。** 保留未被鎖定的基礎層資產和提高手續費的途徑。大量爭議同時發生時，平時便宜的系統恰可能在急需退出時變貴。
- **金鑰或狀態資料遺失。** 依實作的正式方法備份通道狀態。除非協定明確保證安全，否則不要用舊快照恢復仍在運作的通道。
- **容量與路由失敗。** 檢查出入向流動性、儲備、最大條件式轉帳、到期餘量和每個中介。錢包總餘額不等於可用通道容量。
- **交易對手與在線性風險。** 交易對手通常無法改寫已正確保障的結果，但可以拒絕更新或合作關閉，迫使使用者走較慢的爭議途徑。
- **實作風險。** 用戶端、裁決合約、簽章域、轉換邏輯或升級控制的缺陷可能破壞預期保證。核驗實際部署的協定及其稽核。
- **隱私洩漏。** 鏈下更新不會自動匿名。對等節點、路由節點、網路觀察者、備份和最終爭議交易都可能暴露關係或應用資料。

<a id="misconceptions"></a>

## 常見誤解

- **「鏈下就代表無須區塊鏈也不必信任。」** 正是可信的鏈上執行途徑限制了交易對手信任；其安全性、可用性和費用仍然重要。
- **「只要雙方簽署，任何狀態都能結算。」** 哪些證據可執行，由協定特定的排序、有效性、最終性、撤銷和逾時規則決定。
- **「助記詞能恢復整個通道。」** 它通常只恢復金鑰，不一定恢復最新狀態、撤銷秘密、待處理轉帳或對等節點資料庫。
- **「使用者可以無限期離線。」** 許多設計要求在有限時間內觀察並回應，可由使用者親自完成，也可委託監控服務。
- **「通道容量等於錢包餘額。」** 資金必須先承諾給通道，可用容量還取決於方向、儲備、待處理轉帳和路由流動性。
- **「狀態通道可以全面取代 Rollup。」** 它最適合已知參與者之間的重複互動。需要開放成員資格、全域共享狀態或廣泛可組合性的應用，可能更適合 Rollup 或一般鏈上執行。

<a id="related"></a>

## 相關主題

- [Gas 費](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [Layer 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [智慧合約](/crypto/smart-contract/)

<a id="sources"></a>

## 來源

- [通用狀態通道網路](https://doi.org/10.1145/3243734.3243856) - ACM（存取日期：2026-08-21）
- [Nitro 協定](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive（存取日期：2026-08-21）
- [狀態與通道](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels（存取日期：2026-08-21）
- [BOLT #2：通道管理對等協定](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications（存取日期：2026-08-21）
- [BOLT #5：鏈上交易處理建議](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications（存取日期：2026-08-21）

Source: https://wiki.fcontext.com/zh-tw/crypto/state-channels/index.mdx