The State of L2s: Theory and Reality
Written by Daniel Goldman —December 6, 2023
If you’re trying to make sense of the crypto space from the outside, you’ll find you have a tough task ahead of you. Visit a project’s website, and you then have to figure whether their product description applies to something they’ve actually built, a Platonic ideal of what their product could one day become, or something in between. Layer 2s are certainly no exception here. Filtering the reality out of projects’ claims has quite literally become a full-time job.
How then to make sense of the L2 space? Where should one begin?
We can start with a simple definition: a layer 2 is a blockchain designed to derive its security from and provide scale to another blockchain (a layer 1). An owner of assets on Ethereum, for example, can bridge these assets into a layer 2 and use them to transact for lower fees, while still, to some extent, benefiting from Ethereum’s security.
Fine. This definition broadly tells us what a layer 2 does and why someone may want to use one. But when we look at actual protocols in production, we find that things get more complex. A complete, functional “L2” is really composed of many different components working together. If any of these components aren’t fully and properly implemented, it can have direct implications on the system’s security and usability.
In this post, we’ll break down the various parts that comprise an L2 in theory, and explain how they are actually, really (truly) currently instantiated on the public Arbitrum One chain today.
Data Availability Mechanism
Every L2 needs some way to ensure that its “input data” — i.e., users’ transaction data — is publicly available to all parties who need it. In order for other parts of the system (described below) to do their jobs, they first need access to transaction data.
The Arbitrum tech stack offers two options for data availability, as seen in Arbitrum One and Nova respectively. For Arbitrum One, smart contracts on Ethereum ensure that transaction data be posted on L1; this, by definition, makes Arbitrum One a rollup. So long as the security properties of Ethereum itself hold, Arbitrum One’s input data is guaranteed to be available. By contrast, in Arbitrum Nova, data is managed off-chain by a “Data Availability Committee,” introducing a trust assumption in turn reducing transaction fees (we call this an “AnyTrust” chain).
Full Node
The node is the software that handles processing users’ transactions. Nodes keep track of the chain’s state, receive new transactions, execute them, and update the chain’s state accordingly. Nodes also serve public endpoints so that other applications can read and write to the chain. If you’ve used an L2 dapp, it was interacting with a node.
Arbitrum One nodes use Nitro, a fork of Geth (the most popular Ethereum execution client) modified to support L2-specific functionality like special gas handling, cross-chain messages (see below), and new custom precompiles. Building Nitro out of a fork of Geth means Arbitrum chains get strong compatibility with Ethereum, along with the performance optimization benefits that have gone into Geth over the years (see “why Nitro”).
Prover
A complete L2 includes a way to prove the validity of the L2 state back on L1. The prover is how and why L2s can claim to derive security from L1, and is critical for ensuring that withdrawals from L2 to L1 are valid. L2s — particularly Rollups — come in two varieties: Validity Rollups (aka “ZK Rollups”), which use cryptography to actively prove that each state update is valid, and “Optimistic Rollups,” which assume updates are valid and take reactive action in the form of fraud proofs only when challenged.
Arbitrum One is an Optimistic Rollup that has had fraud proofs active since day one. It uses an interactive fraud proof game which ends in execution that proves that an invalid update has occurred. Fraud proofs are adjudicated by smart contracts on L1; they are carried out by special full nodes called Validators, which are built to properly interact with the proving contracts. Currently, on Arbitrum One, fraud proving can be performed by a set of whitelisted entities, modifiable by the DAO. An updated version of fraud-proof game, BOLD, is under consideration for adoption by the DAO, and could pave the way for permissionless fraud proving.
Sequencer
L2s need some way to determine the ordering of their transactions. In practice, all L2s handle this by introducing a role called the Sequencer. The Sequencer is a full node given the special affordance to determine transaction ordering.
The benefits of having a Sequencer include giving users the choice to accept fast transactions if they opt to trust the Sequencer (we call these “soft confirmations”). The Sequencer architecture also leaves the door open for the L2 to experiment with novel ordering mechanisms.
Arbitrum One uses a Sequencer run by Offchain Labs on behalf of the Arbitrum Foundation; this role can be changed and/or revoked by the Arbitrum DAO. The Sequencer implementation includes smart contracts that grant the Sequencer its ordering rights and allow users to bypass the Sequencer (if e.g., Sequencer goes offline or attempts to censor).
Fee Handling
L2s need to charge users fees for similar reasons that L1s do; to put a price on spam / chain congestion and to compensate parties for critical work they’ve done. L2 fees, however, introduce their own questions and challenges that don’t arise on L1s; i.e. how to handle pricing transactions that interact with multiple chains (L2 and L1), and deciding who the recipient of the system’s fees should be.
The Arbitrum tech stack includes a mechanism to ensure the Sequencer gets directly compensated for the cost of posting transactions. It also split fees into four different components, allowing for granularity of distribution. On Arbitrum One, for example, the Sequencer is compensated for the cost it incurred posting batches, and all other fees (i.e., the profits) are given to the Arbitrum DAO.
L1 / L2 Bridge
A “bridge” between two blockchains is a set of smart contracts that allows the two chains to communicate with each other. Arbitrum One, like all Arbitrum chains, includes a general-purpose bridge to its underlying chain. This means contracts on the parent chain can make arbitrary calls to contracts on the Arbitrum chain, and vice versa. Additionally, Arbitrum chains include a “token bridge,” contracts that use the generic bridge to allow for the transfer of ERC-20 tokens between L1 and L2.
Upgradability Mechanism
Unlike L1s—which can upgrade via social consensus—L2s require explicit on-chain actions for upgrades (see “ArbOS Upgrades”).
Arbitrum One handles upgrades via a robust cross-chain governance system; any upgrade to the system can be carried out either via a governance vote or via a quick emergency action from the DAO-elected multisig of independent parties called the security council (this emergency affordance, as of yet, hasn’t ever been used). The system is designed such that the DAO also has the ability to upgrade all aspects of the governance system itself.
Conclusion
It takes work on many different levels of the software stack to take an L2 from an idea to an actual, usable, secure chain; the builders of Arbitrum have done this work. Arbitrum Orbit chains get the benefits of all this work on day one, along with customizability to suit their particular needs. When you’re choosing which L2 stack to use, make sure to pick a real one.
