他是 IC3 成员，Idorse.io 参谋，为 RSK 做过两次安详审计。

为相识锁这个应用，任一玩家都可以提交游戏的所有状态到 battleship.unlock() 中。这将会查抄整个游戏状态的所有哈希，通过哈希函数匹配并验证状态通道中存储的状态，之后举办状态的存储可能解锁合约。此时这个游戏就可以在区块链上继承玩了。

一组人必需抵押钱到区块链上，并同意参加运行一个链下的应用。各方配合在当地授权当地应用措施的新状态。假如有一方不相助，那么应用的当前状态会被存储到区块链上，而且这个状态的执行将会由区块链完成。

本质上，这个问题表示为争议进程中支持应用的再次陈设、配置全部状态和在区块链上继承执行的经济本钱问题。

一个玩家通过挪用 SC.triggerdispute() 触发争议；

我们发明最大的痛点是这种环境：状态通道封锁后两边玩家都必需到区块链上完成应用的执行。对付战舰游戏，完成一场战舰游戏每一个玩家约莫需要举办 200 多次操纵，约莫需要耗费 $16.27-$24.05 。更糟糕的是，由于区块链上生意业务确认需要时间，这个进程需要的时间多达数个小时（即，每一次操纵需要 5 分钟，200 次操纵约莫 16 个小时）。经济支出和时间本钱导致进攻者（好比一个自动化的呆板人）可以或许等闲地让一小我私家类玩家放弃这个游戏。

首先加密钱币是无法扩展的。

在本年的 IC3-ETH 集训上，我（Patrick McCorry）和 Surya Bakshi 提出在状态通道内里做一个战舰游戏的想法。

同时 Patrick McCorry 在行业内多场国际大会上颁发演讲，包罗 Devcon 3、Financial Cryptography 等等。

链下办理方案——各个参加方各自之间处理惩罚一个应用（可能一系列的付出），区块链仅作为一个法院的脚色，来办理大概呈现的争议，并担保资金的安详性和应用的活性（Liveness，也就是担保应用可以或许执行）。如此只有一小部门的生意业务需要提交到区块链中，可以或许淘汰区块链的承担。

我们（Patrick 和同事）从社区中（以太坊基金会和以太坊社区基金）得到扶助来支持我们对状态通道的研究和实践。承袭这个资金以及开源社区的精力，我们在尝试举办进程中始终保持开源，，而且尽大概在我们得到成就时随时更新进度。为了实现这种果真透明，我们抉择果真论文的 GitHub Repository。

对付游戏中每一步，一位玩家提出一个指令（好比，对 A，0 这个位置开火），之后两边对新的状态授权（譬喻，这位玩家击中了这个位置）。每一个新的状态都陪伴着计数器数字的增加，带有最大计数的状态将会被状态通道合约认为是「最新状态」。

社区中提出了多种实现「扩展」的方法。

Patrick McCorry 是伦敦国王学院助理传授，英国第一位结业的加密钱币规模 Ph.D.。他的研究主要在加密钱币、漫衍式系统和加密协议，由以太坊基金会和以太坊社区基金和 Research Institute 提供资金支持。

在本次研究中，我们着眼于状态通道的实证评估。

一方可能两边通过 SC.setstatehash() 提交状态的哈希 + 计数；

今朝，状态通道对付面向一小组人，每组人只需要往返几轮的应用，以及各方会在应用中反复执行的环境下是有用的。这个偏向的应用包罗付出、集会会议投票、拍卖和赌场游戏。

关于这个研究原本是一篇论文，链接如下：https://nms.kcl.ac.uk/patrick.mccorry/battleship.pdf。

新的区块链协议——如 DAG，Hashgraph，Avalance 等这些可以或许被用于提高整个网络吞吐量的技能。可是正如我们之前指出的，这个会淘汰整个网络中验证者的数量。

在「争议期」之后，任一玩家挪用 SC.resolve()，之后状态通道合约就会将计数最大的状态哈希做为最终状态。

在抱负的环境下，在两位玩家之间可以或许执行多次战舰游戏。状态通道可以或许提供即时确定性（即，只要两边都互换了签名就确定这个状态），而且可以或许制止发生手续费。

难以执行。我们的尝试强调了在状态通道中办理争议的痛点在于完成应用的执行。除非配置鼓励来防备有一方封锁通道（这个今朝还没办理），不然状态通道大概对付那些难以在区块链上直接执行的应用是不符合的。

合约强制执行一个「争议期」，这段时间里两边玩家都可以或许提交最新的「状态哈希」+ 计数；

状态通道是最早由 Lighting Network 在 2015 年提出的链下扩容技能，成长至今，呈现了如 Celer Network、FunFair、Perun、Lighting Network 、Counterfactual 等数十个项目，得到了大量的成本和市场的承认。

状态通道就是一个兔子。它很快（即两边假如相助，那么战舰游戏就是免费的而且有即时确定性）并且很机动（可以在任何时间建设和取消应用）。可是兔子也很懦弱，任一方由于任何原因分开城市让通道瓦解。

在集训之后我们继承在 GitHub 上完善这项事情。我们提出了「陈设状态通道的合约，获得游戏最终状态并从头激活应用」这样的一个简朴的状态通道生命周期。

领略如何应用鼓励机制来担保这个「兔子」不瓦解，将会是研究状态通道团队的将来任务。就像是 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.）

在这里，我们首先对状态通道作出以下界说：

6 月底在德国柏林举行的 Master workshop: off the chain 勾当上，我们发明每小我私家对状态通道的界说是纷歧样的。（https://binarydistrict.com/workshop/master-workshop-off-the-chain/ ）

本质上来说，状态通道只能是一种「乐观的扩展方案」， 因为它的前提是相信参加方会厚道共同，而这个假设自己很重要。

不外用 Patrick 本人的话来说，「too long don't read」（哈哈 Patrick 也是很为各人着想的），所以在 GitHub Repo 的 readme 和 Medium 上有了两篇文章先容相关的研究事情，我们把文章翻译过来供各人阅读，假如对这个战舰游戏感乐趣，可以看看代码库：https://github.com/stonecoldpat/statechannels

本文是 Patrick McCorry 以及同事关于状态通道的一项研究，别的我们还从他的另一篇文章节选了一部门内容做了整合，形成如下文章，内容很是好的归纳综合了状态通道的技能逻辑、近况、面临的一些通用问题以及状态通道的范围性。

在最差的环境下，两位玩家大概都同意玩这个游戏，但之后有一方封锁了这个通道。（由于区块链上不知道谁是退出者）这时两个玩家都需要将游戏的 200 多个操纵提交到链上处理惩罚，这会带来（而且没有告竣一致）庞大的经济支出（究竟每一笔链上生意业务都需要耗费生意业务费）。

假如一方不相助（好比 Bob 即将要把 Alice 打败了，Alice 这时候拒绝对她输了角逐的最新状态举办签名），这时候另一方（即 Bob）必需触发争议处理惩罚措施。这样做会封锁状态通道，接下来两位玩家会在区块链上办理这个游戏，进程如下：

在这个研究中我们着眼于状态通道方案。

龟兔协议

FunFair 两难逆境

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。