反事实：以太坊上的通用状态通道 | 作者：Liam Horne | 状态通道 | Medium

Counterfactual：以太坊上的广义状态通道

一个典型的状态通道，由反事实实例化的对象组成。

在 L4 我们一直在研究状态通道和其他区块链可扩展性技术。今天，我们很高兴与大家分享我们工作的基础性文献之一：Counterfactual：广义状态通道（pdf）。

状态通道是可用分布式应用程序的基础技术。它们可以在一组确定的参与者之间使用，例如支付或象棋、扑克等游戏。将这些应用程序“通道化”可以使其成本明显降低，并减少当今区块链应用中不可接受的高延迟，从而实现用户所期望的类网响应时间。

尽管如此，状态通道在当今的以太坊应用中仍未得到充分利用。每个希望使用状态通道的项目都必须有效地构建自己的自定义实现，导致冗余和不必要的风险。其次，现有的状态通道实现_仍然_将过多的操作放在链上，并以不必要的方式妨碍隐私。

我们设想一个更好的未来。早些时候，我们描述了两个广泛的目标：

1. 设计一个广义状态通道实现，该实现保护隐私，使用模块化组件构建，支持在单个通道内部的多个并行操作，并允许用户无需任何链上操作即可升级通道设计。
2. 使开发者能够_轻松_利用状态通道，提供一个框架和标准的模块化组件来构建安全、高效的应用程序。

我们的论文（pdf）描述了一种状态通道设计，该设计尽可能少地将操作放在链上，同时仍然保持安全。我们相信这将成为构建安全和优化状态通道的标准参考，这是以太坊社区长期所需的。

我们将参加在柏林举办的 Off the Chain，我们将在那里更深入地讨论我们的技术。无需多说，我们并不进行ICO或任何其他涉及代币的筹款活动。

在这篇博客中，我们总结了我们论文中描述的方法。如果你对状态通道工作方式的概念描述感兴趣，请查看 Josh Stark的第二层扩展文章的状态通道部分。这篇博客的其余部分假设读者对基本技术有一定的熟悉度。

状态通道术语

状态通道背后的基本技术已知多年。从那时起，我们找到了新的词汇，以便能够抽象特定的实现并讨论所有状态通道中出现的组件和技术。

状态通道通过把一部分区块链状态“锁定”到一个由确定参与者控制的多签名合约中来工作。被“锁定”的状态称为状态存款。例如，这可能是一笔以太币或ERC20代币，但也可以是一个cryptokitty或ENS域名。

在状态存款被锁定后，通道参与者使用链下消息交换和签名有效的以太坊交易，而不将其部署到链上。这些是_可以_随时在链上部署的交易，但实际上并没有。

更新通道状态总是通过一致同意进行。所有参与者都签署每个链下交易（并保留自己的副本）。因为这些“状态更新”完全发生在链下，所以它们没有交易费用，其速度仅受基础通信协议的限制。

因此，状态通道提供了“即时”交易——即，参与方不必等待任何区块链确认。一个应用程序可以_立即_将一个操作视为已完成并向用户显示，而无需等待设定数量的确认。这就是状态通道能够提供类网响应时间的原因。

我们称这个属性为即时最终性。在共识研究中，“最终性”指的是状态转换不被回滚的保证程度。在状态通道的上下文中，如果Alice选择在区块链上实现某个操作，那么这个操作就是最终的。

如果状态通道中的最新“更新”显示“Alice = 5ETH，博布 = 1 ETH”，那么这个状态就是“最终的”。请记住，更新是一个由Alice和博布共同签署的有效交易，任何一方都可以随时在链上部署。只要我们假设Alice能够在某个时候将该交易广播到互联网，她就可以将该交易视为最终的。

状态通道的核心属性是只在_必要时_回溯区块链。如果一个通道构建得当，那么所有参与方均可进行快速操作，提供即时最终性。如果遇到任何问题，所有参与方始终有选项将最新版本的状态部署到区块链上。

请记住，状态通道——以及所有区块链技术——应根据适当的威胁模型进行考虑。我们在论文的第3节中详细考察了适合状态通道的威胁模型，并在第7节中讨论了状态通道的局限性。

最小化链上操作

现有的特定应用状态通道实现要求用户为他们希望使用的每个应用打开一个新的通道，支付高昂的交易费用。例如，两个用户需要进行一次链上交易来打开一个支付通道，另外，他们还需要进行另一次链上交易来进行一次棋局。

我们的状态通道在链上的要求降到极低，将尽可能多的逻辑移动到链下。这导致了我们论文中的一个重要见解：一个功能足够强大的多签名钱包是任何个别状态通道中唯一必要的链上组件。

将逻辑移至链下使我们在现有通道中获得了显著的优势。我们可以_将新应用安装_到状态通道中，而无需任何链上的操作。我们甚至可以在无需链上交易或费用的情况下升级或重新设计状态通道。

这种方法还有显著的隐私好处。正确构建的用于保护状态存款的多签名钱包应该与任何其他多签名钱包没有区别。在链上，没有办法区分一个普通的多签名和用于创建状态通道的一个多签名。

反事实术语

我们能够通过我们所称的“反事实实例化”来实现这些结果。解释这种技术首先需要定义相关术语。

“反事实”意味着一些_可能_是真的，但实际上并不是。这是讨论状态通道时非常有用的概念，因为我们在讨论许多_可以_发生在链上的事情时，实际上它并没有发生。

在状态通道中，我们称之为“反事实X”是为了描述以下情况：

1. X可以在链上发生，但没有发生
2. 任何参与者都可以单方面使X发生在链上
3. 因此，参与者可以像X已经在链上发生一样行动

例如，假设Alice和博布之间有一个支付通道。Alice通过通道向博布发送4个ETH，这在实践中意味着双方都签署一笔交易。此交易_可以_随时由任一方在链上部署，但实际上却没有。因此，我们可以说“反事实Alice给博布4个ETH”。这使他们能够将该交易视为已经发生——在适当的威胁模型下，它是最终的。

反事实实例化

在以上几个部分中，我们提到我们的方法使你可以在没有_任何链上操作或费用_的情况下为状态通道安装新应用。这是如何实现的？

这种能力的关键是我们所称的反事实实例化。在上一节中，我们描述了Alice和博布之间的反事实交易。但我们也可以创建反事实合约。反事实实例化意味着在实际上并未在链上部署合约的情况下实例化合约。当一个合约被反事实实例化时，通道中的所有参与者都表现得好像它已经部署，尽管实际上并没有。这项技术使我们能够将几乎所有通道逻辑移至链下。

反事实实例化的实现是让用户签署并共享对多签名钱包的承诺。这些承诺声明如果反事实实例化的合约_被_实例化在链上，持有状态存款的多签名钱包将查看实例化的合约，並根据该合约的状态转移相应的状态存款。

为了实现这一点，我们需要在合约部署之前通过承诺提到反事实实例化的合约。为此，我们引入了一个全局注册表：一个链上合约，将任何反事实合约的唯一确定性地址映射到实际的链上部署地址。² 用于生成确定性地址的哈希函数可以是考虑到字节码、其拥有者（即多签名钱包地址）和唯一标识符的任何函数。

例如，我们可能有一个合约 C，带有字节码和构造参数 initcode_。在注册表上运行函数调用的结果是向注册表添加一条条目；其键是反事实地址，其值是实际的链上部署地址。

这为我们提供了一种无需先在链上部署合约就能引用链下合约的方法。我们只需在注册表中查找对应反事实地址的地址。在Solidity中，这样简单：

Registry(registryAddress).resolve(counterfactualAddress)

面向对象的通道设计

我们的通道设计允许开发人员采取面向对象的方法来构建状态通道。任何单个状态通道将由几个反事实对象组成——例如一个支付通道对象，或一个棋局通道对象。因为这些是反事实实例化的，所以将其添加到通道中无需支付费用——仅需双方之间的签署承诺。

例如，Alice和博布可以在任何时候选择在他们的通道内反事实实例化一个合约——例如，一个定义棋局的合约。然后，他们可以在彼此之间交换状态更新，_引用_那个反事实实例化的游戏，以实际_进行_象棋游戏，所有操作均无链上费用。

我们相信这种面向对象的方法提供了许多显著的好处：

• 应用开发人员可以针对定义良好的API编程，连接每个通道所需的核心组件。
• 我们可以确保，只要核心组件经过大量审计并保持安全，应用开发者代码中的漏洞可以仅限于其控制的状态。
• 应用开发人员可以通过反事实寻址重用现有组件，就像重用以太坊合约一样——例如，可以证明公平的随机性来源。
• 用户在争议中可以保持隐私，仅将争议中的对象放到链上。
• 我们可以在正常操作中传递的消息与争议情况下需要发布的交易之间的权衡曲线上访问更多的点，在某些情况下这可以让我们在通道之间摊销对过时状态的响应。

结论

如果你对了解更多关于广义状态通道和反事实技术感兴趣，我们鼓励你阅读论文。该论文包括很多我们在这篇文章中没有总结的重要内容，包括：

• 与侧链和Plasma等其他技术的比较
• 现有状态通道设计的回顾
• 对相关威胁模型的深入考察
• 元通道
• 广义状态通道的示例构建

要获取更新，请关注我们 @statechannels 并关注我们的网站。

最后，我们要感谢以太坊基金会对这项重要工作的持续支持。我们很高兴能成为一个致力于扩展以太坊网络的优秀社区的一部分，为 Web 3 打下基础。我们还感谢维塔利克·布特林、埃里克·布赖恩、汤姆·克洛斯、乔什·斯塔克、尼玛·瓦兹里、阿尔曼·费兰特、丽莎·埃基、克里斯蒂娜·霍斯塔科娃、洋一·平井和西尔万·洛朗在论文早期草稿中对我们的讨论和反馈。

注释

² 在未来， 一旦账户抽象生效，我们就能轻松做到这一点，因为合约地址将可以根据其字节码和构造参数计算。

• 原文链接： medium.com/statechannels...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～