Counterfactual是一个典型的状态通道（state channel），由counterfactual实例化对象构成。
在L4中，我们已经研究了状态通道和其它的一些区块链扩展性方案。今天我们很高兴能够和大家分享我们工作中的一个基础部分，关于广义状态通道counterfactual的研究。
状态通道是可用分布式应用程序的基层技术，可用于一组特定的成员之间的任何互动，例如支付活动或者象棋和扑克之类的小游戏。将这些应用“通道化”可以大大降低其使用成本，而且可以减少目前使用区块链应用的等待时间，达到用户们期待的web服务响应时间。（每次用户想要进行链上操作的时候，他们都必须支付gas费用，而且他们必须等几个块开采后才能采取下一步行动。）
尽管如此，状态通道在今天的以太坊应用中并没有得到充分的利用。每一个想要使用状态通道的项目都必须要搭建自己的自定义实现框架，从而导致冗余和不必要的风险出现。其次，现存的状态通道实现还是会将很多操作放在链上，而且需要以不必要的方式放弃一些隐私性。
我们期待未来这项技术能够被更好的利用，我们曾经描述过关于状态通道的两大目标：
1. 设计一个可以保护隐私的广义状态通道，使用模块化组件搭建，支持单个通道内的多个并行操作，而且允许用户在不进行任何链上操作的情况下升级通道设计。
2. 提供一个框架和标准化组件，构建安全、性能良好的应用，让开发者能够更简单地使用状态通道。
我们的论文描述了一个状态通道设计方案，在保证安全的情况下尽可能的减少链上操作。我们相信它会成为构建安全、优化的状态通道的一个标准参考设计，这也是以太坊社区长久以来一直需要的。
我们将会参加柏林的Off the Chain活动，更深层次的讨论我们的技术技巧。我们不会进行ICO或者任何与token相关的募资活动。
在这篇文章中，我们总结了论文中描述的方法。如果你只对状态通道如何工作的概念描述感兴趣，请查看the state channels section of Josh Stark’s Layer 2 scaling article。阅读本文的需要读者掌握一些基础的技术知识。
状态通道术语
状态通道背后的基础技术好几年前已经为人所知。这期间，我们发现了新的词汇能够让我们抽象出现在所有状态通道中的特定的实现并讨论组件与技术。
状态通道通过将区块链状态的某些部分“锁入”多重签名合约来进行工作，该合约由一组固定的参与者控制。这种被“锁定”的状态被称为状态存入（state deposite）。举个例子，存入可能是一定数量的以太币或者是一个ERC20 token，但是也可以是一只加密猫或者一个ENS域名。
在状态存入被锁定后，通道参与者使用链下信息传递来进行交换和签署有效的以太坊交易，而不用将它们部署在链上。这些交易可以随时被放回到链上，但是它们并不在链上发生。
通道状态的更新需要获得一致同意（unanimous consent），所有的成员都要在每一笔链下交易上签字（并保留一份副本）。由于这些“状态更新”完全在链下发生，交易者无需支付任何交易费用，而且它们的速度仅受限于底层通信协议。
因此可以说状态通道能够提供“即时”交易，例如：参与者不需要等待任何来自区块链的确认。无需等待一系列链上确认，应用可以立即将操作认定为终止并且展示给用户。这就是状态通道可以提供web服务响应时间的原理。
我们将这种特质称为即时终结性（instant finality）。在共识研究中，“终止（fanality）”的意思是到达状态转换不会被还原的程度。在状态通道的例子中（Alice和Bob是密码学中经常会引用的一对学术情侣，关于解释状态通道的例子是这样的：想象一下，Alice 和Bob 想玩一个井字游戏，赢家可以获得1eth。摒弃在以太坊链上创建一个智能合约，每次操作支付gas费用而且需要等待时间的做法，我们可以设计一个系统，让Alice和Bob在尽可能少地进行链上操作的情况下来玩井字游戏。Alice和Bob将能在链下更新游戏的状态，同时仍然有充分的信心，如果有必要的话，他们可以恢复到以太坊主链的状态。我们把这种系统称为状态通道。），如果当Bob和Alice选择将交易放在链上而不能阻止Alice进行操作时，那操作就终止了。
如果状态通道中最新的状态“更新”说“Alice = 5ETH, Bob = 1 ETH”，那么这个状态就是终结性的。记住，这个更新是由Alice和Bob两个人共同签名的有效交易，他们两人的任何一方都可以随时将这笔交易放回到链上。只要我们可以假设Alice可以在某个时间向全网广播这笔交易，她就可以认为这笔交易终止了。
状态通道的核心特质是仅在必要时才返回链上。如果通道能够被合理构建，那么所有的参与方都可以进行更快的操作并且获得即时终结性。如果有任何地方出现了问题，所有的参与方都可以选择将最新版本的状态发布到链上。
状态通道以及所有的区块链技术都应该考虑其威胁模式的验证。（我们在论文的第3部分中详细查验了状态通道的威胁模式，在第7部分中检查了状态通道的局限性。）
最小化链上操作
目前存在的用于特定应用的状态通道实施需要用户为他们想要使用的每一个应用都打开一个新的通道，并且需要支付高昂的交易费用。举个例子，如果两个用户在链上进行了一笔交易开通了一条支付通道，他们需要再做一笔交易来玩象棋游戏。
我们的状态通道把对链上的需要减少到了极致，尽可能的将压力转移到非链层。这就引出了我们论文中最重要的一个见解：一个强大的多重签名钱包是个人状态通道所需要的唯一链上组件。
将操作逻辑转移到链下使我们能够获得现在的通道所不具有的优势。我们可以直接在链下向状态通道安装新的应用。我们甚至可以不通过链上交易，并支付费用而直接升级或者重新设计一个状态通道。
这种方法对于保护隐私也有很好的作用。通过合适的构造，用于保护状态存入的多重签名钱包就会和其它的多重签名钱包一样。没有任何方式可以分辨普通的多重签名钱包和创建状态通道的钱包。
counterfactual术语
我们可以使用 “counterfactual实例化”来实现这些结果。解释这项技术需要首先定义术语。
“counterfactual”意思是某件可以是真实的事情却不是真实的。当讨论状态通道时，这是一个非常有帮助的概念。我们在状态通道上花大量的时间推理可以发生在链上的事情，但是他们却不是发生在链上。
在状态通道中，我们用“counterfactual X”来描述这样一个案例：
1. X可以发生在链上，但是却不是
2. 任何参与者都可以单方面地使X发生在链上
3. 参与者可以因此认为X发生在链上
举个例子，想像Alice和Bob之间有一个支付通道。Alice使用通道向Bob发送了4ETH，实际上就是双方对交易进行了签名。这笔交易可以由他们两人中的任一人随时部署在链上，但是它并没有在链上发生。因此我们可以说“Alice 反事实地‘counterfactually’给了Bob 4个ETH”。这样他们就可以认为交易已经发生了，而且在适用的威胁模式内，交易是最终有效的。
Counterfactual实例化
在上面的部分中，我们说我们的方法可以让你任何链上操作或费用直接向状态通道内安装新的应用。你可能会想这怎么可能呢？
实现它的关键就是我们所说的counterfactual实例化（counterfactual instantiation）。在上面的部分中，我们描述了Alice和Bob 之间的counterfactual/链下交易。但是我们也可以通过创建一个counterfactual合约的形式来实现。
counterfactual实例化的意思是在不部署在链上的情况下将合约实例化。当一份合约被counterfactual实例化后，通道中所有的参与者都会当作它已经被部署在链上了，即使它其实并没有在链上。这种技术几乎可以让我们将所有的通道逻辑全部转移到链下。
counterfactual实例化是通过让用户签名并共享对多重签名钱包的承诺来实现的。这些承诺是如果counterfactual实例化合约在链上实现了实例化，多重签名钱包（持有状态存入的钱包）将会查看实例化合约并按照合约状态转移约定的状态存入。
为了实现这一点，我们需要在合约部署之前，在承诺中引用counterfactual实例化合约。而为了做到这一点，我们引入一个全局注册表：一个链上合约，可以将任意counterfactual合约的唯一确定地址映射到真实的链上部署地址。（在未来，一旦可以实现抽象账户，我们就可以做到这一点，这是由于合约地址可以根据字节和构造函数参数计算得出。）用于产生确定性地址的散列函数可以是包含账户字节，持有者（例如多重签字钱包地址）和唯一标识符的任意函数。
举个例子，我们有一份合约‘C’拥有‘initcode’字节和构造函数参数。运行函数调用‘initcode’参数注册表的结果是向注册表中添加一个条目；它的密匙是counterfactual地址，它的值是真正的链上地址。
这给了我们一种无需部署在链上就可以引用链下合约的方式。我们只需要在注册表中进行查找，看看哪个地址对应cunterfactual地址。在Solidity语言中，就像下面一样简单：
Registry(registryAddress).resolve(counterfactualAddress)
面向对象的通道设计
我们的通道设计让开发人员采用一种面向对象的方法来实现状态通道。任何个人状态通道都会由几个counterfactual对象构成，例如：支付通道对象，或者象棋游戏通道对象。因为这些是counterfactual实例化的，通道中不存在任何费用，只有参与者之间签字的承诺。
举个例子，Alice和Bob可以随时选择在他们的通道中counterfactual实例化一份合约，假设是一份定义了象棋游戏的合约。为了能够真正的玩游戏，他们可以参照实例化的游戏彼此交换状态更新，并且不需要支付链上费用。
我们认为这个面向对象的方法提供了很多显著的好处：
应用开发人员可以针对一个定义良好的API进行编程，插入到每一个通道所需的核心组件中。
我们可以确保，只要核心组件经过大量审计并且保持安全，应用程序开发人员代码中的bug就可以被隔离到只有代码控制的状态区域。
应用程序开发人员可以通过counterfactual寻址重新使用现有组件，就像再次使用以太坊合约一样，例如：通过可证公平随机性源。
用户可以在纠纷中保留隐私，只需要把有争议的对象放在链上。
我们可以获取更多正常操作中信息传递的选择曲线上的点，以及在产生争执的情况下需要发布的交易，在某些情况下，我们可以跨通道分期处理陈旧的状态。
结论
如果你想要了解更多关于广义状态通道和counterfactual技术的知识，我们推荐你阅读一下论文原文。论文中还有我们在这篇文章中没有总结的重要内容，包括：
与其他技术，如：侧链和Plasma的比较
对状态通道现有设计的回顾
相关威胁模式的深度验证
Meta-channels
广义状态通道的一个构建示例
更多更新，请关注我们的twitter账号@statechannels 和网站。
最后，我们想要感谢以太坊基金会对这项工作的支持。我们很高兴能够成为社区的一部分推动以太坊网络规模化，这也为Web 3奠定了基础。我们也要感谢以下人员在论文早期起稿时给予的讨论与反馈：Vitalik Buterin, Erik Bryn, Tom Close, Josh Stark, Nima Vaziri, Armani Ferrante, Lisa Eckey, Kristina Hostakova, Yoichi Hirai, Sylvain Laurent。
作者简介 Liam Horne 状态通道开发人员
零识仅为翻译中文供大家学习使用，本文原英文内容版权归原作者所有。