State Channels for Dummies: Part 2
App-Specific State Channels
Note: I have decided to change the name of this series to focus on State Channels instead of Counterfactual so that we would be able to cover all of the work being done in this space without conflating the two ideas.
Before we get started, if you have not already read my previous article — Counterfactual for Dummies: Part 1 — Payment Channels, you should definitely give it a look over as we’re going to be building on what we learned there.
If you’re more technical and would like an example of a payment channel in code, you’re in luck! This past weekend I wrote a simple payment channel that you can download and run locally (it even has tests!) — it’s a very straightforward implementation that lets you create payment channels between you and someone else using the Ethereum blockchain. I am also working on an web application right now that integrates this with Metamask and will be releasing that shortly — you can find that code here, for now.
On to the business at hand — today, we’re going to be discussing application-specific state channels. With this kind of state channel, we can allow people to engage in turn-based systems (like games) completely off-chain and resolve payments (bets) based on the outcome of those games on-chain. One example of this would be a game of chess where two people put up 5 ETH and the winner is awarded 10 ETH.
Application-Specific State Channels
Before we get into the technicals, let’s run through an example of an application-specific state channel with the example of two people playing Connect Four.
If you haven’t played Connect Four before or are unfamiliar with the rules, the game is effectively a grid that two players take turns filling up with circular pieces of their respective color. The goal of the game is to get four of your pieces in a row either horizontally, diagonally, or vertically. If you notice here, the boy in the picture is about the accomplish this goal.
Side Note: If you’re really picky, you’ll notice that it makes no sense that the girl did not win her last turn — leave me a comment if you can refute this, please.
So, you can imagine two people playing Connect Four for money (brings me back to elementary school) — but what is to stop one of the two from walking away to prevent the loss of their bet? This is where an ‘adjudicator’ (judge) comes in — a judge serves the following duties in this scenario:
- Holding on to the funds for the duration of the game
- Serving as the source of truth regarding the rules of the game to resolve disputes between the players (Ex: Cheating, Stalling)
- Distributing the funds appropriately in the case of a win or draw
Once the judge has been decided, he / she will hold on to the funds for the duration of the game and oversee its execution. If at any time, one of the players feels like the other is cheating or stalling gameplay, they can pay a small fee to appeal to the judge and be rewarded the total pool funds in the case that they are found to be correct — if incorrect, the game continues. When one of the players sees that they or the other player has won, they can ask the judge to verify and the judge will remit payment to both players.
This is effectively how an application-specific state channel works — the judge is a smart contract that understands the rules of the game and will remit payment based on the outcome of the board that is presented to him (by rewarding the winner, punishing the cheater, or declaring a tie). This setup would look like the following:
So, in the same fashion as before (referring to the previous article) where both parties were agreeing to the total amount of ETH they each had in the payment channel, now they are agreeing to the state of the game each time someone makes a move. We can see in the above example that Alice has won the game, but Bob is refusing to sign the transaction to prevent her from submitting the winning state to the judge — this is referred to as ‘griefing’.
Instead, Bob submits an earlier state to the judge and claims that Alice is stalling the game. Alice is then allowed to refute this during a ‘challenge period’ where she submits the newest state that they had both signed (Nonce 29) to show the last place that they were in agreement. This would then open another challenge period for submitting a newer state.
Note: Nonces serve as sequence numbers for state and allow the judge to determine if some state is newer or older than one previously submitted.
At this point, if Bob does not sign the off-chain transaction and submit it, he will still lose his ETH to Alice. So, in this case, Bob is not only losing his bet, but he is also losing the fee he paid to appeal to the judge when griefing Alice.
Here is an example of how that scenario would play out:
Now, when the challenge period expires, the judge smart contract will look at the state and pay out based on the rules it has stored on it to apply to the state. In this case, Bob did not respond to the dispute within two minutes and there was no ‘Connect Four’ in the submitted state, so all the ETH is awarded to Alice (Rule 3). But, if Bob had signed the last state where Alice had won, the smart contract would have recognized the ‘Connect Four’ and awarded all ETH to Alice (Rule 1).
So, in summary — application-specific state channels are basically where the players agree to and codify the rules of the application in a smart contract before using it. The rules of the application must also account for the cases where one player is being non-cooperative and how to deal with that as well. With this sort of framework, we can build games that can be played off-chain to achieve privacy, instant finality, and lower cost — all while being able to award people on-chain. Cool, right?
Who is Working on This?
A great example of some of the work being done here would be the Force-Move Games Framework that Tom Close and his team are working on at Magmo. It very closely adheres to the specification that I’ve outlined above, but is modular and extendable in such a way to easily enable the development of various kinds of turn-based games.
More on Tom Close and the Force-Move Framework:
- Introduction to the Force-Move Games Framework
- Overview of the Force-Move Games Framework
- The Whitepaper
- The Code
Part 3: Hub-and-Spoke Payment Channels
In my next post, I’m going to be delving into the Hub-and-Spoke payment channels that the team at Connext have been working on which enable high throughput conditional payments for blockchain applications. Their implementation will be live in production soon on the SpankChain network
Contributing and LearnChannels.org
If you have any projects leveraging state channels, I’d love to see your implementation and how you’re approaching things. A number of companies in the space are working to put forth a group of standards and learning materials for docs.learnchannels.org (now live)— which will serve as the state channels version of learnplasma.org
Contact / Want to Learn More?
So, if you’d like to learn more about state channels or second-layer scaling solutions, feel free to contact any of the companies listed in this post — Connext, Magmo, Spankchain, Counterfactual, or myself through Twitter or LinkedIn.
Spam the Clap Button (>30x) and Share
If there’s something about this that I can improve, please don’t hesitate to let me know in the comments section, here. Lastly, if you’ve gained something from this article, I am but a social media noob and would greatly appreciate you sharing this to your network. Here’s the link to do so:
https://medium.com/@eolszewski/state-channel-for-dummies-part-2-2ffef52220eb
Special thanks to Steven McKie and Alison Emily for putting me in touch with their networks to hear what companies in the space are working on.
