Summary of "What kind of layer 3s make sense?" by Vitalik Buterin

Summary of the article “What kind of layer 3s make sense?” by Vitalik Buterin. Images are from the original article.

Are Layer 3s Useful?

The article examines the usefulness of layer 3 protocols and especially the following argument:

Layer 2 is secure because of layer 1 but helps to scale layer 1. Similarly, we can secure layer 3 by achoring into layer 2 and help it to scale the ecosystem even more.

Layer 3s had problems before:

• Data availability
• Reliance on L1 bandwith for emergency withdrawals

Starkware proposition: layer 2 and layer 3 should have different functions.

The Problem With Rollups on Rollups

The two main blockchain bottlenecks: computation and data.

• Computation: Fraud proofs or SNARKs solve this. A few actors verify and many others partially check the computation of the proving process. It can be almost limitless.
• Data: There is no good solution yet.
  • Rollups compress data (~8X on EVM) but they still need to make data availalbe for users to verify and prove.
  • There is no point of adding another layer of compression because any improvement on compression can be added to the first compression.

Starkware Proposition: Layer 2 and Layer 3 Should Have Different Functions

Examples:

• L2 for scaling and L3 for customized functionality (e.g. privacy).
• L2 for general purpose scaling and L3 is for customized scaling.
• L2 is for trustless scaling (rollups) and L3 is for weakly-trusted scaling. Examples are validiums that use SNARKs for verification but leave data availability to a third party.

Transactions Between Layer 2s

A three-layer model allows a sub-ecosystem to exist within a single rollup, making possible cheap cross-domain operations without touching the layer 1.

However, cheap transactions between layer 2s of the same layer 1 are also possible.

Direct Layer 2 to Layer 2 Transactions

This approach does not have to issue tokens and assets in the root chain. It can use a wrapper in one layer 2 to move represent the asset of the other layer 2.

Steps:

1. Send tokens to the base contract.
2. Base contract generates a receipt.
3. Send the Merkle proof of that receipt (rooted in L1 state) to a wrapper contract on the other layer 2.
4. The wrapper contract verifies the token and issues a wrapper token in the second layer 2.

Comparison With Optimistic Rollups

The approach has some weaknesses compared to optimistic rollups.

• L1 rooted token depositing is instant, withdrawing is one week.
• Here, both depositing and withdrawing requires waiting the fraud proof window.

However, a three-layer architecture of optimistic rollups is hard to secure.

ZK rollups

• They are much faster
• They still require a shorter window for the following reasons:
  • Cover non-parallelizable compute time (esp. ZK-EVM rollups). Solution: Next-gen ZK-EVM.
  • “consideration of needing to submit proofs rarely to minimize the fixed costs associated with proof transactions”. Solution: Better batch verification architecture.

Solutions For The Scaling Problem

Rollups pay a high fixed cost but little per transaction cost. It takes lots of time to wait for a high number of transactions that make the whole batch affordable.

Tradeoff between batch interval and costs:

$ \frac {\text{cost}} {\text{transaction}} = \text{transaction cost} + \frac {\text{batch cost}}{\text{transactions per second} * \text{batch interval}}$

Example:

• per-batch cost: 600000
• transaction cost: 368
• speed: 5 transaction per second
• cost / transaction values:
  • 12 second long batch: 10368
  • 1 hour long batch: 401

Customized validiums and application-specific environments slow down transaction speed and make the tradeoff even stronger.

Layer 3 Solution

• ZK rollup inside a ZK rollup has a much lower fixed costs of 8000 gas
• This changes the respective cost / transaction values:
  • 12 second long batch: 501
  • 1 hour long batch: 368

Aggregate Verification based on ERC-4337

With this method we can achieve similar results as a three-layered solution.

Mechanism:

• A ZK rollup or validium accepts a new state root if it is the result of data processing on the old state root ($S_{new} = STF(S_{old}, D)$).
• A ZK rollup accepts a message from a batch verifier that has verified a proof of batch statements with each statement following this proof.
• Batch handlers validate the transition: A batch handler verifies the proof once and passes off the message to each rollup with the $(S_{old}, S_{new}, D)$ triple.
• Implementation can be a recursive SNARK scheme or Halo aggregation.
• Cost per rollup would be close to 8000

This is similar to a layer 3 approach but the middle step (batch mechanism) is much simpler than there (rollup with an EVM).

Starkware has a similar solution to this (SHARP).

Semantic Confusion Around ‘Layers’

There are special-purpose services that are not necessarily ’layers':

• Validiums
• Proof aggregation schemes
• ERC 4337
• On-chain privacy systems
• Solidity
• Tornado Cash

A proposed definition of layer 2 layers:

• Purpose is scalability
• It is a blockchain that can process transactions and have their internal state
• Inherit the full security of Ethereum

Examples fitting into this category:

• Optimistic rollups
• ZK rollups

Conclusion

• Stacking the same scaling scheme on top of itself usually does not work.
• A three-layered architecture where each layer have different purpose can work.
• Intermediary services between user-facing environments and layer 1 should be as simple as possible (not a full-on layer).