以太坊Rollup二层方案大热，我们还需要状态通道吗？

写在前面：以太坊的扩容解决方案层出不穷，例子有 状态通道 、 Plasma 、 分片 以及最近非常流行的zk-rollup和optimistic rollup等，而像Plasma方案，此前已被判定了死刑，可以说，目前的以太坊社区更倾向于选择rollup及零知识证明方案，那状态通道方案的情况又如何呢？来自Consensys研发部Magmo团队的负责人Tom Close在这篇文章中解释了状态通道与rollup方案的互补作用，并简单提到了状态通道方案需要解决的一些问题。

（图片来自：tuchong.com）

如果你关注过一阵子以太坊生态，你可能听说过状态通道（state channel）这个术语，你可能了解过它们具有提高区块链可扩展性的潜力，以及它们为交易提供“即时终局性”的能力，但这些都是老新闻了，在一个rollup技术大行其道的以太坊世界里，你可能会想知道状态通道的位置是在哪里。

在这个系列的文章中，我们将介绍关于状态通道的最新进展。我们会从零开始，解释它的重要概念以及最新的设计。此外，我们还会分享自去年宣布状态通道合作以来所做的工作：我们构建了一套工具，它允许项目将状态通道添加到其技术栈中。为了让大家更好地了解并体验状态通道，我们还将发布几个项目来演示状态通道的功能。

图：关于状态通道的开发活动

而在今天，我们将探讨区块链技术领域中的状态通道，并对它们的工作方式进行一个大概的总结，当然，这些总结对您来说可能并不是全新的，但它应该能够很好地刷新有关新状态通道的基本知识。

状态通道有什么好处？

状态通道通常被描述为一种可扩展性解决方案。自从状态通道首次被提出以来，关于Layer 2扩容方面已经有了很多进展（Layer 2是指构建在区块链之上的解决方案，因此它们不需要对核心协议进行任何更改。）

而最新的Layer 2扩容解决方案就是zk-rollups和optimistic rollups，这两种方法都涉及定期向区块链提交批处理交易数据以及生成的状态根，从而允许更高的交易吞吐量。使用zk-rollups方案，可提供关于整体状态转换正确性的零知识证明，从而保证链上状态有效，并允许立即撤出。由于生成证明的复杂性，zk-rollup系统目前仅被用于简单的资产转换。而Optimistic rollups方案则允许在链下设置中执行任意EVM代码，但要求用户在退出其资金之前等待一个挑战期（challenge period），并依赖挑战不正确状态的各方来维护转换的完整性。

这两种方法的可扩展性都很可观，可能实现大约500 tx/s的交易吞吐量。（ 译者注：这是Vitalik早期提出的一个估计值，在以太坊完成伊斯坦布尔硬分叉后，使得这两个方案的理论tps最高提升到了2048，而假设以太坊成功转向PoS方案，则这些方案的理论tps上限可得到极大的提升 ）

状态通道也有助于提高可扩展性，在某些用例中，状态通道有可能实现超过rollup方案的吞吐量，这是因为它消除了链处理大多数交易的需要。它们还具有一些独特的属性，这使得它们适用于一些用rollup方案难以实现的场景。

而其中一个非常重要的特性，在于它能够实现交易的非中介化：一旦双方建立了通道，他们就可以交换价值而无需第三方参与。但在rollup方案中，情况并不是这样的，因为所有交易都必须由rollup运营方处理的，而另一个重要特征就是转移的终局性。使用状态通道，在收到更新后即会更新状态，这意味着价值转移会立即发生。

例如，假设你想要求Infura API的用户为每个API调用支付少量的ETH。一个典型的用户每10秒左右就会碰一次你的endpoint，你希望能够向他们收取一分钱的费用，并且仍然给出一个亚秒级的响应时间。在这种情况下，你没有时间联系rollup操作者，即使这样做了，rollup交易的开销成本也将太高，即使它降低到100 gas （当前约为0.02分）。

或者，假设你想构建一个去中心化的ISP（互联网服务提供商），它允许用户从邻居那里购买带宽，并按MB为单位进行付费。或者，如果你想通过启用去中心化按需付费模式，为内容创作者提供广告收入的替代选择。或者，如果你想建立一个物联网设备网络，该设备可以在收集和提供数据时接受付款。或者，如果你想为状态提供者付款，以激励他们提供支持无状态ETH1.x区块链所需的数据……

在以上的这些情况下，你就有可能会想到状态通道方案了。

好吧，说了那么多，我们还没有提到状态通道的“状态”部分。在大多数情况下，上面的例子会需要用到支付通道（一种专门的状态通道），其中状态只是每个参与者的余额。链外交换的状态可以比这更通用，从而允许状态通道在用户之间提供更复杂的交互。在状态通道内，包括原子互换、任意复杂的条件支付，甚至是国际象棋游戏都可以完成。在设计激励方案时，这为系统设计人员提供了很大的灵活性。

总而言之，状态通道占据了权衡空间的一个独特区域，其特性在广泛的应用中具有重要意义。在本文的其余部分内容中，我们将概述状态通道的运作方式，以便更好地理解它们是如何实现上述特性的。

状态通道是如何运作的？

那什么是状态通道？我们将通过一个典型的状态通道交互来回答这个问题：

交互是从两个参与者Alice和Bob开始的，他们将一些资金存到区块链上的状态通道合约当中。然后，他们就如何分配资金交换协议结果（agreement）。这些协议结果（agreement）可以是简单的余额更新，也可以是更复杂的对象（例如包含棋局状态的对象），而其结果将用于分割资金。参与者在发送给对方之前将其签名添加到状态当中，而在最后一个协议结果（agreement）发送到状态通道合约当中时，该合约将相应地支付资金。

这种设置带来的可扩展性好处来自于这样一个事实：在第二阶段，当Alice和Bob交换已签署的协议（agreement）时，他们可以在不与区块链交互的情况下进行很多“交易”，而这仅受他们签署及交换消息的速度限制。

你可能想知道，这种情况下“交易”的真正含义是什么，因为实际上链上的资金并没有发生移动啊。

虽然状态通道合约中持有的资金没有变化，但索取权却发生了变化，当Bob收到Alice的最新消息时，他知道他目前可索取的资金份额已经发生了变化。这也是交易具有“即时终局性”的意义。

那我们需要经常监视区块链吗？

到目前为止，我们只讨论了一切顺利的合作场景。但在状态通道这样的系统中，你应该要担心的一件事就是交易对手风险：如果你与Charlie一起开通了一个状态通道，并将资金存入该状态通道合约当中，那么当Charlie变得不合作，或者他丢失私钥时，通道中的资金会面临什么呢？你能把资金拿回来吗？或者Charlie是否可能会以此要挟于你，强迫你向他支付股份以释放资金？而这些问题的答案，是状态通道系统的另一个重要组成部分： 挑战（challenge）机制 。

从某种意义上说，针对这些问题有一个简单的答案：如果Charlie反应迟钝，你只需要通过向链上发送最新协议结果（agreement）来关闭通道，就像上述合作案例中一样。但是，这样做的问题在于，区块链无法判断你发送的协议结果是否实际上是最后一个，也就是说存在可能你可以通过它来做恶。那如何解决这个问题呢？有两种解决办法：

1. 第一种解决方案是针对合作情况的，其要求所有参与者明确签署声明，声明所讨论的是最终协议结果，并且该通道现已关闭。这样做的好处是可以即时取款，但如果一个或多个参与者无响应，则它对我们是没有帮助的。
2. 第二种方法，是让区块链在假定的最后一个状态提交之后，强制执行一个挑战期，并在撤回资金之前给其他参与者提交一个状态的机会。如果有人恶意提交挑战，则会遭受惩罚，从而可激励良好的行为。

而一个好的通道框架，是结合这两种方法，允许在合作情况中即时提款，同时仍提供在非合作情况中提款的途径。

好吧，这是不是意味着状态通道参与者需要不断监视区块链，以便检测恶意挑战的情况，然后做出响应？事实上，这一要求并没有看上去那么糟糕，参与者不必持续监控，他们只需要在每个挑战期检查几次区块链即可。而这里的负担，可通过谨慎选择挑战期来减轻，确保任何预期长期运行的通道都具有较长的挑战期。还可以向状态通道系统添加功能，以允许参与者抢先向链上提交最新状态，以确保他们在离线期间不会受到挑战。

下一步是什么？

在本系列的其余部分文章中，我们将深入探讨一系列状态通道主题，以使您全面了解它们的工作方式及用途。我们还将演示并发布一些用于处理状态通道的工具，然后允许您自己进行实验。

敬请期待！