The State of Layer-2 Protocol Development #1
A progress report on all things layer-2 on Ethereum.
Welcome to the first post in a series about layer-2 scaling solutions being designed and built on top of Ethereum! The zeroth post, by Kevin Zhang, covered Plasma. From now on, I’ll be bringing you regular updates on all layer-2 progress being made by the Ethereum community. For layer-1 protocol development, check out the State of Ethereum Protocol series by my colleague Ben Edgington. This first post will cover the basics of the core design philosophy of the most popular layer-2 techniques, along with an overview of the latest and greatest in bringing these techniques one step closer to production deployment.
A Brief Overview of Layer-2 on Ethereum
Layer-2 scaling techniques move transactions off-chain (as opposed to layer-1 scaling techniques, which improve the transaction throughput of the base chain). If constructed properly, layer-2 solutions can leverage many of the benefits of blockchains (security, immutability, decentralization, etc.) without incurring the same costs (slow confirmation times, volatile and high transaction costs, etc.), with minor tradeoffs and assumptions.
A driving philosophy for layer-2 scaling techniques being built on Ethereum is the use of fraud proofs rather than validity proofs. Validity proofs (such as zk-S[NT]ARKS) can be used to prevent incorrect state transitions from occurring off-chain. Unfortunately, in addition to being extremely resource-intensive, proofs of validity are monopolistic rather than competitive to generate, so systems centered around validity proofs tend to become permissioned and therefore not decentralized. For an overview of what “decentralized” entails, see this previous post on the scalability problem. Perhaps more importantly, validity proofs only have their nice properties if they are implemented bug-free — if not they can be no better than fraud proofs!
Fraud proofs, on the other hand, are optimistic in nature: we assume that everything is correct until a challenge proves otherwise. The generation of these proofs is usually simple and cheap (especially when compared to generating validity proofs), and so anyone may participate.
The two main scaling proposals on Ethereum for the past couple years have been child chains (i.e. Plasma) and state channels (more general versions of payment channels, which have been around for many years on the Bitcoin network).
Plasma
Plasma is a framework for the design of child chains. Konstantopoulos describes a Plasma child chain as a “non-custodial sidechain.” This definition dictates that: 1) the side chain can’t steal your funds and 2) the side chain can’t prevent you from claiming your funds. This is accomplished by the use of a trustless (or, almost trustless, as we shall see soon!) two-way peg. A more precise definition of a child chain is: a “trustless side chain borrowing security from its parent chain through periodic commitments.”
The two-way peg has been the single biggest challenge in designing side chains with minimal trust assumptions. The forward peg (parent chain → side chain) is trivial to implement: simply lock funds into a contract on the parent chain. The backward peg (side chain → parent chain), however, is the root cause of the problems, as the side chain is “easier” to attack/manipulate than the parent chain. Several methods have been proposed to resolve this (list non-exhaustive):
- Only support a one-way peg. This prevents anyone on the side chain from being malicious and stealing funds on the parent chain. This design is currently being suggested for the beacon chain in Ethereum 2.0, whereby ETH is burned on the parent chain (the PoW Ethereum chain) and simultaneously minted on the side chain (the PoS beacon chain) as BETH, with no way of doing the reverse.
- Use a federated peg. In this scheme, one or usually more operators control the backward peg process through a multisignature scheme. In other words, the operators decide when funds can be unlocked on the parent chain. Unfortunately, this scheme results in the side chain effectively being custodial, federated side chains are for all intents and purposes isomorphic to centralized exchanges.
- Enter: Plasma (the topic of half of this post)! Plasma allows for an almost trustless two-way peg, specifically the reverse peg of assets from the child chain back to the parent chain. It accomplishes this through the use of an exit game, which makes use of fraud proofs implicitly or explicitly, relying on variations of challenges that must be issued within a given timeout.
Note that contrary to popular belief, Plasma on its own does not enable low-latency transactions, only increased throughput through optimistic commitments of many transactions as a single hash on the Ethereum chain. Indeed, the latency of child-chain transactions can be considered higher than those of the parent chain without any channel-like features to reduce this.
Caveats
As with all layer-2 schemes that rely on fraud proofs rather than validity proofs, there is a trust assumption on an honest majority of block producers on the parent chain. A majority of miners (in a PoW chain) can censor transactions: in the case of fraud proofs, if challenges are censored, then funds can be stolen. This is why Plasma isn’t completely trustless or completely non-custodial, and indeed this is a fundamental caveat of the child chain design.
The State of Plasma
Continuing on from this previous post on the state of Plasma as of September 2018, let’s see how Plasma has advanced in the past 6 months.
Plasma Cash (March 2018) is a variant of Plasma that uses a non-fungible, channel-like data model, as opposed to Plasma MVP (January 2018), which uses a fungible UTXO data model similar to Bitcoin. Unlike payment channel networks, Plasma Cash allows users to join the network to send and receive coins without making an on-chain transaction. Unfortunately, also unlike payment channel networks, this is accomplished by requiring an ever-growing coin history to be passed around when a coin is transacted, and to be kept as a proof of coin ownership. This history grows linearly with the number of Plasma chain blocks.
Plasma Prime (October 2018) was the next major milestone in Plasma research. It uses RSA accumulators for Plasma Cash coin history compression, first proposed to be used in a blockchain context for UTXO batching on Bitcoin. An in-depth explainer of RSA accumulators has been graciously written by Konstantopoulos here, and a technical talk by Bünz here. At a high level, accumulators are a fixed-size integer that can prove membership or non-membership of set elements identified by unique prime numbers, and on which we can perform addition and removal operations. This serves to make the previously-linear coin history in Plasma Cash fixed size, regardless of the number of Plasma blocks!
Plasma Group, publicly announced in January 2019, is a new non-profit group that is doing fundamental research and development of Plasma. They began by releasing a specification for a Plasma Cashflow chain. This resolves the issue of coin fragmentation found in Plasma Cash, but does not resolve the coin history size problem. Most recently, they released a design for general-purpose Plasma using predicates. The gist of this “plapp” design is that a singular Plasma chain can execute state transitions from contracts deployed on the parent Ethereum chain. This means developers no longer need to spin up their own Plasma network (including writing complex p2p clients, etc.) to make use of Plasma’s scaling benefits, but can instead simply deploy a predicate contract onto Ethereum.
Loom Network has been using a Plasma Cash chain operated using Delegated Proof-of-Stake called PlasmaChain (note that contrary to the title of the article, staking is only used to provide operator liveness, not secure the network). This doesn’t provide any novel research contributions, but does show how an early iteration Plasma can be leveraged for small real-world applications.
OmiseGO released an alpha of their Plasma MoreVP implementation, dubbed Ari, on Rinkeby. Hoard used this network to demonstrate a game at ETHDenver called PlasmaDog.
Future Work
The mass exit problem for MVP-style child chains has resulted in research in that direction grinding to a halt. At a high level, MVP-style Plasma chains rely on users full validating the Plasma chain and exiting when an invalid block is produced by the operator, or the operator withholds a block. Exits are performed on the parent chain (Ethereum) and the currently-best devised exit schemes are linear in the number of exits. Under adversarial conditions, the safe cumulative throughput of all Plasma MVP-style chains running on Ethereum is upper bounded by the exit throughput of the Ethereum chain itself. As a result of this problem, the majority of Plasma research has shifted towards Plasma Cash and its derivatives.
For Plasma Cash variants, major work has been done on reducing the asymptotic growth of the coin history. Using RSA accumulators, as in Plasma Prime, is not without drawbacks: 1) RSA accumulators require a trusted setup — how decentralized trusted setups are is a point of contention across the cryptocurrency space , and 2) compact and efficiently-verifiable proofs using RSA accumulators is still the subject of ongoing research.
See Also (non-exhaustive)
- Plasma Group [Twitter] (non-profit Plasma R&D, Plasma Cashflow)
- Plasma Implementers Calls
- Learn Plasma (resources to learn about Plasma design)
- OmiseGO [Twitter] (Plasma MVP variants)
- Loom Network [Twitter] (Plasma Cash variants), Georgios Konstantopoulos [Twitter]
- LeapDAO [Twitter] (Plasma Leap)
State Channels
“Channels” refers to a layer-2 construction that proceeds by unanimous consent among channel participants. This requires any update to the channel to be digitally signed by all network participants. These channel updates can always be sent on-chain to resolve disputes. Given that parties can communicate out of band to coordinate signing, channels can have extremely low latency, especially when compared to using a blockchain.
While the idea of payment channels (channels between two or more parties facilitating monetary payments between them) has existed for a while, the concept of state channels has more recently been actively explored on Ethereum. State channels allow for potentially arbitrary state transitions to happen off-chain rather than just payments, opening up the possibility of performing scalable, low-latency computations off-chain with similar security to on-chain transactions.
Caveats
As with Plasma, channels are only safe to use when the base chain isn’t censored by the block producers (i.e. miners in the case of Ethereum).
The single biggest unsolved problem facing channels is a result of their statefulness, with only the latest state being valid (a requirement in adversarial conditions). This leads to channels only supporting copies, not backups. To illustrate the difference between the two, consider the following: private keys and mnemonic phrases can be backed up to paper wallets. These backups can be replicated, tested, and will work indefinitely into the future (presumably). On the other hand, the requirements for safely managing channel state copies is a little more involved and interesting things happen when attempting to use backups.
Lastly, channels, unlike chains, operate on a fixed set of live participants. This is partially alleviated by channel networks, but routing and liquidity issues make them non-viable as solutions at the moment (along with a compounding of the copy-problem mentioned above). The always-online nature of channels also remains unsolved.
The State of State Channels
Despite all the caveats listed above, channels have notable properties over chains , including near-instant finality and lower communication overhead, making them cheaper to use in many cases.
Since publishing their paper in June 2018, Counterfactual, an open-source project founded by L4, has been working on building developer tooling around their generalized state channel architecture centered around counterfactual contract instantiation — in which a contract’s address is uniquely defined based on how it’s initialized, allowing contracts to be used off-chain and only created on-chain (at the same address) in case of a dispute.
To enable counterfactual instantiation, a new opcode, CREATE2, was developed and recently deployed with the Constantinople hard fork on February 28. The opcode implements the functionality described above, and its absence was a key roadblock in the deployment of generalized layer-2 constructions.
Patrick McCorry has been hard at work developing Pisa, a watchtower framework for ensuring safety of channel funds when users go offline and are unable to watch the chain for fraudulent channel closures. Pisa watchtowers are unique in that they include a proof that the watchtower was contracted to watch a channel and allowing it to be penalized in the event of malfeasance. The economics of the capital lockups required to implement this framework, and resultant fees, remain the subject of active research however.
On top of these research advancements, a wide range of projects have been using simple payment channels and application-specific state channels (too many to list!).
See Also (non-exhaustive)
- Counterfactual [Twitter] (generalized state channels), Jeff Coleman [Twitter], Liam Horne [Twitter], Josh Stark [Twitter]
- SpankChain [Twitter] (payment channels for streaming services), Ameen Soleimani [Twitter]
- FunFair [Twitter] (state channels for gambling using provably random numbers)
- Patrick McCorry [Twitter] (Pisa, watchtowers)
- Raiden Network [Twitter] (payment channel network a la Lightning Network)
- Connext [Twitter] (payment channel network)
Concluding Remarks
A significant amount of progress has been made on developing layer-2 scaling techniques on Ethereum in the past half a year alone, and we can expect this pace to increase in subsequent months and years. However, many challenges still remain before we can bring these techniques to a production-level public deployment. If you’re interested in helping make blockchain usable for general public use, reach out to one of the teams listed above (or one of the many I didn’t have space to list).
Stay tuned for the next installment of this approximately bi-monthly series for the latest updates on layer-2!
Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.
