Measuring Ethereum’s Consensus Security and DA Layer Post-EIP-4844 | HackerNoon

Table of Links

Abstract and 1. Introduction

2. Background

   2.1 Rollup

   2.2 EIP-4844

   2.3 VAR(Vector Autoregression)

3. Data

   3.1 Consensus security data

   3.2 Ethereum usage data

   3.3 Rollup Transactions Data

   3.4 Blob gas fee data

4. Empirical Results

   4.1 Consensus security

   4.2 Ethereum usage

   4.3 Rollup transactions

   4.4 Blob gas fee market

5. Conclusion and References

A. Consensus Security Data

B. Rollup Data Collection

C. Detailed Var Model Results for Blob Gas Base Fee and Gas Fee

D. Detailed Var Model Results for Blob Gas Base Fee and Blob Gas Priority Fee

E. Rollup Transaction Dynamics

3 DATA

Data Availability. All data and code utilized in this study are openly accessible to ensure the reproducibility of our analyses and to support further research. These resources can be found at [3].

3.1 Consensus security data

To mitigate geographical biases and better isolate the impact of network speed variations across different locations, we deployed three Ethereum full nodes with homogeneous hardware configurations and client versions. Each node was hosted on an AWS t3.xlarge instance equipped with Ubuntu 22.04, featuring 4 vCPUs and 16GB of memory, and ran identical software stacks—Geth 1.13.14[45] as the execution client and Prysm v5.0.0[27] as the consensus client. These nodes were located in distinct geographic regions: Virginia, Paris, and Singapore. This setup ensured that any observed differences in data propagation and processing times could be predominantly attributed to network latency rather than variations in hardware performance or software configurations.

In this study, we analyze slots from 8,570,000 to 8,626,175 representing eight days prior to the implementation of EIP-4844, and slots 8,626,176 to 8,839,999 covering approximately four weeks following its introduction. However, as indicated in the subsequent analysis of the fork rate, there exists data anomalies between slots from 8,720,000 to 8,740,000 due to incorrect implementations by other network entities. Since these anomalies stem from mistakes at the application level and not from the EIP-4844 specification itself, they are excluded from the analysis. Going forward, slots from 8,570,000 to 8,626,175, before the introduction of EIP-4844, will be referred to as pre-4844, and slots from 8,626,176 and 8,720,000, and 8,740,000 to 8,839,999 after its implementation will be alternately referred to as post-4844.

The following data fields were extracted from the debug mode log file in the Prysm client:

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

• chain_service_provide_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: 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

To better understand the significance of these fields, it is essential to comprehend the operational flow of the consensus client. Figure 3 illustrates the client workflow, which details how data is processed and logged within the system.

When the consensus client receives the slot, it is recorded as receive_time. Upon receiving a slot, the Prysm client simultaneously updates the consensus state and triggers the execution of the execution payload(block) within the execution layer. Since blobs are propagated separately from the block itself, it is necessary to verify the arrival of all blobs before selecting a fork. The duration required to ensure all blobs have arrived is referred to as the data_availability_time. Once all blobs are arrived, the fork choice process begins, which includes the verification of attestations and the handling of potential reorganizations. The moment when the slot processing is completed is recorded as the sync_time. The time difference between the reception of the slot and its synchronization, excluding the data_availability_time, is recorded as the chain_service_process_time.

3.2 Ethereum usage data

To assess the impact of EIP-4844 on Ethereum usage effectively, we focused on the top 10 rollups by Total Value Locked (TVL) as reported by L2BEAT[26]. As of April 28, 2024, these rollups—Arbitrum One, Optimism, Base, Blast, Starknet, zkSync Era, Linea, dYdX v3, Mode Network, and Scroll—account for 98.5% of the ecosystem’s TVL. We gathered data from sender addresses associated with these rollups, which are pivotal in committing transaction batches and verifying state differences. Our study spans 180,000 blocks before and after the implementation of EIP-4844, covering the period from February 17 to April 7, 2024.

A significant challenge in this analysis is distinguishing the transactions that contribute directly to Ethereum’s role as a DA layer. Not all transactions from rollups serve this function; for instance, zk rollups often utilize Ethereum more for execution than for DA. Importantly, execution transactions, which are not DA transactions, cannot be replaced with blob transactions. To navigate this, we categorized transactions into two groups based on their roles: transactions from optimistic rollups that commit batches are deemed DA transactions, while for zk rollups, only those committing batches and posting state updates are classified as DA transactions. The specific sender addresses and their categorization are detailed in Appendix Table 10.

Data extraction was performed using an Erigon[28] 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.

[3] https://github.com/etelpmoc/eip4844