Thread by @jbrukh

(State channel rant.) An explainer on the exciting developments blockchain is heading for with *state channels* and *generalized state channels.*

I’ll try to keep this mostly non-technical but it is a technical topic, alas. . .

First, state channels are a “Layer 2” technology. Layer 1 is the blockchain — txs are relatively slow and expensive and require consensus and fees. Layer 2 is an “off-chain” layer which can be settled or “taken” on-chain; it doesn’t require consensus and can be very fast.

[Aside: there are only two layers we actually understand fairly well right now — Layer 1 and 2. If someone tries to sell you Layer 3 or Layer 0, caveat emptor.]

Why do we need this?

Because blockchains don’t scale & this is a strategy for much higher tx throughput using blockchains only as a settlement layer in a large class of use cases.

But most importantly: off-chain throughput & lack of fees create *much better user experience.*

So what is a state channel?

It’s a smart contract where two parties deposit collateral; next, they can pass around signed txs (the “state”) without actually putting them on a blockchain. It’s way cheaper and faster. Eventually, the channel is closed and settled on-chain.

In Bitcoin, this is known as payment channels (or lightning networks) and it applies to payments. On Ethereum, txs are smart contract executions and mutation of state.

So for example, we might create a contract which plays checkers. We’ll open a state channel to manipulate the state of the game off-chain, and when we settle on-chain the winner will get a payment.

State channels massively improve privacy. If we have a channel open via an on-chain contract, our off-chain txs are not visible to the public blockchain.

However, there are some limitations of state channels. For one, I have to open a channel (using an on-chain tx) for every kind of specialized state channel — checkers or chess, for example.

Another limitation is that all parties in a state channel must be known ahead of time. For example, I wouldn’t be able to offer a bounty in a state channel as its future recipient is not known.

Finally, state channels have inefficiency conditions. Suppose we’re playing a state channel chess game, and I purposefully stop moving. You’ll then have to force me on-chain in order to enforce a timeout, but. . .

. . .that means I can arbitrarily force you on-chain and make your state channel interaction much more expensive. (Ouch.)

Now on to generalized state channels.

In generalized state channels, we still want to not have to set up a new specialized state channel for each game of chess or checkers. We want to be able to instantiate multiple, possibly related smart contracts *off-chain*. This way, you need not have specialized state channels.

This is where we enter the world of the “counterfactual”.

The term refers to operations that you perform “counter to the fact that” they aren’t actually on a blockchain. You’re simulating the behavior of a smart contract as if it *were* on-chain.

For example. “Counterfactual instantiation” refers to the idea of instantiating a smart contract in a state channel.

There’s only one problem: to interact with a smart contract one needs an address — but off-chain contracts don’t have one!

So counterfactual instantiation solves this with mappings which essentially give off-chain contracts temporary addresses. If there is a dispute, then those contracts are taken on-chain and state is replayed through them with on-chain addresses.

All of this is really cool! Here are some reasons why. . .

For a huge subset of use cases, generalized state channels are sufficient to implement them. Suddenly you can implement high quality (i.e. fast & feeless) user experiences while getting beyond the scalability bottleneck of today’s blockchains.

Generalized state channels essentially *absolutely minimize the number of on-chain transactions* required for applications. You’re playing with a bunch of virtual contracts whose force and trustlessness are backed by the *threat* of being taken on-chain.

(The end.)