This page is still under construction

Although the idea for payment channels has been around since at least 2011, and the idea for generalising blockchains to support arbitrary operations goes back to 2013, surprisingly little progress has been made since then on generalising the payment channel concept to support arbitrary state updates between a fixed set of parties. One of the main reasons for this has been the lack of a clear, understandable abstraction to clearly delineate what can be done and how.

This article is an overview of a generalised state channels approach developed at Ledger Labs from 2015-2016. The approach is partially implemented on Ethereum by the Toy State Channels project, although that project is not yet fully compliant with the finer details of this abstraction. Where this wiki differs in its descriptions from the functionality expressed there, it will usually be the case that the wiki describes the preferred method or the more general approach.

Here are the properties we would like in a generalised state channel design:

• Minimises on-chain storage and operations
• Supports high degrees of performance
• Secure, trust free design
• Allows composability of channels
• Support for arbitrary parallel subchannels (i.e. closing out one operation while continuing another without interruption)
• Creation of new subchannel types without any on-chain operation
• Support for privacy-preserving operations and techniques
• State and/or number of responses does not needlessly balloon over time (which would present a DoS vector)
• On-chain component(s) can remain unchanged for year-like timescales

We propose an abstraction that is hierarchical and versioned, allowing support for both subchannel parallelism and efficient revocation of abrogated state to eliminate DoS vectors. Using a Unanimous Consent object as our primary on-chain contract, we rely extensively on counterfactual instantiation in order to minimise on chain operations.

This abstraction is implemented in two primary bodies of code: a set of blockchain smart contracts and a corpus of local client code that plays a specifically prescribed "correct strategy" over the set of (largely counterfactual) contracts. The abstraction is modular and allows additional subchannel types to be created and added independently. Subchannel modules likewise consist of one or more blockchain smart contracts and the locally runnable code that plays a prescribed correct strategy over the (primarily counterfactual) contracts.

The architecture of blockchain contracts contained in our abstraction is summarised in the following diagram:

Insert diagram

Note that the scope of this abstraction does not intend to encompass the network communications, routing, pathfinding, etc. which would be involved in a larger state channel network such as Raiden.

To be completed