以太坊的雷电网络原理:状态通道
状态通道是非常广泛和简单的方法,来在区块链上对其进行扩容,但是这是在区块链链下进行的,并没有显著增加区块链参与者的风险。这种方案最出名的案例就是比特币的支付通道,它可以让两者之间直接发送快速以及手续费很低的支付。
状态通道是支付通道的统称,可以把这个技术应用到任何状态更改的操作,大多数情况下是在区块链上进行。
将计算移动到链下,就不需要多余的信任,可以导致成本的降低和速度的极大提升。状态通道是区块链扩容技术的重要组成部分,可以支持更高级别的使用。
状态通道基本的组成部分有以下:1. 区块链的部分状态通过多个签名和部分智能合约锁定,所以这部分参与者必须要完全同意对方去更新它。2. 参与者通过产生以及签名转账来自己更新状态,这最终会上传到区块链上,而不是直接在链上进行计算。每个新的更新会刷新之前的更新。3. 最终,参与者将状态传回到区块链上,然后关闭状态通道,并且再次锁定状态(通常是按照和开始不同的设置)。
如果参与者之间更新的“状态”是数字货币余额,那么我们就会有支付通道。第一步和第三步,就会开启和关闭这个通道,包括区块链操作。但是第二步,无限的更新就会快速进行,而且不需要区块链的干预- 这就是状态通道的力量,因为只有第一步和第三步需要公开到网络上,支付手续费,或者等待确认。其实,有了精心的计划和设计,状态通道可以几乎保持无限开启,并且被用作中心和分支系统,来助力整个经济和生态系统。
尽管我们是很简单地描述,其实状态/支付通道是很复杂的。这里有几个原因,其中一个就是这三步背后有很复杂的分散步骤。让我们仔细来看看,这些都是什么,让我们从以下开始:
可以提交到区块链。
为了让状态通道工作,参与者必须要保证他们可以在任何时候公开通道目前的状态。这就会导致很多重要的限制,例如有人必须要在线去保护每个参与者,直到通道关闭。
想象下,当我们开启支付通道,我通过100个比特币开始,但是你是通过10个比特币开始。如果我们开始签名一个更新,转账10个比特币给我,然后又签名一个更新,转账50个比特币给你,那么之后的更新很明显是比早前的那个更有利益。如果你不幸地没有网络连接了,那么假设第二个更新永远不会发生,那么我就可以将第一个转账更新到区块链上,然后从你那边偷走50个比特币!你需要做的,就是有人在线,并且有之后转账的复制,从而他们可以“覆盖”前个转账,并且保证你的比特币是被保护的。不一定非要是你- 你可以这个备份传送给很多随机的服务器,它们都是通过智能合约同意地,并且只要需要,就可以公开转账(当然,需要很少的手续费)。但是无论你怎么做,你需要保证最近的签名更新是可以覆盖所有其他的。
这就到我们的第二个步骤:
每个新状态“覆盖”之前的更新
为了完成状态通道的这部分工作,锁定和解锁机制必须要能够合理地设计,从而提交到区块链的旧状态更新有机会被替代他们的更新状态所纠正。最简单的方法,就是让任何解锁都开启计时器,在这段时间里,任何更新的更新能替代旧的更新(同时也重新启动计时器)。当计时器完成的时候,通道就会关闭,并且状态就会反应收到的最后一个更新。计时器的长度会为每个状态通道特定选择,从而平衡一个长通道的关闭时间,同时也增强安全性,这会防止网络连接或者区块链问题。另外,你可以通过金融惩罚的方式来构建通道,从而任何向区块链公开不准确更新的人,通过假设之后的转账不会发生,让这些人失去更多。
但是这个机制并不是很重要,因为(回到之前所说的点)这个情况下的博弈论会让事情变得很糟糕。这个机制可能只是理论上听起来没问题,但是可能从不会使用。其实通过计时器/惩罚过程,也许会导致多余的费用,延迟或者其他不方便;如果让某些人进入到这个机制,并不能给你任何好处,状态通道的更方可能只是通过人工同意最终的状态通道,从而关闭通道。最终的关闭操作需要和正常的“中介”更新不同(因为它会绕过上面的“覆盖”机制),所以一旦在某个通道的部分状态锁定,参与者会只是签署最终的转账。
这些“细节”不是特别重要。它最终分解开,可以理解为,参与者通过设置一个“法官”智能合约来打开通道,互相签署协议,如有必要,裁判可以强制执行,然后通过在其中达成共识关闭通道,那么法官的判断就不需要。只要“法官”机制是可靠的,这些承诺就可以被认为是即时转账,法官只在特殊情况下上述,例如一方参与者消失。
当然,这些细节只是人们认为状态/支付通道复杂的愿意之一。更多地是,比特币支付通道是很复杂的。在比特币中建立“法官”机制是非常错综复杂的。但是一旦你对状态通道有清晰的理解,你可以看到这仅仅来自于在受限的上下文中实现这个想法。基础的智能合约机制,例如计时器机制以及根据上传的签名信息来选择两个不同的道路,这其实在比特币中更难做到。某些功能是逐渐添加和建立的。通过看到支付通道只是特殊的广泛“状态通道”概念的子案例,我们发现这是更快宽泛的技术,并且这个状态通道能够应用到任何智能合约中,它们和定义的参与者之间进行高频的更新。你可以预见,这种方式会在很多分布式应用中出现。