As popular cryptocurrencies become more widespread in their adoption, blockchain networks such as Bitcoin and Ethereum witness a surge in transaction volumes thanks to their popularity and ever-expanding applications, including NFTs, DeFi etc. Given that blockchains have a hard limit on the transaction rate (Ethereum processes up to max. 15 TPS), this rise in popularity affects the network throughput, processing and response times simultaneously. The vast and ongoing developments in the Ethereum ecosystem have given rise to off-chain processing and scaling solutions which handle this particular dilemma so that the strain on the popular chains is greatly diminished, and these solutions fall under the "layer 2" category of protocols.

But what is a "Layer" in Crypto Land?

A layer, similar to the OSI model in networking, abstracts away the set of specifications and infrastructure of a given blockchain platform.

Layer 1 (L1) refers to the base layer, i.e the underlying (Ex. p2p) on-chain network infrastructure of a given blockchain. This specifies the consensus mechanism (ex. Proof of Work (PoW), Proof of Stake (PoS)), the difficulty, how transaction/gas fees are accrued etc. In our blockchain class, we've been introduced to the blockchain trilemma, analogous to the CAP theorem of distributed systems. Proposed by Ethereum's co-founder Vitalik Buterin, it states that a blockchain network can satisfy at most two of the three goals - security, scalability and decentralization, but not all the 3 together. Most Layer 1 blockchains like Bitcoin and Ethereum sacrifice scalability while adhering to security and decentralization alike.

To address the current scalability and throughput issues on L1, Layer 2 (L2) protocols and networks were introduced. The primary idea is to process transactions away from L1 (off-chain), thereby offloading a considerable amount of processing away from the base network.

Types of "Layer 2" Scaling technologies

Plasma Chain

As per the Ethereum Docs, this is a separate blockchain anchored to Ethereum Mainnet but executing transactions off-chain with its own mechanism for block validation. They're sometimes referred to as child chains, essentially smaller copies of the Ethereum Mainnet. These child chains use smart contracts plus cryptographic verification to offload transactions from the parent chain.

While reporting to the Ethereum main net, Plasma chains use fraud proofs to arbitrate disputes, whereby

• transactions are rolled up into batches and submitted to Ethereum in a single transaction (similar to rollups).

• Assumed valid by default, these transactions can be challenged if fraud is suspected

• A fraud proof then runs the transaction to check if fraud actually took place.

Here's a rough sketch on the working of the Plasma chain:

Side Chains

These are separate blockchain networks that are EVM compatible and run parallel to Ethereum main chain. They typically maintain a two-way bridge to the mainnet for compatibility, and there exist two types of sidechains:

• One chain dependent on another (like Ethereum), and

• independent sidechains Sidechains typically adopt their own consensus protocols to achieve more efficient and fast transaction processing, such as proof of authority (PoA), proof of history (PoH), delegated PoS etc. This is non-custodial for the consumer with a major limitation - it doesn't inherit the security properties of Ethereum mainnet, which means it's responsible for its own security mechanisms and the consumer must rely on that.

Sidechains provide a much more affordable and efficient way to transact in the blockchain. And since they are EVM compatible, developers can easily deploy their applications to the sidechain without any changes. However they are less decentralized, and since they rely on their own mechanisms instead of layer 1, they are sometimes not considered as a layer 2 solution, although a good candidate.

Rollups

One of the more popular scaling solutions to date. They reside in parallel to the Ethereum main net on layer 2, and execute transactions in an inexpensive and (highly) scalable manner whilst leveraging Ethereum's layer 1 security schemes, hence not reinventing the wheel in that regard. Simply put, a rollup is a bunch of transactions compiled into one. This bundling is achieved through smart contracts, and the group of transactions is acknowledged by the mainnet as a single transaction, which means their execution is processed faster. In addition to this, validators or sequencers manage the data and submit the collections of highly compressed transaction data to the main chain.

Rollups are categorized depending on how the transaction data is eventually recorded on the layer 1 mainnet:

Optimistic Rollup

These rollups operate on trust, with transactions being processed off-chain by validators, and post transaction data to the layer 1 mainnet, with the assumption that they're correct (rather, being optimistic).

Optimistic rollups benefit from not doing additional work in the optimistic scenario. For every attempt to publish, a dispute resolution period is entered within a brief timeout. Other participants can act as a challenger for this attempt during this duration, wherein they submit what's termed as a fraud proof if they feel something's not quite right.

The participant who submitted the proof for the transaction bundle will be disincentivized if errors were found, and the wrong transactions will be re-executed. To achieve this, the rollup must preserve the previous correct state for restoration, and must enforce a penalty procedure, which typically involves parties staking their proof submission/challenge, and losing that stake in case of wrongdoing.

This challenge period however causes a limitation, since it delays finalizing transactions and withdrawals take longer in general. And since all transactions need to be posted on chain, some experts believe that optimistic rollups aren't as efficient.

ZK-Rollups

A ZK-Rollup attempts to address the limitations of the optimistic rollup by using zero-knowledge proofs to improve security and scalability. Instead of submitting the bunch of transactions to the layer 1, this rollup only sends a proof of a state transition to the mainnet, which indirectly conveys the existence of a series of transactions signed by owners, that lead from the old Merkle root to the current one. To be exact, a ZK-Rollup produces a cryptographic commitment verifying the transactions it processed offline, which is known as a validity proof. However, the verification process of a validity proof is very complex, which means that zk-Rollups don't necessarily scale well and won't be an ideal choice for high-throughput blockchains.

The purpose of using a zero-knowledge proof (ZKP) is to ensure that the prover doesn't reveal any additional information to the verifier other the proof that a given statement is true. The anatomy of a ZKP can be given through the famous cave example.

• Let's assume that the verifier (the green-shirt boy) wants to know if the prover (girl with the purple shirt) is aware of a particular secret word, which is used to open a magic door in a cave.

• The verifier doesn't know the path that the prover has taken going inside the cave.

• Now suppose the verifier shouts the path from which the prover must come out from the cave, either A or B, at random.

• If the prover knew the secret word, she opens the door if necessary and takes the desired path.

• However, if she didn't know, she can return only through the path she entered in the cave. Since the verifier chooses A or B at random, the prover has a 50% chance of being correct. Repeating this experiment many times decreases her chances of anticipating the verifier's requests, and hence the probability becomes very small.

Considering the above example, this is how a zk-rollup typically works:

• The prover provides a mathematical proof to the verifier representing the hashes of the newly created merkle tree from the set of recent transactions bundled.

• The verifier uses the (set of) hashes part of the proof to verify the validity of the transactions

• In this case, the validity proof is received without revealing additional information to the verifier

The above is a simplification of the rather complex computations and processes that occurs, hence optimistic rollups have had a relatively better head start compared to zk-rollups due to their simplicity. Proponents however consider a long-term solution for scalability due to the usage of cryptographically verifiable validity proofs.

Validity proofs leverage ZKP, so that parties can prove correctness of a statement without revealing the statement itself. These proofs can arrive from a rollup in two forms:

• zk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge)

• zk-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge)

At the time of writing, zk-SNARK is more widely adopted in comparison with zk-STARK, although this could change since zk-SNARK requires a time-consuming trusted setup of required key infrastructure to formulate proofs, and they're not quantum resistant compared to zk-STARK. Regardless of this debate, zk-Rollups are a layer 2 technique to look out for in the near future, since they offer greater security and scalability in the sense that the Ethereum mainnet nodes only require to verify the proof of computation instead of the entire transaction data itself, which means that such data need not be sent from the rollup to layer 1.