State Channels on Ethereum with Counterfactual by Liam Horne (Devcon4)

Perfectly. So, I'm going to talk about Counterfactual. This is an open source project that aims to source project that aims to simplify the creation of secure off-chain secure off-chain applications on Ethereum. You have just seen two reports: on building a network of payment channels and on creating an applied state applied state channel for casinos. We want to make the process of creating such things as simple as possible for developers.

For example, Jeremy from FunFair is exactly the kind of developer we want to make easier for , as is the entire FunFair team sitting in front of me. So, first of all, who am I ? My name is Liam Horn. I am the co- founder of L4. We are a L4.

We are a company that is trying to do a lot in this area. We are mainly promoting the vision of Web3. We helped build this project. We helped build ETH Global and a number of other initiatives. But I'm also an engineer on the Counterfactual project.

The difference between them is not yet completely clear, but I will try to explain it in my report. So what will I talk about? I will go through four points. First, what are generalized state channels? You've just seen examples of using payment channels, as well as an example of what I would call an application-specific state channel.

I want to show what generalized state channels are as a second- level solution that uses this technique for blockchain technique for blockchain transactions in a general way. What the Counterfactual project is, and explain our engineering approach to building a framework for it, as well as how you can do it yourself. So, the main agenda is: Background, Generalization, Engineering, and Counterfactual. So let's get started. When I first came into this field, I asked the question: why are n't ordinary people using this yet?

The answer I got was that scalability is important. This was about a year and a half ago, and there were a number of issues that needed to be worked on, including sharding, and one of them was state channels them was state channels . And I wondered: why is n't anyone approaching this not as a separate technique to accelerate a specific application, but as a general solution for scaling Ethereum? Why can't everyone who wants to build an app use this technique to make their app very fast by default? I came across this post and met the author, Jeff Coleman.

I realized Coleman. I realized that there were a lot of ideas out there about how to build state channels as a second-level scaling method, but there was almost no implementation, and I wondered why. After much thought and research, we realized that this was a great opportunity to try to create something remarkable. So we approached this with this thought: how do we create a second-level scaling solution using this technique that is universal enough for any application with the maximum amount of off-chain amount of off-chain interactions, without creating it as a separate implementation for a specific application? We started by writing this article, which is a formal version of Jeff's post.

It describes in detail how this can be implemented. What security models are worth considering? What general parameters are targeted? How to make the most of off-chain interactions through state channels for any application? This is a fairly abstract concept, but if implemented correctly, it opens up extremely powerful possibilities.

I'll show you how useful it is. The article is long useful it is. The article is long , but its essence comes down to a very simple idea. I'll go through it very briefly. You already know what payment channels are, but I'll get you started.

You are quite familiar with this technique. You have a blockchain. You put some money into the channel. Balance A, balance B. You wait a certain amount of time while Alice and Bob communicate off-chain via a communication protocol.

They update the balances between themselves, from version zero all the way up to version N. When they finish, they go back to the blockchain, transmit this latest state, and the balances are paid out balances are paid out . We are all very familiar with this . This is the payment channel. And what is a state channel for a specific application?

What are they doing? Everything is very similar, but they work with an arbitrary state. They have a different state for each application, whether it's roulette, blackjack, or whatever else they're playing. And they have this addition in the chain— application logic to resolve disputes, essentially, or cases where someone deviates from protocol and they need to figure out who actually won the game. This is how they ensure evidentiary integrity.

So it's very similar to a payment channel. Here's what you can do with the application state. But what is a generalized state channel? As I mentioned, you have the application logic, but what is a generalized state channel? In the aggregation channel, you have the same configured blockchain contract.

You deposit there: ETH, ERC20, or anything else you want to use off- chain. But over time you do an interesting thing. You are actually creating opportunities for yourself. You sign transactions that distribute a portion of that state, a sub-deposit, into what we might call an off-chain application. And you do it almost exactly the same way you would in a specialized state channel for a specific application.

But since you can push this to the application level, no matter what in the chain, you can do it many times. The key advantage is that you can now install, update, and remove arbitrary applications: a roulette game, a tic-tac- roulette game, a tic-tac- toe game, a blackjack game, a payment channel— payment channel— anything you want, within a single state channel in the chain. With this single contract on- chain, you can use multiple applications. This is the key idea behind generalized state channels. This is very cool.

If you do it this way, it will no longer be just a quick method for a single application. This becomes a generalized solution for scaling. This is very powerful. Disputes or deviations from the protocol are resolved very similarly to the case with a specialized application. You simply take one of these states, the one that needs to be checked for honesty and resolved in the chain, and post it to the chain.

The main idea is that off-chain you install and uninstall applications without fees, without on- chain transactions, and that's great. So two questions I always get asked . First: how do you make sure that all subdeposits are summed correctly? Isn't that too complicated? Yes, it's complicated, and that's why, as Jeremy rightly pointed out , a clearly defined protocol is needed.

You need a protocol so that participants in the state channel can communicate with each other and ask, "How do I install the app?" How do we remove it? What do we even say to each other? What exactly are our obligations? This is a bit complicated, so it requires a well- defined protocol, which I will explain.

The second point, about which there was some misunderstanding if you read the article: " you read the article: " Don't you have to deploy the contract every time, and isn't that too expensive?" The answer is no. As Jeremy said: in practice, you deploy a contract on the network that defines the rules of the game in advance, but for the application it is done once. In the article we introduced the concept of counterfactual instantiation, you may have heard that it allows you to do this offline; This is a useful technique for productivity and updatability, but not mandatory. So it's very highly efficient very highly efficient , just like a state channel for a specific application.

So, great. Quick about what is counterfeiting and what do we do about it? Why are we even talking about this? The main thing is that we talking about this? The main thing is that we are an open source project.

Our goal, our vision, is to make goal, our vision, is to make applications like the ones I mentioned as easy to create as possible. In the future, a developer at a hackathon should say, “I want to write a quick app,” and they should be able to create a great interface in 36 hours. It should be as simple as possible. This is our vision. Our mission is to create the necessary infrastructure for this .

We want to make it as easy as possible for the entire community to use the technique I described. We are not a company, we are not some business with a specific business specific business model. We are an open source project trying to contribute something useful to the community. This is the main essence of our project. It covers three key infrastructure elements that need to be implemented need to be implemented so that people can build on them .

They constitute a minimalist level of contracts. A completely minimalistic, easy to read and deploy set of contracts with few lines of code that need to be present. Based on which, you can design a protocol that does what I was talking about—a protocol for state channels. You need something that defines how to install apps, how you want to install them, and how to update them. And also an application library, something that allows developers to interact using this protocol.

So you can think in a very similar way. It almost looks like a Web 3 stack in the sense that you have the underlying blockchain. You have the Ethereum protocol that you adhere to and an application library similar to Web 3. We are trying to replicate a similar developer experience for the second layer. So let's dive into some of the details of how we approached this and what it looks like.

First of all, the on-chain of all, the on-chain library, the actual contract layer, consists of a very basic on-chain basic on-chain library for conditional transactions. You may have heard the term “conditional payments” or “ payments” or “ instant transfers.” The basic idea is that you place the most minimal component for unanimous consent on the chain—a unanimous consent on the chain—a multi-signature wallet. It achieves N out of N consensus. Also, we have a very simple way to use this multi-signature wallet to sign conditional transactions, using the best practices of many people, who I think you'll hear from after me, who have already talked about how to optimally resolve disputes in state channels.

So we took a lot of the best research from all of these areas and created a simple component to allow this to work on the web. And we've already released all of that. The great thing is that it is designed to support all of this. One-way payment channels, two-way payment channels, multi-way, hub-and- multi-way, hub-and- spoke, plasma, ERC-20, 1121—you name it spoke, plasma, ERC-20, 1121—you name it . The main idea is that we do not assume any specific type of transaction, other than the most primitive transaction unit in Ethereum for data transfer.

That's all we assume. This means that over time, this framework remains independent of protocol updates. As long as you don't change the very concept of a transaction in Ethereum, the protocol will continue to work, and we can gradually improve it as Ethereum evolves, without having to do massive updates for each EIP. For example, apart from the general on-chain components, we created a very basic library based on finite state machines. And you can see again, as in the first presentation, this is what they came up with in terms of how best to describe the applications.

State, action, new state. This is exactly the approach we expect when someone develops their application. And we support it "out of the box." We have also added three very simple methods so that your blockchain your blockchain application can be easily defined using this framework. So, a resolver is something that can take your status and the previous deposit commitment you made and determine what transactions need to be made.

A terminal condition terminal condition is something that indicates: is this game over? And I'll show you now how it all connects. And a move ordering mechanism that determines whether an update is valid. The key point here is four very simple functions that can be implemented for implemented for any application. If you implement them If you implement them , the framework will provide support out of the box support out of the box .

Here's a very simple, high-level example—a bidirectional payment channel. For example, this is the simplest possible state machine. You have one state and people can just update a version of it. In this case, it is a final state channel, and here there are only two elements in the array ; all you do is update them. This is the simplest case simplest case , but what if we wanted something more complex, for which there are various specialized applications, such as a one-way payment channel?

Well, we just write a state machine that looks like this. You start in an open state, and for context: a unidirectional payment channel—this is the type where payments can only be sent in one direction. So, A and B: A can send to B, and B cannot send to A. And the idea is that B is And the idea is that B is the recipient, and if he wants to leave, he can leave instantly. So how do you determine that?

You can define a machine where, in an open state, the sender can send funds, and this is a valid action. And you can reach the point of completion in the terminal state, which I've marked with this orange ring orange ring , where if you're the recipient and you call the close action, you can exit instantly. So, you define your state machine this way and get all the properties of unidirectional payment channels without implementing anything different from the generalized structure. Noughts and structure. Noughts and crosses.

A little more complicated, but the idea is the same, right? You define what your state machine is. Whose move is it now, X? Whose move is it now, O? X can bet X and win, or X can bet X and there could be a draw.

You get the point. And again, you define your condition in such a very simple way. So, while developing this framework, in addition framework, in addition to making it very general and suitable for creating a variety of applications based on state channels, we also spent a significant amount of time on the technical side to make it as simple as possible for developers, and this is evident from the implementation details of some of the example applications. So I'm going to show you some very short code snippets from the code snippets from the counter application. Where you essentially have a counter.

You can increase it, you can decrease it. A basic example of an application, and it looks like this . This is a stateless contract. And here are three slides. I'll walk through them.

A contract without a state. You simply define the structure of your state. And, as Jeremy mentioned, it's that simple. We actually have a workaround to get around the need to use abi.decode in the codebase right now, but when it comes out, that will be great too.

You simply define your state as a structure and define actions that can be used to change it. And again , this function signature allows you to simulate the operation of a state machine. You have a simple action application function, as I mentioned: you take a state, take an action, and decide what to do with it. This is a very simple control flow. And then there's control flow.

And then there's just the basic implementation. So, this is literally the entire contract for a very simple simple counter application. So the great thing about this, again, as Jeremy rightly pointed out, is that state machines encompass any kind of thing that can be run in the EVM, which are essentially pure functions. There is an aspect of time measurement here, which I think maybe one of the future speakers will talk about, which adds some complexity. But for things that can be run on EVM, it covers everything, which is just great.

So, this is the minimalist level of contracts. Additionally, we developed a protocol for this whole concept of generalized state channels, and without going into too much detail, we essentially did it. It is essentially a generic software that clients can run for all possible event messages sent and received through channels, and it is designed to be as portable as possible. So this is not exactly the full node software that we developed. It's just a basic, very basic implementation of the protocol implementation of the protocol that defines the types of messages that can be sent to others to use the state deposit on the network, install applications, uninstall them, etc.

It's very practical, and we tried to make sure there were no unnecessary network costs. One sends to the other, receives a response within all protocols of the entire design, so it is practical and can be deployed today. If you want to look at the protocol specifications, we have the full specifications document on the website, or on GitHub, and you can check it out there. This is kind of the beginning of what we hope will become a very good standard for the best you can get for state channels in Ethereum. And over time, it would be nice if we could build something based on this common standard.

And we hope that many studies can be completed here; At least, that's our goal. So finally, the application library, and this is actually what application library, and this is actually what I mentioned as the web3 counterpart. This is an application library that a developer integrates into their decentralized application (DApp). They interact with their wallet not through the web3 interface, but through this counterfactual interface or this second- level interface. You perform actions such as updating the wallet state, and the wallet, through the protocol implementation protocol implementation , figures out how to interact with counterparties.

And again, it's a little abstract, but it's a complete toolkit that proves that this use case is possible. And all of this was designed with the idea of being as simple as possible for the developer. And as I mentioned before, we actually do hackathons. So we spend a huge amount of time with developers trying to understand what exactly might be causing people difficulties. So, why do we do all this at all and what values ​​drive us to do it ?

As mentioned earlier, Counterfatch is an open source project. It has a lot of contributors, and I'll tell you who they are, but we think it's just regular open source. We just want to be able to work with the Ethereum ecosystem, with the people who are here, with those who are at DevCon, and try to take a lot of the great research that we've been talking about for years and that has, you know, been published on ETH Research, make it concrete, come to standards, agree on best practices, and build on that . There is no unnecessary ego or attachment to the developer here. The only question is how we can create open standards that benefit everyone.

And we want to do this as a regular open project. We don't believe there is a need for a business or token here. We think it's just regular open source code. Developer focus—I've mentioned this a few times, and it shows in how we've designed everything. This should be as simple as possible for developers to use.

We want to strive for compatibility. We want compatibility. We want Ethereum to have the best state channel protocol before any other blockchain, and we can do it together, ensuring our software is compatible. Perfectly. So who is involved in this ?

I already mentioned that this is an open source project. I want to thank many people. Currently, it's mostly a collaboration between L4 and Prototype. Several people from each team and many independent participants. Recently, in the last few weeks, we have had many more people join us who are just starting to work.

They all share a common vision: let's take all these ideas, find a common place to capture them, and create something that people can use. So a big thank you to everyone who contributed throughout the year. We also work with the best specialists best specialists . We spent a lot of time with many great people in this field last year. With MetaMask, we've spent a lot of time recently trying to figure out how to practically implement this in web implement this in web wallets today.

Seller Network. We spent a lot of time with Mo, especially learning about the fundamental research on how to build generalized state channels. We hope to be able to reach common interfaces in the near future. Pisa did a phenomenal job, and they will be speaking later on how to create truly optimal watchtowers with state channels. We're also going to try to integrate that.

And Magma is also a phenomenal team of state channel engineers who have inspired many state channel finite state machine-based projects. So, if you want to get involved, we have a lot of code on GitHub. We also just released a lot more . Everything I just mentioned is the full implementations that we have working. We don't have a large demonstration environment yet.

This is one of our main next goals, but it is already working locally and you can test it. And we are actively developing this at a very rapid pace. If you want to chat with us, we are available all the time. You can join our chat join our chat group at counterfactual.com/chat.

We are very friendly. We just want to help the community as much as possible. So join in, no matter what you want to talk about. And if you just want to learn more about the product in general, check out counterfactual.com.

Well, actually, that's all. Thank you very much. I have a minute and 20 seconds left, so if there are any questions, I can answer one. Or I can awkwardly walk off stage. Yes.

What is the difference between a state channel and a Plasma state channel and a Plasma chain, if explained in 30 seconds? Is that... Yes, that was in my slides. First, there's a really great talk by the guy who just handed you the microphone, Josh Stark, yesterday called "Achieving Level Two," which explains this basic difference in 30 seconds. I like to describe it this way: technically, in state channels, a fixed group of people contribute state to a network contract, then they unanimously agree on everything off- network, and at some point they all go out, take all that state and put it back on-network, whereas in Plasma everything stays off- network all the time.

With Plasma, a group of people contribute state to a contract, and there are two types of people there. There is an operator, and there are users, and the operator periodically places a Merkle proof on the chain, which gives users finality. So, every time a Merkle proof is placed in the chain, it means that it is now the final state. So there is a kind of periodic checkpoint mechanism. The main difference is that, say, in channels, finalization occurs instantly occurs instantly .

There is a slight delay in Plasma because it is a checkpoint. Um, technically they are implemented implemented differently, but both are very useful solutions for scalability. I would recommend watching Josh's performance. Perfectly. OK.

Thank you.