2/
状态通道并不新鲜。事实上，它们是以太坊最早的扩展解决方案之一。
状态通道本质上是：
-获取链上状态的一部分；
-不断改变链下状态；
-在需要时将最终状态提交至链上。
3/
显然，该概念是比特币闪电网络设计的延伸，闪电网络基本上是一个支付通道
然而，如果没有zkp，状态通道就没有任何意义。
4/
如果没有zkp，所有授权更改状态(链下)的签名都必须稍后在链上进行验证。
与链上交易相比，这并没有显著降低成本。
5/
zkp很容易解决这一问题。
状态通道参与者只需生成一个证明(链下)，证明他们所有的交互和签名都是有效的。证明在链上验证成本很低，节省大量成本。
6/
那么，这与扩展多人链上游戏有什么关系呢？
许多多人游戏（如扑克）都是基于匹配的，也就是说，一群玩家创建一个游戏，在游戏中竞争，根据游戏结果，每个人的资产都会发生变化。
7/
对于这类游戏，你需要一个共享层来存储每个人的资产。
比起游戏的最终结果（注：这会改变资产余额），每场游戏中所发生的细节并不重要。
此外，玩家不能同时参与多个游戏。
8/
这使得这些游戏成为zk状态通道的理想选择。
一旦游戏开始，参与玩家的状态就会锁定在Rollup中。
在游戏过程中，玩家生成zkp来证明其行为的有效性。
这些 ZKP在之前的 ZKP 的基础上递归，以此类推。
9/
当游戏结束时，只有最终的ZKP和相关的状态变化才会被提交到应用程序Rollup 进行结算。
由于中间交易不在Rollup上进行处理，因此这可以将扩展性提高100倍。
10/
这一方法也适用于非回合制游戏，如「Among Us」。
然而，在这种情况下，实体需要充当“临时”排序器，对通道交易进行排序，并生成中间递归zkp。
我称这类情况为“短暂的L3”。
11/
zk 状态通道方法的主要挑战在于通道参与者的有效性要求。
退出的参与者可能会迫使其余参与者继续执行应用程序rollup。因此，迫使其他参与者支付更高的成本。
尽管如此，这类方法的潜力巨大，许多团队正在朝着该目标努力，包括@ontropy、@PaimaStudios，以及@cartridge_gg。
