26

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

 4 years ago
source link: https://ethfans.org/posts/do-we-still-need-state-channels
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

如果你一直有留意以太坊生态的发展，那想必已经听说过状态通道了。不管是它提升区块链可拓展性的潜能，还是确保交易 “即时确认” 的能力，其实都已经是旧新闻了。你或许会困惑状态通道目前进展到了什么阶段，它和流行的 rollup 方案是否存在关联。

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

6n2iQzi.png!web

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

状态通道有什么用？

状态通道往往被视为一种扩容方案。自状态通道问世以来，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 链的用户提供数据服务...... 在上述的场景中，使用状态通道就对了。

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

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

状态通道如何运行？

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

faIvQrm.png!web

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

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

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

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

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

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

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

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

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

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

接下来呢？

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

点关注，不迷路！

（完）

原文链接: https://blog.statechannels.org/do-we-still-need-state-channels/

作者:Tom Close

翻译&校对:安仔C1int & 阿剑


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK