学习状态通道，Part-2：App 定制型状态通道

Part-1：支付通道

注：我决定改变这个系列的名称，把重点放在状态通道，而不是 Counterfactual 上，以便我们能够涵盖状态通道中所有的工作，而且不会将这两个概念混为一谈。

在我们开始之前，如果你没有读过我的第一篇博文——菜鸟学习状态通道 Part-1，你一定得看一下，因为本博文是基于上一篇的。

如果你更具懂技术，并且希望在代码中使用一个支付通道的例子，那你就很幸运了！上周末我写了一个简单的支付通道，你可以在下载到本地运行（它甚至还能进行测试！）——这是一个非常简单的实现，可以让你基于以太坊区块链创建一个和别人的支付通道。我现在还在写一个 Web 应用程序，把支付通道与 Metamask 集成，不久之后应用程序就会发布了，现在你可以在这里找到程序代码。

就今天的手头业务而言，我们将讨论应用于特定应用程序的状态通道（Application-specific State Channel）。在这种状态通道下，我们能够允许人们完全在链下参与轮次系统（例如游戏），并根据游戏在链上的最终结果解决支付问题（或是下注）。其中有个例子就是国际象棋，两人开始时都下注 5ETH ，赢的人获得 10ETH 。

-搞不好这真的会写成一本书。-

App 定制型状态通道

在我们进入技术部分之前，让我们来看一个 App 专用型状态通道示例，两个人玩 Connect Four，四子连珠。

-我们现在玩到哪一步了？-

如果你以前没有玩过四子连珠，或者对游戏规则不熟悉，那么我简单介绍一下游戏规则，四子连珠实际上是一个网格，两个玩家轮流填充他们自己颜色的圆片。获胜条件是在水平对角或垂直方向连续填充四片。你可能注意到了，照片中的男孩就要完成这个目标了。

旁注：如果你真的很挑剔，你会注意到，当前的局势对女孩其实毫无意义，因为她最后无法完成四子连珠，如果你能驳斥这一点，请给我留言。（校对注：看图片会发现，女孩执黑，男孩执红。黑子有 13 个，红子有 12 个，所以现在轮到男孩落子。所以斜着连成三子的黑子是没有意义的，女孩赢不了）

所以，你可以想象有两个人为了钱而玩四子连珠（我小学的时候就是这样）——但是怎么做才能防止其中一个人因害怕损失赌注而中途反悔退场？这就是裁判员（法官）出现的原因——法官履行以下职责：

在比赛期间持有游戏资金
作为游戏规则的真相来源，解决玩家纠纷（例如：欺骗，拖延）
在某一方赢或双方平局的情况下适当分配资金

一旦选出了法官，他/她将在比赛期间持有资金并监督比赛进行。如果在任何时候，其中一个玩家感觉对方是在作弊或拖延游戏，他们可以通过支付小额费用向法官上诉，如果上诉正确，他们得到总游戏资金——如果不正确，游戏继续。当其中一名玩家看到他们或对手获胜时，他们可以要求法官核实验证，然后法官分别给两名玩家分配游戏奖励。

这就是一个 App 定制型状态通道运行的场景——法官就是一个可以理解游戏规则的智能合约，并能根据提交给他的结果进行汇款（通过奖励获胜者、惩罚作弊者或宣布平局的方式）。这种设置看起来如下图所示：

所以，就像上一篇一样，双方都同意他们在支付通道中拥有的 ETH 总量，现在他们每次都同意双方在游戏中进行的下一步操作。我们可以在上面的例子中看到 Alice 赢了游戏，但是 Bob 拒绝签署交易，阻止 Alice 向法官提交赢的状态——这就是“恶意破坏”。

相反，Bob 向法官提交了一个更早的状态，声称 Alice 正在拖延比赛。然后，Alice 可以在挑战期内驳斥 Bob 的观点，她提交了双方都签署的最新状态（Nonce 是 29）显示他们最新达成的一致意见。然后就开启了新状态的另一个挑战期。

注：Nonces 是状态的序列号，法官可据以判断某个状态是否比先前提交的状态新或旧。

在这种情况下，如果 Bob 没有签署链下交易并提交，他仍然会输给 Alice。所以在这种情况下，Bob 不仅输掉了赌注，而且他也失去了恶意破坏游戏时支付的法官上诉的费用。

下面有一个例子，说明了这种情况将如何发生的：

- Bob 试图提交一个旧交易-

- Alice 提交一个双方都签署的新的交易-

-合约在挑战期过后进行支付-

现在，当挑战期过了，法官智能合约会检查状态，并根据规则进行支付，来更新最新状态。在这种情况下，如果两分钟内 Bob 没有回应，并且提交的状态总没有四子连珠，那么所有的 ETH 都会被授予 Alice（根据规则 3）。但是，如果 Bob 签署了 Alice 赢的那个最后状态，那么智能合约就会识别出四子连珠，并将所有的 ETH 授予 Alice（根据规则1）。

因此，总的来说—— App 定制型状态通道就上是玩家在使用智能合约之前同意并编码应用程序的规则的地方。应用程序的规则还必须考虑一个参与者不合作的情况以及如何处理这种情况。利用这种框架，我们可以构建链下游戏，实现隐私、即时确定性和更低的成本——同时能够奖励链上用户。很酷，对吧？

谁在做相关的开发？

一个非常棒的例子就是 Tom Close 和他的团队正在 Magmo 开发的 Force-Move 游戏框架。它非常紧密地遵循我上述的规范，但是它模块化的、可扩展的方式，使得开发人员能够轻易地开发各种回合制游戏。

更多关于Tom Close和Force-Move 框架的资料：

Force-Move 游戏框架简介
Force-Move 游戏框架综述
Force-Move 游戏框架白皮书
Force-Move 游戏框架代码

第三部分：中心辐射支付通道

在我的下一篇文章中，我将深入研究 Connext 团队正在开发的中心辐射支付通道（Hu-and-Spoke Payment Channel），可为区块链应用程序提供高支付吞吐量。他们的支付通道将很快在 SpankChain 网络上投入运行。

如果你在开发利用状态通道的项目，我非常希望看到你的实现以及你开发的方式。这个领域的许多公司正在为 LearnChannels.org 提出一组标准和学习材料——它将会作为 learnplasma.org的状态通道版本。

如果你想了解更多关于状态通道或 Layer-2 扩展方案的信息，请随时通过 Twitter 或 LinkedIn 联系我，或者本文中列出的公司：Connext、Magmo、Spankchain、Counterfactual。

特别感谢史蒂文·麦基和艾莉森·艾米莉，让我与他们取得联系，并了解这个领域的公司正在做的事情。

Part-3：中心辐射状态通道
Part-4：账本通道和虚拟通道
Part-5：广义状态通道

链接: https://medium.com/blockchannel/state-channel-for-dummies-part-2-2ffef52220eb