跳转至主要内容

状态通道

上次编辑: , Invalid DateTime

状态通道让参与者可以安全地进行链下交易，同时最大限度地减少和以太坊主网的交互。 通道对等节点可以进行任意数量的链下交易，并且只需提交两个链上交易以打开和关闭通道。 这样便实现了极高的交易吞吐量，并为用户降低了成本。

前提条件

你应该已经阅读并理解关于以太坊扩容和二层网络的页面。

什么是通道？

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

通道是简单的对等协议，允许双方进行多笔交易，然后只将最终结果发布到区块链。 渠道使用加密算法证明产生的摘要数据确实是一组有效中间交易的结果。 “多重签名”智能合约确保交易由正确的相关方签署。

相关方通过通道执行和验证状态变化，最大限度减少以太坊执行层上的计算。 这就减少了以太坊拥塞，也提高了用户的交易处理速度。

每条通道都由以太坊上运行的多签智能合约管理。 要打开一条通道，参与者在链上部署通道合约并将资金存入其中。 双方共同签署一个状态更新来初始化通道的状态，之后他们就可以快速且自由地进行链下交易。

要关闭通道，参与者需要将各方一致同意的通道最终状态提交到链上。 然后，智能合约根据通道最终状态下每个参与者的余额分配锁定资金。

对等通道在一些情况下非常有用，比如，某些预先确定的参与者希望频繁进行交易，并且不会产生明显的费用。 区块链通道分为两类：支付通道和状态通道。

支付通道

将支付通道描述成由两个用户共同维护的“双向账本”最为恰当。 账本的初始余额是通道打开期间锁定在链上合约中的存款总和。 支付通道转账可以立刻执行，并且除了最初建立一次性链上通道以及通道的最终关闭外，其余部分无需区块链实际参与。

账本余额的更新（即支付渠道的状态）需要渠道中所有各方的批准。 通道更新在所有通道参与者签署后被视为最终确定，这和以太坊上的交易非常相似。

支付通道是最早的扩容方案之一，用于最大限度减少因简单的用户交互带来的高成本链上活动（例如，以太币转账、原子交换、小额支付）。 通道参与者彼此之间可以进行不限次数的即时、无费用交易，只要他们的转账总净额不超过存入的代币。

状态通道

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

状态通道与支付通道仍有很多共同点。 例如，当用户通过交换加密签名的信息（交易）进行互动时，另一些通道参与者也必须对信息签名。 如果提出的状态更新没有获得所有参与者的签名，则认为是无效的。

但是，除了保存用户的余额外，通道还跟踪合约存储的当前状态（即合约变量的值）。

这使得两个用户之间可以在链下执行智能合约。 在这种情况下，智能合约内部状态的更新只需由创建通道的另一方批准即可。

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

状态通道没有同样的安全保障。 在某种程度上，状态通道是主网的缩影。 由于执行规则的参与者有限，发生恶意行为（例如，提出无效状态更新）的可能性增加。 状态通道的安全性来自基于欺诈证明的争议仲裁系统。

状态通道如何运作

状态通道中的活动基本上都是一系列涉及用户和区块链系统的交互。 用户大多数情况下在链下相互交流，只是在打开通道、关闭通道或解决参与者之间的潜在争议时才与底层区块链交互。

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

打开通道

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

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

通道对等方必须签署一个他们一致同意的初始状态。 该初始状态表示状态通道的开通，之后用户可以开始交易。

使用通道

在初始化通道的状态后，对等方进行交互，他们签署交易并相互发送交易进行批准。 参与者使用这些交易发起状态更新，并签署来自其他人的状态更新。 每笔交易包括以下内容：

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

  • 通道的原有状态

  • 通道的新状态

  • 触发状态转换的交易（例如，Alice 向 Bob 发送 5 个以太币）

通道中的状态更新不会像用户在主网上交互时那样在链上广播，这与状态通道最大限度减少链上足迹的目标一致。 只要参与者一致同意状态更新，它们就与以太坊交易一样最终确定。 如果出现争议，参与者只需依赖主网的共识。

关闭通道

要关闭状态通道，需要将通道的各方一致同意的最终状态提交给链上智能合约。 状态更新中引用的详细信息包括每个参与者所实施行为的次数和获批准交易的列表。

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

上述场景代表了成功用例下的情况。 有时，用户可能无法达成一致并最终确定通道状态（失败用例）。 以下任何一种情况都可能是失败用例：

  • 参与者离线并且未能提出状态转换

  • 参与者拒绝共同签署有效的状态更新

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

  • 参与者提出无效的状态转换供其他人签署

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

解决争议

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

但是，一方可以提交链上请求以结束智能合约的执行并最终确定通道状态 — 而无需等待对方的批准。 如果出现上述任何破坏共识的情况，任何一方都可以触发链上合约以关闭通道并分配资金。 这样就实现了去信任，确保诚实的参与方可以随时提取他们的存款，而不管另一方的行为如何。

要处理通道退出，用户必须将应用的最后一次有效状态更新提交给链上合约。 如果状态更新得到证实（即，带有所有参与方的签名），那么资金会按照有利于他们的方式重新分配。

但是，执行单用户退出请求会有延迟。 如果关闭通道请求获得一致批准，则立即执行链上退出交易。

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

作为一种对策，状态通道允许诚实用户通过在链上提交最新、有效的通道状态来挑战无效状态更新。 状态通道的设计使得较新的、一致同意的状态更新优先于较早的状态更新。

一旦一个对等方触发了链上争议解决系统，另一方需要在一个时限内（称为挑战窗口）做出响应。 这样用户就可以挑战退出交易，尤其是在另一方应用过时更新的情况下。

不管是哪种情况，通道用户总是拥有可靠的最终确定性保障：如果他们拥有的状态转换由所有成员签署并且是最新的更新，那么它与常规链上交易具有相同的最终确定性。 他们仍然必须在链上挑战另一方，但唯一可能的结果是最终确定他们拥有的最新有效状态。

状态通道如何与以太坊交互？

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

与二层网络扩容解决方案不同，状态通道不会向主网发布交易数据或状态承诺。 但是，它们与主网的连接比侧链等更加紧密，这使得它们更加安全。

状态通道依赖于以太坊的主要协议，实现：

1. 可用性

打开通道时部署的链上合约负责通道的功能。 如果合约在以太坊上运行，则通道始终可用。 相反，即使主网正常运行，侧链也会随时失败，使用户资金面临风险。

2. 安全性

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

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

3. 最终确定性

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

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

虚拟状态通道

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

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

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

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

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

虚拟支付通道

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

状态通道的应用

支付

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

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

  1. 吞吐量：每条通道的链下交易数量与以太坊的吞吐量无关，而是受各种因素的影响，尤其是区块大小和出块时间。 通过在链下执行交易，区块链通道可以实现更高的吞吐量。

  2. 隐私：因为通道存在于链下，参与者之间的交互细节不会记录在以太坊的公共区块链上。 通道用户只需在向通道中存入资金和关闭通道或者解决争议时才进行链上交互。 因此，通道适用于希望进行更多私密交易的个人。

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

  4. 成本：当一组参与者需要长时间交换大量状态更新时，状态通道尤其适用。 唯一的成本是开启和关闭状态通道智能合约；在通道开启和关闭之间的每个状态变化的成本都比上一个更低，因为结算成本是相应分配的。

在二层网络解决方案（例如卷叠）上实施状态通道，可以使它们对支付更具吸引力。 虽然通道可以提供低廉的支付服务，但在通道打开阶段在主网上建立链上合约的成本可能会变得很昂贵 — 尤其是当燃料费飙升时。 基于以太坊的卷叠提供较低的交易费(opens in a new tab)，并且可以通过降低设置费用来减少通道参与者的开销。

微交易

微交易是低价值的支付（例如，不足一美元），商家无法在不产生损失的情况下处理它。 这些实体必须向支付服务提供商付款，然而，如果客户支付的利润太低而无法盈利，支付服务提供商就无法处理支付。

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

除了打开和关闭通道的成本外，参与者不会在微交易上产生更多费用（无燃料费用）。 这是一种双赢局面，因为客户在为服务支付多少费用方面拥有更大的灵活性，而且商家也不会失去有利可图的微交易。

去中心化应用程序

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

状态通道通常仅限于简单的基于回合的应用程序，因为这样可以更轻松地管理提交到链上合约的资金。 此外，由于定期更新链下应用程序状态的参与方数量有限，对不诚实行为实施惩罚相对简单。

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

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

状态通道应用程序的其他可能用例包括以太坊域名服务名称所有权、非同质化代币账本等等。

原子转账

早期的支付通道局限于双方之间的转账，限制了它们的实用性。 然而，虚拟通道的引入允许个人通过中间人（即多条对等通道）进行转账，而无需在链上打开新通道。

这种路由支付通常被描述为“多跳转账”，属于原子转账（即，交易的所有部分或者全部成功或或者全部失败）。 原子转账使用哈希时间锁定合约 (HTLC)(opens in a new tab) 确保只有在满足特定条件时才发放付款，从而降低另一交易方的风险。

使用状态通道的缺点

可用性假设

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

实际上，用户可能会因为无法控制的原因（例如，网络连接差、机械故障等）离线。 如果诚实用户下线，恶意对等方就可以利用这种情况，他们将旧的中间状态提供给裁决者合约并窃取提交的资金。

一些通道使用“瞭望塔”，这类实体负责代表他人监控链上争议事件并采取必要行动，例如提醒相关方。 但是，这可能会增加使用状态通道的成本。

数据不可用

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

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

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

流动性问题

要建立区块链通道，参与者需要在通道的整个生命周期将资金锁定在链上智能合约中。 这降低了通道用户的流动性，也会限制通道只能由那些有财力将资金一直锁定在主网上的用户使用。

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

链下服务提供商还可以打开包括多个对等方的通道，让通道可用于路由支付。 当然，用户必须为使用了服务而向链下服务提供商支付费用，这对某些人来说可能是不情愿的。

悲伤攻击

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

欺诈证明容易受到悲伤攻击，因为诚实的一方必须对每一个争议做出响应，即使是无效的争议，否则会面临失去资金的风险。 恶意参与者可以决定在链上重复发布过时的状态转换，迫使诚实方以有效状态进行响应。 这类链上交易的成本会迅速增加，导致诚实方在此过程中受损。

预定义的参与者集

根据设计，组成状态通道的参与者数量在通道整个生命周期中固定不变。 这是因为更新参与者集会使通道的运营复杂化，尤其是在向通道存入资金或解决争议时。 添加或移除参与者还需要进行额外的链上活动，这会增加用户的开销。

虽然这使得状态通道更容易推断，但它将通道设计的实用性局限于应用程序开发者。 这在一定程度上解释了为什么状态通道已被其他扩容解决方案所取代，例如卷叠。

并行交易处理

状态通道中的参与者轮流发送状态更新，这就是状态通道为何最适合“基于回合的应用程序”（例如，两人棋类游戏）的原因。 这样就无需处理同时出现的状态更新，并减少了链上合约为惩罚提出过时更新的发布者而必须完成的工作。 然而，这种设计的副作用是交易相互依赖，这增加了延迟并减弱了整体用户体验。

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

使用状态通道

许多项目提供状态通道实现，你可以将它们集成到自己的去中心化应用程序中：

延伸阅读

状态通道

还有哪些社区资源对你有所帮助？ 编辑本页面以添加！

返回顶部 ↑

本文对您有帮助吗？