Layer Cake: A guide to Layer 2s

Hello!

I’m Zac, the CEO of Aztec. We’re the inventors of the Plonk universal ZK-SNARK and zk.money, the world’s first private rollup and one of the new layer 2 protocols that have recently been deployed to Ethereum.

The layer 2 landscape is becoming a truly fascinating place to explore as multiple teams have been converting vision into reality and deploying their tech to the Ethereum mainnet.

It’s also a bit of a minefield to navigate if you’re not plugged into the ecosystem and can work your way through the jargon.

Unfortunately, most people in a position to explain layer 2s have skin in the game and have some biases towards certain technologies (i.e. the ones their protocol uses!).

So what makes me different? Absolutely nothing! But at least I’ll tell you that upfront instead of pretending to be impartial, eh?

Still, I’ll do my best to give you a balanced overview. The world of blockchain-based cryptography/scaling is a small one and the teams that are pushing the boundaries all deserve respect for what they do. So I guess we should get into it!

What is a layer 2 and why are they important?

The transaction throughput of Eth 1.0 is limited which has led to extremely high transaction costs.The main cost of Eth transactions come from:

• Cost of storage changes
• Cost of transaction data
• Cost of computation

Layer 2s delegate one or more of the above to a secondary network running on top of Ethereum.There are traditionally two categories of layer 2’s each with its own security requirements and trade-offs: optimistic rollups and zk rollups. Aztec is defining the third category, private rollups.

Optimistic Rollups

An optimistic rollup acts much like a miniature version of the Ethereum blockchain. It acts as its own network that hosts smart contracts and transactions.

Periodically, the optimistic rollup will broadcast transaction blocks to a layer 1 smart contract. The ‘blocks’ contains the complete transaction data of every transaction in the block, but nothing else. The layer 1 smart contract does not perform any computation or make any storage updates. This massively reduces the cost of publishing a block.

These rollups are ‘optimistic’ because they assume that every transaction is correct by default — they are not checked directly by a layer 1 smart contract.

Instead, if a user thinks a transaction is incorrect (e.g. double-spending), they can post a “fraud-proof”. The layer 1 smart contract can use the rollup’s published block data to validate the correctness of the alleged fraudulent transaction.

This is very expensive but only has to be done when bad behavior is suspected.

If bad behavior is discovered, the entity that published the optimistic rollup block (typically called a validator) loses some cryptocurrency they have staked.

Optimistic rollups rely on this economic consensus to ensure transactions are correct.

Withdrawal times from optimistic rollups are typically long (e.g. 1 week). This is because once a transaction has been published, one must wait to see if anybody alleges bad behavior and posts one of these fraud proofs (this is a bit like the awkward silence part in a wedding when the priest says “if anybody objects…”)

The main cost of transactions on an optimistic rollup comes from the cost of publishing transaction data on-chain. This data availability problem is shared by all rollups, optimistic or otherwise. In order to prevent funds from being frozen, users need access to all of the rollup’s transaction data. Either it gets published onto layer 1, or extra trust assumptions are required (e.g. trust that some sidechain will make this data available).

At the time of writing, if the rollup does not publish its transaction data on-chain this implies that you are relying on a centralized service to not freeze your funds.

‍Pros:

• Feature-rich. Can copy Eth 1.0 architecture and support smart contract
  
• Easier to build and deploy vs zk-rollups

Cons:

• Slow exit times. Need to wait ~1 week between tx execution and tx considered ‘safe’ due to the lack of a fraud-proof
  
• Slow exit times can be mitigated with underwriters (entities that allow instant withdrawals by taking a small fee in lieu of risk…)

ZK Rollups

Computation and storage handled by a secondary network.

L2 broadcasts transaction data to mainnet along with a proof of correctness. A mathematical proof that the transactions are correct. i.e. the L2 transactions are rolled up into a single mega-transaction that is broadcast to a L1 smart contract.

The ‘zk’ in zk rollups stands for ‘zero knowledge’. However, zk rollups are not private — all transactions are public by default like optimistic rollups. The ‘zk’ comes from the fact that the proof of correctness is typically produced by a zero-knowledge proving system (e.g. a ZK-SNARK or a ZK-STARK).

The upside to this is that the cost of storage updates and computation is removed from Ethereum. There is no need to optimistically assume the transactions are correct, if the proof is valid you can know that the transactions are correct.

This means that withdrawal times are much faster vs optimistic rollups and fewer trust assumptions are required.

The white elephant in the room is that zero-knowledge proofs add a massive computational overhead to a transaction.

Creating a zero-knowledge proof of a computation is approximately 1,000,000 times slower than running the computation directly! This is a rough estimation that will vary depending on the computation in question, but is accurate for the types of computations found in Solidity smart contracts.

ZK rollups handle this by delegating proof construction to third parties with a lot of computing resources, “rollup providers”. Users will be dependent on these third-party services to create transactions for them. Rollup providers can censor or front-run transactions, much like Ethereum miners. The more computing power required, the fewer rollup providers are likely to be available, so the censorship problem must be adequately handled by the protocol architecture.

This computation overhead presents problems when it comes to porting smart contracts to the L2. Full EVM compatibility is the goal, but this 1,000,000 factor slowdown must be handled. The EVM is extremely SNARK-unfriendly because of its 256-bit word size and native support for SHA3 and other SNARK-unfriendly hashing algorithms. Even delegating proof computation to a third party with significant computation resources is likely insufficient. One possible solution is etching zkSNARK prover algorithms directly into silicon via FPGAs or ASICs. Rollup providers will require this hardware to construct proofs.

Typically, SNARK and STARK programming languages have to accommodate the inefficiencies of the underlying proving system. Typically these languages have difficulties implementing variable-length loops and dynamic memory access (think dynamic arrays and vectors). Our latest Plookup research mitigates some of these problems, but not all of them.

This means that the zk rollup may require developers to port their contracts into a custom language (e.g. Starkware’s Cairo).

For zk rollups that do not aim for full EVM compatibility, one upside is cheaper transactions. Without needing to conform to EVM semantics, it is possible to reduce the amount of data broadcast per basic transaction. The Hermes network is an example of such a rollup.

‍Pros:

• Possibly cheaper transactions than optimistic rollups
• No need for fraud proofs, very fast withdrawal times

Cons:

• Slower feature velocity than optimistic rollups
• Dependent on third-party proof constructors with custom hardware
• May require custom programming languages with limited features

Private Rollups

Aztec launched its private rollup on mainnet in March 2021. You can wrap your Eth in a privacy shield and make private transactions using our online privacy wallet zk.money.

Private rollups use similar tech to zk rollups but are a very different beast. The private rollup is architected to provide strong privacy guarantees to every user of the L2. Users hold their funds anonymously. When performing transactions, the sender and recipient are anonymous and the value being transferred is encrypted.

We use a state-of-the-art zero-knowledge proving system, Plonk, to do this. We invented Plonk in 2019 and it is rapidly becoming an industry-standard amongst teams using zero-knowledge proofs and building on blockchains.

Enabling privacy by design requires a radically different rollup architecture to a zk-rollup. We went with a privacy-first approach because we know that it is very difficult to retrofit programmable privacy onto a public L2 without damaging the user experience or requiring a drastic protocol re-architecture.

Current Ethereum-based privacy solutions are mixers. They can be used to anonymize a user’s holdings but little else. Our full vision for a private layer 2 encompasses much more:

• Fully programmable private smart contracts. Private currencies can have advanced transaction logic
• Private ownership of NFTs
• NFTs with properties that are hidden to all but the owner
• Anti-money-laundering and know-your-client checks can be programmed directly into private tokens/dApps (e.g. KYC tokens — you can trade with trusted counterparties without knowing their identity)
• Private DeFi! This is a huge topic that deserves its own article (coming soon…)

This is only possible by architecting the protocol to put privacy first. The transaction and state models for the protocol must be designed to be compatible with privacy.

‍Pros

• Transactions are private. User’s financial activity cannot be analyzed by third parties
• Rollup providers cannot censor or front-run individual transactions. For the rollup provider, every tx looks like a list of random numbers
• No need for fraud proofs, very fast withdrawal times
• Users can unilaterally withdraw without assistance from a third party to perform computation
‍

Cons

• More expensive than public L2s (but cheaper than main-net), until data availability solutions/Eth 2.0 come online
• Users must construct private transaction zk proofs locally. No delegating to a 3rd party. The zk-proving system must be lightning fast to achieve this
• Slower feature velocity than a zk rollup or optimistic rollup due to client-side proof construction. Programmability can be achieved, but full EVM compatibility is a while off
• The state model is different. The value must be represented in bitcoin-style UTXO ‘notes’ and not via Ethereum’s account model. This can be abstracted away at the application layer.

Sorting the signal from the noise

The L2 landscape is competitive and there is an enormous pressure to launch and gain users before one's competitors.

This can lead to corners being cut and additional trust assumptions being added, that are obscured from users.The biggest issue right now is that of data availability.

If the L2 does not publish its transaction data on-chain, the L2 controllers can freeze user’s funds.

Every team working on L2s is striving to push the boundaries of what is possible with today’s technology. While admirable, this makes it easy to hide protocol flaws in technical jargon.

If you’re thinking about using a layer 2, they should be able to adequately address the following questions:

• How is the L2 approaching data availability? If their tx cost is <20x of a regular Eth transfer they might not be broadcasting everything on-chain
• Can a user unilaterally withdraw from the L2 using only the information published on Ethereum?
• Is there a public technical description of the protocol that third parties can validate?

In addition, for zk rollups and private rollups one should ask the following:

• Is the on-chain data provably correct? Is all of it being fed into the rollup circuit as public inputs?
• Is the L2 dependent on centralized compute clusters to create rollups? If so, what is their plan to prevent censorship and front-running? When fully decentralized, how many rollup providers will there likely be?
• Are the proof construction algorithms publicly viewable and auditable?

The shape of what’s to come

The next 12 months are going to be a profoundly exciting time in the Layer 2 space. The myriad of protocols hitting mainnet is the culmination of years of deep R&D and engineering work from across the industry.

For Aztec’s private rollup, our focus is on pulling programmable private smart contracts into the world. Our flagship Plonk programming language, Noir, is designed to compile high-level programs into heavily optimized ZKSNARK circuits, ones that are fast enough for proof construction to happen in the browser. This tech will be the keystone to our Aztec 3.0 rollup architecture, which will support user-defined circuits created with Noir.

By combining programmable privacy with scaling, we’re adding the last missing link required for truly mainstream adoption of web3 technology. At last, web3 will be able to compete on a level playing field against traditional web2 tech, with strong privacy guarantees as standard. We want to foster a rich ecosystem of private cryptocurrencies and NFTs that interact in a privacy-preserving manner both with DeFi protocols and more traditional financial services.

We’ve demonstrated with zk.money that this is not some wild future tech. We’ve already developed the key technologies required to build this ambitious project, now we’re going to knuckle down and execute on our vision.