The state of state channels: 2018 edition

In July 2018, I published a market map of the various state channel projects in development. In this post, I will provide an overview of where we are with this technology today and a summary of the projects below. In a nutshell, we’ve come a long way this year. While there are still many technical challenges that need to be addressed, teams are diligently working on solutions that are moving the industry towards wide-spread adoption.

“Wait, what are state channels again?”

To provide an overview, state channels are, at the core, an architecture choice that says “let’s not go to the blockchain if we don’t have to”. They introduce a design that looks at the blockchain as a “judge”, “supreme court”, or “settlement layer”. The main concept is that state channels move transactions “off-chain”. By doing so, state channels minimize the number of transactions that actually have to go “on-chain”. They do this with a comparable level of security to actually being on-chain, since participants could go on-chain whenever they want. More specifically, state channels use the threat of resolving disputes on-chain to create secure and trustless transactions off-chain.

Design choices represent a set of trade-offs. For example, the iPhone and Samsung Galaxy represent two different design choices, the former maximizing usability and UX, and the latter maximizing features. As such, state channels represent a trade-off between speed/finality and liquidity; opening and maintaining a state channel requires capital lock-up for the duration of that channel, but you gain the benefit of instant finality, meaning that as soon as both parties sign a state update, it can be considered final. They also trade-off those benefits for “long-tail risk”; in the low-probability event where everyone wants to close their channels at the same time (e.g. someone discovered a bug which caused a reaction akin to a “run on the bank”), the volume of pending transactions on the underlying blockchain might prevent users from safety recovering their funds. Lastly, state channels also represent “philosophical” trade-offs in consensus. While blockchains have byzantine fault-tolerant consensus models that don’t require input from the user, state channels require unanimous consensus and interactivity (i.e. action from the user).

Because of these trade-offs, state channels inherit properties that make them best suited for certain types of use-cases. State channels are most useful when the participants are going to be exchanging many state updates between each other; while there is an initial cost to creating the channel, state updates inside the channel are free and the cost per state update is amortized across the number of transactions. State channels are only able to be used for applications with a defined set of participants; funds are held in multisignature wallets where only the participants in the state channel are the signers to that multisig. Finally, state channels are best for use-cases that benefit from increased privacy; because everything is happening inside a channel between participants, only the opening and closing transactions must be broadcast publicly and recorded on-chain. In practice, this just means that two machines on the internet are sending messages to each other across TCP/IP.

Put together, many state channel developers see Layer 1 as the Security Layer and Layer 2 as the Scalability Layer. Furthermore, Layer 2 provides lower latency and cost per transaction that would otherwise not be possible beyond a certain level of throughput. with Layer 1 solutions. In summary, I believe that state channels are a readily-accessible solution for developers looking to build internet-scale decentralized applications.


Payment channel networks: many routes, similar destinations

Because there are very few people with whom you regularly transact, most payments have to go to a new person with whom you don’t have a channel. Payment channel networks, such as Bitcoin’s Lightning Network (discussed further below), make this possible by “routing” transactions between nodes who don’t have direct channels.

The main technique for implementing these networks is through the use of “Hashed Timelock Contracts” (HTLCs), however generalized state channels have introduced alternative constructions of “routing” state.

Routing via HTLCs

If Alice has a channel open with Bob, Bob has a channel open with Charlie, and Charlie has a channel open with Dave, it is possible for Alice to route her payment to Dave via Charlie and Bob. To do this without introducing additional trust assumptions, Alice needs to ensure that Bob or Charlie cannot run away with her money. This attack vector is addressed using HTLCs, which follow a multi-step process to complete the transaction.

In this model, Dave generates a pre-image, R, which is a random number, and shares the hash of the pre-image, H, with Alice. Alice then generates an HTLC with Bob that says “I will pay you 1 BTC if you show me the pre-image, R. If you don’t show me R within three days, I will take back my 1 BTC”. Bob then generates a similar HTLC with Charlie, with the difference that it will refund the 1 BTC after two days. Similarly, Charlie generates an HTLC with Dave, also with a shorter refund period.

HTLCs are generated from left to right (A->B->C->D)

Dave will now show the pre-image, R, to Charlie, who will now pay Dave the 1 BTC. Because Charlie now has R, he will show R to Bob, who will then pay Charlie the 1 BTC. Lastly, Bob will show R to Alice to redeem his 1 BTC. In this way, Alice was able to indirectly and securely send a payment to Dave.

R is revealed from right to left (D->C->B->A)

Routing via “Virtual Channels”

Routing payments could be done in an alternative form via a technique known as “virtual channels”, introduced by Perun (more detail later), which use an intermediary that serves as a “virtual payment hub”. Anyone with a payment channel connected to the hub could establish virtual channels between each other. More specifically, if Alice and Bob both have a payment channel open with Ingrid, then Alice and Bob could establish a virtual channel between themselves. Unlike routing payments via HTLCs, Ingrid does not need to be involved in every payment between Alice and Bob. This property reduces latency and costs, and increases privacy.

To open a virtual channel, Alice and Bob essentially need to “lock-up” a set number of coins from their payment channel with Ingrid. The amount of locked coins will become the value of the virtual channel between Alice and Bob. Notice that Ingrid remains financially neutral by mirroring balances, effectively becoming Bob to Alice, and Alice to Bob.

Z(A) and Z(B) become the balances in Alice’s and Bob’s virtual channel (dotted line), respectively.

This technique could be reapplied to increase the length of the channel. Because a virtual channel is an instance of an off-chain contract, increasing the length does not require another transaction on-chain.

Bob becomes the “Ingrid” between Alice and Charlie.

Virtual channels also represent a different business model from channel routing. Lightning Network HTLCs have a “pay-per-payment” fee model since you need to incentivize each intermediary to route the payment. Virtual channels, on the other hand, have a “rent-a-path” fee model. In this model, an intermediary acts as a virtual payment hub that has direct channels with multiple parties. If Ingrid is the intermediary, then Alice and Bob pay Ingrid to keep the channel open for a certain period of time. It’s worth noting that such a model might have better economics for high-volume micropayments.

Routing via “Meta Channels”

This technique, developed by Counterfactual (more on the project below), achieves a similar goal to Perun’s virtual channel network (i.e. participants without a direct channel could interact), but with differences in construction. In the Counterfactual design, Alice & Ingrid, and Ingrid & Bob each have a generalized state channel open, each of which has a payment channel instantiated. Alice and Bob then create a counterfactually instantiated payment channel object owned by themselves, which could be called “O”. Lastly, two proxy payment counterfactual objects are created, one each in the Alice-Ingrid and Ingrid-Bob channels, that have state deposits (a, b) assigned to them, and that observe O.

Suppose the Alice-Bob payment counterfactual object has state (a, b) representing balances of Alice and Bob, respectively. The proxy payment object on the left assigns a to Alice and b to Ingrid, and the proxy payment object on the right assigns a to Ingrid and b to Bob. That way, Ingrid always has a + b assigned to her, remaining financially neutral.

Counterfactual uses the same “assign Alice’s balance to the left and Bob’s balance to the right” to generalize this to intermediary chains of arbitrary length.

While Perun and Counterfactual have introduced novel ways of routing payments across multiple intermediaries, HTLC-based routing is currently the primary implementation on blockchain mainnets. We need to wait and see the effectiveness of these new designs as implementations come to market. For Counterfactual, developers will need to wait for Ethereum’s Constantinople upgrade, which contains the necessary opcode.


Stale state & unavailability griefing

The primary attack vector that state channels face is “stale state griefing”, which occurs when a malicious actor posts an outdated state to the blockchain.

The “challenge period”: a partial solution

Let’s take the case of a state where (Alice: 10 ETH, Bob: 0 ETH). Bob might be incentivized to publish the prior state which is (A: 5 ETH, B:5 ETH). To address this scenario, the closing process for state channels involves a “challenge period”, which gives Alice the chance to post a later state to the chain. In practice, each state update contains a “nonce” that is essentially a counter which is incremented upwards. Alice submitting a state with a higher nonce, that is also signed by Bob, will supersede Bob’s posted state. It will also restart the challenge period timer, giving Bob a chance to submit a newer state.

Introducing third parties to address the “always online” assumption

An issue with the challenge period is the assumption that Alice will be online to submit her state. If Alice is offline or is DDoS’d, she will be unable to post the finalized state and Bob will succeed in cheating Alice out of her money.

The main category of solutions to this issue is to introduce a third party that acts as a safeguard against these scenarios. This means that Alice could hire a third party to submit a later state in the case where she’s offline. Each of these designs has various benefits and drawbacks.

Lightning Network “Monitors” / “Watchtowers”

The “Monitor” was initially designed for the Bitcoin Lightning Network. The concept is to hire full nodes to watch the blockchain for fraudulent transactions. The participant in a channel outsources the monitoring to multiple third parties by sending consolidated transaction data to them. If the Monitor catches the other party trying to cheat, they could publish a “fraud proof” and earn a reward. One issue with this is that there is limited incentive for the Monitor to participate because fraudulent transactions are quite rare and channels are meant to be open for long periods of time. The other issue is that each Monitor has to maintain a full history of the chain, which is not scalable.

Pisa “Custodians”

Pisa is a project which proposes a model with lower storage requirements and additional incentives. In this model, there is a third party called the “Custodian”, which is required to put down a large security deposit to get the job. If the channel participant proves that the Custodian did not do their job correctly, the watchtower loses its deposit. One issue with this design is that it leads to additional centralization, since there is a large collateral requirement for Custodians who want to service multiple channels. Another issue is that this doubles the liquidity cost of maintaining a state channel.

Celer “State Guardian Network”

Celer Network proposes a “State Guardian Network (SGN)”, which has a side chain construct similar to Plasma. Similar to Pisa’s deposit model, State Guardians must stake Celer tokens to participate in the network. When the user goes offline, they submit their state and payment to the SGN. This solves the liquidity problem because it’s staking Celer vs others, and solves the pricing issue by creating a market. One argument against this model is that it introduces additional trust assumptions, which is that users now need to trust the side chain and its actors.

These solutions are relatively early in their development and will require a robust third-party economy to produce the intended effects at scale, which presents a large opportunity for layer 2 service provisioning.

Layer 1 capability limits Layer 2 complexity

State channels are only as good as the underlying blockchain, meaning that an application that is unreasonable to build in Layer 1 will also likely be unreasonable to build in Layer 2. If we take a complex two-person game like battleship and build it on layer 2 state channels, it opens up an attack vector where the cost of disputing state and having the code execute on-chain (e.g. $100) could be more expensive than the initial bet for playing the game (e.g. $10). Patrick McCorry summarizes this dilemma with the following question:

If the player is about to win a $10 bet, but the counterparty has stopped responding in the channel, then is it worthwhile for the player to turn off the channel, complete the dispute process, re-activate the application and win the bet via the blockchain if this process costs $100?

In Patrick’s experiment of building a two-person battleship game on Ethereum state channels, the cost of executing the smart contract on-chain was ~12 million gas, which is more than could fit inside a block (currently ~7 million)!

For Ethereum specifically, off-chain computation is still limited by the EVM. Web Assembly (WASM) will allow for the execution of off-chain contracts directly within the end-users’ browser, which will improve execution speed, enable interoperability between other WASM-based blockchains, and reduce reliance on Infura, which is increasingly becoming a centralization risk for the ecosystem.


Applications: Gaming, gambling, and micropayments

The majority of payment channel networks will be used for, well, payments. P2P is the most prevalent use-case, but several projects, such as Althea Mesh and Machinomy, are tackling M2M payments as well. From a B2C perspective, virtual payment channel hubs are being used as a solution for content micropayments, such as PopChest for videos and SpankChain for adult entertainment.

Many state channel infrastructure projects, such as Connext, Kava, and Sprites, are primarily being used to improve the performance and UX of payment channel networks. That said, state channels have also emerged as a popular scalability solution for gaming and gambling use-cases, with projects like FunFair, Finality Labs, and Horizon Games implementing the technology.

As projects increase their focus on user adoption, I think we will continue to see the proliferation of two-party games built on state channels.

Firmly on the road to user adoption

Projects are continuing to #BUIDL. Many have launched on mainnet in 2018, and the others are expecting to do the same within the next year. Here is a more detailed summary of the projects building or incorporating state channel technology:

Direct Payment Channels

SpankChain

SpankChain is an adult entertainment ecosystem powered by blockchain technology. The project is one of the earliest adopters and developers of state channel technology. SpankChain raised $6.5 million in their ICO in November 2017 and was the first production implementation of Machinomy’s unidirectional payment channels on the Ethereum mainnet in April 2018. It also released, in partnership with Finality Labs, a generalized state channels proof-of-concept in March 2018. It also launched, in partnership with Connext and Kyokan, the first non-custodial payment hub on mainnet in September 2018.

Stack

Stack is a cryptocurrency that uses state channels for real-time point-of-sale transactions. To make a purchase, their ERC-20 token (STK), provides access to a payment channel between a crypto wallet (i.e. users) and third-party liquidity provider (i.e. Stack’s own wallet), which will then convert and pay the merchant in fiat via existing payment rails. It’s also working on “multi-token channels”, which allows an existing payment channel to create “sub-channels” that support additional ERC-20 tokens. The project raised $17mn in their ICO in December 2017 and is currently on the Ethereum testnet.

Commonwealth Crypto

Commonwealth Crypto is building a way of doing cross-chain atomic swaps at centralized cryptocurrency exchanges. They also allow traders to maintain custody of their coins while trading via “escrow-backed trading”, which is implemented through the use of unidirectional payment channels. The project started in early 2017 and closed a $1.5mn seed round later that year.

PopChest

Popchest is an Ethereum-based video distribution platform (think “YouTube on the blockchain”) using micropayments and token incentives instead of relying on advertising and paid subscriptions. Micropayments are currently implemented via Machinomy’s open sourced unidirectional payment channels.

Cent

Cent is an Ethereum-based social network where users could earn money by sharing content. The project implemented payment channels within their “Cent Wallet”, allowing users to deposit funds into an address and perform actions, such as seeding and tipping content, off-chain. The project launched in 2017 and implemented payment channels in October 2018.

Payment Channel Networks

Lightning Labs

Lightning Labs is the company behind Bitcoin’s Lightning Network, a bidirectional, HTLC-based payment channel network. The project was founded in 2016 has been on the Bitcoin mainnet since May 2018, when it raised a $2.5 million seed round. As of December 2018, the network has over 4,000 nodes and 12,000 payment channels. The protocol continues to explore innovative upgrades, such as multi-party payment channels based on the idea of “channel factories”.

Raiden Network

Raiden Network is Ethereum’s version of Bitcoin’s Lightning Network. It is a bidirectional, HTLC-based payment channel network. The main difference is that Raiden uses a token to pay for services, such as path finding or channel monitoring, within the network. The project raised $33 million in November 2017 and launched its mainnet in December 2018.

Trinity Network

Trinity Network is NEO’s version of Raiden, though the project has started developing on Ethereum and Zilliqa as well. It is a HTLC-based payment channel network with a native token that’s used to pay for fees and services. Trinity raised $20 million in its ICO in January 2018, and is currently in testnet.

Liquidity Network

Liquidity Network is a payment channel network that developed “NOCUST” hubs, which are non-custodial payment hubs built on a Plasma-like construction. NOCUST is similar to Plasma in that it regularly commits state on-chain, but different in that it uses an account model (whereas Plasma uses a UTXO model). Members of a payment hub could pay any other member with their allocated funds, which are also accessible to all members of the hub. This enhances liquidity because the funds are not locked between only those two users. The project raised $23 million in their ICO and has been active on the Ethereum mainnet since June 2018.

Althea Mesh

Althea Mesh is a project that aims to replace centralized ISPs with a competitive market of individuals and businesses participating in one decentralized network. Each node on the network establishes payment channels with each of its neighbors, allowing users to send and receive Ethereum micropayments for forwarding packets. The project started in mid-2017 and currently has two small live mesh networks in Colombia and Oregon.

Teechain

Teechain is a payment channel network that’s built using Trusted Execution Environments (TEEs), specifically Intel SGX hardware enclaves. At the cost of introducing an additional trust assumption (i.e. trusted hardware), this design allows for higher throughput, asynchronous blockchain access, faster channel creation, and lower collateral costs relative to non-hardware-based approaches. The project published their whitepaper in July 2017 and are currently live on the Bitcoin mainnet.

Kava

Kava is leveraging the work of Cosmos and Interledger to build a fast-finality blockchain for interoperable payment channel networks. Their initial implementation uses unidirectional payment channels, which can be opened by a sender and closed immediately by the receiver, or by the sender subject to a dispute period. The project started in mid-2017 and is currently in public testnet.

Sprites

Sprites is a research paper that proposes a payment network in which payment channels are derived from a more general state channel construction. The paper claims several improvements over Lightning Network and Raiden, specifically around reduced collateral costs, improved throughput, and guaranteed constant time resolution for multi-hop payments. Enuma Technologies received a $200K Ethereum Foundation grant to implement their state channel construction.

Direct State Channels

FunFair

FunFair, a casino on the blockchain, is one of the earliest projects implementing state channel technology. It uses “Fate Channels”, which are state channels with the added ability to verify a progressive reveal scheme by both parties, advancing a deterministic (“fated”) but unpredictable sequence of random numbers. The project raised $26 million in their ICO in June 2017 and has been on mainnet since May 2018.

Aeternity

Aeternity is a smart contract platform (i.e. a new blockchain) with native support for two-party generalized state channels. It also introduces the concept of a “snapshot”, which addresses the data unavailability problem by allowing a recent off-chain state to be recorded on-chain. After its inclusion, the channel cannot be closed using an older state than the one provided in the snapshot. The project raised $24 million in June 2017 and launched their mainnet in December 2018.

Magmo

Magmo is a team of researchers working on state channels for Ethereum. They have developed the “Force-Move Games” framework, which is a (not fully general) state channel framework designed to support turn-based games whose moves don’t depend on time or data that is external to the channel (e.g. chess, rock-paper-scissors). Magmo is supported by the Ethereum Foundation and L4, and collaborates closely with the Counterfactual team.

State Channel Networks

Connext

Connext is a layer two scaling platform that uses an implementation of Perun’s virtual channels to offer payment hub infrastructure for Ethereum projects. Within a Connext Hub, users can trustlessly pay any other user of the Hub without needing to pay gas or wait for block confirmation. The project’s first hub went live on mainnet in September 2018, and the team recently received, together with Kyokan and SpankChain, a $420K Ethereum Foundation grant to develop and release an open-source SDK for their non-custodial payment channel hub solution. ​​

Celer Network

Celer Network is a blockchain-agnostic off-chain scaling platform with incentive-aligned cryptoeconomics and a layered architecture. It’s stack consists of “cChannel”, a generalized state channel and sidechain suite that supports generic off-chain state transitions, “cRoute”, a high throughput routing algorithm, and “cOS”, a development framework and runtime for off-chain enabled applications, as well as “cEconomy”, their cryptoeconomic model that provides network effects, stable liquidity, and high availability for the off-chain ecosystem. Celer raised $30mn in their token pre-sale and has launched its testnet on October 2018.

Perun Network

Perun Network is a framework that supports off-chain protocols for simple payments and generic smart contract off-chain execution. The project has released whitepapers and Open Source implementations for their Virtual Payment Channel Hubs and Generic State Channel Networks. It is currently an academic project developed jointly by the TU Darmstadt (Germany) and the University of Warsaw (Poland). It is partly funded by the German Research Foundation and the Polish National Science Center.

Generalized State Channels

Counterfactual

Counterfactual is building a generalized framework for native state channels integration in Ethereum-based decentralized applications. The framework consists of a library for off-chain applications, a generalized state channels protocol, and a set of Ethereum smart contracts. It is an Open Source project with contributors from L4, a fund and “incubator” space in Toronto, Prototypal, an application development company, and individuals from academia and industry. Both L4 and Prototypal have received Ethereum Foundation grants ($1.5 million and $375K, respectively) for state channel research and development.

Finality Labs

Finality Labs is an organization focusing on the research and development of distributed gaming systems. The team released a framework called Set-Payment channels, which is a variant of Perun that’s optimized for human interactions (e.g. tipping) in a payment channel facilitated by a hub. They’re also working on a protocol which combines state channels, plasma, and TrueBit-like verification to handle virtual channels containing arbitrarily complex state and computations outside of the bounds of Ethereum’s gas limits. The team also recently received a $250K grant from the Ethereum Foundation to develop Forward-Time Locked Contracts (FTLC), an alteration of the Hashed-Timelocked-Contracts deployed to the Lightning and Raiden network, which could enhance the user experience of payment channels by allowing an online party to initiate and complete a payment to an offline party.

Machinomy

Machinomy is a project founded by Sergey Ukustov that has developed a micropayments SDK for Ethereum that’s based on unidirectional payment channels, as well as a generalized state channel framework in March 2018. The team is targeting use-cases around machine-to-machine micropayments, such as real-time microinsurance and autonomous vehicle & appliance payments. Their open source frameworks are used by various projects in the space.

Fuel Games

Fuel Games is the studio behind Gods Unchained, a blockchain-based collectible card game inspired by Hearthstone and Magic the Gathering. They’re developing a generalized state channels framework (not yet open soure), called “Ansible Channels”, which is designed for high-throughput games on Ethereum. The project raised $2.4 million in seed funding in mid-2018 and is planning a mainnet launch in early 2019.