Overview of Layer 2 Technology

Layer 2 is a set of technologies or systems that are constructed to run on top of Ethereum (Layer 1) whilst:

• Inheriting the security properties of Layer 1.
• Providing greater throughput.
• Lower opereating cost.
• Faster transaction confirmations.

than Layer 1 alone. Most L2 solutions proposed are a set of off chain clusters (including nodes, validators, operators etc.) run by a decentralised, 3rd party or business entity that the compute EVM compatible transactions.

Why do we need Layer 2?

• Currently transactions are expensive and severely impacting the retail adoption of Ethereum and dApps running on the network. Many investors feel priced out from the network.

Gas fees and confirmation times ballooned at the height of the yield farming craze. Credit: https://ycharts.com/indicators/ethereum_average_transaction_fee

• Some use-cases where speed of transaction affects the ability of the DApp to operate at an optimal level (blockchain games). Assuming in cases where users transactions are added instantly to a block, it still takes an average 15 seconds for blocks to be processed.

Credit: https://etherscan.io/chart/blocktime

• Still utilising the security that Ethereum provides but with scalability instead of using other blockchain networks entirely.
• If the mainet blockchain grows too large, hardware requirements to run an Ethereum full node increases significantly over time, reducing decentralisation.
• Simply increasing block size is not feasible since it places incredible strain on each validator.

Plasma

The first solution to scaling was Plasma. Plasma was a simple solution where the side chain network was extended from the main Ethereum blockchain. The side chain layer would proces transactions off the main chain with the processing operated via a centralised actor or in a more secure and advanced chain, a proof of stake system (e.g. Matic Plasma Chain).

How Plasma works

1. A transaction where an asset is moved from the mainchain to the Plasma network is sent to the smart contract managing Plasma and given a unique ID.
2. The protocol operator will generate a batch of Plasma transactions based on the ones received from the smart contract.
3. Like how the EVM batches transactions on Ethereum, the side chain operator generates a transaction trie from the batch in the side chain block.
4. The root hash of the trie is added to the Ethereum blockchain to record the state.
5. Users are given the index of the branch in the trie corresponding to their assets on the chain (they are now owners of those assets).
6. Users interact throughout the chain and their states are constantly updated by the Plasma operator.
7. To withdraw an asset a user can publish their branch and the asset will be sent to them on their ETH address on the mainnet.

The fundamental flaws of Plasma prevented it’s wider adoption as a scaling solution for Ethereum:

• Users on the chain have had to continuously verify the sidechain and update the ownership state of the assets on the chain against the Ethereum mainnet protocol. This requires a constant state of data availability from the Plasma chain.
• The requirement to always assign assets to owners and update that on record off the chain brings about problems where owners are not required for an asset. An example of this is the Uniswap liquidity pools which have no “owner” and thus interactions on Plasma with Uniswap are not possible unless a version of Uniswap exists purely on the sidechain.
• In order for users to withdraw from the side chain, they are required to retain a large amount of the transacted data in case of challenge and validate themselves. There is also an extensive mandatory challenge period (up to a week in most cases) before the side chain transactions can be solidified as accurate.
• In a scenario where the all users on a sidechain entire need to be offboaorded due to a compromise in security, the entire history of the chain would need to be verified by main Ethereum blockchain, overloading the network entirely.

Rollups

Rollups are another layer 2 solution that performs transaction execution outside the main Ethereum chain, but posts the transaction data on layer 1. Rollups inherit the security properties of layer 1 whilst making transactions fast and inexpensive utilising off chain computation.

Rollups differ to Plasma in that they maintain some of the data of the transactions on the chain. Data availability on chain removes the need to map assets to owners, meaning general purpose scaling where existing Ethereum applications can migrate directly. It also means anyone can detect fraud. Storing data on the chain is also relatively cheap (in gas) compared to smart running executions on the chain which are more complex and take up a larger footprint.

How Rollups work:

The state of the rollup (composed of the account balances, contract code, etc.) is maintained by a smart contract on chain via the root of the rollup trie. The contract switches the state root to the new state root everytime a new batch of transactions occurs is rolled up. The smart contract manages the interactions the inputs and outputs between transactions in the rollups and on the mainchain. Now the issue arises, if any user can submit a batch with any post-state root with no consequences, they could transfer all the assets inside the rollup to themselves. The solution to these are the proofs and there are two predominant models of Rollups:

Zero Knowledge Rollups

Runs computation off-chain and submits a validity proof to the chain. Every batch includes a cryptographic proof called a ZK-SNARK which proves that the post-state root is the correct result of executing the batch. The zero knowledge element of the proof refers to where one can prove possession of certain information (a secret key for example), without revealing that information, and without any interaction between the prover and verifier. No matter how large the computation, the proof can be very quickly verified on-chain. With a ZK-rollup, there are no delays when moving funds from layer 2 to layer 1 because a validity proof accepted by the ZK-rollup contract has already verified the funds. The downside however is that validity proofs are intense to compute and not worth it for applications with little on-chain activity.

Optimistic Rollups

Optimistic Rollups are called ‘Optimistic’ because they assume that all transactions are valid by default and only runs computation, via a fraud proof, when challenged. Transactions occuring off the mainnet constantly propose a new state to the mainnet without computing any complex proof prior to commiting like a ZK Rollup, thus Optimistic rollups are improve scalability significantly (up to 10–100x improvements in scalability dependent on the transaction).

The lack of validation computation however means that meaning that after a transaction is made there is a time period where fraudulent transactions must be identified by users or bots. If someone notices a fraudulent transaction, the rollup will execute a fraud-proof and run the transaction’s computation, using the available state data. This means you may have longer wait times for final transaction confirmation than a ZK-rollup, because it could be challenged. Participants get penalized for conducting fraud and reimbursed for proving fraud (the gas to run the computation of the fraud proof is reimbursed by the network).