by Seongwan Park, Bosul Mun

TL;DR

• We collected data on rollup smart contracts, rollup blocks, and Ethereum block delay and analyzed how they have changed before and after EIP-4844.

• The total data size posted on Ethereum by rollups increased by 221%, the total fee paid by rollups decreased by 44%, and the price for using data availability space for 1MiB decreased by 56%.

• The number of rollup transactions showed an increase in Arbitrum One, Optimism, Base and a decrease in Starknet, zkSync Era.

• In spite of overall increased rollup activities, rollup user delay showed a large increase in Optimism, Base and Starknet, while Arbitrum One and zkSync Era showed a slight decrease in rollup user delay.

• There were increases in fork rates and sync time, even excluding periods affected by client problems.

• The most significant contributor to increased sync time is receive time, while blob propagation had minimal impact.

Introduction

On March 13th, 2024, EIP-4844 introduced a new data structure known as blobs, designed primarily for rollups to utilize as a data availability layer. These blobs, which are not directly accessible from the execution layer (EVM) and are deleted after 18 days, have substantially reduced fees for rollups, as evidenced by various data sources (e.g., l2fees). However, a comprehensive investigation into the overall impact on the Ethereum and rollup ecosystems has been lacking.

Given that blobs increase the data size that needs to be propagated, there are concerns about potential delays in node synchronization and the resulting consensus risks. To understand the broad impacts of EIP-4844, we explored its effects on Ethereum usage, rollup transactions, and consensus delay. For transparency and further research, all code and datasets are publicly available at GitHub Repository.

Dataset

We utilized different datasets for each part of our analysis. Acquiring rollup block data and consensus delay data is resource-intensive, leading us to use shorter periods compared to the Ethereum usage data.

The Dencun upgrade block is identified as block number #19426589.

1) Ethereum usage

Data period : From 500,000 blocks before to 500,000 blocks after the Dencun upgrade block, spanning January 3 to May 22, 2024.

Rollups : Top 10 rollups by Total Value Locked (TVL) - Optimism, Arbitrum One, Base, Blast, Starknet, zkSync Era, Linea, dYdX V3, Mode, Scroll.

We gathered rollup sender addresses associated with each of 10 rollups from l2beat, which are pivotal in committing transaction batches and verifying state differences. Data extraction was performed using an Erigon archive node, from which we retrieved gas fees, blob gas fees, and the sizes of calldata and blobs used by the identified rollup sender addresses. This data helped us derive three key metrics to analyze Ethereum’s usage dynamics: posted data size, total fees paid, and the cost of posting 1MiB on the Ethereum network.

2) Rollups

Data period : From 120,000 blocks before to 180,000 blocks after the Dencun upgrade block.

Rollups : Optimism, Arbitrum One, Base, Starknet, zkSync Era

Among the various transaction types initiated by rollups(e.g. verifyFRI, proveBatches, finalizeBatches..) we specifically collected batch transactions, which compress all individual rollup transactions. These transactions are crucial for ensuring user security by mitigating operator risk and safeguarding user funds. Batch transactions typically precede other transaction types such as proving and finalizing transactions, reflecting their foundational role in securing user interactions on rollups. We regard the timestamp of batch transaction sent to Ethereum as the settlement of rollup transactions, and calculate the delay by getting the time difference from rollup block timestamp.

Each rollup employs unique encoding mechanisms, often modified by updates (e.g. span-batch mechanisms), which posed significant decoding challenges. Additionally, the rapid block times and large data volumes of rollups like Arbitrum (0.26 seconds) and Optimism (2 seconds) necessitated the use of specialized tools and methods for data collection and analysis, as maintaining full nodes for all monitored rollups was infeasible. We utilized a variety of rollup explorers and batch decoding tools(e.g. ethernow) tailored to each rollup’s specific needs. Our analysis concentrated on five rollups—Arbitrum One, Optimism, Base, Starknet, zkSync Era—where we were able to obtain decoded batch transaction data for a given period.

3) Consensus data

Data period : From 56,175 blocks before to 213,824 blocks after the Dencun upgrade block.

To evaluate the impact of EIP-4844 on Ethereum’s consensus security without geographic bias, we set up three Ethereum full nodes with identical hardware and software configurations. Each node operated on an AWS t3.xlarge instance with 4 vCPUs and 16GB of RAM, running Geth as the execution client and Prysm as the consensus client. The nodes were located in Virginia, Paris, and Singapore to ensure that any differences in data propagation were due to network speeds rather than hardware or software discrepancies.

We utilized detailed logs from the Prysm client to extract key metrics, including receive time, chain service process time, data availability time, and sync time of the slots.

• Receive time : The time when the consensus client received the slot, measured from the start of the slot

• Chain service process time(CSP time) : The time taken by the consensus client to execute the slot, update the consensus state and execution layer state, and the fork choice.

• Data availability time(DA time) : The time the consensus client waits for any blobs that have not yet arrived after executing the slot.

• Sync time : The time when the consensus client synced the slot, measured from the start of the slot.

However, there were data anomalies between slots 8,720,000 and 8,740,000 due to incorrect implementations by other network entities. Since these anomalies were caused by application-level errors rather than issues with the EIP-4844 specification itself, they were excluded from our analysis.

Findings

1) Ethereum usage

A key measure of the success of protocol changes is whether they achieve their intended goals. One significant purpose of EIP-4844 was to lower the data availability cost for rollups, and many sources indicate that the cost of posting data for rollups has significantly decreased.

Additionally, it's important to assess whether this change stimulated rollup activity. We focused on how EIP-4844 impacted Ethereum usage by rollups. The charts below illustrate the changes in: 1) Total data size posted on Ethereum. 2) Total fees paid on Ethereum. 3) The cost of 1MB data availability on Ethereum.

(1) Data size posted on Ethereum

EIP-4844 aimed to encourage rollups to use Ethereum as a data availability layer at lower costs. As expected, rollups utilized more data space through blobs. The chart below shows a significant increase in the total data size posted on Ethereum after EIP-4844, from 0.0855 MB per block to 0.1894 MB per block. The total calldata size decreased to 0.0273 MB per block, indicating that blobs increased more than twice the total data availability needs while reducing calldata usage by 69%.

Optimistic rollups, in particular, showed a remarkable decrease in calldata size, from 0.049 MB to 0.009 MB per block, compared to zk rollups, which decreased from 0.041 MB to 0.028 MB per block. The increase in total data usage is more notable in optimistic rollups, likely because batch transactions constitute most transactions in these rollups.

(2) Fee paid

The average fees paid by rollups per block saw a substantial decrease following the implementation of EIP-4844. Before EIP-4844, rollups paid an average of 0.057 ETH per block. This fee dropped to 0.0123 ETH per block after the upgrade, marking a 79% decrease. This reduction was particularly notable among optimistic rollups. Before EIP-4844, these rollups paid approximately 0.0297 ETH per block, making up about 52% of the total fee. After EIP-4844, their contribution dramatically dropped to 0.0035 ETH per block, representing 28% of the total fees paid.

(3) Price for 1MiB data availability

The cost of data availability per 1MiB before the implementation of EIP-4844 was approximately 1.4445 ETH per block. Following EIP-4844, this price significantly decreased to 0.6441 ETH per block, representing an 82% reduction. This substantial decrease underscores the effectiveness of EIP-4844 in reducing the costs associated with data availability on Ethereum, thereby lessening the economic burden on rollups that rely on Ethereum for data posting. This reduction in cost is crucial for enhancing the scalability and economic feasibility of using Ethereum as a data availability layer.

2) Rollups

(1) Rollup transactions

A substantial increase was observed across three rollups: Arbitrum One, Optimism, and Base. Notably, Base experienced a significant rise of 345%, while Arbitrum, Optimism each saw increases exceeding 70%. This overall uptick suggests that the reduced fees resulting from EIP-4844 may have incentivized a greater volume of transactions on rollups. Starknet and zkSync Era showed a slight decrease, approximately 30%. However it is still hard to say that EIP-4844 has affected the decrease, since the occasional demand peak can highly affect the total number of transactions.

(2) User delay

We define rollup user delay as the time difference between the time when the transaction is included in the rollup block and the time when the transaction is included in the batch transaction.

Figure below illustrates the distribution of user delays for each rollup before and after the implementation of EIP-4844. Despite an increase in the number of rollup transactions, four out of six rollups showed an increase in user delay. Notably, Arbitrum One saw a significant decrease in user delay by 62%, and zkSync Era by 40%, indicating faster transaction settlement times. Conversely, other rollups exhibited notable increases in delay.

Increased user delays indicate that users often experience longer wait times before their transactions are settled on Ethereum, requiring them to maintain trust in the rollup operators until their transactions are committed. A potential cause for increased delay could be rollups waiting to fill blobs to their capacity of 128KiB before committing them.

The standard deviation of user delay is also a crucial indicator of predictability in waiting time, essential for user assurance regarding transaction security. Table below indicates that the standard deviation of user delays increased in all rollups except Arbitrum, suggesting that users frequently face longer waiting times for their transactions to be settled on Ethereum.

While increasing transaction volumes that rapidly fill the 128KiB capacity may help reduce these delays, rollups with smaller or infrequent transactions might still face extended waiting times. This issue highlights the need for blob sharing protocols among different rollups to hasten transaction commit times and enhance user experiences by shortening wait periods.

3) Consensus delay

(1) Fork rate

We first analyzed the fork rate, which is a critical indicator of chain stability. Notably, after the introduction of EIP-4844, our data showed a temporary but significant spike in fork rates due to a bug in some network implementations. However, even after removing the anomalous data, the fork rate still increased significantly from 3.097 to 6.707 per 2,000 slots, representing a sustained increase of 116.538%. This finding highlights the need for further investigation into the causes of higher fork rates after EIP-4844.

(2) Sync time

Analysis revealed that longer sync times significantly contributed to increased fork rates, as shown by a logistic regression model that showed a clear relationship between the two. The model showed that an increase in sync time was significantly associated with a higher probability of a slot being forked, with a coefficient of 1.5×10^(-3) and a highly significant p-value (<0.001). This suggests that slots that take longer to synchronise are more likely to fork.

Furthermore, the average sync time saw an approximate rise of 140ms, linked with an increase in the number of blobs per slot. Despite the general increase, slots without blobs also experienced a rise in sync time. This increase could stem from operations which run fixed number of times to support EIP-4844, such as blob gas calculations, or possibly from other minor updates included in the Dencun upgrade. Our analysis, to focus on the specific effects of EIP-4844, estimated a conservative increase by excluding the delays associated with slots without blobs.

(3) Sync time components

We have thoroughly analyzed three key components of sync time: receive time, CSP time, and DA time.

Our results indicate that the introduction of EIP-4844 primarily affected receive time, which saw an increase in total sync time of approximately 56.102ms. On the other hand, DA time, despite being a new addition, did not have as significant an impact as expected, and CSP time did not appear to be affected by EIP-4844, based on our conservative estimates.

(4) Receive time

After EIP-4844, average receive times increased from 1759.066 ms to 1840.032 ms, with the increase correlating with the number of blobs per slot. Specifically, slots with no blobs experienced a small increase of 24.864 ms, indicating that the minimum impact of EIP-4844 on receive times is approximately 56.102 ms. This finding suggests that the additional responsibilities of handling blob data and generating KZG commitments under EIP-4844 are likely to cause delays. The data also shows that the proportion of slots arriving after 4000 ms has increased from approximately 0.18% to 0.415%. This data suggests that the likelihood of slots being susceptible to reorganisation attacks has increased slightly following the introduction of EIP-4844, as slots arriving later are more susceptible to such attacks.

Conclusions

We have thoroughly examined the impact of EIP-4844 on various aspects. However, the blobs are not currently used enough to maintain the price of 1 wei, and our analysis period was not very long(~5 months).

What we were still able to learn from the analysis are:

• The use of Ethereum as a data availability layer has increased significantly, and the price of the data availability fee has decreased significantly.

• Cheaper rollup fees have led to an increase in rollup transactions, especially for optimistic rollups.

• After EIP-4844, we observed longer sync times and increased fork rates. On the other hand, blob propagation time seems to have minimal impact on the longer sync time.

We hope our analysis not only provides the clear understanding of the immediate impact, but also helps improve understanding of future improvements such as increasing gas limits or Danksharding.