scaling.tex

\section{Scaling with state channels}
\label{sect:channels}

Conceptually one can regard a state channel as an agreement between
two parties, further called \textit{participants}, to build a chain of
state changes just between themselves.
Communication happens peer to peer with the blockchain acting as the ultimate
source of truth.
The lifecycle of a state channel is defined by two different state-machines
tracking the off- and on-chain state.

Opening a channel involves two participants agreeing on and then posting a
mutually authenticated channel create transaction on-chain. This transaction
specifies the involved parties' on-chain accounts, amount of coins they want to
lock in the channel and hash of the initial state.

In case neither party want to dispute any operations executed in the channel,
all that ends up on chain are exactly just amounts, accounts and a state hash.
This makes state channels not just a possible throughput but also a privacy
improvement.

\subsection{Off-chain}

Anything happening off-chain is not part of consensus and thus, at least in
theory, it is completely irrelevant what the participants do off-chain as long
as they can agree on the on-chain transactions.

In practice, the current implementation is a fairly complex finite state
machine that needs to deal with constant disconnects and all the other problems
of distributed computation. To be able to re-use as much logic as possible, the
off-chain logic closely resembles what would happen on-chain. Participants
exchange transactions modifying the available state trees, for example smart
contract interactions.
The actual consensus between the participants is established via a simple
two-phase commit protocol instead of Bitcoin-NG.
By default, there are no transaction or gas costs involved\footnote{In a state
channel participants can agree to have a kind of transaction cost, but it
is not the default setup} and most notably transactions are confirmed as
quickly as both parties can sign them. Confirmation time can therefore be
reduced to milliseconds, significantly increasing throughput compared to
on-chain.

\subsection{On-chain}

A state channel requires both parties to sign each state to make
sure the state is agreed upon. Typically a state channel can be closed
under mutual agreement and then a closing transaction is used to
re-distribute and return the reserved balances to the on-chain
accounts. Another way to extract reserved funds from a state channel
is to mutually agree upon a withdrawal from the channel to an account of
one of the parties.

But there might be disputes. For example, a customer
could decide not to cancel a subscription, but keep an empty account
in the state channel forever. This is disadvantageous for the shop,
because it cannot extract the funds from the already paid coffee in
mutual agreement. For this reason, there is a solo close transaction,
a way for one party to close the channel on-chain and use the last
signed and agreed state as a proof on how the funds should be divided.

Dealing with disputes is a considerable part of the logic and
implementation of state channels. This becomes even more evident in
the context of using contracts in a channel. A contract may be build
in such a way that it re-distributes balances after a certain state has
been reached. Imagine s tic-tac-toe game contract, where the funds are
re-distributed only after one party has won. It could then be beneficial for a
party to quit the game when loosing and solo close, or to simply refuse to sign
the last transaction.

Clearly, there are a plethora of scenarios in which one can try to
cheat. One could buy a coffee off-chain and at the same time solo
close the channel on-chain. That would mean a free coffee. Therefore,
funds are not immediately returned after a solo close, but kept for a
certain period, called a \textit{lock period}. During this period the
other party can post a transaction to refute this claim and show a
later state obtained by a mutually signed transaction (the one after
buying the additional coffee). Which then again could possibly be
refuted, etc.

Quitting when one expects to lose
harms the other party, because there is no next state that is more
beneficial than the initial state. For this purpose the other party
can then force progress the contract and move to the winning
state. That is, the party can perform a contract call on-chain and show that it
ends up in state that can be claimed the actual final state for which
the channel should be closed. This force progress requires more than
just the state hash. Here enough of the state has to be revealed such that a
miner can execute the next step in the contract.

Finally, it is important to keep in mind that just like when interacting with
smart contracts there is always the possibility of losing all deposited coins
to a maliciously crafted contract inside a channel.