 So I'm going to be talking about counterfactual. It's an open source initiative to make secure off-chain applications easy to build in Ethereum. So you just saw two talks about building a payment channel network and about building a production application specific state channel casino game kind of application. We want to try and make those types of things as easy as possible to build for the developers that build it. So Jeremy, for example, from Funfairs, our target kind of developer that we want to help make their life easier and the whole Funfair team in front of me. So first of all, who am I? My name is Liam Horne. I am the co-founder or one of the co-founders of L4. We're a company that tries to do a lot in this industry, basically promoting kind of the Web3 vision. We help build this project. We help build ETH Global and a handful of other initiatives. But I'm also an engineer in the counterfactual project, the distinction for which has not yet been so clear, but I'm going to try to articulate in this talk. So what am I talking about? I'm going to go through four things. Basically, what are generalized state channels? You just saw use cases of payment channels, and you saw use case of what I'm going to kind of show is the application-specific state channel. I want to show what generalized state channels are, kind of a layer two solution that uses this technique in general for blockchain transactions. What counterfactual the project is. And explain how we've approached engineering, a framework for this stuff, and then how you can, too. So basic agenda, background, generalized state channels, engineering, and counterfactual. So let's jump in. Initially, when I kind of first came into this space, I asked the question of why is it not the case that this stuff is being used by everyday people yet? And the answer I got was basically that scalability is important, and this was about a year and a half ago. And there were a handful of problems that needed to be worked on, including sharding. And one of them was state channels. And I basically was wondering, why is it not the case that anyone's really tackling this? Not necessarily as an app-specific technique you can do to make your app go faster, but as a general solution for scaling on Ethereum. Why is it not the case that anyone that wants to build an application can take advantage of this technique to make their application just by default be really fast? I stumbled upon this post, got introduced to the guy that wrote it, Jeff Coleman, and realized a lot of the ideas were there for how you could build state channels into a layer two kind of scaling technique, but not a lot of the implementation had been there yet, and kind of wondered why. After lots of thought and research, we basically realized that this is an opportunity to try and build something great. And so what we did is we tackled it very much with the mindset of, like I mentioned, how do you build a layer two scalability solution using this technique? Generalize enough to allow for arbitrary applications with maximum off-chain interactions without necessarily having to build it as a one-off implementation technique for your particular application. So we started off by writing this paper, which is basically the formal version of the post that Jeff had put on. It goes in a ton of depth of how you can do this. What are the security models going to be thinking about? What are the general parameters that you want to be aiming for? How can you maximally have off-chain interactions using state channels for any application? A very abstract notion, but one that if you can get right, enables an enormously powerful technique to be used. And I'll show you how it's useful. So there's a long paper, but it basically summarizes into some very simple, a very simple idea. And so I'm going to go through it very briefly. So you already know what payment channels are, but just to set up, you're pretty familiar with this technique. You have a blockchain, you put some money into a channel. A balance, B balance, you wait some time, off-chain, Alice and Bob, move basically over some communication protocol. They update some balances between them. You know, we're from version zero all the way up to to end basically. And then whenever they're done, they go back to the chain, they put that latest date on and the balances get paid out. We're familiar with that here. And so that's a payment channel. So what's an app-specific state channel? What's fun for doing? It's a very similar, but what they're doing is that they have arbitrary state. They have different state per application, whether it's roulette or blackjack or whatever they might be playing. And they have this added thing on the chain, which is they have the application logic to handle disputes essentially, or cases where someone's deviating from the protocol and they need to figure out who won the game actually. That's how they get the provable fairness. It was very similar in the payment channel. So that's what you can do with application state, but what is the generalized state channel? And as I mentioned, you have the application logic. But what is the generalized state channel? In a generalized state channel, you have the same setup, blockchain contract. You put some deposit in there, and again, ETH, year C20, whatever it is you want to be using off-chain. But you do this interesting thing. As time goes on, you actually create for yourself, you kind of sign transactions that purport to allocating some subset of that state, the sub-deposit, into what we can call an off-chain application. And you do this in very much the same way in the application-specific state channel, but because you can push it down to the application, agnostic to what's on-chain, you can do it multiple times. So the key benefit is that you can now install an update and uninstall applications, arbitrary applications, that you would say, a rule of game, take that toe, blackjack payment channel, whatever you want, in the same on-chain state channel. And with the same single contract on-chain, you can do multiple applications. That's the key insight of generalized state channels. It's very cool. If you do it this way, then it becomes less of a quick technique for one app. It becomes a generalized scalability solution. It's very powerful. And then disputes, actually, or deviations from the protocol are very similar to the application-specific case. You just take one of those states, whichever one is the one that's being, you need to kind of ensure the fairness of an adjudicate on-chain. You put that on-chain. But the key idea is that off-chain, you're installing an uninstall applications with zero fees, no on-chain transactions, and that's great. So, two FAQs that I always get asked. One, how do you ensure all the sub-deposites add up? Isn't this really complicated? Yes, it's complicated, and that's what warrants, as Jeremy rightly mentioned, a protocol to be defined. You need a protocol for participants of a state channel to speak to each other to say, how do you install an application? How do we uninstall it? What are we saying to each other? What are the specific commitments? And that gets a little bit complicated, so you need a well-specified protocol, which I will get into. And the second thing is, and it's been a bit of misinterpretation, if you've seen the paper, is this notion, don't you need to deploy the contract every time and isn't this absurdly expensive? The answer is no, very similar to Jeremy in practice. Of course, you deploy a contract on-chain that has the rules that are defined in the game ahead of time, but that's a one-time thing for application. We have introduced in the paper a notion of this term that's called counter-factual instantiation, which maybe you've heard, which allows you to do this off-chain, but it's a useful technique for performance and upgradability, but it's not necessarily a must-have. So it's very, very performant in much the same way as an app-specific state channel might be. So great, so very quickly, what is counter-factual and what are we doing about all this? Why is this something we're talking about? Basically, the most important thing is that we are an open-source project. Our goal, our vision, is that these types of applications, like I've mentioned, should be as easy as possible to build. In the future, it should be the case that a developer goes to a hack-a-thon and says, I want to write an application and I want it to be really fast and they should be able to build a great user experience in 36 hours. It should be as simple as possible for that to be the case and so our vision is to get to that. Mission, in terms of what the project's goals are, is to build that framework. We want to make it as easy as possible for this entire community to benefit from this technique that is described. And so we're not a company, we're not any particular business, with any kind of business model behind us. We're an open-source project, trying our best to give something to the community and so that's the key takeaway of the project. So what is encompassed within that? It's three core pieces of infrastructure that basically needed to be implemented and need to be available for people to build using this technique. And they are a minimalist contracts layer. The absolute most bare bones, simple to read, simple to deploy, small ends of code, set of contracts that need to be there, on top of which you can design a protocol that does kind of what I described. A protocol for state channels, you need something that defines how you install applications, how you want to install them, how you update them. And an application library, something that allows developers to interface using this protocol. So you can think very similarly, this kind of looks like the Web 3 stack, in the sense that you have the underlying blockchain, you have the protocol that you're following and you have a theory, I mean you have an application library like Web 3, we're trying to emulate a similar developer experience for layer two. So let's dive into some of the details of how we've approached it and what it looks like. First of all, the on-chain library, the actual contracts layer consists of a very basic on-chain library for conditional transactions. You may have heard the term conditional payments or immediate transfers. Basically the idea here is that you put is the most minimal component for unanimous consent as possible in the chain, a multi-signature wallet. It achieves N of N consensus. And then what we have in addition to that is a very basic way to use that multi-signature wallet to sign conditional transactions. And using kind of the best in-class research from a lot of the people that you're gonna hear, I think after me and I've already spoken, about how you can adjudicate a state channel in a very optimal kind of way. And so we've taken a lot of the best research from all those things and built a simple component to enable this to work on chain. And we've already released all of this. The great thing is it's built to support all of this stuff. Unidirectional payment channels, bidirectional payment channels, N-party, HUB and Spoke, Plasma, E, Ethereum C20, 2121, you name it. The main idea is that we're not assuming any particular type of transaction besides the most primitive unit of transaction on Ethereum to value data. That's all that we're assuming. Which means as time goes on, this framework is agnostic to protocol updates as long as you don't change the idea of a transaction on Ethereum, the protocol will still run. And we can incrementally improve this protocol as Ethereum develops over time without necessarily having to have massive upgrades per EIP, for example. What we've done separately to the generic on-chain components, we've created a very basic state machine-based library. And you can see again from from first presentation, this is kind of what they've landed on too in terms of what's the optimal way of describing applications. State, action, new state. This is the type of way in which we're assuming someone can design their application. And we support this out of the box. And we've also added three very simple methods to enable your blockchain application to kind of benefit from, from basically be easy to define using this framework. So a resolver, something that can take your state and the pre-commitment, the sub-deposit pre-commitment that you've made and figure out what transactions need to be made. A is terminal clause, something that says, is this game over? And I'll show you how all these are relevant in a second. And kind of a turn-taking mechanism which can define, is it a valid update or not? The key point here, four very simple functions that you can implement for arbitrary applications. If you implement them, the framework supports out of the box. So very simple high-level example. A bi-directional payment channel, for example. Basically here, it's the most basic possible state machine. You have one state, and people can just update the version of where you're at with that. In this case, it's an end-party state channel, and in this case, it's just two in the array. All you do is update it, both basic case. So what if you wanted something like more complicated for which there's all kinds of different separate bespoke applications like a unidirectional payment channel? Well, we just write a state machine looks like this. You start in an open state, and as a bit of a context, a unidirectional payment channel is one of the kind where only one, the payments can only be sent in one direction. So A and B, A can send to B, B can't send to A, and the idea is that B is the recipient, and if they wanna just leave, they can instantly leave. So how can you define that? You can define a machine where in the open state, the sender can send, and that's a valid action, and you can get to the point where you are done in a terminal state, which is what I would represent with this orange ring, where if you are the receiver and you call the close action, you can instantly exit. So you define your state machine in this way and you get all of the properties of unidirectional payment channels without having to implement anything different from the generalized framework. Take tacto, a bit more complicated, but it's the same general idea, right? You define what is your state machine? It's the X turn, is it O's turn? X can place an X and he can win, or X can place an X and it can be a draw. You get the idea. And again, you're defining your state in this very simple way. So in designing that framework, in addition to making it very generic and possible to build all kinds of state channel applications using it, we've also spent a significant amount of time on the engineering side to make this as easy as possible for developers to build on top of. And you can see this in kind of the implementation details of some example applications. So I'll show you very quick snippets of some code from a counter application, one where basically you have a counter, you can increment it, you can decrement it, the basic kind of example app. And basically it looks just like this. It's a stateless contract, and there's three slides here I'll go through. There's a stateless contract. You just define what is the structure of your state? And kind of like Jeremy mentioned, it's as simple as this. We actually have a hacky solution to get around the necessity for ABI.D code in the code base right now, but when it comes out that'll be great too. And you just define your state as a struct. And you define the actions that you can use to modify it. And again, this function signature allows you to mimic what a state machine does. You have a simple function, apply action like I mentioned. You take the state, you take the action, you decide what to do about it. It's a very simple control flow. And then there's just very basic implementation. So this is literally the entire contract for a very basic counter app. So the great thing about this, again as Jeremy rightly mentioned, is that state machines encompass arbitrary things that you can run on the EVM. That are basically pure and content functions. There's an aspect of time dimension here, which I think probably one of the future speakers will talk about that, add some complexity. But for things that you can run that are EVM based, this encompasses everything, which is great. And so that's the minimalist contracts layer. On top of that, we've had the device of a protocol for this whole generalized state channel concept. And without going into too much detail, we've essentially done that. This is basically a generic software that clients can run. And it was all possible in that messages that you can receive using channels. And it's designed to be as portable as possible. So this is not like a full node software that we've developed. This is just a basic implementation of a protocol that says different types of messages that someone can send to another to use their on-chain state deposit to install applications and install applications and so on and so forth. And it's very practical. We've tried to make it be the case that there's no unnecessary network overhead. It's A sends to B, they get a response back for all of the protocols in the entire construction. And so it's practical and it can be deployed today. If you want to look at the specifications of the protocol, we have a whole spec stock on the website, along GitHub. And you can dive into there. This is kind of the beginnings of what we hope will become a very good standard for what is the best that you can get for state channels in Ethereum. And eventually it would be nice if we can build on top of this common standard. And hopefully a lot of the research can end up here. That's our goal at least. So finally an application library. And this is basically the thing I mentioned analogous to Web 3. It's an application library that a developer pulls into their app. They simply interact not with their wallet in a way that is kind of through the Web 3 interface but with kind of this counterfactual interface with this layer 2 interface. You do things like update state to your wallet and the wallet with the implementation of the protocol figures out how to interact with its counterparties. And again, this is a little bit abstract but it's this entire full stack suite that proves that the use case is possible. And all of this has been designed in mind to be as easy as possible for a developer. And like I mentioned earlier, we actually run hackathons and so we spend enormous amounts of time with developers trying to understand what is it that will kind of get people caught up. So why? Why is it that we're doing any of these things and what are the kind of values that align us for this? As mentioned earlier, kind of Fatchel's open source project is multiple contributors and I'll get into who they are. But we think this is just plain old open source. We really just want to be able to work with the Ethereum ecosystem, the people that are here and people that are at DevCon and try to just take a lot of the great research that we've talked about over the years and then have, you know, each research posts about make it concrete, arrive at standards, arrive at things that we can agree are kind of best in class research and build on top of that. There's no unnecessary ego and no unnecessary lock-in. It's just a matter of how do we build open standards that are helpful for everybody? And we want to do that as just plain old open source. We don't think there's any necessity for a business or a token. We think that there's just plain old open source. And developer focused, mentioned as a handful of times and you can see through the way that we've designed this. This is meant to be something as easy as possible for developers to use. And we want to drive for compatibility. We want to make it be the case that Ethereum can have down to the best in class state channels protocol before any other chain and that we can do this basically together and be interoperable with each other's software. Great, so who's involved in this? I mentioned it's an open source project. I do want to give kudos to a bunch of people. This is right now, mostly been a collaboration between L4 and Prototypal, a handful of people from each of the teams and a bunch of independent contributors. We've recently even had a whole bunch in the past few weeks that are just ramping up now, all sharing the same general vision of like, let's take all these ideas, have a common place that we can write them down and make something that people can use. So really thanks to everyone that's contributed over the year. And we're also working with some of the best. We've, over the past year, we spent a bunch of time with a lot of great people in this space, Metamask. We've been recently spending a ton of time with trying to figure out practically how are we going to get this implemented in web wallets today. Cellular network, we spent a ton of time with Moe, especially looking at the actual underlying research of how do you build generalized state channels. We're hoping we can arrive at common interfaces over the next little while. PISA, which has done a phenomenal job when they're speaking later about how to do really optimal watch towers with state channels. We're also going to try and fold that in. And Magma as well, a phenomenal kind of state channels engineering team through which a lot of the state channel, state machine based designs have been kind of inspired by. So yeah, if you want to get involved, we have a bunch of code on GitHub. We just released a whole bunch recently as well. The whole, everything I just mentioned is a full implementations of and that we have running. We don't have a big demo environment yet. That's one of our major kind of next goal, but we do have it running locally and you can test it out. And we're actively developing this very fast pace. If you want to chat with us, who are available all the time, you can go to our chat group, counterfactual.com slash chat. We're very friendly. We really just, we want to like try to help out the community as much as possible. So, you know, come in, whatever you want to talk about. And if you want to just learn more about the product in general, check it out, counterfactual.com. And yeah, that's it. Thanks so much. I do have a minute and 20 seconds left. So if there's a question I can take one or I can kind of awkwardly walk off stage. Yeah. What's the like 30 second different explanation between a state channel and a plasma chain? Is it a sub set? Yeah, I had that in the slides. There's a really, first of all, there's a really great talk by the guy who just gave you the microphone, Josh Stark, yesterday called Making Sensitive Layer Two, which gives like the 30 second basic difference. The way I like to describe it is that from a technical standpoint, when state channels, a fixed group of people put state into an on-chain contract and then they agree unanimously off chain. And then at some point, they all go back off, take all that state, put it back on the chain or they stay off chain with plat and it's all off chain the whole time with plasma, a bunch of people put state into a contract and there's two types of people. There's an operator and then there's the users and the operator periodically puts a Merkle proof on the chain that lets the users have finality. So every time the Merkle proof is put on chain, that is the notion of this is now the final state. So there's this periodic checkpointing kind of mechanism. So the main difference is that state channels with instant finality all of the time, plasma, you have a bit of a delay because it's the checkpoint and then technically they're implemented differently but they're both very useful scalability solutions. I'd recommend watching Josh's talk though. Great, all right, thanks.