State Channels
Published in

State Channels

Why is it difficult to use state channels today?

  1. A public API — public or external functions on their contract
  2. Authorization logic — usually by checking msg.sender
  3. Resolution logic — to decide how funds are distributed
  • It’s not clear how the public API should be written since you aren’t signing Ethereum transactions anymore, you’re signing generic state objects
  • The authorization logic requires each user of the state channel to sign an object for each update and verify these signatures using ecrecover
  • The resolution logic is now more complicated by the fact that there is a built-in “challenge” or “dispute” period every time new state is submitted

What can we do to make it easier?

An Example — Tic Tac Toe

An example Tic Tac Toe smart contract written in Solidity.
An example of a state machine for the Tic Tac Toe application. If it is X’s turn, X can take an action to win the game, end the game in a draw, or just place their piece and pass it over to O for their turn.
A Tic Tac Toe application with a single reducer function that handles PLACE_X and PLACE_O actions instead of multiple functions called placeX and placeO. The reducer function “dispatches” the actions to helper functions.
The StateChannel can use the App Logic as a means of determining valid transitions but handle the authorization and resolution logic itself based on information provided to it by the app logic.
  1. What if Bob submits outdated state?
    The contract has to be able to implement a timeout period such that Alice has time to submit newer state than what Bob submits. If the state that Bob submits is provably old, then Bob should be punished.
  2. What if Bob stops responding?
    The contract has to give Alice the ability to submit the latest signed state she has received from Bob in order to get her money out (after the timeout period elapses). In some situations, it might be possible for Alice to “make a move” that progresses the app’s state machine, and so she must be able to use the application’s reducer in that case.
  • Creating a dispute.
    One party submitting the latest signed copy of the state and optionally taking an action on the app that will logically progress the state to the next state.
  • Progressing a dispute.
    One party responding to the dispute from another party by taking an action on the state that has been submitted.
  • Cancelling a dispute.
    Both parties agreeing to cancel the dispute and resume off-chain normally.

Where are the funds stored?

The set of contracts required for a simple application that uses state channels without using counterfactual instantiation, but just using regular contract references.
The same setup as above, but this time the state channel contract and app logic contract are counterfactual — they only ever need to be deployed on-chain in the case of a dispute.
When we use counterfactual, adding and removing applications is free and instant.

Next steps

  • Standardizing research terminology, sharing insights, and following through on other fascinating research problems in state channels and layer 2 scaling.
  • Integrating generalized state channel patterns into existing state channel systems and applications based on off-chain paradigms.
  • Working with web3 frameworks to make off-chain concerns well-known for the future development of their developer APIs.
  • Working with wallet providers to help provide clear protocol specifications and standards around how state channels can exist in their domain.

How can I learn more and contribute?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store