---
title: "状态通道"
description: "介绍状态通道和支付通道，这是以太坊社区目前使用的一种扩容解决方案。"
lang: zh
sidebarDepth: 3
---

状态通道允许参与者安全地在链下进行交易，同时将与[以太坊](/)主网的交互保持在最低限度。通道对等节点可以进行任意数量的链下交易，而只需提交两笔链上交易来打开和关闭通道。这实现了极高的交易吞吐量，并为用户降低了成本。

## 前提条件 {#prerequisites}

你应该已经阅读并理解了关于[以太坊扩容](/developers/docs/scaling/)和[二层网络 (l2)](/layer-2/)的页面。

## 什么是通道？ {#what-are-channels}

由于其分布式架构，以太坊等公共区块链面临着可扩展性挑战：链上交易必须由所有节点执行。节点必须能够使用普通硬件处理区块中的交易量，这就对交易吞吐量施加了限制，以保持网络的去中心化。区块链通道通过允许用户在链下交互，同时仍然依赖主链的安全性进行最终结算，从而解决了这个问题。

通道是简单的点对点协议，允许双方在彼此之间进行许多交易，然后仅将最终结果发布到区块链上。通道使用密码学来证明它们生成的摘要数据确实是一组有效中间交易的结果。一个[“多重签名”](/developers/docs/smart-contracts/#multisig)智能合约确保交易由正确的各方签名。

通过通道，状态更改由相关方执行和验证，从而最大限度地减少了以太坊执行层上的计算。这减少了以太坊上的拥堵，同时也提高了用户的交易处理速度。

每个通道都由运行在以太坊上的[多重签名智能合约](/developers/docs/smart-contracts/#multisig)管理。要打开通道，参与者在链上部署通道合约并将资金存入其中。双方共同签名一个状态更新以初始化通道的状态，之后他们可以在链下快速自由地进行交易。

要关闭通道，参与者将最后达成一致的通道状态提交到链上。之后，智能合约根据通道最终状态中每个参与者的余额分配锁定的资金。

点对点通道特别适用于一些预定义参与者希望高频交易而不产生明显开销的情况。区块链通道分为两类：**支付通道**和**状态通道**。

## 支付通道 {#payment-channels}

支付通道最好被描述为由两个用户共同维护的“双向账本”。账本的初始余额是在通道打开阶段锁定在链上合约中的存款总和。支付通道转账可以瞬间完成，除了最初的一次性链上创建和最终的通道关闭之外，不需要实际区块链本身的参与。

账本余额（即支付通道的状态）的更新需要通道中所有各方的批准。由所有通道参与者签名的通道更新被认为是已最终确定的，就像以太坊上的交易一样。

支付通道是最早的扩容解决方案之一，旨在最大限度地减少简单用户交互（例如 ETH 转账、原子交换、微支付）的昂贵链上活动。只要转账的净总额不超过存入的代币，通道参与者就可以在彼此之间进行无限量的即时、免手续费交易。

## 状态通道 {#state-channels}

除了支持链下支付外，支付通道尚未被证明可用于处理通用状态转换逻辑。创建状态通道是为了解决这个问题，并使通道可用于扩展通用计算。

状态通道与支付通道仍然有很多共同点。例如，用户通过交换经过密码学签名的消息（交易）进行交互，其他通道参与者也必须对其进行签名。如果提议的状态更新没有得到所有参与者的签名，则被认为是无效的。

然而，除了持有用户的余额之外，通道还跟踪合约存储的当前状态（即合约变量的值）。

这使得在两个用户之间在链下执行智能合约成为可能。在这种情况下，智能合约内部状态的更新只需要创建通道的对等节点的批准。

虽然这解决了前面描述的可扩展性问题，但它对安全性有影响。在以太坊上，状态转换的有效性由网络的共识协议强制执行。这使得不可能对智能合约的状态提出无效更新或更改智能合约的执行。

状态通道没有相同的安全保证。在某种程度上，状态通道是主网的微缩版本。由于执行规则的参与者数量有限，恶意行为（例如，提议无效的状态更新）的可能性会增加。状态通道的安全性源于基于[欺诈证明](/glossary/#fraud-proof)的争议仲裁系统。

## 状态通道如何工作 {#how-state-channels-work}

基本上，状态通道中的活动是涉及用户和区块链系统的交互会话。用户主要在链下相互通信，仅在打开通道、关闭通道或解决参与者之间的潜在争议时才与底层区块链交互。

以下部分概述了状态通道的基本工作流程：

### 打开通道 {#opening-the-channel}

打开通道要求参与者将资金提交给主网上的智能合约。存款还充当虚拟账单，因此参与者可以自由交易而无需立即结算付款。只有当通道在链上已最终确定时，各方才会相互结算并提取账单上的剩余资金。

这笔存款还作为保证金，以保证每个参与者的诚实行为。如果在争议解决阶段发现存款人有恶意行为，合约将罚没他们的存款。

通道对等节点必须签名一个他们都同意的初始状态。这作为状态通道的创世状态，之后用户就可以开始交易了。

### 使用通道 {#using-the-channel}

初始化通道状态后，对等节点通过签名交易并将其发送给彼此以供批准来进行交互。参与者通过这些交易发起状态更新，并签名来自其他人的状态更新。每笔交易包括以下内容：

- 一个**随机数**，它充当交易的唯一 ID 并防止重放攻击。它还标识了状态更新发生的顺序（这对于争议解决很重要）

- 通道的旧状态

- 通道的新状态

- 触发状态转换的交易（例如，Alice 向 Bob 发送 5 ETH）

通道中的状态更新不会像用户在主网上交互时通常那样在链上广播，这符合状态通道最小化链上足迹的目标。只要参与者对状态更新达成一致，它们就和以太坊交易一样具有最终性。只有在出现争议时，参与者才需要依赖主网的共识。

### 关闭通道 {#closing-the-channel}

关闭状态通道需要将通道最终达成一致的状态提交给链上智能合约。状态更新中引用的详细信息包括每个参与者的操作次数和已批准交易的列表。

在验证状态更新有效（即由所有各方签名）后，智能合约最终确定通道并根据通道的结果分配锁定的资金。在链下进行的支付将应用于以太坊的状态，每个参与者都会收到其剩余部分的锁定资金。

上面描述的场景代表了在理想情况下发生的事情。有时，用户可能无法达成一致并最终确定通道（糟糕的情况）。以下任何一种情况都可能发生：

- 参与者离线且未能提议状态转换

- 参与者拒绝共同签名有效的状态更新

- 参与者试图通过向链上合约提议旧的状态更新来最终确定通道

- 参与者提议无效的状态转换供其他人签名

每当通道中参与者之间的共识破裂时，最后的选择是依赖主网的共识来强制执行通道的最终有效状态。在这种情况下，关闭状态通道需要在链上解决争议。

### 解决争议 {#settling-disputes}

通常，通道中的各方会事先同意关闭通道，并共同签名最后的状态转换，然后将其提交给智能合约。一旦更新在链上获得批准，链下智能合约的执行就会结束，参与者带着他们的钱退出通道。

然而，一方可以提交链上请求以结束智能合约的执行并最终确定通道——而无需等待对方的批准。如果发生前面描述的任何破坏共识的情况，任何一方都可以触发链上合约以关闭通道并分配资金。这提供了**去信任化**，确保诚实的一方可以在任何时候退出他们的存款，而不管另一方的行为如何。

为了处理通道退出，用户必须将应用程序的最后一个有效状态更新提交给链上合约。如果验证通过（即它带有所有各方的签名），那么资金将重新分配给他们。

然而，在执行单用户退出请求时存在延迟。如果结束通道的请求获得一致批准，则链上退出交易将立即执行。

由于存在欺诈行为的可能性，延迟在单用户退出中发挥作用。例如，通道参与者可能试图通过在链上提交较旧的状态更新来在以太坊上最终确定通道。

作为对策，状态通道允许诚实用户通过在链上提交通道的最新有效状态来挑战无效的状态更新。状态通道的设计使得较新的、达成一致的状态更新胜过较旧的状态更新。

一旦对等节点触发链上争议解决系统，另一方必须在时间限制（称为挑战窗口）内做出回应。这允许用户挑战退出交易，特别是如果另一方正在应用过时的更新。

无论情况如何，通道用户始终拥有强大的最终性保证：如果他们拥有的状态转换由所有成员签名并且是最新的更新，那么它与常规链上交易具有同等的最终性。他们仍然必须在链上挑战另一方，但唯一可能的结果是最终确定他们持有的最后一个有效状态。

### 状态通道如何与以太坊交互？ {#how-do-state-channels-interact-with-ethereum}

虽然它们作为链下协议存在，但状态通道有一个链上组件：打开通道时部署在以太坊上的智能合约。该合约控制存入通道的资产，验证状态更新，并仲裁参与者之间的争议。

与[二层网络 (l2)](/layer-2/)扩容解决方案不同，状态通道不会将交易数据或状态承诺发布到主网。然而，与[侧链](/developers/docs/scaling/sidechains/)等相比，它们与主网的连接更紧密，这使得它们在某种程度上更安全。

状态通道在以下方面依赖于以太坊主协议：

#### 1. 活跃度 {#liveness}

打开通道时部署的链上合约负责通道的功能。如果合约在以太坊上运行，那么通道始终可供使用。相反，即使主网正在运行，侧链也可能随时发生故障，从而使用户资金面临风险。

#### 2. 安全性 {#security}

在某种程度上，状态通道依赖以太坊来提供安全性并保护用户免受恶意对等节点的侵害。正如后面部分所讨论的，通道使用欺诈证明机制，让用户能够挑战试图使用无效或过时更新来最终确定通道的行为。

在这种情况下，诚实的一方将通道的最新有效状态作为欺诈证明提供给链上合约进行验证。欺诈证明使互不信任的各方能够进行链下交易，而不会在此过程中使其资金面临风险。

#### 3. 最终性 {#finality}

由通道用户共同签名的状态更新被认为与链上交易一样好。尽管如此，所有通道内活动只有在以太坊上关闭通道时才能实现真正的最终性。

在乐观的情况下，双方可以合作并签名最终状态更新并提交到链上以关闭通道，之后根据通道的最终状态分配资金。在悲观的情况下，如果有人试图通过在链上发布不正确的状态更新来作弊，他们的交易在挑战窗口结束之前不会被最终确定。

## 虚拟状态通道 {#virtual-state-channels}

状态通道的简单实现是在两个用户希望在链下执行应用程序时部署一个新合约。这不仅不可行，而且还否定了状态通道的成本效益（链上交易成本会迅速累积）。

为了解决这个问题，创建了“虚拟通道”。与需要链上交易来打开和终止的常规通道不同，虚拟通道可以在不与主链交互的情况下打开、执行和最终确定。使用这种方法甚至可以在链下解决争议。

该系统依赖于所谓的“账本通道”的存在，这些通道已在链上获得资金。双方之间的虚拟通道可以建立在现有的账本通道之上，账本通道的所有者充当中介。

每个虚拟通道中的用户通过一个新的合约实例进行交互，账本通道能够支持多个合约实例。账本通道的状态还包含多个合约存储状态，允许不同用户之间在链下并行执行应用程序。

就像常规通道一样，用户交换状态更新以推进状态机。除非出现争议，否则只需在打开或终止通道时联系中介。

### 虚拟支付通道 {#virtual-payment-channels}

虚拟支付通道的工作原理与虚拟状态通道相同：连接到同一网络的参与者可以传递消息，而无需在链上打开新通道。在虚拟支付通道中，价值转移通过一个或多个中介进行路由，并保证只有预期的接收者才能收到转移的资金。

## 状态通道的应用 {#applications-of-state-channels}

### 支付 {#payments}

早期的区块链通道是简单的协议，允许两个参与者在链下进行快速、低费用的转账，而无需在主网上支付高昂的交易费用。今天，支付通道对于专为以太币和代币的交换和存款而设计的应用程序仍然有用。

基于通道的支付具有以下优势：

1. **吞吐量**：每个通道的链下交易量与以太坊的吞吐量无关，后者受各种因素（特别是区块大小和出块时间）的影响。通过在链下执行交易，区块链通道可以实现更高的吞吐量。

2. **隐私**：由于通道存在于链下，参与者之间交互的详细信息不会记录在以太坊的公共区块链上。通道用户只需在为通道提供资金和关闭通道或解决争议时才在链上交互。因此，通道对于希望进行更私密交易的个人很有用。

3. **延迟**：如果双方合作，通道参与者之间进行的链下交易可以立即结算，从而减少延迟。相比之下，在主网上发送交易需要等待节点处理交易、生成包含该交易的新区块并达成共识。用户可能还需要等待更多区块确认，然后才能认为交易已最终确定。

4. **成本**：状态通道在一些参与者将在很长一段时间内交换许多状态更新的情况下特别有用。产生的唯一成本是打开和关闭状态通道智能合约；在打开和关闭通道之间的每次状态更改都将比上一次更便宜，因为结算成本被相应地分摊了。

在二层网络 (l2) 解决方案（例如[汇总](/developers/docs/scaling/#rollups)）上实现状态通道，可能会使它们对支付更具吸引力。虽然通道提供廉价的支付，但在打开阶段在主网上设置链上合约的成本可能会变得昂贵——尤其是当 Gas 费用飙升时。基于以太坊的汇总提供[更低的交易费用](https://l2fees.info/)，并且可以通过降低设置费用来减少通道参与者的开销。

### 微交易 {#microtransactions}

微交易是低价值的支付（例如，低于几美分），企业在不遭受损失的情况下无法处理这些支付。这些实体必须向支付服务提供商付款，如果客户付款的利润率太低而无法盈利，他们就无法做到这一点。

支付通道通过减少与微交易相关的开销来解决这个问题。例如，互联网服务提供商 (ISP) 可以与客户打开一个支付通道，允许他们在每次使用服务时流式传输小额付款。

除了打开和关闭通道的成本外，参与者不会在微交易上产生进一步的成本（没有 Gas 费用）。这是一个双赢的局面，因为客户在支付服务费用方面有更大的灵活性，而企业也不会错失有利可图的微交易。

### 去中心化应用 (dapp) {#decentralized-applications}

与支付通道一样，状态通道可以根据状态机的最终状态进行有条件支付。状态通道还可以支持任意状态转换逻辑，使其可用于在链下执行通用应用程序。

状态通道通常仅限于简单的回合制应用程序，因为这使得管理提交给链上合约的资金变得更加容易。此外，由于只有数量有限的各方定期更新链下应用程序的状态，惩罚不诚实行为相对简单。

状态通道应用程序的效率也取决于其设计。例如，开发人员可能会在链上部署一次应用程序通道合约，并允许其他玩家重复使用该应用程序而无需上链。在这种情况下，初始应用程序通道充当支持多个虚拟通道的账本通道，每个虚拟通道在链下运行应用程序智能合约的新实例。

状态通道应用程序的一个潜在用例是简单的双人游戏，其中资金根据游戏结果进行分配。这里的好处是玩家不必互相信任（去信任化），并且由链上合约而不是玩家来控制资金的分配和争议的解决（去中心化）。

状态通道应用程序的其他可能用例包括 ENS 名称所有权、NFT 账本等等。

### 原子转账 {#atomic-transfers}

早期的支付通道仅限于两方之间的转账，限制了它们的可用性。然而，虚拟通道的引入允许个人通过中介（即多个点对点通道）路由转账，而无需在链上打开新通道。

路由支付通常被称为“多跳转账”，它是原子的（即，交易的所有部分要么全部成功，要么完全失败）。原子转账使用[哈希时间锁定合约 (HTLC)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)来确保仅在满足特定条件时才释放付款，从而降低交易对手风险。

## 使用状态通道的缺点 {#drawbacks-of-state-channels}

### 活跃度假设 {#liveness-assumptions}

为了确保效率，状态通道对通道参与者响应争议的能力设置了时间限制。该规则假设对等节点将始终在线以监控通道活动并在必要时对挑战提出异议。

在现实中，用户可能会因为无法控制的原因（例如，互联网连接不良、机械故障等）而离线。如果诚实用户离线，恶意对等节点可以通过向裁决合约提交旧的中间状态并窃取提交的资金来利用这种情况。

一些通道使用“瞭望塔”——代表他人监视链上争议事件并采取必要行动（如提醒相关方）的实体。然而，这可能会增加使用状态通道的成本。

### 数据不可用性 {#data-unavailability}

如前所述，挑战无效争议需要提供状态通道的最新有效状态。这是另一个基于假设的规则——用户可以访问通道的最新状态。

虽然期望通道用户存储链下应用程序状态的副本是合理的，但这些数据可能会由于错误或机械故障而丢失。如果用户没有备份数据，他们只能希望另一方不会使用他们拥有的旧状态转换来最终确定无效的退出请求。

以太坊用户不必处理这个问题，因为网络强制执行关于数据可用性的规则。交易数据由所有节点存储和传播，并在必要时可供用户下载。

### 流动性问题 {#liquidity-issues}

要建立区块链通道，参与者需要在通道的生命周期内将资金锁定在链上智能合约中。这降低了通道用户的流动性，也将通道限制在那些能够负担得起将资金锁定在主网上的人。

然而，由链下服务提供商 (OSP) 运营的账本通道可以减少用户的流动性问题。连接到账本通道的两个对等节点可以创建一个虚拟通道，他们可以随时在链下完全打开和最终确定该通道。

链下服务提供商还可以与多个对等节点打开通道，使其可用于路由支付。当然，用户必须向 OSP 支付服务费用，这对于某些人来说可能是不可取的。

### 捣乱攻击 {#griefing-attacks}

捣乱攻击是基于欺诈证明的系统的常见特征。捣乱攻击不会直接使攻击者受益，但会给受害者带来悲伤（即伤害），因此得名。

欺诈证明容易受到捣乱攻击，因为诚实的一方必须对每一个争议（甚至是无效的争议）做出回应，否则就有失去资金的风险。恶意参与者可以决定反复在链上发布过时的状态转换，迫使诚实的一方以有效状态做出回应。这些链上交易的成本会迅速累积，导致诚实的一方在此过程中遭受损失。

### 预定义的参与者集合 {#predefined-participant-sets}

按照设计，组成状态通道的参与者数量在其整个生命周期中保持固定。这是因为更新参与者集合会使通道的操作复杂化，尤其是在为通道提供资金或解决争议时。添加或删除参与者还需要额外的链上活动，这增加了用户的开销。

虽然这使得状态通道更容易推理，但它限制了通道设计对应用程序开发人员的实用性。这部分解释了为什么状态通道被放弃，转而支持其他扩容解决方案，例如汇总。

### 并行交易处理 {#parallel-transaction-processing}

状态通道中的参与者轮流发送状态更新，这就是为什么它们最适合“回合制应用程序”（例如，双人国际象棋游戏）。这消除了处理同时状态更新的需要，并减少了链上合约为惩罚过时更新发布者而必须做的工作。然而，这种设计的一个副作用是交易相互依赖，增加了延迟并降低了整体用户体验。

一些状态通道通过使用“全双工”设计来解决这个问题，该设计将链下状态分为两个单向的“单工”状态，允许并发状态更新。这种设计提高了链下吞吐量并减少了交易延迟。

## 使用状态通道 {#use-state-channels}

多个项目提供了状态通道的实现，你可以将其集成到你的去中心化应用 (dapp) 中：

- [Connext](https://connext.network/)
- [Perun](https://perun.network/)
- [Raiden](https://raiden.network/)
- [Statechannels.org](https://statechannels.org/)

## 进一步阅读 {#further-reading}

**状态通道**

- [理解以太坊的二层网络扩容解决方案：状态通道、等离子体 (Plasma) 和 Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark，2018 年 2 月 12 日_
- [状态通道解释](https://www.jeffcoleman.ca/state-channels/) _2015 年 11 月 6 日 - Jeff Coleman_
- [状态通道基础知识](https://unlock-protocol.github.io/ethhub/ethereum-roadmap/layer-2-scaling/state-channels/) _District0x_
- [区块链状态通道：最新技术](https://ieeexplore.ieee.org/document/9627997)

_知道对你有帮助的社区资源吗？编辑本页面并添加它！_