状态通道是最早由 Lighting Network 在 2015 年提出的链下扩容技术，发展至今，出现了如 Celer Network、FunFair、Perun、Lighting Network 、Counterfactual 等数十个项目，获得了大量的资本和市场的认可。
本文是 Patrick McCorry 以及同事关于状态通道的一项研究，另外我们还从他的另一篇文章节选了一部分内容做了整合，形成如下文章，内容非常好的概括了状态通道的技术逻辑、现状、面对的一些通用问题以及状态通道的局限性。
关于这个研究原本是一篇论文，链接如下：https://nms.kcl.ac.uk/patrick.mccorry/battleship.pdf
不过用 Patrick 本人的话来说，「too long don’t read」（哈哈 Patrick 也是很为大家着想的），所以在 GitHub Repo 的 readme 和 Medium 上有了两篇文章介绍相关的研究工作，我们把文章翻译过来供大家阅读，如果对这个战舰游戏感兴趣，可以看看代码库：GitHub - stonecoldpat/statechannels: An experimental implementation of state channels from IC3-ETH. Combines Sprites/Pisa/Perun/L4 dispute process.
原文作者：Patrick McCorry
翻译/整理：Ryan
这是一个评估状态通道作为加密货币扩展性方案的实验，下面是我们（Patrick McCorry 和他的同事）的一些工作摘要。
问题是什么？
首先加密货币是无法扩展的。
这个扩展性问题的核心是，在「交易吞吐量」和「验证者的去中心化」之间有一个权衡。
如果能够提升区块链中交易的吞吐量，那么很可能使用这个网络的交易手续费会降低。毕竟当使用区块链的手续费变得合理并且能够接受，会有很多用户使用区块链。
然而问题来了，简单地提高一个网络的吞吐量将会直接减少整个网络中验证者的数量。大部分家用电脑（的处理能力）并不能支持每秒 5000 笔交易的验证，对于他们来说，甚至仅仅下载交易都是一件困难的事情（更别说还要验证了）。这样我们会失去一个让公有链与众不同的属性——网络维护者（也就是验证者）的去中心化。
不同的扩展方式？
社区中提出了多种实现「扩展」的方式。
新的区块链协议 ——如 DAG，Hashgraph，Avalance 等这些能够被用于提高整个网络吞吐量的技术。但是正如我们之前指出的，这个会减少整个网络中验证者的数量。
分片（Sharding） ——创建专用于特定交易的「处理区域」。比如一个分片用来处理预定酒店的交易，一个用来处理预定火车票的交易。这样能够将验证任务分发出来，验证者只要验证他们关心的交易。但是如果验证者需要关注其他几个分片，那么这个问题就仍然不能解决。
链下解决方案 ——各个参与方各自之间处理一个应用（或者一系列的支付），区块链仅作为一个法院的角色，来解决可能出现的争议，并保证资金的安全性和应用的活性（Liveness，也就是保证应用能够执行）。如此只有一小部分的交易需要提交到区块链中，能够减少区块链的负担。
目前链下解决方案有两种，包括 侧链 （即 Plasma）和 状态通道 。两个方案最本质的差别在于，在侧链中用户和侧链的维护者不是同一批人，而在状态通道中用户就是通道的维护者。
在这个研究中我们着眼于状态通道方案。
什么是「状态」通道？
在 Berlin 举行的 workshop 中我们发现每一个人对状态通道的定义是不一样的。（ https://binarydistrict.com/workshop/master-workshop-off-the-chain/ ）
在这里，我们对状态通道提出了以下的定义：
一组人必须抵押钱到区块链上，并同意参与运行一个链下的应用。各方共同在本地授权本地应用程序的新状态。如果有一方不合作，那么应用的当前状态会被存储到区块链上，并且这个状态的执行将会由区块链完成。
以上，区块链只被用来「解决争议」。它保证各参与方资产的安全，而且能够保证应用执行的活性（Liveness），因为应用的执行在链上完成。
在今年的 IC3-ETH 集训上，我（Patrick McCorry）和 Surya Bakshi 提出在状态通道里面做一个战舰游戏的想法。
在集训之后我们继续在 Github 上完善这项工作。我们提出了「部署状态通道的合约，得到游戏最终状态并重新激活应用」这样的一个简单的状态通道生命周期。
具体细节可以在论文中查看，但是在这篇文章中更有意思的是一些实证研究观察到的东西。
状态通道能做到多好？
在本次研究中，我们着眼于 状态通道的实证评估 。
我们通过区块链建立了一个能够让两位玩家进行战舰游戏的智能合约。一般来说，一场战舰游戏可能需要 200 次交易（这是最坏的情况，每个玩家打中了对方战舰甲板的每个组件，也就是没有集中火力）。
我们在代码库中展示了一个战舰游戏在状态通道中运行所需要做的最小的改动。所有玩家都同意将应用合约通过 battleship.lock() 锁定，之后游戏就不在链上运行，它实例化为一个「状态通道合约」。玩家双方能够在链下互相执行战舰游戏的操作。
对于游戏中每一步，一位玩家提出一个指令（比如，对 A，0 这个位置开火），之后双方对新的状态授权（例如，这位玩家击中了这个位置）。每一个新的状态都伴随着计数器数字的增加，带有最大计数的状态将会被状态通道合约认为是「最新状态」。
如果一方不合作（比如 Bob 即将要把 Alice 打败了，Alice 这时候拒绝对她输了比赛的最新状态进行签名），这时候另一方（即 Bob）必须触发争议处理程序。这样做会关闭状态通道，接下来两位玩家会在区块链上解决这个游戏，过程如下：
一个玩家通过调用 SC.triggerdispute() 触发争议；
合约强制执行一个「争议期」，这段时间里双方玩家都能够提交最新的「状态哈希」+ 计数；
一方或者双方通过 SC.setstatehash() 提交状态的哈希 + 计数；
在「争议期」之后，任一玩家调用 SC.resolve()，之后状态通道合约就会将计数最大的状态哈希做为最终状态。
为了解锁这个应用，任一玩家都可以提交游戏的所有状态到 battleship.unlock() 中。这将会检查整个游戏状态的所有哈希，通过哈希函数匹配并验证状态通道中存储的状态，之后进行状态的存储或者解锁合约。此时这个游戏可以在区块链上继续玩了。
从中我们能学到什么？
在理想的情况下，在两位玩家之间能够执行多次战舰游戏。状态通道能够提供即时确定性（即，只要双方都交换了签名就确定这个状态），并且能够避免产生手续费。
在最差的情况下，两位玩家可能都同意玩这个游戏，但是之后有一方关闭了这个通道。（由于区块链是不知道谁是退出者）这时两个玩家都需要将游戏的 200 多个操作提交到链上处理，这会带来（并且没有达成一致）巨大的经济支出（毕竟每一笔链上交易都需要花费交易费）。
本质上来说，状态通道只能是一种「乐观的扩展方案」， 因为它的前提是相信参与方会诚实配合，而这个假设本身很重要。
其他的如 FunFair 两难困境（也就是争议过程产生的成本为游戏增加了额外的、可能致命的加密经济因素，这个后面会提到）。
最后指出，社区设置一些机器人，让机器人互相竞争会非常好玩。
实证评估观察和未来工作
FunFair 两难困境
在 workshop 中，FunFair 和 Counterfactual 针对下面两个问题展开了讨论：
应该让状态通道在链下创建和消除应用，还是应该让状态通道要求这个应用已经存在于区块链上？
本质上，这个问题表现为争议过程中支持应用的再次部署、设置全部状态和在区块链上继续执行的经济成本问题。
我们所做的这个实验强调这个过程中的经济支出大约需要 $10.87 来部署战舰游戏的合约，以及 $1.56 来完成整个争议过程（即，存储所有的游戏状态并且重新激活合约）。虽然使用以太坊中的特殊的 opcodes 可以降低部署战舰游戏合约的成本，但这并不是在为状态通道设计应用的时候需要考虑的最关键的标准。
我们发现最大的痛点是这种情况：状态通道关闭后双方玩家都必须到区块链上完成应用的执行。对于战舰游戏，完成一场战舰游戏每一个玩家大约需要进行 200 多次操作，大约需要花费 $16.27-$24.05 。更糟糕的是，由于区块链上交易确认需要时间，这个过程需要的时间多达数个小时（即，每一次操作需要 5 分钟，200 次操作大约 16 个小时）。经济支出和时间成本导致攻击者（比如一个自动化的机器人）能够轻易地让一个人类玩家放弃这个游戏。
龟兔协议
上述的痛点强调了在状态通道中部署应用非常像一个龟兔协议。
状态通道就是一个兔子。它很快（即双方如果合作，那么战舰游戏就是免费的并且有即时确定性）而且很灵活（可以在任何时间创建和撤销应用）。但是兔子也很脆弱，任一方由于任何原因离开都会让通道崩溃。
区块链就像乌龟。它很慢（在上面玩战舰游戏的话需要几个小时）而且贵（玩这个游戏需要十几美金）。但是它非常可靠，并且能够保证各方只要够耐心、愿意承担这个支出，就能完成这个应用。
理解如何应用激励机制来保证这个「兔子」不崩溃，将会是研究状态通道团队的未来任务。就像是 Gas Token（gastoken.io) 证明的那样，激励这个事情特别复杂棘手，非常难做好。在 2017 年的 Financial Cryptography 上 Silvio Micali 总结的非常好，他说：「设计激励机制就好像狮子在追逐狗，狗在追猫，猫在追老鼠。」（Designing incentives is like a lion chasing a dog, a dog chasing a cat and a cat chasing a mouse.）
可使用的应用
我们发现了在状态通道中运行应用的两个限制（对操作的） 达成共识 非常难。状态通道要求各方在应用运行的整个过程都保持在线。如果有一方退出了，那么这个通道就崩溃了。这意味着状态通道仅仅适用于一小群人，这样才能降低只要一有人退出通道就崩溃的风险。
难以执行。 我们的实验强调了在状态通道中解决争议的痛点在于完成应用的执行。除非设置激励来防止有一方关闭通道（这个目前还没解决），否则状态通道可能对于那些难以在区块链上直接执行的应用是不合适的。
目前，状态通道对于面向一小组人，每组人只需要来回几轮的应用，以及各方会在应用中重复执行的情况下是有用的。这个方向的应用包括支付、会议投票、拍卖和赌场游戏。
开源精神
我们（Patrick 和同事）从社区中（以太坊基金会和以太坊社区基金）获得资助来支持我们对状态通道的研究和实践。秉承这个资金以及开源社区的精神，我们在实验进行过程中保持了开源，并且尽可能在我们获得成果时随时更新进度。为了实现这种公开透明，我们决定公开论文的 GitHub Repository。
希望通过将这个实验和论文开源，能够为新的博士学生和更广阔的社区提供一些参考。
毕竟，论文是为了让讨论的议题更充分地被讨论，而不是为了正确与否。
关于Patrick McCorry
Patrick McCorry 是伦敦国王学院助理教授，英国第一位加密货币领域 Ph.D.。他的研究主要在加密货币、分布式系统和加密协议，由 Ethereum Foundation、Ethereum Community Fund 和 Research Institute 提供资金支持。
他是 IC3 成员，Idorse.io 顾问，为 RSK 做过两次安全审计。
同时 Patrick McCorry 在行业内多场国际大会上发表演讲，包括 Devcon 3、Financial Cryptography 等等。
本周日（12 月 16 日下午）Patrick McCorry 将会来到杭州，进行一次题为「Scaling Cryptocurrencies via State Channels」的主题分享，如果你对 Patrick McCorry 的研究方向有一定的兴趣和了解，欢迎 点此链接 报名。
