概要：这是一篇介绍以太坊最新技术的文章，以太坊采用这项技术后将极大提升用户体验，提高系统性能。
在L4，我们一直在进行状态通道和区块链可扩展性的研究。现在，我们很兴奋地和大家分享我们在基础研究上取得的一项成果---反事实（Counterfactual）：广义状态通道（Generalized State Channels）。
状态通道是分布式应用的一项基础技术。任何一个系统中的多个参与者进行交互（比如支付，游戏等）时都可以用到这项技术。这项技术能让分布式应用“通道化”，会极大缩减成本，还能缓解系统的延迟。它能让区块链应用达到互联网应用的响应速度（注：目前区块链应用对用户响应的速度非常慢，和互联网应用相比，完全不在一个等级）。
尽管有这么多好处，但状态通道目前在以太坊上的应用还相当落后。主要表现在两方面。一.部署在以太坊上的应用如果想使用状态通道还必须自己开发。这不仅重复了大量工作而且会引入额外的风险。二.以太坊现有的状态通道技术把过多的操作放在了主链上，并损害了隐私性。
我们希望改进这个现状，并很早就讨论过两个目标：
一. 设计一个模块化的广义状态通道。它能保护隐私，支持在一个通道内并行处理多个任务并允许用户在主链下完成通道的升级。
二. 提供一个框架和一系列标准模块，让用户方便地使用状态通道构建安全，高性能的应用。
我们曾经写过一篇论文（注：该论文地址为：https://www.counterfactual.com/statechannels/），专门描述过一种状态通道的设计。我们主张在保证安全性的前提下，让链上行为越少越好。我们认为这会成为状态通道设计的一种标准做法，既保证安全性，也能使设计尽量优化。这也符合以太坊社区的需要。
在德国柏林即将举行的“Off the Chain”大会上，我们会深入讨论我们的技术细节。不过，我们不会搞ICO也不会进行任何代币融资。
本篇我们会总结一下我们在那篇论文中提到的方法。如果您对状态通道的工作原理感兴趣，可以参看Josh Stark关于的Layer 2扩展的文章。我们假定本文的读者对一些基本技术有一定的了解。
状态通道的术语
状态通道的基础技术已经问世好几年了。这些年，一直都有新的术语出现，不断地从具体的实现细节中抽象出来。
状态通道在工作时会在智能合约中锁定区块链的部分状态。这些智能合约通常是多重签名的智能合约。被锁定的状态被称为“状态存储”（“state deposit”）。它可以是以太币，ERC20代币，甚至是加密猫（CryptoKitty）或ENS域名。
当状态被锁定后，状态通道的参与者就可以把一些本来要在链上进行的交易和签名活动放在链下，用链下通信机制进行处理。
当全体参与者都一致同意后，大家可以对状态通道的状态进行更新。所有的参与者都各自保留一份自己的交易记录，并对每一笔链下交易进行签名。由于这些交易都在链下发生，因此没有任何交易费用产生，并且交易的速度仅仅受限于它们所使用的通信协议。
因此，状态通道能提供“即时”交易----交易方无需等待区块链的确认，就能直接确认交易并显示结果。这使得状态通道的响应时间能快到和互联网应用一样。
我们把这称为“瞬时确认”（“Instant Finality”）。在共识机制中，“确认”意味着状态转变无法逆转。在状态通道中，“确认”意味着某个操作得到了大家的公认。
举例来说，如果最新的状态显示爱丽丝有5个以太币，鲍勃有1个以太币。那这个状态就是“确认”的。注意，这个状态一定是爱丽丝和鲍勃同时签了名的，它可以随时被任何人发布到以太坊上。换句话说，在任何时候爱丽丝都可以把这个状态发布到以太坊，因此在她看来，这个状态就是“确认”的。
状态通道的核心价值在于仅当必要时，状态才需要被提交回区块链。当一个通道被适宜地建立起来后，通道中所有的参与方就都能进行“瞬时确认”的交易。如果有任何意外发生，所有的参与方总能把最新的状态提交回区块链。（注：这里的意思是，一旦状态通道中的交易发生意外，最新的状态会被提交回区块链作最终裁决）
这里请注意，所有的状态通道和所有的区块链技术都必须在特定的威胁模型（threat model）下讨论。我们在论文的第三节讨论了威胁模型，在论文的第七节讨论了状态通道的局限性。
尽量减少链上操作
现有状态通道的实现方式要求用户对每一个新的应用都建立一个新的通道，并为此支付昂贵的费用。比如，两个用户为了进行一笔链上交易已经开通了一个支付通道。现在他们为了玩游戏又得再开通一个通道。
我们的状态通道技术为了极尽所能地减少链上操作，将尽可能多的业务逻辑放到链下。这引出了我们论文的一个重要发现：任何一个状态通道仅仅只需要一个足够强大的链上多重签名钱包就可以了。
将业务逻辑尽量移到链下，用这种方式建立的状态通道会大大优于现有的状态通道技术。我们可以就在状态通道上安装应用程序，而无需再在区块链上安装。我们不必进行任何链上交易，也无需任何额外花费就可以升级或重新设计状态通道。
这个方式也极大提高了隐私性。只要设计合理，用于存储状态的多重签名钱包将和普通的多重签名钱包看起来毫无区别，不会被看出哪个钱包是普通的钱包，哪个钱包是用于状态通道的钱包。
术语：反事实
我们发明了一个新的术语“反事实实例化”。用这个术语可以推导出我们刚才所描述的那些结果。我们先来看看这个术语的定义。
“反事实”的意思是一件事可以是真实发生的，但又没有真实发生。这个概念在我们的状态通道技术中极其重要。我们花了大量事件反复推敲它的意义。
当我们说“反事实 X”时，我们的意思是X是可以在区块链上发生的，但实际上没有在区块链上发生。
X所涉及的交易方中任何一方都可以把X提交到区块链上进行处理。因此，所有的交易方实际上都可以认为X已经是在区块链上得到确认发生了。
举例来说，爱丽丝和鲍勃之间有一个支付通道。爱丽丝通过这个通道给鲍勃发送了4个以太币。这笔交易经过双方的共同签名，并且可以在任何时候由爱丽丝或鲍勃提交到以太坊，但实际上双方都没有真的提交到以太坊。这就是一个“反事实”，我们说“爱丽丝反事实地给了鲍勃4个以太币”。基于这个“反事实”，爱丽丝和鲍勃可以继续进行后续的交易，都假定认为这件事已经发生了。当然这要在特定的威胁模型下才成立。
反事实实例化
上面我们提到用户可以在状态通道中安装应用程序，而无需在区块链上安装，也无需支付任何费用。这是怎么实现的呢？
关键就在“反事实实例化”。我们刚才举了爱丽丝和鲍勃之间的反事实交易。我们也能创建反事实合约。反事实实例化就是实例化一个智能合约，但不在区块链上真正部署它。当一个合约被反事实实例化以后，状态通道中所有的交易方都会认为这个合约已经真的被部署在区块链上了，尽管实际上它并没有。这就使得我们可以将所有的业务逻辑全部移到链下。
反事实实例化要求所有交易方都许下承诺，并对承诺进行签名，将承诺提交到多重签名的钱包中。这个承诺要表明如果反事实合约部署到区块链上，那存储状态的多重签名钱包就要检查该合约，并将存储在钱包中的状态根据合约的要求发送到接收方。
这份承诺必须在代码中引用这个反事实实例化合约，然后才能被部署。为此，我们引入一个全局注册表：它也是一个链上合约。它将所有反事实合约的唯一确定性地址与其对应的链上部署地址一一对应。反事实合约的唯一确定性地址由哈希函数产生。这个哈希函数必须考虑字节码，所有者（多重签名钱包的地址）和一个唯一标识符。
举例来说，智能合约“C”，包含字节码和构造函数参数“initcode”。当用“initcode”参数调用函数操作这个全局注册表时，会给注册表增添一条记录。这条记录的键值（Key）是反事实合约的地址，这条记录的值（Value）是合约实际部署在区块链上的地址。
这种方式使我们可以引用链下合约，而无需在链上部署它。我们可以在全局注册表中通过一个反事实合约的地址查找到它所对应的区块链上的部署地址。在Solidity中，它的表述方式如下：
Registry(registryAddress).resolve(counterfactualAddress)
面向对象的通道设计
我们的通道技术让开发者可以用面向对象的方法设计状态通道。任何一个状态通道都可以由若干个反事实对象组成，比如支付通道对象，棋牌游戏通道对象等。由于这些对象都是反事实的实例化，因此它们无需任何费用，只需要所有参与方都共同签名承诺即可。
举例来说，爱丽丝和鲍勃可以在任何时候在一个状态通道内反事实实例化一个智能合约，比如一个游戏合约。他们在玩这个合约游戏的过程中，会不断更新游戏的状态，但整个游戏过程无需任何链上费用（因为整个游戏都在链下的状态通道中进行）。
我们确信这种面向对象的设计方法有诸多好处，比如：
应用开发者可以基于一个定义好的API编写应用程序，向状态通道中插入核心模块。
如果核心模块经过严格地审查，安全性有保障，那么即便应用程序出现问题，这些问题也能被限制在应用程序可控制的状态范围内。
应用开发者可以在反事实地址上重用已有的模块，就和他们调用以太坊上部署的合约一样。比如调用一个被证明是可靠的随机数据源。
当发生异议时，用户只需要把有异议的部分提交到区块链上，而把涉及到隐私的部分仍然保留在链下。
我们可以在正常的信息通信和有争议的交易之间取得更多平衡。在某些情况下，我们可以在通道中对一些旧的状态作分期响应。
结论
如果您对广义状态通道及反事实技术感兴趣，希望了解更多内容，我们鼓励您直接阅读我们的论文。在论文中我们还详细讨论了下面这些细节：
- 状态通道和侧链以及Plasma的对比
- 状态通道技术的现状
- 威胁模型的深度解析
- 元通道（Meta-channels）
- 广义状态通道的一个构造实例。
如果希望了解我们的最新进展请关注推特 @statechannels 以及我们的官网。
最后，衷心感谢以太坊基金会，感谢他们一直以来对这项重要工作的大力支持。我们为能成为这个天才社区的一员而感到兴奋。这个社区正极力扩展以太坊的性能，为Web 3的基础工作贡献力量。我们也感谢Vitalik Buterin, Erik Bryn, Tom Close, Josh Stark, Nima Vaziri, Armani Ferrante, Lisa Eckey, Kristina Hostakova, Yoichi Hirai以及Sylvain Laurent，感谢他们参与我们论文的讨论并给出了宝贵的意见。
注 2：未来，当账户抽象技术成功部署后，我们能更细致地推进我们的工作，因为届时，合约地址将能基于字节码和构造函数的参数计算出来。
参考链接：https://medium.com/statechannels/counterfactual-generalized-state-channels-on-ethereum-d38a36d25fc6
网友评论