-由反事实实例化（Counterfactually Instantiated）对象组成的典型状态通道-
我们已经进行了一些关于状态通道和区块链扩展性的研究，并在 L4 上展示。今天很高兴再次分享我们的基础工作之一： 《Counterfactual：广义的以太坊状态通道》（PDF）
状态通道，可用分布式应用的基础技术。状态通道可以用在特定参与者们的任何交互上，比如支付，或是西洋棋、扑克等游戏。将这些应用“通道化”能大幅降低成本，缓解目前区块链应用让人难以接受的网络延迟，并提供使用者期待的如网页一般快速的响应时间。即便好处这么多，时至今日，以太坊应用还未充分使用状态通道。原因包括：每个想要使用状态通道的项目，必须建立自定义的部署，这会导致系统冗余和不必要的风险。其次，现有的状态通道的实施，仍然 在链上进行过多的操作，且在许多不必要的方面过多地考虑隐私。
我们构想了更好的未来。在早些时候，我们提出了两点大方向：
设计一种广义的状态通道部署方法，它能保证隐私性，由模块化组件构成，单通道内支持多个平行任务，并且允许用户在不进行链上交互的情况升级通道。
提供状态通道框架和标准化模块组件，方便 开发者使用状态通道构建更安全、更高性能的应用。
我们的论文（PDF）阐述了一种状态通道——在尽可能减少与链上交互的情况下，保证其安全性。我们相信在建立更安全、更好的状态通道时，这会成为有力的参考；这也是以太坊基金会接下来会长期需要的。
我们将在柏林参加 Off the Chain 大会，届时会深入讨论我们的技术。当然，我们不会进行任何 ICO 或是和代币相关的融资活动。
在这篇博文，我们总结了论文中阐述的方法。如果你有兴趣了解更多关于状态通道工作的概念描述，可以查看以下链接：Josh Stark 写 Layer 2 扩展方案的文章中关于状态通道的部分（编者注：中译本见文末《弄清第二层扩展方案》） ；本文默认各位读者对基础技术已经有一定的认识。
状态通道背后的基础技术，其实几年前就已经被众人所熟知。从那时开始，我们陆续发明了一些新词汇描述特定的部署、讨论相关组件，及说明其他在状态通道被用到的技术。状态通道将部分区块链上的状态“锁定”在多重签名智能合约中，由指定参与者控制。这些被“锁定”的状态又称作状态抵押（State Deposit）。举例来说，状态抵押可以是一定数量的以太币或 ERC20 代币，也可以是以太猫（Crptokitty）或 ENS 域名。状态抵押被锁定之后，该通道的参与者开始在链下进行交易发送和验证交易，这些行为都不会 被记录上链。当然，这些交易随时 能够 被记录上链，只是没有这么做而已。
每次更新状态通道总是要得到各方同意（Unanimous Consent），也就是各方要对链下交易签名（并保留副本）。因为这类“状态升级”是发生在整个链下，所以不存在交易手续费，而且他们唯一的速度限制只来自于基础通讯协议。基于这些原因，状态通道提供一种“即时”的交易——参与者无需等待任何的区块确认。对于应用来说，好处是可以 立刻 响应最终操作并反馈给用户，不需要等待设置的确认数完成；这也是为什么我们说状态通道能提供网页般的快速响应。我们把这种特性称为即时确定性（Instant Finality）。在共识研究中，“Finality”指的是一个交易状态保证不会被重置的程度。在使用状态通道的情况下，如果没有人能阻止 Alice 将某个操作记录上链，我们就说该操作 确定（final）了。
如果最近的一次状态通道的“更新”显示：“Alice = 5 ETH, Bob = 1 ETH”，则这个状态是“确定的”。请记住，这个更新是 Alice 和 Bob 都签过名的、有效的交易，也就是说这次更新随时能部署上链。只要我们假设 Alice 能够在任意时间点将交易广播到网路，在她眼里，这个交易状态就是“确定的”。状态通道的核心特性是，只有在必要时，才向区块链返回结果。一旦正确创建通道，所有参与者都能享受到交易状态即时确定性的好处。如果出了什么差池，所有参与者也保有将最新的状态记录上区块链的选择权。请注意，状态通道（以及其他所有区块链技术），都必须考虑在威胁模型下的适应性。在论文第三章节我们做了关于状态通道面对威胁模型的适应性检查；第七章讨论了状态通道的局限。
现有的特定应用的状态通道，要求用户针对每个应用开启新的通道，并支付昂贵的交易手续费。举例来说，两个用户必须进行一次链上交易来开启两人的支付通道；如果他们想要和对方下西洋棋，还得再次进行链上交易开启另一个新通道。我们的状态通道方法尽可能的减少和链上交互的需求，并把这些逻辑操作放在链下进行。这引出我们在论文中表达的一个重要观点：对于任何一个**的状态通道来说，想要和链上进行交互，唯一必要的功能组件是一个强大的多重签名钱包。将逻辑操作移到链下进行，让我们的状态通道比现有的通道方法更具优势。我们能够在从未上链的情况下，在状态通道 安装应用 ；甚至能在不产生链上交易、不支付手续费的情况下，对状态通道进行升级或重新设计。这对于隐私保护也带来巨大的好处。在正确创建的情况下，用于保护状态抵押的多重签名钱包不会区别于其他普通多重签名钱包；在链上没有方法区分一个普通的多重签名和被用来创建状态通道的多重签名。
我们能够借由“反事实实例化（Counterfactual Instantiation）”达到上述的结果，为了解释这项技术，我们先定义几个术语：“反事实（Counterfactual）”是指，对过去发生的事实进行否定而重新表述，尽管现实中表述没有实现。这个观点在接下来讨论状态通道时很有帮助，因为我们会花大量时间论证那些 可能 会发生在链上、但实际上没有发生的事情。
在状态通道中，一个“反事实的 X 事件”代表：
X 可以在链上发生，但它并没有。
任何参与者都可以单方面使得 X 在链上发生。
参与者们能够假设“ X 已经在链上发生”，并基于此进行其他行动。
举例来说，Alice 和 Bob 创建了他们之间的支付通道，然后 Alice 从通道发送 4 ETH 给 Bob，实际上他们双方也都对这笔交易进行签名了；这笔交易随时 可能 被任何一方广播到链上，但他们没有这么做。所以我们可以说，Alice 给 Bob 4 个 ETH 是“反事实的”（校注：即该行为并没有发生（上链），但我们假设发生了（上链了），并以此为前提指导接下来的行动）。这让他们能在默认这笔交易已经发生的前提下，进行其他行动——这是在适当威胁模型下的确定性。
上面的章节中，我们提到你 不需要支付任何链上操作的费用，就能在状态通道上安装应用。这是怎么办到的呢？
其中的关键是反事实实例化（Counterfactual Instantiation）。上面的例子我们提到 Alice 和 Bob 之间的反事实 交易，同样的，我们也能创建一个反事实 合约。反事实实例化指的是，我们实例化一个实际上不会部署上链的合约。当一个合约被反事实实例化，则各方都会在假设这个合约已经被部署上链（即使这不是真的），这项技术让我们能够将绝大部分逻辑操作移至链下进行。
通过用户签名和分享多重签名钱包的确认，反事实实例化才得以实现。确认指出，如果反事实实例化合约将在链上被实例化，则（存放状态抵押的）多重签名钱包会查询实例化的合约，并根据合约状态转移合适的状态抵押。
为了实现这点，我们需要在合约被正式部署之前，参考被确认的反事实实例化合约。这里我们引入全局注册表（Global Registry）：它是一个链上合约，将与反事实合约绑定的唯一地址，映射到实际链上的合约地址 <注 2>。 用来生成绑定地址的哈希函数都需要包含地址的字节码、所有者（比如多重签名钱包地址），和唯一的标识符。
举例来说，有个合约 C ，包含字节码和构造函数的参数 initcode 。当一个带有参数 initcode 的函数调用注册表时，会有一条键-值对信息被添加进注册表。这条信息的 key 是反事实合约地址， value 是实际链上的合约地址。这使得我们不需要将这个合约上链，就能定位到链下的合约。我们可以直接在注册表中检查反事实合约地址和哪个地址相匹配，用 Solidity 操作非常简单：
Registry(registryAddress).resolve(counterfactualAddress)
我们的状态通道设计，提供开发者面向对象的开发环境。任何的**状态通道由数个反事实对象所组成——比如，支付通道对象、西洋棋通道对象等等。因为这些对象都是反事实实例化的，所以添加进状态通道不需要支付任何费用，只需要相关方的签名确认。举例来说，Alice 和 Bob 可以在他们的通道中，在任何时间点反事实实例化一个合约——比如西洋棋游戏。然后在这个反事实实例化游戏里，相关参与者就能真正地进行西洋棋游戏，而且不会产生任何链上费用。
我们相信这种面向对象的方法能带来很多好处：
开发者能够使用定义清晰的 API 进行编程，并很好地嵌入各个通道的核心组件。
我们能够确保，只要我们严格审计核心组件代码，确保核心组件安全，即使开发者的代码出现 bug ，错误也只会隔离在受其控制的状态中。
开发者能够通过反事实定位，重新使用已经存在的合约，这和以太坊合约重用类似——比如一个可证公平的随机数源。
使用者能够在有争议时保护自己的隐私，因为只需要将有争议的对象部署上链。
我们更够在正常消息传递和有争议的交易之间，取得更多平衡点；因为我们可以借着通道分摊一些旧的状态响应。
如果你对如何生成一个广义状态通道，或是对反事实技术感兴趣，我们非常推荐你读一读这篇文章。文章中还有很多丰富的内容在本文里没有提及，包括：
与其他相关技术的比较，如侧链、Plasma
回顾一些已有的状态通道设计
深入研究相关的威胁模型
元通道
示范如何构建状态通道
后续的更新请订阅并持续关注我们， @statechannels 。最后，非常感谢以太坊基金会对我们工作的大力支持。我们很高兴能够加入这么有天赋的团队，一起为以太坊网络扩容和 Web3 落地贡献力量。我们还要感谢 Vitalik Buterin、Erik Bryn、Tom Close、Josh Stark、Nima Vaziri、Armani Ferrante、Lisa Eckey、Kristina Hostakova、Yoichi Hirai, 和 Sylvain Laurent；感谢他们对于这篇文章提出的讨论和反馈。
