EIP-8077: Nonce Gap Simulation Report

Executive Summary

This report presents the results of a Monte Carlo simulation analyzing the frequency of nonce gaps in a sharded blob mempool environment. A nonce gap occurs when consecutive blob transactions (type-3) from the same sender are assigned to different shards within the same slot, potentially causing transaction ordering issues for block proposers.

Key Finding: With random shard assignment, a significant percentage of blob transactions (up to ~36% in worst-case scenarios) are affected by nonce gaps. The frequency depends on both the number of shards and the skewness of transaction distribution among senders. This highlights the need for improved transaction announcement mechanisms as proposed in EIP-8077.

1. Motivation: Supporting EIP-8077

1.1 Scope: Blob Transactions and Mempool Sharding

This analysis focuses exclusively on type-3 transactions (blob transactions) introduced in EIP-4844. We specifically examine the sharding of the blob mempool rather than the regular transaction mempool for the following reasons:

1. Blob size: Each blob is 128KB, significantly larger than regular transactions (typically < 1KB)
2. Bandwidth consumption: Blob propagation dominates network bandwidth usage
3. Scalability pressure: As L2 adoption grows, blob demand increases, making mempool sharding essential
4. Concentrated senders: Blob transactions come primarily from L2 sequencers (Base, Optimism, Arbitrum, etc.), creating highly skewed sender distributions

Sharding the blob mempool allows nodes to subscribe to a subset of blobs, reducing bandwidth requirements while maintaining network connectivity. However, this introduces the nonce gap problem that this study quantifies.

1.2 The Problem

EIP-8077 proposes extending Ethereum’s devp2p protocol to include sender address and nonce information in transaction announcements. This simulation study provides quantitative evidence for why this enhancement is necessary.

In a sharded blob mempool, blob transactions from the same sender (e.g., an L2 sequencer) may be distributed across different shards or arrive at different times. When a block proposer receives blob transactions, they need to:

1. Order transactions correctly by nonce for each sender
2. Identify nonce gaps that would make transactions temporarily unincludable
3. Prioritize fetching transactions that fill gaps over those that create new ones

Without sender and nonce information in announcements, nodes must:

• Fetch transactions blindly, risking nonce gaps
• Use inefficient trial-and-error to fill gaps
• Maintain large transaction hash caches
• Miss opportunities for selective fetching by source address

1.3 Why This Study Matters

This simulation quantifies the scale of the nonce gap problem under realistic conditions:

• Up to 36% of transactions can be affected by nonce gaps in high-skewness, high-shard scenarios
• Skewness significantly impacts gap frequency - networks with dominant senders (major L2 sequencers like Base, Optimism, Arbitrum) face higher gap rates
• Same-slot analysis focuses on what matters to proposers - gaps within a single block building period

These findings demonstrate that as Ethereum scales (more shards, higher throughput), intelligent transaction fetching becomes critical. EIP-8077’s metadata enables nodes to make informed decisions about which transactions to fetch, reducing wasted bandwidth and improving mempool consistency.

1.4 Key Implications for EIP-8077

2. Simulation Parameters

2.1 Configurable Parameters

2.2 Derived Values

2.3 Shard Configurations

Six shard configurations were tested:

2.4 Skewness Configurations

Six sender distribution patterns were modeled using exponential decay functions P(i) = exp(-λ * i):

3. Methodology

3.1 Transaction Distribution Over Time

Transactions are distributed across the simulation period with random, non-periodic patterns to simulate realistic network activity:

1. Random Base Noise: Each slot starts with a random transaction rate centered around the target average
2. Random Bursts: 200 random activity bursts with varying duration (50-2000 slots) and intensity (1.2x-2.0x)
3. Random Lulls: 100 random low-activity periods with varying duration (100-1500 slots) and intensity (0.3x-0.7x)
4. Capacity Cap: All slots are capped at MAX_TX_PER_SLOT

transactions_over_time1753×817 34.5 KB

Figure 1: Transaction rate over the 30-day simulation period showing random bursts and lulls (no artificial periodicity).

3.2 Sender Distribution

The probability of a transaction being sent by the sender i follows an exponential distribution:

P(sender = i) = exp(-λ * i) / Σ exp(-λ * j)

Where λ is the decay rate controlling skewness.

transaction_distribution1514×817 71.2 KB

Figure 2: Probability distribution showing how transaction frequency varies across senders for different skewness levels.

transactions_per_sender1547×817 76.7 KB

Figure 3: Absolute number of transactions per sender for each distribution type.

3.3 Same-Sender Transaction Distance

An important factor in nonce gap frequency is how often the same sender has multiple transactions within the same slot. This depends on the skewness of the distribution.

sender_distance_boxplot1494×840 43.6 KB

Figure 4: Distribution of slot distances between consecutive transactions from the same sender. More skewed distributions result in shorter distances (more same-slot pairs).

3.4 Shard Assignment

Each transaction is assigned to a shard uniformly at random:

shard = random.randint(0, num_shards - 1)

This models a scenario where shard assignment is independent of sender identity.

3.5 Nonce Gap Measurement

Critical Design Decision: We only count nonce gaps between consecutive same-sender transactions that occur within the same slot. This is because:

• Different slots are built by different proposers
• A proposer only cares about nonce gaps within their own block
• Cross-slot gaps are irrelevant for block building

The metric we measure is:

Nonce Gap Frequency = (Shard Switches in Same-Slot Pairs) / (Total Transactions)

This represents the percentage of all transactions that are involved in a same-slot nonce gap.

4. Results

4.1 Nonce Gap Frequency Heatmap

nonce_gap_heatmap1217×1071 60.6 KB

Figure 5: Heatmap showing nonce gap frequency (as percentage of total transactions) across all shard and skewness configurations.

4.2 Numerical Results

4.3 Key Patterns

1. Vertical Pattern (More Shards): Increasing shards increases gap frequency, but with diminishing returns
2. Horizontal Pattern (More Skewness): Higher skewness dramatically increases gap frequency
3. Worst Case: Very high skewness + 32 shards = ~36% of transactions affected
4. Best Case: Uniform distribution + 2 shards = ~3.6% of transactions affected

5. Analysis

5.1 Why Skewness Matters

Unlike our initial hypothesis, skewness significantly affects nonce gap frequency. This is because:

1. Skewed distributions concentrate transactions among fewer senders
2. Concentrated senders have more same-slot consecutive pairs
3. More same-slot pairs = more opportunities for nonce gaps

With uniform distribution, blob transactions are spread across 100 senders, making same-slot consecutive pairs from the same sender rare. With very high skewness (reflecting a network dominated by major L2 sequencers like Base), a few dominant senders produce many same-slot consecutive pairs, each with a (N-1)/N probability of being a gap.

5.2 Why This Supports EIP-8077

5.3 Implications for Different Network Conditions

6. Conclusions

6.1 Key Findings

1. Nonce gaps are a significant problem: Up to 36% of transactions can be affected in high-skewness, high-shard scenarios.

2. Skewness is a major factor: Networks with dominant blob senders (major L2 sequencers like Base, Optimism, Arbitrum) face substantially higher gap rates than networks with uniform transaction distribution.

3. Sharding exacerbates the problem: More shards = more gaps, following (N-1)/N probability for each same-slot pair.

4. Same-slot analysis is critical: Focusing on what matters to proposers (gaps within their block-building window) gives actionable insights.

6.2 Support for EIP-8077

This simulation provides strong quantitative support for EIP-8077:

• The problem is real: A significant percentage of transactions are affected by nonce gaps
• The problem is scalable: It worsens as Ethereum adds more shards/throughput
• The solution is targeted: Sender/nonce metadata enables intelligent fetching
• The benefit is measurable: Nodes can reduce wasted bandwidth and improve block building efficiency

6.3 Recommendations

1. Adopt EIP-8077 to provide nodes with the metadata needed for intelligent blob transaction fetching
2. Prioritize major L2 sequencers when fetching to maintain complete nonce sequences for high-volume blob senders
3. Consider sender-aware shard assignment as a complementary strategy to reduce gaps at the protocol level

7. Future Work

• Simulate the impact of EIP-8077’s metadata on fetching efficiency
• Model different fetching strategies enabled by sender/nonce information
• Analyze real Ethereum mainnet transaction patterns for skewness calibration
• Consider dynamic shard rebalancing scenarios
• Study the interaction with other scaling solutions (rollups, data availability sampling)

Appendix: Code Structure

The simulation is implemented in EIP-8077/simu.py with the following components:

Configurable Parameters (at top of EIP-8077/simu.py):

NUM_SLOTS = 216000        # 30 days worth of slotsAVG_TX_PER_SLOT = 14      # Target average transactions per slotMAX_TX_PER_SLOT = 21      # Maximum transactions per slotNUM_SENDERS = 100         # Number of unique senders

Dependencies: numpy, matplotlib, random