状态通道是可用于分布式应用程序的基础技术。它们可以用于与一组已定义的参与者进行任何交互，例如付款或类似象棋或扑克的游戏。“通道化”这些应用程序使其成本大大降低，并减少了当今区块链应用程序中不可接受的高延迟，从而实现了用户预期的类似网络的响应时间。
尽管如此，在当今的以太坊应用中，状态通道的利用率仍然很低。每个想要使用状态通道的项目必须有效地构建自己的自定义实现，从而导致冗余和不必要的风险。其次，现有的状态通道实现仍然将太多的操作置于链上，并以其他的方式危害隐私。
实现一个保护隐私的通用状态通道，使用模块化组件构建，支持单个通道内的多个并行操作，并允许用户升级通道设计，而无需任何链上操作。
通过为构建安全、高性能的应用程序提供框架和标准模块化组件，使开发人员能够轻松地利用状态通道。
我们的论文描述了一种状态通道设计，它在保持安全的同时尽可能少地将数据链放置在其中。我们相信它将成为构建安全和优化状态通道的标准参考，这是以太坊社区长期需要的。
状态通道技术
状态通道通过将区块链状态的一部分“锁定”到一个由一组定义的参与者控制的多签名合同中来工作。被“锁定”的状态称为状态存款。例如，这可能是一定数量的以太或erc20令牌，但也可能是cryptokitty或ENS域名。
在状态存款被锁定，通道的参与者使用链外消息交换和签署有效的以太坊交易，而不将它们部署到链上。这些事务可以随时放到链上。
更新频道的状态总是在一致同意的情况下进行。所有当事方签署每个链下交易。因为这些“状态更新”完全是在链外进行的，所以它们的交易费用为零，并且它们的速度仅受其底层通信协议的限制。
因此，状态通道提供“即时”交易，即各方无需等待任何区块链确认。应用程序可以立即将已完成的操作并将其显示给用户，而无需等待设置数量的确认。这就是状态通道如何提供类似web的响应时间。
我们称之为即时终结。在共识研究中，“最终性”是指状态交易不被逆转的程度。在状态通道的上下文中，如果不能阻止Alice实现区块链上的操作，则操作是最终的。
如果州频道的最新“更新”表示“alice=5eth，bob=1eth”，则该状态为“最终”状态。记住，更新是一个由Alice和Bob签名的有效事务，任何一方都可以随时在链上部署它。只要我们假定Alice可以在某个时间点将该事务广播到互联网，她就可以将该事务视为最终事务。
状态通道的核心属性是仅在必要时才能返回区块链。如果正确构建了一个状态通道，那么所有各方都可以进行即时终结的快速操作。如果出现任何问题，各方总是可以选择将最新版本的状态部署到区块链。
最小化链上操作
现有的特定于应用程序的状态通道实现要求用户为他们想要使用的每个应用程序打开一个新的通道，支付昂贵的交易费用。例如，两个用户将进行一个链上交易，在他们之间打开一个支付渠道，他们需要进行另一个链上交易，以进行一个棋局。
我们的状态通道将链上需求最小化到极端，将尽可能多的逻辑转移到链外层。这导致了我们论文中最重要的观点之一：一个足够强大的多签名钱包是任何单个状态通道唯一必要的链上组件。
将逻辑从链上移开可以使我们获得比现有信道更大的优势。我们可以将新的应用程序安装到一个状态通道中，而无需进行链操作。我们甚至可以升级或重新设计一个状态通道，而不需要链上交易或费用。
这种方法还具有显著的隐私优势。正确构造，用于保证状态存款的多签名钱包应与任何其他多签名钱包不可区分。在链上，没有办法区分常见的multisig和用于创建状态通道的multisig。
反事实技术
我们可以使用所谓的“反事实实例化”来实现这些结果。解释这种技术需要首先定义术语。
“反事实”是指可能是真的，但不是。在讨论状态通道时，这是一个非常有用的概念，我们花了很多时间对可能发生在链上的事情进行推理，但事实并非如此。
在状态通道中，我们称“反事实X”来描述一个案例，其中：
X可能发生在链上，但不会发生
任何参与者都可以单方面使X在链上发生
因此，参与者可以表现为X发生在链上
例如，想象一下Alice和Bob之间的支付渠道。Alice通过频道向Bob发送4个ETH，这实际上意味着双方都签署了一个交易。任何一方都可以随时在链上部署此交易，但事实并非如此。所以我们可以说“反事实的Alice给了Bob4ETH”。这使他们能够像已经发生的交易一样行动-在适当的威胁模型中，这是最终的交易。
反事实实例化
在上面的部分中，我们说我们的方法允许您将新应用程序安装到状态通道中，而无需任何链上操作或费用。这怎么可能？
这种能力的关键是我们所谓的反事实实例化。在上面的部分中，我们描述了Alice和Bob之间的反事实交易。但我们也可以创建反事实合约。反事实实例化是指在不实际将合同部署到链上的情况下实例化合同。当一个合约被反事实地实例化时，通道中的所有当事方就好像它已经被部署了，即使它没有。这种技术可以让我们将几乎所有的通道逻辑从链上移开。
反事实实例化是通过让用户签署并共享对multisig钱包的承诺来实现的。这些承诺表明，如果反事实例示的合同在链上被例示，multisigwallet将查看例示的合同，并根据该合同的状态转移适当的状态存款。
为了实现这一点，在部署合同之前，我们需要在承诺中引用反事实的实例化合同。为此，我们引入了一个全局注册表：一个链上合约，它将任何反事实合约的唯一确定性地址映射到实际的链上部署的地址。用于生成确定性地址的哈希函数可以是任何考虑到字节码、其所有者的函数）和唯一标识符。
例如，我们可能有一个合约“c”，其中包含字节码和构造函数参数“initcode”。使用参数“initcode”对注册表运行函数调用的结果是将一个条目添加到注册表中；其键是反事实地址，其值是实际的链上部署地址。
这为我们提供了一种引用链外合同的方法，而无需首先将它们部署到链上。我们只需在注册表中进行一次查找，看看哪个地址对应于反事实地址。在Solidity中，这很简单：
Registry(registryAddress).resolve(counterfactualAddress)
面向对象的通道设计
我们的通道设计允许开发人员对状态通道采用面向对象的方法。任何单个状态通道都将由几个反事实对象-组成，例如支付通道对象或棋类游戏通道对象。因为这些都是反事实的实例，所以它们不需要向通道中添加费用-只需要双方签署承诺。
例如，Alice和Bob可以在任何时候选择反事实地在他们的通道内实例化一个合约，比如，定义一个国际象棋游戏的合约。然后，他们可以相互交换状态更新，这些更新引用了反事实的例示游戏，以便真正玩国际象棋，所有这些都不需要链上费用。
我们相信这种面向对象的方法提供了许多显著的好处：
应用程序开发人员可以针对定义良好的API编程，插入每个通道所需的核心组件。
我们可以确保，只要核心组件经过严格审核并保持安全，应用程序开发人员代码中的错误就可以隔离到它控制的状态。
应用程序开发人员可以通过反事实寻址重用现有组件，就像他们将重用以太坊合同一样，例如，一个可以证明是公平的随机性源。
用户可以在有争议的情况下保护隐私，只需将有争议的对象链接起来。
我们可以在正常运行期间传递的消息和发生争议时需要发布的事务之间的权衡曲线上访问更多的点，在某些情况下，这使我们可以跨通道分摊对过时状态的响应。
结论
如果您有兴趣了解有关广义国家频道和反事实技术的更多信息，我们建议您阅读本文。本文包含我们未在本文中总结的重要内容，包括：
侧链和Plasma等其他技术进行比较
审查现有的状态通道设计
深入研究相关威胁模型
元信道
广义状态通道的示例结构
本文转载公众号：区块链研究实验室
海纳学院的内容将围绕：区块链技术，产品社群，经济模型等全方位的知识体系输出，为大家带来不一样的社群学习体验。欢迎联系作者微信加入社群：csschan1120
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。