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

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

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

状态通道如何运行？

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

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

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

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

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

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

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

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

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

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