What's A Universal Mental Model for Layer 2 Networks? (Part 1)
Thanks to Tyson Wynne and Patrick McCorry for contributions and review.
In the rapidly evolving world of blockchain technology, Layer 2 networks (L2s) have emerged as key instruments for scaling Ethereum's capacity. As we will describe in this series, L2s allow for cheaper and faster transactions compared to those on Ethereum Mainnet. They achieve this in two ways:
They compress many L2 transactions in a single Ethereum Mainnet transaction.
They provide trustless methods within Ethereum Mainnet to process L2 transactions in the case of corruption or system failure.
Many users can describe why a network like Ethereum is more independent and resilient than a more centralized blockchain secured by only a single company. But many are lacking a similar intuition for Layer 2 implementations. “Don’t trust, verify” is the promise of blockchain but truly understanding the underlying technology and approach for Layer 2s can be intimidating.
In this article, we will propose a group of components and elements that, in our opinion, define essential aspects of a Layer 2 network such as Arbitrum, Optimism, zkSync Era, Starkware, Linea, etc.
Without these elements, a network is not a proper L2. Within these elements, a user can better assess and compare L2 networks. They are critical “tradespaces” where different networks implement similar functionality in different ways.
There’s a lot to unpack, so we’re going to divide the series up into three parts. We can separate them into three basic questions (with their accompanying technical wording) to ask whenever you’re examining a network to quickly get your bearings:
Is it Optimistic or ZK?** (How does it compute and aggregate network state?)
How do the L2 users communicate with L1? (What data does it include on its L1 state root updates? What are its dispute mechanisms?)
Where is its data stored? (What are its data availability layers?)
*(*This article)
This series aims to simplify things. We will abstract away complex details in the hope of broader understanding. (Throughout the series, we’ll also link resources to guide you into deeper, more technical aspects.)
We aim to give the reader a resilient mental model to better understand Layer 2 technology. We hope this allows them to better debate in, contribute to, and strengthen this important space.
Let’s dive in!
User Onboarding & Transactions
Bridging
A bridge connects the familiar Ethereum mainnet (Layer 1) to the rollup (Layer 2) solution.
The bridge is crucial as it becomes the linchpin of security for those assets: Rather than the user trusting the L2 network, they only need to trust the logic of the smart contract. This validating bridge has within its logic the ability for users to forcibly withdraw, with on-chain proof, in the case of L2 corruption (more on that later).
Once the assets are secure, the bridge creates their counterparts on the Layer 2 side within the rollup. The assets carry the same inherent value and utility, but now have the added benefits of Layer 2 — typically faster transactions and lower fees.
Note that users can also be onboarded directly to Layer 2s by simply receiving a transfer of L2 assets to an Ethereum address, skipping Layer 1 entirely. They will be able to withdraw to L1, if desired, as the L2 assets transferred are represented in the bridge contract.
Transactions
Once onboarded to the Layer 2 landscape, users can typically engage in every operation available on Ethereum, including deploying arbitrary code in a smart contract. The user’s experience, from signing transaction to deploying contracts, should feel similar to their Layer 1 habits.
However, behind the scenes, the specialized architecture and consensus mechanisms of Layer 2 solutions spring into action. They process these transactions at a faster pace and lower cost compared to Layer 1. The magic of Layer 2 lies in this very difference - the seamless, behind-the-scenes processing that empowers users to interact with decentralized applications or transfer assets in a swift, cost-efficient manner.
Across all Layer 2s, the first program in this architecture collecting and ordering transactions is known as a Sequencer.
These onboarding steps are fairly universal across L2 implementations. However, we are coming upon our first major distinctive component.
Ordering and Computation
After the transaction is signed and submitted by the user, the next stage involves the Sequencer computing the updated state of the Layer 2 blockchain. This crucial step happens in a different way than the Ethereum Virtual Machine (EVM) used in Layer 1.
The sequencer’s computation environment is a core element of Layer 2 solutions, designed to alleviate the computational load on Layer 1 and enable a more scalable system. It is also a place where L2 implementations diverge dramatically. As such, they are an excellent place to compare Layer 2 networks.
There are broadly two forms of computation and commitment processes on Layer 2s: Optimistic and ZK.
Optimistic Ordering and Computation
Optimistic rollup sequencers collect a number of transactions and collect them all into a block. They assume the transactions are valid until proven otherwise by a fault proof (formerly known as “fraud proof”).
This is a strong trust assumption which could easily be exploited. However, optimistic rollups use a mechanism known as a fault proof to protect against bad actors. The fault proof is made secure by a challenge window during which users are financially incentivized to check the validity of transactions. We’ll discuss this in more detail in the next section.
Ordering and computation on these optimistic networks are not dramatically different from Ethereum Mainnet. As such, optimistic networks can simply use slightly altered versions of Ethereum execution clients.
Once a transaction has been ordered by a sequencer, it is considered a soft or pseudo-commit — despite not being confirmed on L1, MetaMask, for example, will consider it confirmed on L2. We’ll get into this more below.
ZK Ordering and Computation
ZK-Rollup sequencers also batch a number of transactions into a block. Rather than relying on fault proofs, ZK-Rollups use a powerful form of cryptography known as zero-knowledge (ZK) proofs to generate a single, mathematically irrefutable proof to validate the entire block of transactions. This enormous amount of execution, which would be extremely expensive of L1, is compressed by the zero-knowledge proof to a much smaller size.
However, zero-knowledge proofs are computationally very expensive. As we mentioned earlier, the sequencer will create a soft commit on a batch of transactions: It will order and compute the state change but not the accompanying zero-knowledge proof yet. This is a “soft commit,” because block of transactions will most likely be submitted but we will only be sure when the zero-knowledge proof is submitted with the L2 block to mainnet later in the lifecycle.
Having a block of transactions secured by a single zero-knowledge proof is incredibly powerful. Rather than having every node process every transactions, we can now allow the L1 nodes verify the correctness of a huge number of transactions in a way that is smaller, faster and cheaper than ever before.
Whether the transactions are secured optimistically or through a zero-knowledge proof, all L2 solutions submit these batches of transactions, known as an L2 block, as a single commit to the bridge contract. This aggregation is the driving force behind the scalability of Layer 2 solutions, providing orders of magnitude improvement in cost and speed.
Up Next…
In Part Two of this series, we’ll tackle L2 to L1 commitment of the L2 blocks, how that commitment is secured, and what data different networks provide alongside their blocks.