Assessing the Impact of EIP-4844 on Layer2 Protocol Costs and Profits

Impact of EIP-4844 on Layer2 Protocol Costs and Profits

The second layer solution (L2) such as Rollups (Arbitrum, Optimism, zkSync) can solve the scalability problem of Ethereum. At the same time, the implementation of EIP-4844 will reduce the cost of L1 and have an impact on the token economics and decentralized sequencer mechanism of L2.

1. Second Layer Solution

The Ethereum mainnet currently processes an average of 12 transactions per second. During periods of high network activity, transaction costs have reached levels that most users cannot afford. This scalability problem is due to the fact that every node in the network needs to store and verify all the transactions that occur on the network.

To solve this problem and scale Ethereum, a second layer solution (L2) was invented. The second layer is an independent blockchain that extends Ethereum and inherits its security guarantees. L2 is essentially an independent blockchain where users can conduct transactions outside the main chain (Ethereum). Each L2 solution has its own set of security guarantees and trade-offs. The most popular form of L2 extension on Ethereum is Rollups (Arbitrum, Optimism, zkSync).

• Why is no one talking about ‘blockchain’ now?
• Decoding Intent Revolutionizing the Web3 User Experience and Blockchain Order Flow
• An Overview of Coinlist’s Upcoming Native Cross-Chain DEX Chainflip Mechanism, Features, and Token Economy

2. Rollup

Rollup is an L2 solution that processes L1 transactions before returning to L1. Standard transactions on Ethereum are usually 156 bytes, with the signature being the most data-intensive. Therefore, Rollup processes many transactions on the L2 execution environment and bundles them into one transaction for regular state verification on L1. The act of bundling multiple transactions into one reduces the gas fees paid per transaction, as it is divided into multiple transactions instead of one. However, not all Rollups are the same and there are many different types:

• Smart Contract Rollup
  – OP-Rollup (Arbitrum, Optimism)
  – ZK-Rollup (Matic’s zkEVM, zkSync, Scroll)
• Celestiums
• Sacred Rollup

• Sovereign Rollup

1) Smart Contract Rollup

Smart Contract Rollup is a Rollup where users send funds to a Rollup smart contract on L1, and this smart contract manages transactions and state changes.

In general, a key component of Rollup and blockchain is the Merkle tree. The Merkle tree is a data structure that stores the state of each person’s funds and the transactions that occur, allowing L1 to verify the state on L2 without downloading the entire state. In simple terms, users interact and transact with their funds on L2 (thus changing the state), and L2 periodically sends the Merkle root of the state to L1 for verification.

In addition to publishing the Merkle root to L1, L2 must also publish enough Merkle tree change data so that users can fully recreate the Merkle tree themselves. If this data is not provided, users will be stuck on L2 if it fails for any reason. Therefore, L1 smart contracts have “emergency functions” where users can withdraw funds from the Rollup smart contract if L2 fails. You can see the relevant risk information for each major L2 below.

2) Proof

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

3) OP-Rollup

OP-Rollups like Arbitrum and Optimism use fraud proofs to ultimately determine the state. The working principle of fraud proofs is as follows:

1. L2 nodes publish the Merkle root and small bonds to the L1 smart contract

2. The L1 smart contract defaults to trusting the L2 nodes, hence the term “optimistic” – L1 optimistically trusts L2 updates.

3. However, this state change will not become final for 7 days.

4. During these 7 days, someone can submit a proof to show that the submitted Merkle root is fraudulent, which will revert the update and punish the L2 nodes by giving the submitted bond to the reporter of the fraudulent update.

5. The reporter can prove that the update is fraudulent by verifying all the transactions that occurred in the state transition and confirming that each signature on these transactions is valid. This is because the L2 nodes publish the Merkle root and enough Merkle change data to recreate the Merkle tree.

6. If there is no dispute raised against the state transition during the 7-day challenge period, the update will be finalized and considered immutable.

4) ZK-Rollup

ZK-Rollups use zero-knowledge proofs. They work as follows:

1. The Layer 2 nodes publish the Merkle root and ZK proofs to the L1 smart contract, proving that L2 correctly processed the transactions 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 ZK proof, and thus the L1 smart contract will not accept the new Merkle root.

3. Once the ZK proof is verified, the state update is immediately settled.

3. Sequencer

The sequencer is the mechanism by which L2 collects transactions and publishes them back to the Ethereum main chain. In the current centralized state, their operation is as follows:

1. Users submit transactions on L2 – DeFi, NFT, sending/receiving, etc.

2. These transactions are collected by centralized sequencers.

3. Then, these transactions (call data/state diffs) are sorted by the sequencer (block construction) into a single block or batch of transactions.

4. Currently, L2 sequencers use a first-in, first-out (FIFO) sorting method for these transactions.

5. Then, the sequencer submits this batch of transactions back to the Ethereum mainnet to be included in a block.

In the current state, the sequencers of Rollups are centralized and controlled by a single entity (Arbitrum’s offline lab and Optimism’s Optimism PBC). This centralization can lead to single points of failure and may cause scalability issues (as well as lack of censorship resistance) – if the sequencer fails, L2 cannot operate properly.

For example, in early June, Arbitrum’s sequencer encountered an error that caused its batch to be restored on the chain, resulting in a loss of gas cost for sending the batch. In a short period of time, batch submitters ran out of fuel and could not process transactions with Ethereum correctly.

4. L2 Gas Fees

Now we will examine how two main smart contract Rollups calculate the gas fees users will pay and their impact on the bottom line of centralized sequencers.

On Arbitrum and Optimism, users pay two types of transaction costs:

1. L2 Gas/Execution Fee

2. L1 Calldata/Security Fee

1) L2 Gas/Execution Fee

L2 Gas fee works similarly to Ethereum Gas fee. Each transaction on L2 must pay a gas/execution fee, which is equal to the amount of gas used by the transaction multiplied by the current gas price set by the transaction platform.

L2_gas_price * L2_gas_used

2) L1 Calldata/Security Fee

L1 calldata fee is used to pay for the cost of sending the transaction back to Ethereum. This fee exists because the sequencer or the batch submitter who publishes the sequencer transaction batch on Ethereum pays L1 Gas to publish the transaction on Ethereum.

L1_gas_price_estimate * (L1_calldata_size + L1_buffer)

3) Sequencer Revenue Model

In its current form, Optimistic Rollup (ORU) generates revenue through the operation of a single centralized sequencer. In the future, ORU is expected to decentralize, which will open the door for other revenue streams through MEV or require sequencer operators to stake native tokens/share revenue.

However, currently, in the simplest representation, we can assume that the sequencer charges L2 transaction fees (sequencer revenue) from ORU users and must pay L1 gas fees to submit batches containing user L2 transaction data to the Ethereum network (Cost #1) as well as pay for the operational costs of running the sequencer (Cost #2).

Furthermore, we can break down the revenue and costs into specific components. Although different ORUs (such as Arbitrum, Optimism) do not have exactly the same pricing formulas, they follow a common framework:

4) Revenue (L2 Gas Fee)

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

5) Costs

Cost = L1_actual_gas_price * L1_calldata_size + Sequencer_operational_costs

6) L2 Fee Pricing

In all ORUs, the L2 fee price is a function of L1 computation scale, L1 computation cost, L2 computation scale, and L2 computation cost. Considering that all L2 sequencers incur costs when publishing batches/proofs back to the L1 mainnet, it makes sense to pass on the dynamic cost of settling on the mainnet to users when executing L2 transactions.

The way L2 fee pricing works on Arbitrum and Optimism is different. One very important difference between the two is how they calculate the cost of L1 computation. Arbitrum uses an oracle to price L1 computation, which means that the oracle prices L1 computation in the same way before and after EIP-4844 without a governance vote. 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.

7) Arbitrum

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

Transaction fees (TXFEES) = L2 Gas price (P) * Gas limit (G)

Where:

G = (L2G + ((L1P * L1S) / P))P = L2 Gas priceL1P = Estimated L1 Gas priceL1S = Estimated L1 Gas units used

From this, we note that:

• As the L2 Gas price rises, the L2 Gas limit decreases

• The L2 Gas limit increases with L2 computation, L1 Gas price, and L1 computation

8) Optimism

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

Fee 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

Notes:

• The dynamic_overhead variable is a variable set by the Optimism team to ensure that their sequencer adequately compensates for the gas costs incurred when submitting batches of transactions back to the L1 network.

• Currently set at 0.684, which indicates that the sequencer is subsidizing the gas costs.

• Historically, this value has been primarily set above 1, indicating that the sequencer is charging an additional fee to maintain the L1 gas settling buffer.

Manage fees/dynamic L1 scalar fees over time

EIP-4844

Currently, Optimistic Rollup has lower costs for execution and storage at Layer 2, but publishing data to Layer 1 is still expensive for users in order to comply with data availability.

Data is published to Layer 1 using the calldata opcode, so both Arbitrum and Optimism are implementing calldata compression algorithms such as Zlib and brotli. The cost of this data publishing is high and accounts for 80-90% of the transaction fees paid by L2 users.

However, during the period from October 2023 to February 2024, the highly anticipated Ethereum Improvement Proposal (EIP-4844, Proto-danksharding) is planned to be launched. EIP-4844 proposes to add a novel transaction type in Ethereum that allows for the acceptance of “blob” data. Unlike the permanent storage of existing call data, these “blobs” will be deleted or pruned after approximately two weeks. These blobs are designed to be small enough to reduce storage costs on the mainnet chain.

The high transaction fees on Ethereum Layer 1 (L1) are the main cost for deploying batches and proofs for L2 Rollups. The impact of EIP-4844 is that it significantly reduces L1 cost expenses while allowing enough time for batch data to be available for publishing any fraud proofs. It is currently estimated that the cost savings factor is 10 to 100 times the current L1 batch posting cost.

5. Advanced Overview of Sequencer Revenue Impact

1) Model Prediction Changes due to EIP-4844

Before delving into the changes we expect to see in Arbitrum and Optimism, it’s important to consider the differences in L1 pricing between Arbitrum and Optimism (as described in the previous section on L2 cost pricing). Considering Arbitrum’s L1 pricing oracle, we now know that we are likely to see Arbitrum pass 100% of the fees onto users (unless we see governance votes). This is different for Optimism as they still control the dynamic expenditure variable (allowing them to adjust the amount saved).

Nevertheless, the sensitivity table below gives us an in-depth understanding of the potential outcomes after EIP-4844 and could be useful for Arbitrum if they decide to conduct a DAO vote to determine the percentage of savings passed on.

2) Arbitrum

Given Arbitrum’s current financial situation mentioned in the previous section, we explore the potential changes in Arbitrum valuation under certain assumptions. With the expected significant decrease in costs after EIP-4844, it is anticipated that profits and profit margins will increase even with unchanged revenue.

Through these, we have created a sensitivity table that displays various possible outcomes of different combinations of EIP-4844 savings passed on to users (Y-axis) and EIP-4844 cost reduction factors (X-axis, the larger the number = higher cost savings from EIP-4844).

We have added shading to the combinations that we believe are most likely to occur after EIP-4844.

By passing on 100% of the savings to users, we can assume that this cost savings can increase the number of transactions on Arbitrum (new types of dApps, more users).

Making some assumptions:

• Keep the current P/E ratio

• Assume a 10x cost reduction

• Increased transaction volume due to savings

We can calculate the prices of ARB and OP for these changes. For example, if the number of Txs increases by 40% and only 90% of the savings are passed on to users, the price of ARB is $2.10.

3) Optimism

For OP, we have the following results from the same exercise.

4) L2 Token Economics and Valuation

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

In the current state, both L2 solutions heavily rely on their centralized sequencers, and all the profits from building and proposing centralized blocks are transferred to the Arbitrum Foundation and Optimism Foundation. However, both solutions promise to transition to decentralized sequencer mechanisms, where the foundations are not the sole entities building and proposing L2 blocks. The first step in the value accumulation of L2 Tokens is the decentralized sequencer, which is not an easy task, but it can allow L2 Token holders to participate in the value generated through the building and proposing process.

The decentralization of the sequencer is likely to be achieved through a proof-of-stake mechanism, where users can stake the native L2 Tokens in the mechanism. If the stakers fail to fulfill their responsibilities or engage in malicious behavior, they will be slashed. Stakers can earn partial transaction fees, MEV (in a post-FIFO world), or receive staking rewards in the form of native tokens.

The decentralization of the sequencer is crucial because a centralized sequencer can potentially lead to user transactions being censored, create bottlenecks, extract excessive rent, generate harmful MEV, and have adverse effects on users.

5) Rollup Dashboard

We have created a daily updated Rollup dashboard to track Arbitrum and Optimism. It is a read-only link that allows you to monitor important fundamental Rollup and sequencer metrics:

Summary Dashboard

Note: The above links point to public Google Sheets.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!