Scaling Through Off-Chain Protocols

Another line of proposals from both academic and industry consider off-chain so- lutions that work on the so called second layer. In contrast to first layer solutions,

they aim to increase transaction throughput of existing cryptocurrencies without changing their consensus protocol. They rely on optimistic protocol execution where parties first try to agree without the blockchain and only rely on this ex- pensive and slow component in case someone disagrees. This approach makes off-chain protocols directly compatible to current existing systems. The main idea that these solutions have in common is that a large portion of (transaction) data is processed off-chain between users and are not sent to the blockchain. In contrast to the overall mining network there is no trust assumption on the users, which means they could potentially deviate from the protocol. Therefore second layer solutions use the underlying blockchain (also called parent chain) to secure the user funds during the off-chain phase. While we give a high level overview of existing schemes here, we refer the reader to [103] and [93] for a full overview on existing off-chain proposals.

Payment Channels. The most prominent off-chain solution approach to increase the transaction throughput in blockchain technology is given by payment channels, which allow users to send many transactions off-chain and only commit the final

distribution of coins to the parent chain. The first proposal for payment channels was made by Spilman and Hearn [176, 96] who proposed payment channels on Bitcoin as early as 2011 [95]. They construct a unidirectional payment channel using a Bitcoin transaction that can either be spent by the issuer after a timeout

t or by two signatures of both the issuer and the recipient of a payment. This

technique allowed the issuer to promise increasing shares of the locked money to the recipient (by sending his signature). The recipient would eventually send the latest statement, which represents all accumulated shares to the blockchain and append both his own and the issuers’ signature. The timeout t prevents that the

issuers’ money is locked forever in the channel.

More advanced proposals [61, 161] build bidirectional channels, which allow two users to re-use locked coins off-chain. Bidirectional channels require that channel updates invalidate older channel distributions such that users cannot send outdated states to the parent chain and get more coins than they deserve. In Bitcoin, this is done with refund transactions. Whenever a party proposes a state update, it will ask the channel partner to sign a refund transaction for the previous state, which will make it impossible to collect the coins on-chain from it (in time). In Ethereum, bidirectional channels can be implemented easier by using version numbers or counters [148, 165].

Any channel lifetime can be separated into three distinct phases. During the

opening or funding phase both players commit their funds on-chain to a multi-

signature funding transaction or smart contract. When all funds are locked, the channel is considered to be open. If Alice locks cAlice and Bob cBob, the initial

channel balance reflects this distribution. In order to send a payment, the parties update their channel balance and confirm it with their digital signature. For example, if Alice wants to sendqcoins to Bob, she updates the channel balance to cAlice−qandcBob+q. Then she signs the new channel balance and sends it and her

signature to Bob. If he also sends his signature to Alice, the update concludes, and both parties have the guarantee that they can enforce the newly updated balance on the blockchain (if they must).

The security that channels offer is that any fund distribution and state that both parties agreed on during the off-chain phase can be enforced on the blockchain within some predefined absolute or relative time period if at least one of the channel participants is online and reactive. If the channel should be closed or if one party notices misbehavior, it sends the latest (signed) channel balance to the blockchain. Then the channel partner will have a predefined time to react and send his own latest version or invalidate any outdated version. After this timeout, the channel

is closed, and the funds are paid out.

Payment channels offer high scalability for many payments between two parties. As long as neither of them aborts from the protocol or closes the channel, they can send transactions off-chain, without additional delays or fees. The parties can only move the money, which is locked on the parent chain, which means they might have to continue on-chain or reopen the channel if a party has insufficient funds for the desired payment.

State Channels. Most literature focuses on payment channels, but some con- structions also allow the extension of state channels [148, 71, 56, 86]. They allow a set of parties to execute complex smart contracts off-chain. As long as all parties are honest and agree on the state transitions, the blockchain is contacted only during funding and closing. The update, i.e., the proposal of a new state of a channel contract, is performed off-chain. However, once parties start to disagree, they have to resolve their dispute on-chain and perform the contract evaluation via the blockchain. This is an additional step, which is not necessary in payment channels.

The opening of a state channel works analogous to payment channels. Once the channel is open and funded, the channel state can be updated, which means users can send transactions to each other. This step, often called state transition [93, 56], is executed off-chain. Again, the closing phase requires on-chain interaction by at least one of the players and ensures that the latest update (the laststate) is

enforced on-chain. While in the optimistic case when all parties are honest, state channels are very efficient, a potentially heavy computation might need to be done on-chain in case of disagreement. Just as payment channels, state channels need to provide mechanisms that allow all channel participants to enforce the off-chain state and prevent that money is locked forever.

Additional Works on Payment Channels. Some channel constructions also al- low routing of transactions in so-called channel networks [161, 148, 135, 136]. We give a detailed overview of channel network proposals in 4.1.2. Other propos- als [148, 68, 56, 35] extend channels to support n parties instead of just two. We

will discuss this extension in more detail in Section 4.7.

Payment channels require, that channel participants continuously need to watch the blockchain, in case a malicious user tries to close the channel with an outdated state. In particular, this requires that channel participants are online and have a running node of the underlying blockchain. One factor that influences this problem

is the closing timeout, which says how much time some party has to react to a proposed channel closing. If this parameter is high, e.g., one day, parties only need to check the blockchain for channel-related messages roughly once every 24 hours, but at the same time, this means a channel closing might take one day to finish. A more practical solution for the always online requirement is provided by watchtower services [141, 11, 110]. Users send their latest state to watchtowers before they go off-line and trust the watchtower to complain on their behalf. Arbitrum. The disadvantage of state channels, i.e., the potentially heavy on- chain execution in case of dispute, is addressed by the Arbitrum proposal [105]. Every smart contract, which Arbitrum models as a Virtual Machine (VM), to be executed off-chain has a set of manager parties responsible for correct VM execution. As long as managers reach consensus on the VM state transitions, execution progresses off-chain in a similar fashion as state channels. But, in case of dispute, managers do not perform the VM state transition on-chain. Instead, one manager can propose the next VM state, which other managers can challenge. If the newly posted state is challenged, the proposer and the challenger run an interactive protocol via the blockchain, so-called bisection protocol, in which one

disputable computation step is eventually identified and whose correct execution is verified on-chain. Hence, instead of executing the entire state transition on-chain (which might potentially require a lot of time/space), only one computation step of the state transition has to be performed on-chain in addition to the bisection protocol. The Arbitrum protocol works under the assumption that at least one manager of the VM is honest and challenges false states if other managers post them. Since the blockchain interaction during the bisection protocol is rather expensive, Arbitrum uses monetary incentives to motivate managers to behave honestly and follow the protocol.

TrueBit. Another solution that supports off-chain execution of smart contracts using incentive verification is TrueBit [177]. For each off-chain execution, the TrueBit system selects (randomly) one party, called the solver, that is responsible

for performing the state transition and inform all other parties about the new contract state. The TrueBit system incentives parties to become so-called verifiers and check the correctness of the computation performed by the solver. In case they detect misbehavior, they are supposed to challenge the solver on the blockchain and run a verification game, which works similarly to the bisection protocol of

least one honest verifier that correctly performs all the validations and challenges malicious solvers. In contrast to Arbitrum, all inputs and the contract state are inherently public even in the optimistic case when everyone is honest.

Commit Chains. Another off-chain construction relies on a central but untrusted operator, who collects all payments or state updates off-chain and computes a new off-chain state. This is done once every epoch, and then a short commitment to this new state is submitted to the blockchain. These proposals are sometimes called

commit chains and come in different varieties [111, 160]. Commit chains were

designed to reduce the high collateral costs that exists for other off-chain solutions, e.g., for payment channel networks. But an essential distinction between commit chains and channels is the finality of the off-chain transactions. If a user proposes an off-chain state change in a channel and the other channel participants sign it, this change is considered final or valid. This means the user has the guarantee that he can enforce it on-chain. In commit chain scenarios, on the other hand, any proposed change is only final after the operator sends a commitment to the blockchain (at the end of an epoch).

The first proposal for a commit chain was called Plasma, initially introduced by Poon and Buterin [160]. Nowadays, there exists a whole family of plasma protocols4 _{Plasma chains are built on top of the Ethereum blockchain and have}

their own operator who is responsible for validating off-chain plasma transactions. In regular intervals, he posts a short commitment about the current state of the Plasma chain to a smart contract on the Ethereum blockchain. Additionally, he informs all users about the full, or the relevant parts of the state. The regular commitments are in the form of Merkle tree roots over the whole state of the plasma chain, and provide checkpoints of the Plasma chain to the users. As long as the user can verify his inputs were included in the root, he knows that his inputs were processed. In case the operator cheats, the plasma user can at least enforce the state of the latest checkpoint in the plasma smart contract, by providing that state and a Merkle tree path to the root.

The plasma protocol promises that parties can exit the Plasma chain with all their funds. A recent work analyses the limitations of commit chain proposals [70] and identifies a significant efficiency trade-off of current proposals. If the operator is caught cheating, either a so-called mass exit can occur where all honest parties simultaneously leave the system, or an honest party is forced to send lots of data

4_{An overview of plasma proposals can be found at}

https://ethresear.ch/t/ plasma-world-map-the-hitchhiker-s-guide-to-the-plasma/4333.

to the blockchain to prove the latest state is valid. Both scenarios can lead to a high transaction load on the blockchain and to very high fees for honest parties.

While the original goal of Plasma [160] was to support arbitrary complex smart contracts, to the best of our knowledge, there is no formally specified protocol yet that would achieve this goal securely (there currently exist multiple proposals for Minimal Viable Plasma (MVP) [38]). Moreover, the plasma research com- munity currently conjectures that Plasma with general smart contracts might be impossible to construct [16].

In summary, applications that require a fast (reliable) state progression are not ideal candidates for commit chains and should rather rely on state channels instead, as they offer instant finality. Commit chains, on the other hand, allow cheaper off-chain transactions (as no collateral is involved) with delayed finality. The Nocust paper [111] discusses how collateral can help to achieve instant finality over the operator.