ETH | 我们还需要状态通道吗？

本系列博文将向读者介绍 2020 年状态通道的最新进展。我们将从解释最基本的重要概念出发，逐步引出状态通道最新的设计方案。我们也会向读者分享自去年宣布状态通道协作以来，目前完成的工作进展：构建了一系列工具集，方便了其它项目添加状态通道到自己的链技术栈中。除此之外，我们也将发布一系列能体现状态通道性能的项目，给予开发者和用户直观的用户体验。

– 状态通道开发活跃度-

本文将介绍状态通道在区块链技术栈中的层次地位，简要总结其工作原理。读者或许已经了解过相关内容，但重温这些基础知识有助于理解本系列的余下文章。

状态通道有什么用？

状态通道往往被视为一种扩容方案。自状态通道问世以来，Layer 2 扩容也有了许多进展。（“Layer 2” 指在区块链上建构的解决方案，因此无需改进核心协议）

Layer 2 最新的扩容方案为 zk-rollups 以及 optimistic rollups 。上述方案都会周期性地向区块链提交批交易数据以及结果状态根，从而大大提升交易吞吐量。在 zk-rollups 中，侧链会向区块链提交能证明整体状态转移正确性的零知识证明，以确保链上状态的有效性，实现即时撤资。但由于零知识证明生成的复杂性，目前 zk-rollups 系统仅局限于简单的转账。Optimistic rollups 则可以通过链下设置执行任意 EVM 代码，但用户在撤资时需要等待一段挑战期，状态转移的正确性也依赖第三方对错误状态发起挑战。

上述方案在扩容上都能取得很好的效果，具备将主链交易吞吐量拓展到 500tx/s 的能力。

状态通道也能实现扩容，在某些特定场景（完全无需主链来处理交易主体的时候）能匹配甚至超越 rollups 方案带来的吞吐量提升。状态通道也有一些独特的性质，使得它们在某些场景下能取得比基于 rollup 方案更好的效果。

其中一点则是去中介交易：当两方建立好通道后，他们就可以在没有第三方介入的情况下自由交易。在 rollup 中就做不到这一点，所有的交易都需要由 rollup 运营者处理。另一个重要性质是交易的终结性（finality）。在状态通道中，一旦状态更新的消息被接收，就意味着状态已经完成了更新，价值转移已经被即时敲定。

我们来设想一个情景：开发者想要 Infura API 的用户按照 API 调用次数，逐次支付以太币。通常来说，用户一般每 10 秒就会触发一次调用，开发者则想要以零点几分的价格收费，同时响应延迟要保持在亚秒级。在这一场景中，根本没有时间去与 rollup 运营者发生交互，即使退一步来说，允许与 rollup 运营者交互，可 rollup 交易费也太高了，即使只需要 100 gas，也相当于 0.02 分（按成文时的价格计算）。

除此之外，还有很多场景。比方说你想构建一个去中心的 ISP（互联网服务提供商），使用户可以从邻居那里购买带宽，并以流量逐 MB 计费；或者内容创作者需要新的收入模型，在按照内容流支付或者阅读数支付时需要去中心化的支付方式；还有对于一个 IoT 设备网络，想要按照设备收集提供的数据获得酬劳；再或者是向状态数据提供商的激励支付，以促进他们为无状态 ETH 1.x 链的用户提供数据服务…… 在上述的场景中，使用状态通道就对了。

这里我们还没讲到状态通道中的 “状态” 概念。以上大部分例子都采用了一种特殊的状态通道 —— 支付通道，其中状态仅仅是参与方的账户余额信息。链外可用于交换的状态要比这个更宽泛，能为用户提供更复杂的交互操作。原子交换、任意复杂条件下的支付，甚至是棋类游戏都可以用上状态通道。这使系统设计者在设计激励机制时能放开拳脚。

总的来说，状态通道在扩容领域有着独特的地位，它的诸多属性在很多应用中都非常重要。下文将介绍状态通道的运行原理，帮助读者理解状态通道是如何神奇地实现上面介绍的诸多特性。

状态通道如何运行？

那么，状态通道究竟是什么？要解答这一问题，我们首先来看一个典型的状态通道交互过程：

Alice 和 Bob 参与双方进行交互，他们首先在区块链的状态通道合约中存入一定的资金，随后交换关于资金如何分配的协议规则。这些规则可以基于简单的余额更新，也可以取决于复杂的事件，比方说由一盘棋类游戏的结果决定资金的分配。参与双方在互相发送协议更新之前要对状态附上自己的签名。当最后一份双方认可的状态发送到状态通道合约时，资金也随之完成分配。

这种设定带来的可拓展性提升在于第二阶段，即 Alice 和 Bob 互相交换签过名的状态更新，这时他们无需与区块链发生交互就能实现很多 “交易”，交易速度仅仅受到签名以及消息交换的速度限制。

你可能会疑惑这里的 “交易” 究竟意味着什么，因为链上的资金并没有发生转移。虽然状态通道合约中的资金并没有发生变化，但是 申领这些资金的权利 已经发生转移了。当 Bob 收到了来自 Alice 的更新时，他就明白他目前可以从合约中申领的那部分资金已经改变了：他虽然暂时没有把钱提到账户中，但已经有了在未来的某个时间去提取那部分资金的权利。这也是为什么说这些交易具有 “即时确认性” 的原因，资金申领权随着消息的抵达而即时确定。

但难道不需要时刻监控着区块链吗？

目前我们只介绍了双方正常合作的例子，并没有恶意情况出现。在状态通道这种系统中，你应该留意的是来自对手的风险：如果你和 Charlie 一起打开了一条支付通道，向支付通道合约中存入了资金，那么当 Charlie 动了歪心思，或者丢失了他的私钥时，会发生怎样的后果？你可以取回自己的资金吗？Charlie 有没有可能把你的存款当作筹码，要求你额外支付一笔钱才还给你？这些问题的答案就是状态通道另一个非常重要的概念：挑战机制。

某种意义来说，上述问题并没有简单的答案：如果 Charlie 不再响应，你可以直接向链发送最后一笔协议，然后关闭通道，就和前面的例子一样。不过问题来了，区块链无法确定你发送的那笔协议是否真的是最后一笔 —— 你也可能是为了自己的利益而想要提前关闭这个通道。这个问题有两种解决方案。

第一种方案是在双方合作的场景下，每一个参与者都显式地签署一份状态声明，告知合约状态敲定，通道关闭。这种方式可以实现即时取款，但是当有一方不作应答时就无法实现。

第二种方案则是由区块链来强制设定一段挑战期，当有所谓的最后一笔状态提交时，可以给其他参与者一段时间窗口，在各方可以提款之前提交新的状态。惩罚提交了不实最终状态信息的参与者可以激励各方的正常合作。

一个好的通道框架需要同时涵盖上述两种方案，使得双方合作时能实现即时提款，在无应答时也有应对的提款步骤。

看起来状态通道双方需要时刻监控区块链，以侦测恶意的挑战行为，并及时在挑战期作出响应。不过这个要求其实并没有乍看之下那么糟糕；参与各方并不需要一直监测区块链，而是只要在每一段挑战期检查几次。通过合理的挑战期设置可以减轻这一监测负担，确保长期运行的状态通道有较长的挑战期。同时可以在状态通道系统中添加功能，使得参与各方预先向区块链提交最终状态，确保不会发生离线时被挑战的情况。

接下来呢？

在本系列的后续文章中，我们将深入讨论状态通道的方方面面，带你全面认识状态通道的工作原理以及应用场景。我们也会介绍和发布一些状态通道相关的工具，你可以自己上手试一试。

来源：以太坊爱好者