Counterfactual: Generalized State Channels on Ethereum
反事实:以太坊的通用状态通道
At L4 we have been working on state channels and other blockchain scalability research. Today we’re excited to share one of the foundational pieces of our work: Counterfactual: Generalized State Channels (pdf).
在L4，我们一直在研究状态通道和其他区块链可伸缩性研究。今天，我们很高兴能分享我们工作的一个基本部分：反事实：通用状态通道（pdf）。
State channels are the foundational technology for useable distributed applications. They can be used in any interaction with a defined set of participants, such as payments or games like chess or poker. “Channelizing” these applications makes them radically cheaper, and reduces the unacceptably high latency in today’s blockchain applications, enabling the web-like response times expected by users.
状态通道是可使用分布式应用程序的基础技术。它们可以用于任何与已定义的参与者的交互，例如支付或像国际象棋或扑克这样的游戏。“Channelizing”这些应用程序使它们从根本上更便宜，并减少了当今区块链应用程序中不可接受的高延迟，从而实现了用户期望的网络响应时间。
Despite this, state channels are underutilized in today’s ethereum applications. Each project that wants to use state channels must effectively build their own custom implementation, leading to redundancies and unnecessary risks. Second, existing state channel implementations still put too many operations on-chain, and compromise privacy in unnecessary ways.
尽管如此，在今天的ethereum应用中，状态通道没有得到充分利用。每个想要使用状态通道的项目都必须有效地构建自己的定制实现，否则将导致冗余和不必要的风险。其次，现有的状态通道实现仍然在链上放置过多的操作，并以不必要的方式损害隐私。
We envision a better future. Earlier, we described two broad goals:
我们设想一个更美好的未来。早些时候，我们描述了两大目标：
Design a generalized state channels implementation that preserves privacy, is built using modular components, has support for multiple parallel operations inside a single channel, and allows users to upgrade channel designs without any on-chain operations.
设计一种保护隐私的通用状态通道实现，是使用模块化组件构建的，它支持单个通道内的多个并行操作，并允许用户在没有任何链上操作的情况下升级通道设计。
Make it easy for developers to utilize state channels by providing a framework and standard modular components for building secure, performant applications.
通过提供一个框架和标准的模块化组件来构建安全的、性能良好的应用程序，让开发人员可以轻松地利用状态通道。
Our paper (pdf) describes a state channels design that places as little on-chain as possible while still remaining secure. We believe it will become a standard reference for building secure and optimized state channels, something long-needed by the ethereum community.
我们的论文（pdf）描述了一个状态通道的设计，它在保持安全的同时，尽可能少的在链上。我们相信，它将成为建立安全、优化的状态通道的标准参考，这是以太坊社区长期需要的。
We will be attending Off the Chain in Berlin where we will discuss our technique in more depth. Needless to say, we’re not doing an ICO or any other fundraising event involving a token.
我们将在柏林参加会议（off the chain），在那里我们将更深入地讨论我们的技术。不用说，我们不是在做一个ICO或任何其他涉及到代币的筹款活动。
In this blog post, we summarize the approach described in our paper. If you’re interested in a conceptual description of how state channels work, take a look at the state channels section of Josh Stark’s Layer 2 scaling article. The rest of this blog post assumes the reader has some familiarity with the basic technique.
在这篇博客文章中，我们总结了我们论文中描述的方法。如果您对状态通道如何工作的概念描述感兴趣，可以看一下Josh Stark的第二层缩放文章的状态通道部分。这篇博客文章的其余部分假设读者对基本技术有一定的了解。
State channels terminology
状态通道术语
The basic technique behind state channels has been known for several years. Since then, we have found new vocabulary that lets us abstract over particular implementations and discuss components and techniques that appear in all state channels.
多年来，状态通道背后的基本技术已经为人所知。从那时起，我们发明了新的词汇，它允许我们对特定的实现进行抽象，并讨论出现在所有状态通道中的组件和技术。
State channels work by “locking up” some portion of blockchain state into a multisig contract, controlled by a defined set of participants. The state that is “locked up” is called a state deposit. For instance, this might be an amount of ether or an ERC20 token, but could also be a cryptokitty or an ENS domain name.
状态通道的工作是“锁定”区块链状态的一部分，并将其转换为多团体合同，由一组已定义的参与者控制。被“锁起来”的状态被称为状态存款。例如，这可能是一个以太或一个ERC20令牌，但也可以是一个密码或一个ENS域名。
After the state deposit is locked, channel participants use off-chain messaging to exchange and sign valid ethereum transactions without deploying them to chain. These are transactions that could be put on chain anytime, but are not.
在状态存款被锁定之后，通道参与者使用链下消息来交换和签署有效的ethereum交易，而不需要将它们部署到链上。这些交易可以随时被放到链条上，但不是。
Updating the state of the channel always proceeds by unanimous consent. All parties sign (and keep their own copies of) each off-chain transaction. Because these “state updates” are taking place entirely off chain, they have zero transaction fees, and their speed is limited only by their underlying communications protocol.
更新通道的状态总是得到一致同意。所有各方都签署（并保留自己的副本）每一笔交易。因为这些“状态更新”完全是在链下进行的，它们的交易费用为零，而且它们的速度仅受其底层通信协议的限制。
For this reason, state channels offer “instant” transactions — i.e., parties do not have to wait for any blockchain confirmations. An application can immediately consider an operation finalized and display that to users, without having to wait for a set number of confirmations. This is how state channels are able to offer web-like response times.
出于这个原因，状态通道提供“即时”交易——也就是，各方不必等待任何区块链确认。应用程序可以立即考虑最终确定的操作，并将其显示给用户，而不必等待一定数量的确认。这就是状态通道能够提供类似于web的响应时间的方式。
We call this property instant finality. In consensus research, “finality” means the extent to which a state transition is guaranteed not to be reverted. In the context of state channels, an operation is final if Alice cannot be prevented from realizing that operation on the blockchain if they choose to.
我们称这个属性为即时终结。在一致的研究中，“终结”指的是保证状态过渡不会被恢复的程度。在状态通道的上下文中，如果Alice不能被阻止在区块链上实现这个操作，那么操作就是最终的结果。
If the latest “update” in a state channel says “Alice = 5ETH, Bob = 1 ETH”, then that state is “final”. Remember, the update is a valid transaction signed by both Alice and Bob, which could be deployed on-chain by either party at any time. As long as we assume Alice can broadcast that transaction to the internet at some point, she can consider that transaction final.
如果状态通道的最新“更新”显示“Alice=5 ETH，Bob=1”，那么这个状态就是“final”。请记住，更新是由Alice和Bob签署的有效事务，可以在任何时候由任何一方在链上部署。只要我们假设Alice可以在某一时刻将该交易广播到互联网上，她就可以考虑交易的最终结果。
The core property of state channels is the ability to refer back to the blockchain only when necessary. If a channel is properly constructed, then all parties can engage in fast operations that offer instant finality. If anything ever goes wrong, all parties always have the option to deploy the latest version of the state to the blockchain.
状态通道的核心属性是只有在必要时才可以参考区块链。如果一个通道被正确构造，那么所有的参与方都可以进行快速的操作，从而提供即时的最终结果。如果出现任何问题，所有各方都可以选择将最新版本的状态部署到区块链上。
Keep in mind that state channels — and all blockchain technologies — should be considered within appropriate threat models. We examine in detail threat models appropriate for state channels in section 3 of our paper and limitations of state channels in section 7.
请记住，状态通道——以及所有的区块链技术——都应该在适当的威胁模型中考虑。我们在论文第3部分中详细讨论了适合状态通道的威胁模型，以及第7节中状态通道的限制。
Minimizing on-chain operations
最小化链上操作
Existing application-specific state channel implementations require users to open up a new channel for each application they would like to use, paying expensive transaction fees. For instance, two users would make one on-chain transaction to open a payment channel between them, and they would need to make another on-chain transaction to play a game of chess with each other.
现有的特定于应用程序的状态通道实现要求用户为他们想要使用的每个应用程序打开一个新的通道，支付昂贵的事务费用。例如，两个用户将通过一个连锁的交易来打开他们之间的支付通道，他们需要进行另一个在线交易来玩一个国际象棋游戏。
Our state channels minimize on-chain requirements to an extreme, moving as much logic as possible to the off-chain layer. This leads to one of the most significant insights of our paper: a sufficiently powerful multisignature wallet is the only necessary on-chain component of any individual state channel.
我们的状态通道将链上的需求最小化到一个极端，将尽可能多的逻辑转移到链下。这就引出了我们论文中最重要的见解之一：一个足够强大的多签名钱包是任何单个状态通道中唯一必要的链上组件。
Moving logic off-chain allows us to gain significant advantages over existing channels. We can install new applications into a state channel without ever going on-chain. We can even upgrade or re-design a state channel without requiring on-chain transactions or fees.
通过将操作逻辑移动到链下，将使我们能够比现有的渠道获得显著的优势。我们可以将新的应用程序安装到一个状态通道中，而不需要进行链上的操作。我们甚至可以升级或重新设计一个状态通道，而不需要进行链上交易或被收小费。
This approach also has significant privacy benefits. Properly constructed, the multisignature wallet used to secure the state deposit should be indistinguishable from any other multisignature wallet. There would be no way to tell the difference, on chain, between a common multisig and one used to create a state channel.
这种方法也有重要的隐私保护。经过适当的构造，用于保证状态存款的多签名钱包应该与其他的多签名钱包没有区别。在一个普通的多团体和一个用来创建一个状态通道的普通的多团体之间，没有办法区分它们之间在链上的区别。
Counterfactual Terminology
反事实的术语
We are able to achieve these results using what we call “counterfactual instantiation”. Explaining this technique requires first defining terminology.
我们可以使用我们所说的“反事实实例化”来实现这些结果。解释这种技术需要首先定义术语。
“Counterfactual” means something that could be true, but is not. This is an extremely helpful concept when discussing state channels, where we spend a lot of time reasoning about things that could be happening on chain, but are not.
“反事实”指的是可能是真的，但不是。在讨论状态通道时，这是一个非常有用的概念，我们花了很多时间来讨论可能发生在链上的事情，但事实并非如此。
In state channels, we say “counterfactual X” to describe a case where:
在状态通道中，我们说“反事实X”来描述一个案例：
X could happen on chain, but doesn’t
X可以在链上发生，但不会发生
Any participant can unilaterally make X happen on-chain
任何参与者都可以单方面让X发生在链上
Participants can therefore act as though X has happened on-chain
因此，参与者可以表现出X在链上发生的情况
For instance, imagine a payment channel between Alice and Bob. Alice sends 4 ETH to Bob through the channel, which in practice means that both parties sign a transaction. This transaction could be deployed on chain at any time by either party, but it is not. So we can say “counterfactual Alice gives Bob 4 ETH”. This allows them to act as though the transaction has already happened — it is final, within appropriate threat models.
例如，想象一下Alice和Bob之间的支付通道。Alice通过通道发送4个ETH到Bob，这实际上意味着双方都签了一个事务。该事务可以在任何时候由任何一方在链上进行部署，但事实并非如此。所以我们可以说“反事实的爱丽丝给了鲍勃4个”。这使得他们可以采取行动，就好像交易已经发生了——它是最终的，在适当的威胁模型中。
Counterfactual instantiation
反事实的实例化
In the sections above, we said that our approach lets you install new applications into a state channel with zero on chain operations or fees. How it this possible?
在上面的章节中，我们说我们的方法允许您将新的应用程序安装到一个没有链操作或费用的状态通道中。这如何可能?
The key to this capability is what we call counterfactual instantiation. In the section above, we described counterfactual transactions between Alice and Bob. But we can also create counterfactual contracts. Counterfactual instantiation means to instantiate a contract without actually deploying it on-chain. When a contract is counterfactually instantiated, all parties in the channel act as though it has been deployed, even though it has not. This technique lets us move almost all channel logic off-chain.
这个能力的关键是我们所说的反事实的实例化。在上面的章节中，我们描述了Alice和Bob之间的反事实事务。但我们也可以建立反事实的合同。反事实的实例化意味着在不实际部署它的情况下实例化合同。当合同被实际地实例化时，通道中的所有各方都表现得好像它已经被部署了一样，尽管它没有被部署。这种技术可以让我们将几乎所有的通道逻辑都移到链上。
Counterfactual instantiation is achieved by making users sign and share commitments to the multisig wallet. These commitments say that if the counterfactually instantiated contract were to be instantiated on-chain, the multisig wallet (which holds the state deposit) will look at the instantiated contract and transfer the appropriate state deposits based on the state of that contract.
反事实的实例化是通过让用户签署和共享对多团体钱包的承诺来实现的。这些承诺说，如果反事实的实例化合同是在链上实例化的，那么多团体钱包（持有国家存款）将会查看实例化的契约，并根据契约的状态转移适当的州存款。
For this to work, we need to refer to the counterfactually instantiated contract inside the commitment, before the contract is deployed. To do this, we introduce a global registry: an on-chain contract that maps unique deterministic addresses for any counterfactual contract to actual on-chain deployed addresses.² The hashing function used to produce the deterministic address can be any function that takes into account the bytecode, its owner (i.e. the multisignature wallet address), and a unique identifier.
为了使之生效，我们需要在契约部署之前，参考契约中与事实实例化的契约。为了做到这一点，我们引入了一个全局注册表：一个链契约，它将任何反事实契约的唯一确定性地址映射到实际的链部署地址。用来产生确定性地址的哈希函数可以是任何考虑字节码、它的所有者（即多签名钱包地址）和唯一标识符的函数。
For example, we might have a contract `C` with bytecode and constructor arguments `initcode`. The result of running a function call to the registry with the argument `initcode` would be that an entry would be added to the registry; its key being the counterfactual address and its value being the actual on-chain deployed address.
例如，我们可能有一个带有字节码和构造函数参数“initcode”的合同“C”。使用参数“initcode”对注册中心运行一个函数调用的结果是，一个条目将被添加到登记处;它的关键是反事实的地址和它的值是实际的链上部署的地址。
This gives us a way of referencing off-chain contracts without needing to deploy them on-chain first. We simply do a lookup in the registry to see what address corresponds to the counterfactual address. In Solidity this is as simple as:
这为我们提供了一种引用非链契约的方法，而不需要首先将它们部署到链上。我们只是在注册表中进行查找，以查看与反事实地址对应的地址。在可靠性方面，这很简单：
Registry(registryAddress).resolve(counterfactualAddress)
Object-oriented channel design
面向对象的通道设计
Our channel design lets developers take an object-oriented approach to state channels. Any individual state channel will be composed of several counterfactual objects — e.g. a payment channel object, or a chess-game channel object. Because these are counterfactually instantiated, they require no fees to be added into the channel — only signed commitments between the parties.
我们的通道设计允许开发人员对状态通道采用面向对象的方法。任何单独的状态通道都将由几个反事实的物体组成。一个支付通道对象，或者一个国际象棋通道对象。由于这些都是反事实的实例化，所以它们不需要在通道中添加任何费用——只有在双方之间才有签署的承诺。
For instance, Alice and Bob can at any point choose to counterfactually instantiate a contract within their channel — say, a contract that defines a game of chess. They can then exchange state-updates between each other that reference that counterfactually-instantiated game, in order to actually play the game of chess, all with no on-chain fees.
例如，Alice和Bob可以在任何时候选择在他们的通道中进行反向实例化一个契约——比如说，一个定义了一个国际象棋游戏的契约。然后，他们可以在彼此之间交换状态更新，这是反事实实例化的游戏，为了真正地玩国际象棋游戏，所有的游戏都不收取连锁费用。
We believe this object-oriented approach offers many significant benefits:
我们相信这种面向对象的方法提供了许多重要的好处：
Application developers can program against a well-defined API, plugging into the core components necessary for every channel.
We can ensure that, as long as the core components are heavily audited and remain secure, bugs in the application developer’s code can be isolated to just the state it controls.
Application developers can reuse existing components via counterfactual addressing just as they would reuse ethereum contracts — for instance, a provably fair randomness source.
Users can preserve privacy in a dispute, only putting on-chain the objects that are in dispute.
We can access more points on the trade-off curve between messages passed during normal operation, and transactions that need to be posted in the case of a dispute, and in certain cases this lets us amortize responses to stale state across channels.
应用程序开发人员可以针对定义良好的API进行编程，插入每个通道所需的核心组件。
我们可以确保，只要核心组件被严格审计并保持安全，应用程序开发人员的代码中的bug就可以被隔离到它所控制的状态。
应用程序开发人员可以通过反事实的寻址来重用现有的组件，就像他们会重用ethereum合同一样——例如，一个可证明的公平的随机来源。
用户可以在纠纷中保护隐私，只会将争议的对象放在链上。
我们可以在正常操作期间传递的消息和需要在纠纷情况下发布的交易之间获得更多的点，在某些情况下，这允许我们在不同的通道中对陈旧状态进行摊销。
Conclusion
总结
If you’re interested in learning more about generalized state channels and the counterfactual technique, we encourage you to read the paper. The paper includes significant content that we have not summarized in this post, including:
如果你有兴趣了解更多关于广义状态通道和反事实的技巧，我们鼓励你阅读这篇文章。这篇论文包含了我们在这篇文章中没有总结的重要内容，包括：
Comparisons to other techniques like sidechains and Plasma
与其他技术的比较，如侧链和Plasma
Review of existing state channel designs
审查现有的状态通道设计
In-depth examination of relevant threat models
对相关威胁模型的深入研究
Meta-channels
An example construction for generalized state channels
通用状态通道的一个例子
For updates, follow us at @statechannels and keep an eye on our website.
Lastly, we’d like to thank the Ethereum Foundation for their continuing support of this important work. We are thrilled to be part of a talented community driven to scale the ethereum network, laying the groundwork for Web 3. We’d also like to thank Vitalik Buterin, Erik Bryn, Tom Close, Josh Stark, Nima Vaziri, Armani Ferrante, Lisa Eckey, Kristina Hostakova, Yoichi Hirai, and Sylvain Laurent for their discussion and feedback on earlier drafts of the paper.
最后，我们要感谢以太坊基金会继续支持这项重要的工作。我们很高兴能成为一个有才华的社区的一员，这个社区是为了扩大以太网络的规模，为Web 3奠定基础。我们也要感谢维塔利克布特林、埃里克布林、汤姆克洛斯、乔什斯塔克、尼玛瓦兹里、阿玛尼费兰特、丽莎埃克、克里斯汀娜阿科娃、Yoichi Hirai和西尔万洛朗，他们对这篇论文的早期草稿进行了讨论和反馈。
NOTES
注解
² In the future, once account abstraction is live, we’ll be able to do this trivially, since a contract address will be computable based on its bytecode and constructor arguments.
在未来，一旦帐户抽象是实时的，我们就能够做到这一点，因为契约地址将基于它的字节码和构造函数参数进行计算。
原文地址：https://medium.com/l4-media/generalized-state-channels-on-ethereum-de0357f5fb44
作者：Liam Horne
发表时间：2018年6月12日