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

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

4.1 Consensus security

EIP-4844 introduces blobs, a new data type to be propagated and processed. Blobs add new burden for consensus layer[8], potentially slowing validator performance and prolonging the time required to achieve consensus. Such delays could threaten the security of the consensus network. Our thorough examination of the impact of EIP4844 on Ethereum’s consensus security has yielded the following key findings:

(1) Fork Rate Increase: We present evidence that the fork rate has risen since the implementation of EIP-4844, from 3.097 to 6.707 slots per 2000 slots, suggesting a direct impact on network stability. This increase hints at possible challenges to network stability.

(2) Slot Sync Time Increase: We observed an increase in slot synchronization times, correlating with the quantity of blobs per slot. Given that delayed slot synchronization can heighten the fork rate, this extended sync time likely contributes to the observed increase in forks.

(3) Analysis of Slot Sync Time Components: Our analysis identifies receive time as the component most significantly affected by EIP-4844, which has led to increased sync times. Conversely, the DA time remains minimal and shows no direct correlation with the number of blobs, suggesting that blob propagation minimally impacts consensus delays.

4.1.1 Fork rate. A fork occurs when different validators view distinct slots, which share the same parent slot, as valid. Frequent forks can compromise consensus security by invalidating transactions within orphaned slots and diminishing the network’s ability to process transactions efficiently. Forks also potentially increase the vulnerability of forked slots to consensus attacks [22, 41] for malicious purposes, such as stealing MEV(Maximal Extractable Value) or double spending.

To determine if EIP-4844 has increased these risks, we analyzed changes in the fork rate, defined as the number of forked slots per 2,000 slots. Figure 6 shows the fork rate in relation to the number of blobs. Notably, a significant increase is observed between slots 8,720,000 and 8,740,000, initially perceived as a threat to consensus security. This spike was later attributed to a bug in the implementation of EIP-4844 by some network participants, which went undetected until an increase in blob activity occurred [21].

Based on this analysis, we determined that the sharp increase in the fork rate during the spike was not a direct result of the EIP-4844 specification. Nevertheless, our further investigations reveal that, even after excluding this anomalous spike period, the average fork rate has still risen from 3.097 to 6.707 slots per 2,000 slots—an increase of 116.538%. This notable elevation in the fork rate necessitates additional research to clarify its underlying causes.

The average sync time rose by approximately 140.065ms, from 2267.436ms to 2407.501ms. Figure 8b demonstrates that the increase in sync time correlates with the number of blobs per slot. Interestingly, slots without blobs also experienced an increase in sync time by about 77.967ms. Determining the precise cause of this increase is challenging; it 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. For our analysis, we have excluded the delays associated with slots without blobs, offering a conservative estimate of the impact of EIP-4844.

Therefore, the minimal increase attributable to EIP-4844 can be conservatively estimated at 62.098ms, accounting for only half of the observed increments in sync time and fork rates. However, it is vital to dissect which components of sync time EIP-4844 impacts. Such an analysis not only clarifies the direct impacts but also enriches future research on blob-related technologies like Danksharding[12]. Comprehensive understanding of these dynamics is crucial for the refinement and development of forthcoming protocols.

We have conducted detailed examinations of three specific components of sync time—receive time, CSP time, and DA time—as depicted in Figure 3. Our findings reveal that the most significant impact of EIP-4844 was on receive time, contributing approximately 56.102ms to the overall increase in sync time. In contrast, DA time, newly added, did not show as significant an impact as expected, and CSP time appeared unaffected by EIP-4844, according to our conservative analysis.

4.1.3 Receive time. Receive time is a critical component of sync time, particularly due to its influence on validator. According to Ethereum consensus specifications [15], validators are expected to attest to the current slot only if they receive a valid block within the first 4 seconds. Additionally, the proposer boost mechanism, introduced to mitigate balancing attacks [36], grants an extra 40% of votes to slots arriving within this time frame in the fork choice rule [2]. Slots that fail to meet this attestation deadline do not receive the proposer boost, increasing their susceptibility to balancing attacks.

Figure 9b shows the average receive time by city and overall, with a noticeable increase from 1759.066 ms to 1840.032 ms—an elevation of approximately 80.966 ms. Figure 9c further demonstrates that

receive time is correlated with the number of blobs; slots without blobs post-EIP-4844 have similar receive times to those before the implementation, while increases are proportional to blob counts.

After subtracting the 24.864 ms increase in receive time of slots without blobs, we estimate that the minimum impact of EIP-4844 is 56.102 ms. This increment comprises the majority of the observed rise in sync time, suggesting that EIP-4844 predominantly affect the receive time. This impact likely stems from the additional responsibilities of proposers to handle blob data from execution clients and generate KZG commitments for blobs.

Figure 9a illustrates the distribution of receive times before and after the implementation of EIP-4844, showing a slight overall shift towards longer times. Notably, the proportion of slots arriving after 4000ms increased from approximately 0.18% to 0.415% after EIP4844—a more than two-fold increase. These data suggest that the likelihood of slots falling victim to reorg attacks has risen following the introduction of EIP-4844, as slots arriving later are more vulnerable to reorg attacks.

4.1.4 Chain service process time. Chain Service Process (CSP) time is a crucial component affecting the synchronization time of a slot. With the implementation of EIP-4844, new procedures were added, including the validation and storage of versioned hashes of KZG commitments within the execution engine. The increase in CSP time—from 482.565ms to 536.043ms, or about 53.478ms, while the average CSP time for blob-free slots was 52.779. This observation, specified in Appendix Figure 18, suggests that CSP time does not correlate with the number of blobs. Therefore, we conclude that the overall rise in CSP time might not directly result from EIP-4844.

4.1.5 Data availability time. DA time, a new delay introduced by EIP-4844, represents the duration spent waiting for blobs to arrive after slot execution and beacon state updates are completed. Analyzing metric is particularly important as it is newly introduced by EIP-4844.

Figure 10b shows that as the number of blobs increases, the time difference between the arrival of the first and last blobs also increases, hinting at potential delays. However, Figure 10a shows that the actual waiting time for blob arrival is minimal, averaging only about 13.417 ms overall, and just 0.956 ms bigger than slots without any blobs. Even in slots with six blobs, the delay remains below 17.5 ms, dropping to 4.619 ms when excluding slots without blobs, which is relatively minor.

This apparent contradiction is resolved by the independent propagation of blobs from the slot. It allows the consensus layer (CL) to proceed with tasks related to the slot, such as block execution and state transitions, while waiting for blobs, which may arrive more slowly. Remarkably, in 35.519% of cases, the last blob arrived even before the slot itself. This strategy of separating blob propagation from slot propagation effectively minimizes any delays caused by blob transmission. Therefore, despite some impact on consensus security, our findings suggest that the effect of waiting times for blobs is not substantial.