EIP-4844: L2's & Valuations Post Proto-danksharding

In order to combat this issue and scale Ethereum, Layer 2 solutions (L2) were invented. A layer 2 is a separate blockchain that extends Ethereum and inherits the security guarantees of Ethereum. An L2 is essentially a separate blockchain whereby users transact off the main chain (Ethereum). Each layer 2 solution has its own set of security guarantees and trade-offs. The most popular form of layer-2 scaling on Ethereum are Rollups (Arbitrum, Optimism, zkSync).

‍Rollups

‍Rollups are L2 solutions that process transactions for the L1, before settling back to the L1. A standard transaction on Ethereum is typically 156 bytes, with the signature being the most data dense. Therefore, rollups process many transactions on the L2 execution environment before bundling them up into one transaction to post to the L1 for regular state verification. The act of bundling up many transactions into one reduces the gas paid for each transaction, since it is split across many instead of just one. Not all rollups are equal however and there are a number of different types:

- 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 rollups whereby users send their funds to a rollup smart contract on the L1 and this smart contract then manages the transactions and changes in state.

A key component of rollups and blockchains in general are Merkle trees. Merkle trees are data structures that store the state of everyone's funds and the transactions that occurred, allowing the L1 to verify the state on the L2 without downloading the entire state. Simply, users interact and make transactions on the L2 (thereby changing the state) with their funds and the L2 will periodically send a Merkle root of the state to the L1 so that the L1 can verify the state of the chain.

Alongside posting the Merkle root to the L1, the L2 has to post enough Merkle tree change data so that users are able to fully recreate the Merkle tree themselves. Without this data being made available, users would be stuck on the L2 if the L2 went down for whatever reason. The L1 smart contract therefore has ‘emergency functions’ whereby users can withdraw their funds from the smart contract rollup in the event the L2 goes down. You can see the relevant risk information for each major L2 below.

Proofs

‍The L1 needs some sort of proof to ensure that the Merkle root sent by the L2 is in fact valid and this is where the two major smart contract rollups differ. The two main proofs used are fraud proofs and zero-knowledge proofs.


‍Optimistic Rollups

‍Optimistic rollups like Arbitrum and Optimism use fraud proofs to finalize state. Fraud proofs work as below:

1. The L2 nodes post a Merkle root to the L1 smart contract along with a small bond
‍
2. The L1 smart contract by default trusts the L2 node and this is where the term ‘Optimistic’ comes from - the L1 optimistically trusts the L2 update.
‍
3. However, this state change does not become final for 7 days.

4. In those 7 days, someone can submit a proof that the Merkle root submitted is fraudulent and this would revert the update and penalize the L2 node by giving the bond submitted to the reporter of the fraudulent update.

5. The reporter is able to prove the update was fraudulent by verifying all transactions that happened in the state root change and by confirming each of the signatures on these transactions are valid. This is because the L2 nodes post the Merkle root and enough Merkle change data to recreate the Merkle tree.

6. If the state transition is not contested in the 7 day contention period, the update is finalized and considered immutable.


‍Zero-Knowledge Rollups

‍Zero-knowledge rollups use zero-knowledge proofs. They work like this:

1. The Layer 2 nodes posts a Merkle root to the L1 smart contract along with a ZK proof that proves the L2 correctly processed transactions and produced a new Merkle root.

2. If the Layer 2 node were to try post a fraudulent update, they wouldn’t be able to produce a valid ZK proof and thus the L1 smart contract would not accept the new Merkle root.

3. The state update is settled instantly once the ZK proof have been verified.
‍

‍Sequencers

‍A sequencer is the mechanism by which L2s gather and post transactions back to the Ethereum base chain. In their current, centralized state, they work like this:

1. Users submit transactions on the L2 - DeFi, NFTs, send/receive and so on.

2. These transactions are gathered by the centralized sequencer.

3. These transactions (calldata / state differentials) are then ordered by the sequencer (block building) into a single block or batched transaction.

4. Currently, L2 sequencers order these transactions using a first-in-first out (FIFO) ordering approach.

5. The sequencer then submits this batched transaction back to the Ethereum mainnet for inclusion in a block.

In their current state, the sequencers of rollups are centralised and controlled by one entity (Offchain labs for Arbitrum and Optimism PBC for Optimism). This centralisation creates a single point of failure for the rollups and can result in liveliness issues (and a lack of censorship resistance) - if the sequencer goes down, the L2 cannot operate properly.

For example, in early June Arbitrum’s sequencer experienced a bug causing its batches to revert on-chain, leading to the loss of gas cost for sending the batch. For a short period of time the Batch Submitter had no gas and was not processing transactions properly to Ethereum.

L2 Gas Fees

Now we shall examine how the two major smart contract rollups calculate the gas fees a user will pay and it’s impacts on the centralised sequencer’s bottom line.

On both Arbitrum and Optimism, users pay two costs to transact:

1. L2 gas/execution fee

2. L1 calldata/security fee
‍

L2 Gas/Execution Fee

‍The L2 gas fee is similar to how Ethereum gas fees work. Each transaction on an L2 will have to pay a gas/execution fee, equal to the amount of gas used by the transaction, multiplied by the current gas price attached to the transaction.

‍L2_gas_price * L2_gas_used



‍L1 calldata/security fee

‍The L1 calldata fee is paid to cover the cost to post transactions back to Ethereum. This fee exists because the Sequencer, or the batch poster which posts the Sequencer’s transaction batches on Ethereum, pays L1 gas to post transactions on Ethereum.

‍L1_gas_price_estimate * (L1_calldata_size + L1_buffer)



‍Sequencer Revenue Model

‍In their current forms, Optimistic Rollups (ORUs) generate revenue via an operation of a single centralized sequencer. In the future, ORUs are expected to eventually decentralize, which would open the door for other revenue streams via MEV, or requiring sequencer operators to stake native tokens / share a cut of revenue.

But for now, in the simplest representation of this, we can think of the sequencer charging ORU users an L2 transaction fee (sequencer revenue), and having to pay L1 gas fees to submit a batch containing user’s L2 transaction data onto the Ethereum network (cost #1) as well as having to pay operational costs of running the sequencer (cost #2).

Going a step further, we can break down the revenues and costs into their specific components. While different ORUs (e.g. Arbitrum, Optimism) don’t share the exact same pricing formulas, they follow a general framework:

Revenues (L2 Gas Fees)

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



‍Costs

‍Costs = L1_actual_gas_price * L1_calldata_size + Sequencer_operational_costs



‍L2 Fee pricing

‍In all ORUs, L2 fee prices are a function of L1 computation size, L1 computation costs, L2 computation size, and L2 computation costs.

Given all L2 sequencers incur a cost when posting batches / proofs back onto the L1 mainnet, it is only logical that the dynamic costs of mainnet settlement are passed back on to the user when executing an L2 transaction.

L2 Fee pricing works differently on Arbitrum and Optimism. A very important distinction between the two lies in the way Optimism and Arbitrum computes the cost of L1 computation. Arbitrum uses an oracle that prices L1 compute, meaning that without a governance vote, the oracle prices L1 compute in the same way pre and post 4844. However, Optimism’s L1 compute contains a dynamic overhead (scalar) variable that can be tweaked by the Optimism team to adjust L1 compute costs.



‍Arbitrum

‍Arbitrum’s L2 Fee pricing implements a concept of ‘2-Dimensional Gas Fees’, where the gas limit is a function of the L2 gas units used, L1 gas units used and estimated L1 gas price.

‍Transaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)

where :
‍
- G = (L2G + ((L1P * L1S) / P))
- P = L2 gas price
- L1P = Estimated L1 gas price
- L1S = Estimated L1 gas units used

‍From this, we note that:

- L2 gas limit goes down with an increase in L2 gas price.
‍
- L2 gas limit increases with L2 computation, L1 gas price and L1 computation.


Optimism

‍Like Arbitrum, Optimism’s transactions fees take into account the cost of both L1 and L2 computation. Optimism refers to these as the L2 execution fee and L1 data/security fee.

‍Fees charged = L2 execution fee + L1 data/security fee

where:

- L2_execution_fee = (l2_base_fee + l2_priority_fee) * (l2_gas_used)
- L1_data_fee = l1_gas_price * (tx_data_gas + fixed_overhead) * dynamic_overhead

‍Note:

- The dynamic_overhead variable is a variable set by the Optimism team to ensure that their sequencer is adequately compensated for the gas costs incurred when submitting transaction batches back onto the L1 network.

- Currently it is set to 0.684, which indicates that the sequencer is subsidizing gas costs.

- Historically, this has been predominantly set above 1, which indicates the sequencer is charging extra to maintain an L1 settlement gas buffer.

EIP-4844

‍Currently, Optimistic rollups have cheap costs for layer-2 execution and storage but in order to comply with data availability, the posting of data to layer-1 still remains costly for users.

Data is published to Ethereum's layer-1 using the calldata opcode, therefore both Arbitrum and Optimism have been implementing calldata compression algorithms such as Zlib and the brotli compression algorithm. This publishing of data is expensive and makes up 80-90% of the transaction fees that L2 users pay.

However, between October 2023 and February 2024 the highly touted Ethereum improvement proposal (EIP-4844, Proto-danksharding) is scheduled to launch. EIP-4844 proposes the addition of a novel transaction type to Ethereum that allows the acceptance of "blobs" of data. The "blobs" are removed or pruned after approximately two weeks, unlike the permanent storage of existing calldata. The size of these blobs are designed to be small enough to reduce storage overhead on the Mainnet chain.

High transaction fees on Ethereum Layer 1 (L1) are a major cost for L2 rollups when posting batches and proofs. The effect that EIP-4844 has on this is that it significantly reduces the L1 cost overhead while allowing batch data to be available long enough for any fraud proofs to be posted. Current estimates place this cost saving factor from anywhere between 10x-100x of current L1 batch posting costs.



High Level Overview of Impact on Sequencer Revenue

‍Predicted change in model due to EIP-4844

‍Before diving into the changes that we expect to see to both Arbitrum and Optimism, it is important that we take into account the differences in L1 compute pricing by both Arbitrum and Optimism (as explained in the section earlier L2 Fee Pricing. Given Arbitrum’s L1 pricing oracle, we now know that it is likely we see Arbitrum passing on 100% of fees to users (unless we see a governance vote). This is not the same for Optimism, as they still control the dynamic overhead variable (allowing them to tweak the amount of savings passed on).

Nonetheless, the sensitivity tables below give us an insight into possible outcomes post EIP-4844, and may be useful for Arbitrum if they decide to have a DAO vote to determine a savings % rate passed on.



‍Arbitrum

‍Given the current state of Arbitrum’s financials in the section above, we explore possible changes to Arbitrum’s valuation with certain assumptions. As the expectation is for costs to significantly decrease post-EIP4844, one would expect profits and margins to increase given revenues are held constant.

With these, we modeled out a sensitivity table showing various possible outcomes for varying combinations of EIP4844 savings passed on to users (Y-axis) and EIP4844 cost reduction factors (X-axis, higher number = higher savings from EIP4844).

We have shaded in the combinations that we view as most likely post-EIP4844.

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

Making a few assumptions:

- Keep current Price to earnings ratio (P/E)
- Assume a cost decrease by a factor of 10
- Transaction count grows due to savings

We can work out the price of ARB and OP for these changes. For example, if Tx count grows by 40% and only 90% of savings are passed on to users, that prices ARB at $2.10.


Optimism

‍Carrying out the same exercise for Optimism, we arrive at the results below.

L2 Tokenomics & Valuation

Currently, the only value accrual towards Arbitrum and Optimism is governance; that is the only function for ARB and OP. However, ARB and OP value accrual could potentially come from two other sources: transaction fees and MEV.

In their current states, both L2 solutions rely heavily on their centralised sequencer and all the profits of this centralised block building and proposing is passed onto the Arbitrum foundation and Optimism foundation. However, both solutions have made promises to move toward a decentralised sequencer mechanism whereby the foundations are not the only entities building and proposing L2 blocks. The first step toward value accrual for L2 tokens is decentralising the sequencer, which is no easy feat, however, it could allow for the participation of L2 tokens holders in the value generated via the building and proposing process.

Decentralizing the sequencer would be likely achieved through a proof-of-stake mechanism where users would stake the native L2 token. Stakers would be slashed if they did not perform their duties or acted maliciously. Stakers could earn a portion of transaction fees, MEV (in a post FIFO world) or staking rewards in the form of the native token.

It is important to decentralize sequencers because centralized sequencers can lead to censored user transactions, become a bottle-neck, extract excessive rent or create harmful MEV and adversely affect users.