Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Background
2.1 Rollup
2.2 EIP-4844
2.3 VAR(Vector Autoregression)


Data
3.1 Consensus security data
3.2 Ethereum usage data
3.3 Rollup Transactions Data
3.4 Blob gas fee data


Empirical Results
4.1 Consensus security
4.2 Ethereum usage
4.3 Rollup transactions
4.4 Blob gas fee market


Conclusion and References Background
2.1 Rollup
2.2 EIP-4844
2.3 VAR(Vector Autoregression) Background 2.1 Rollup 2.1 Rollup 2.2 EIP-4844 2.2 EIP-4844 2.3 VAR(Vector Autoregression) 2.3 VAR(Vector Autoregression) Data
3.1 Consensus security data
3.2 Ethereum usage data
3.3 Rollup Transactions Data
3.4 Blob gas fee data Data 3.1 Consensus security data 3.1 Consensus security data 3.2 Ethereum usage data 3.2 Ethereum usage data 3.3 Rollup Transactions Data 3.3 Rollup Transactions Data 3.4 Blob gas fee data 3.4 Blob gas fee data Empirical Results
4.1 Consensus security
4.2 Ethereum usage
4.3 Rollup transactions
4.4 Blob gas fee market Empirical Results 4.1 Consensus security 4.1 Consensus security 4.2 Ethereum usage 4.2 Ethereum usage 4.3 Rollup transactions 4.3 Rollup transactions 4.4 Blob gas fee market 4.4 Blob gas fee market Conclusion and References Conclusion and References Conclusion and References A. Consensus Security Data A. Consensus Security Data B. Rollup Data Collection B. Rollup Data Collection C. Detailed Var Model Results for Blob Gas Base Fee and Gas Fee 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 D. Detailed Var Model Results for Blob Gas Base Fee and Blob Gas Priority Fee E. Rollup Transaction Dynamics 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]. Data Availability. 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 • receive_time: • 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. • chain_service_provide_time: • data_availability_time: The time the consensus client waits for any blobs that have not yet arrived after executing the slot. • data_availability_time: • sync_time: The time when the consensus client synced the slot, measured from the start of the slot • sync_time: 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. Authors:
(1) Seongwan Park, this author contributed equally to the paper from Seoul National University, Seoul, Republic of Korea (sucre87@snu.ac.kr);
(2) Bosul Mun, this author contributed equally to the paper from Seoul National University, Seoul, Republic of Korea (bsbs8645@snu.ac.kr);
(3) Seungyun Lee, Seoul National University, Seoul, Repulic of Korea;
(4) Woojin Jeong, Seoul National University, Seoul, Repulic of Korea;
(5) Jaewook Lee, Seoul National University, Seoul, Repulic of Korea;
(6) Hyeonsang Eom, Seoul National University, Seoul, Repulic of Korea;
(7) Huisu Jang (Corresponding author), Soongsil University, Seoul, Republic of Korea. Authors: Authors: (1) Seongwan Park, this author contributed equally to the paper from Seoul National University, Seoul, Republic of Korea (sucre87@snu.ac.kr); (2) Bosul Mun, this author contributed equally to the paper from Seoul National University, Seoul, Republic of Korea (bsbs8645@snu.ac.kr); (3) Seungyun Lee, Seoul National University, Seoul, Repulic of Korea; (4) Woojin Jeong, Seoul National University, Seoul, Repulic of Korea; (5) Jaewook Lee, Seoul National University, Seoul, Repulic of Korea; (6) Hyeonsang Eom, Seoul National University, Seoul, Repulic of Korea; (7) Huisu Jang (Corresponding author), Soongsil University, Seoul, Republic of Korea. This paper is available on arxiv under ATTRIBUTION-NONCOMMERCIAL-NODERIVS 4.0 INTERNATIONAL license. This paper is available on arxiv under ATTRIBUTION-NONCOMMERCIAL-NODERIVS 4.0 INTERNATIONAL license. available on arxiv available on arxiv [3] https://github.com/etelpmoc/eip4844

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Arweave

Empirical

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

15 Common Types of Unethical Behavior Found in Open-Source Projects

How Proto-Danksharding Impacts Ethereum Consensus and Rollups

Ethereum Rollups: Boosting Scalability Without Sacrificing Security

EIP-4844, Blob-Carrying Transactions, and the Future of Ethereum Rollups

Why Blob Gas Isn’t Just Hot Air in Ethereum’s Future

Consensus Risks After EIP-4844: Fork Rate Surge, Sync Delays, and Network Stability

15 Common Types of Unethical Behavior Found in Open-Source Projects

How Proto-Danksharding Impacts Ethereum Consensus and Rollups

Ethereum Rollups: Boosting Scalability Without Sacrificing Security

EIP-4844, Blob-Carrying Transactions, and the Future of Ethereum Rollups

Why Blob Gas Isn’t Just Hot Air in Ethereum’s Future

Consensus Risks After EIP-4844: Fork Rate Surge, Sync Delays, and Network Stability

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps