科普

我们还需要状态通道吗?

曾汨   |     |   698 次阅读

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

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

1

-状态通道开发活跃度-

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

状态通道有什么用?

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

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

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

状态通道如何运行?

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

2

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

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

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

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

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

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

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

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

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

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

接下来呢?

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

点关注,不迷路!

(完)


原文链接: https://blog.statechannels.org/do-we-still-need-state-channels/
作者: Tom Close
翻译&校对: 安仔C1int & 阿剑


你可能还会喜欢:

Layer 2 方案概览:从状态通道到 Roll Up

菜鸟学习状态通道,Part-1:支付通道

状态通道真的可以实现即时确定性吗?

 
0 人喜欢