How the L2 solution works

At a high level, layer-2s typically have two parts: A network that processes transactions and a smart contract on the underlying blockchain that resolves any disputes and achieves consensus on the state of the layer-2 network by cementing it to an underlying blockchain.

Layer-2 networks are where fast execution of transactions and computations occur. They can vary wildly in how they achieve this throughput. A common denominator between each layer-2 environment, however, is that when looking to settle on the base chain, layer 2s must provide some kind of cryptographic and verifiable “proof” to the blockchain on the integrity of the proposed state change, either preemptively or retroactively.

Similarly, the underlying smart contract implementation can vary between layer 2s, but the core functions of the smart contract are always to:

1. Hold and release funds transferred to the layer 2
2. Receive some kind of proof generated by the layer 2, validate it, resolve disputes, and then finalize transactions

A good way to conceptualize these two dynamics is to take two examples of existing layer-2 implementations — payment channels and rollups.

Payment channels

A payment channel enables the off-chain transfer of on-chain tokens between two or more users by pre-funding liquidity into a channel.

Alice and Bob create a payment channel by locking up collective funds in a smart contract and agreeing (through cryptographic signatures) how much each has access to. For example, if both locked up $50 of funds for a total of $100, they would most likely agree that each gets to use $50 each in the payment channel.

Once the payment channel is set up, Alice and Bob are free to transact off-chain via signed messages without submitting transactions to the underlying blockchain. Alice can pay Bob, and vice versa, at zero cost and lightning-fast latencies. When communicating over the two-way payment channel, Alice and Bob’s transactions aren’t posted onto the underlying blockchain; it’s only when they mutually decide to close the channel that the end results are transmitted to, and settled on, the blockchain.

The end result of this system is that Bob and Alice only need to pay for two on-chain transactions to open and close the payment channel. While the payment channel is open, millions of transfers can be made at zero cost and sub-second speeds directly peer to peer — a classic example of scalability.

Rollups

Optimistic and zero-knowledge rollups offer higher throughput and lower costs by executing smart contract state changes off-chain and proving them on-chain. Scalability with rollups is achieved through the following three methods.

1. Rollups perform off-chain execution of transactions, requiring that the underlying base blockchain only needs to execute small proofs to verify network activity and store raw transaction data.
2. Rollups batch transaction data together when submitted to a blockchain so that the on-chain gas cost is distributed across a number of transactions.
3. Rollups only require a minimum of one honest validator to prove the validity of transactions to the base layer blockchain, allowing for smaller validator sets and increased hardware requirements without significantly compromising security.

Off-Chain Execution

A key feature of rollups is that they perform off-chain execution of transactions. This means that layer-2 networks handle the processing of transactions, whether with another user or with a smart contract, on behalf of of the base blockchain. In conjunction with a smaller validator set with better hardware, this offers much higher throughput when transacting on the layer-2 network compared to the base blockchains.

The base blockchain only needs to execute proofs submitted to the rollup smart contract to verify the activity on the layer-2 network (in the case of optimistic rollups, only in the case of a dispute) and store raw, unexecuted transaction data as calldata. In simple terms, this means the blockchain needs to do less work and store less data for transactions that take place on a layer 2, leading to a lower total cost per transaction.

Batch Transactions

Another way to reduce costs is to batch transactions. This can be thought of as gift packing. On a blockchain, every transaction is a separate gift and is delivered in a separate box. This makes shipping expensive as you have to pay a shipping fee every time you want to send a gift. With rollups, you pack many gifts into a larger box at less frequent intervals and split a larger shipping fee across multiple gifts.

A more technically accurate explanation is that rollups batch raw transaction data as calldata. Rollup transactions don’t need to be verified in the same way that on-chain transactions do; rather, batched transaction data is simply a way to keep data stored on the base chain so that, if necessary, a validator or rollup participant can recreate the state of the layer-2 network at any time. However, the core logic is still the same — one batched transaction on the main chain stores data regarding multiple rollup transactions.

This is a clear and straightforward way of reducing the transaction fees that inhibit scalability on a blockchain, and combined with data compression, it offers remarkable improvements in execution costs compared to transacting on the base blockchain.

Both zk-rollups and optimistic rollups batch transactions in a similar way.

Fewer Validators

As previously mentioned, layer 2s inherent the security guarantees and decentralization of their underlying blockchain. This is elaborated on below, but the core idea is that layer 2s must provide a form of proof to their underlying blockchain that their proposed state changes are valid.

This makes it possible for rollups to have fewer validators process all transactions on the layer-2 network. Validators can be permissioned entities and often have much more sophisticated hardware to compute transactions faster and at lower costs. The reason this is possible is that validators don’t provide consensus — that happens through a smart contract on a base chain, and the smart contract requires proof.

Layer 2 Security: The Importance of Proof

The concept of “proof” is fundamental to layer 2s in order for them to inherit the security guarantees of a base chain. In the physical world, proof can take a variety of forms. Fingerprints on a weapon and camera recordings at the time of an incident are both examples of proof.

Cryptographic proof works in a similar way, but the contents are much more objective than what’s admissible in physical courts. Proving something with cryptography gives objective, verifiable, and tamper-proof guarantees that an exact thing is true. If the proof works, it’s guaranteed to be true. In the case of payment channels, cryptographic signatures on transactions provide the definitive truth needed by the smart contract to settle any disputes.

Every layer 2 relies on some form of cryptographic proof to settle disputes on the base chain. The most prominent proofs today are fault proofs and validity proofs (also known as zero-knowledge proofs), foundations for the modern-day optimistic rollups and zk-rollups.

Payment Channel Signed Messages

Suppose that when closing a payment channel Bob or Alice acts maliciously and attempts to take funds that aren’t theirs. Either one can do this by giving the smart contract an outdated copy of the payment channel’s “ledger.”

A key design element of a payment channel is that transactions must always be cryptographically signed. This becomes a form of evidence that’s compatible with the underlying smart contract to resolve disputes. For example, if Alice proposes an outdated copy of the ledger that gives her more funds than she should get, Bob can dispute the settlement transaction and provide a newer copy of the ledger. The correct amounts can then be determined by the smart contract. Alice would also have to pay a fee for her dishonest behavior.

The adjudication process of the underlying smart contract is precisely what makes payment channels a layer 2. An easy way to think about this is to look at it from a “proof” perspective. Once the payment channel is opened, both Bob and Alice must cryptographically sign every transaction they make and store a copy of the other’s signature.

This is proof of the activities within the payment channel, but just having proof isn’t enough. There needs to be enforcement of the truth, much like a judge makes a decision after evidence is provided and the jury have reached a verdict. In this case, the smart contract enforces the judgment and settles the account by returning the correct amount to each participant’s wallet on the base chain.

This is what it means to inherit the decentralization and security guarantees of the underlying blockchain. The payment channel handles the majority of the computation and execution off-chain, but in the case that consensus is needed to settle the channel, the robust consensus layer of an underlying blockchain makes the ultimate decision.

Optimistic Rollup Fault Proofs

Fault proofs are simple in nature. A layer 2 that uses fault proofs assumes all transactions are valid by default. However, there is a dispute period where any network participant can generate a dispute and provide proof to the smart contract that the transaction data and proposed state change are wrong. When a fault proof is published, the rollup transaction is either partially or fully re-executed on-chain and the resulting state change is compared to the original claim. If the re-execution results in a different result, then the original claim is deemed invalid and reverted.

This system is used by optimistic rollups today. The “optimism” comes from the philosophical viewpoint of a fault-proof: The smart contract “optimistically” assumes that all transactions are valid until proven otherwise (innocent until proven guilty). Taking this back to the example of a dishonest validator, any network participant only needs to propose a valid fault proof to the smart contract during the dispute period for the validator’s actions to be nullified before transactions are finalized.