Photo by 0xMlze, Salve Boccaccio & 0xMunehisa

Compiled by: TechFlow

Second layer solutions

The Ethereum mainnet currently processes an average of 12 transactions per second, and at peak network activity, transaction costs have reached a level that is unacceptable to most users. This scalability problem stems from the fact that every node in the network needs to store and verify all transactions that occur on the network.

To solve this problem and scale Ethereum, second layer solutions (L2) were invented. The second layer is an independent blockchain that extends Ethereum and inherits Ethereum's security guarantees. The second layer is essentially a separate blockchain where users conduct transactions outside of the main chain (Ethereum). Each second layer solution has its own security guarantees and tradeoffs. On Ethereum, the most popular form of second layer scaling is Rollups (Arbitrum, Optimism, zkSync).

Rollups

Rollups are L2 solutions that process transactions on L1 before returning to L1. A standard transaction on Ethereum is typically 156 bytes, with the signature being the most data-intensive part. Therefore, Rollups process multiple transactions in the L2 execution environment and then bundle them into a single transaction, which is submitted to L1 for regular state verification. Bundling multiple transactions into one transaction reduces the gas fees paid by each transaction, as the gas fee is spread over multiple transactions instead of just one transaction. However, not all Rollups are the same, there are many different types of Rollups:

  • Smart Contract Rollups: Optimistic Rollups (Arbitrum, Optimism), Zero-Knowledge Rollups (Matic’s zkEVM, zkSync, Scroll);

  • Celestiums;

  • Enshrined Rollups;

  • Sovereign Rollups.

Smart Contract Rollups

Smart Contract Rollups are where users send funds to a Rollup smart contract on L1, which then manages transactions and state changes.

A key component of Rollups and blockchains is the Merkle tree. The Merkle tree is a data structure that stores the state of everyone's funds and the transactions that have occurred, allowing L1 to verify the state on L2 without downloading the entire state. In simple terms, users interact and transact on L2 (thus changing the state), and L2 periodically sends the Merkle root of the state to L1 so that L1 can verify the state of the chain.

In addition to publishing the Merkle root to L1, L2 must also publish enough Merkle tree change data to allow users to fully reconstruct the Merkle tree. If L2 stops functioning for some reason, users will be stuck on L2 if this data is not provided. Therefore, L1 smart contracts have an "emergency function" that allows users to withdraw their funds from the smart contract Rollup when L2 stops functioning.

L1 needs some kind of proof to ensure that the Merkle root sent by L2 is valid, which is the difference between the two main types of smart contract rollups. The two main types of proofs used are fraud proofs and zero-knowledge proofs.

Optimistic Rollup

OptimisticRollups like Arbitrum and Optimism use fraud proofs to finalize the state. Fraud proofs work like this:

  1. The L2 node publishes the Merkle root to the L1 smart contract along with a small security deposit.

  2. L1 smart contracts trust L2 nodes by default, which is what the word “Optimistic” means - L1 is optimistic about L2 updates.

  3. However, this change in status will not be finalized for 7 days.

  4. During these 7 days, anyone can submit a proof that the submitted Merkle root was fraudulent, which will rescind the update and penalize the L2 node, giving the security deposit to the person who reported the fraudulent update.

  5. The reporter is able to prove that the update was fraudulent by verifying all transactions that occurred in the state root change and confirming that every signature on those transactions is valid. This is because the L2 node published the Merkle root and enough Merkle change data to recreate the Merkle tree.

  6. If the state transition is not disputed within the 7-day dispute period, the update is final and considered immutable.

ZK Rollup

ZK Rollup uses zero-knowledge proofs. Here’s how they work:

  1. The Layer 2 node publishes the Merkle root to the L1 smart contract along with a proof that L2 processed the transaction correctly and generated a new Merkle root.

  2. If the Layer 2 nodes attempt to publish a fraudulent update, they will not be able to generate a valid zero-knowledge proof, and therefore the L1 smart contract will not accept the new Merkle root.

  3. Once the zero-knowledge proof is verified, the state update is complete immediately.

Sequencer

Collators are the mechanism by which L2 collects and publishes transactions back to the Ethereum base chain. In their current centralized state, they work as follows:

  1. Users submit transactions on L2 — DeFi, NFTs, send/receive, etc.

  2. These transactions are collected by a centralized sorter.

  3. The sequencer (block builder) then puts these transactions (call data/state differences) in order into a single block or batch of transactions.

  4. Currently, the L2 sequencer uses a first-in, first-out (FIFO) ordering method to order these transactions.

  5. The sorter then submits the batch of transactions back to the Ethereum mainnet for inclusion in a block.

In its current state, Rollup sorters are centralized and controlled by a single entity (Offchain Labs for Arbitrum and Optimism PBC for Optimism). This centralization creates a single point of failure for Rollup and can lead to liveness issues (and lack of censorship resistance) — if the sorter fails, L2 will not function properly.

For example, in early June, Arbitrum’s collator encountered a bug that caused batches to be rolled back on-chain, resulting in a loss of gas costs for the batches. For a short period of time, batch submitters were out of gas and unable to correctly send transactions to Ethereum.

L2 Gas Fees

Now let’s take a look at how these two main smart contract Rollups calculate the Gas fees that users will pay and the impact on centralized sorters.

On Arbitrum and Optimism, users pay two fees when trading:

  1. L2Gas/execution fees;

  2. L1 Call Data/Security Charges.

L2Gas/Execution Fees

L2 Gas fees are similar to Ethereum's Gas fees. Each transaction on L2 is subject to a Gas/execution fee, which is equal to the amount of Gas used by the transaction multiplied by the current Gas price attached to the transaction.

L1 Call Data/Security Fees

The L1 call data fee is paid to cover the cost of publishing the transaction back to Ethereum. This fee exists because the sorter or batch submitter needs to pay the L1 Gas fee to publish the transaction on Ethereum.

Sequencer Revenue Model

In its current form, Optimistic Rollup (ORU) generates revenue through the operation of a single centralized sorter. In the future, it is expected that ORU will eventually be decentralized, which will open the door to other revenue streams through MEV (Maximizing Ethereum Value) or requiring sorter operators to stake native tokens/share revenue.

But for now, in the simplest representation, we can think of the sorter as charging L2 transaction fees to ORU users (sorter revenue), and needing to pay L1 gas fees to submit users’ L2 transaction data in batches to the Ethereum network (cost 1), as well as paying the operational costs of operating the sorter (cost 2).

Going a step further, we can break down revenue and costs into specific components. While different ORUs (e.g. Arbitrum, Optimism) do not have exactly the same pricing formula, they follow a common framework:

Income (L2 Gas Fees)

Fees = L1_gas_price_estimate * (L1_calldata_size + L1_buffer) + L2_gas_price * L2_gas_used

cost

Costs = L1_actual_gas_price * L1_calldata_size + Sequencer_operational_costs

L2 Fee Pricing

Across all ORUs, the L2 fee price is a function of L1 compute scale, L1 compute cost, L2 compute scale, and L2 compute cost.

Since all L2 orderers incur costs when publishing batches/proofs to the L1 mainnet, it is logical to pass on the dynamic costs of mainnet settlement to users when executing L2 transactions.

Arbitrum and Optimism price L2 fees differently. A very important difference between the two is the way Optimism and Arbitrum calculate the cost of L1 computation. Arbitrum uses an oracle that prices L1 computation, which means that in the absence of a governance vote, the oracle prices L1 computation in the same way as before 4844. However, Optimism's L1 computation includes a dynamic overhead (scalar) variable that can be adjusted by the Optimism team to adjust the cost of L1 computation.

Decision

Arbitrum’s L2 fee pricing implements the concept of “two-dimensional gas fees” where the gas limit is a function of the gas units used by L2, the gas units used by L1, and the estimated L1 gas price.

From this we can draw the following conclusions:

  • The L2 Gas limit decreases as the L2 Gas price increases.

  • L2 Gas Limit increases with the increase of L2 computation, L1 Gas Price, and L1 computation.

Optimism

Similar to Arbitrum, Optimism’s transaction fees take into account the cost of both L1 and L2 computations. Optimism calls them L2 execution fees and L1 data/security fees.

Notice:

  • The dynamic_overhead variable is one that is set by the Optimism team to ensure that their sorter is compensated enough to cover the gas costs incurred when submitting transaction batches back to the L1 network.

  • Currently it is set to 0.684, which means that the sorter is subsidizing the gas costs.

  • Historically, this value has been mostly set above 1, indicating that the sorter is charging extra to maintain the L1 settlement gas buffer.

Dynamic management fees over time / L1 scalar fees

EIP-4844

Currently, Optimistic Rollups have lower costs for Layer-2 execution and storage, but publishing data to Layer-1 is still expensive for users to comply with data availability.

Data is published to Ethereum’s Layer-1 using the calldata opcode, so both Arbitrum and Optimism have implemented calldata compression algorithms such as Zlib and brotli compression algorithms. This data publishing is expensive and accounts for 80-90% of the transaction fees paid by L2 users.

However, between October 2023 and February 2024, a highly anticipated Ethereum Improvement Proposal (EIP-4844, Proto-danksharding) is scheduled to be launched. EIP-4844 proposes to add a new transaction type to Ethereum that allows "data blocks" to be accepted. These "data blocks" are deleted or pruned after about two weeks, rather than being stored permanently like existing calldata. The size of these data blocks is designed to be small enough to reduce storage overhead on the mainnet chain.

High transaction fees on Ethereum Layer 1 (L1) are the main cost of L2 Rollup when issuing batches and proofs. The impact of EIP-4844 on this is to significantly reduce the cost overhead of L1 while allowing batch data to be available long enough for any fraud proofs to be issued. Current estimates place this cost-saving factor ranging from 10x to 100x the cost of the current L1 batch release.

High-level overview of the impact on sequencer revenue

Before diving into the changes we expect to see in Arbitrum and Optimism, it’s important that we take into account the differences between Arbitrum and Optimism in terms of L1 computation pricing (as explained in the L2 fee pricing section above). Given Arbitrum’s L1 pricing oracle, we now know that it will likely pass 100% of its fees to users (unless we see a governance vote). This is not the case for Optimism, as they still control the dynamic fee variable.

The table below provides us with possible outcomes after EIP-4844.

Decision

Given the current state of Arbitrum's financial health in the section above, we explore possible changes to Arbitrum's valuation under certain assumptions. With costs expected to be significantly lower post-EIP-4844, one expects profits and margins to increase while revenue remains unchanged.

Based on this, we built a table showing various possible outcomes with different combinations of EIP-4844 savings passed on to users (Y-axis) and EIP-4844 cost reduction factors (X-axis, higher numbers = higher EIP4844 savings).

We have shaded the combinations we think are most likely to occur after EIP-4844.

If 100% of the savings were passed on to users, we can assume that this cost savings could potentially increase the number of transactions on Arbitrum (new dApp types, more users).

Making some assumptions:

  • Maintain current price-to-earnings (P/E) ratios;

  • Assume a 10-fold reduction in costs;

  • Growth in transaction volume due to fee savings.

We can calculate the impact of these changes on ARB and OP prices. For example, if Tx volume grows by 40% and only 90% of the fee savings are passed on to users, the price of ARB would be $2.10.

Optimism

Doing the same calculation for Optimism, we get the following results.

L2 Token Economics and Valuation

Currently, the only value accumulation of Arbitrum and Optimism is governance; this is the only function of ARB and OP. However, value accumulation of ARB and OP may come from two other sources: transaction fees and MEV.

In their current state, both L2 solutions rely heavily on their centralized collators, and all profits from centralized block construction and proposals are passed on to the Arbitrum Foundation and the Optimism Foundation. However, both solutions have pledged to move towards a decentralized collator mechanism where the foundation is not the only entity building and proposing L2 blocks. The first step towards L2 tokens accruing value is to decentralize the collators, which is not easy, but it can allow L2 token holders to participate in the value generated through the construction and proposal process.

Decentralization of the sorter will most likely be achieved through a PoS mechanism, where users will stake native L2 tokens. If the staker fails to perform their duties or acts maliciously, their stake will be slashed. Stakers can receive a portion of transaction fees, MEV (in a post-FIFO world), or staking rewards in the form of native tokens.

The importance of a decentralized sorter is that a centralized sorter may cause user transactions to be censored, extract excessive rents, or generate harmful MEV, which will have an adverse impact on users.