---
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-cn/crypto/state-channels/index.mdx