Abstract

The Ethereum blockchain has long confronted formidable scalability challenges, fundamentally restricting its capacity to process a substantial volume of transactions with requisite efficiency and affordability. Layer 2 (L2) solutions have emerged as critical architectural advancements, particularly in the form of rollups, which significantly alleviate this burden by executing transactions off-chain and subsequently consolidating their data for periodic settlement on the main Ethereum network (Layer 1). The Dencun upgrade, with the introduction of data blobs (EIP-4844), represented a foundational shift, providing a purpose-built, cost-effective channel for L2s to publish data. Building upon this, the Ethereum Improvement Proposal (EIP) 7691, a pivotal component of the Pectra upgrade, marks another significant escalation in Ethereum’s data availability strategy. This EIP dramatically enhances the scalability of L2 solutions by increasing the permissible number of data blobs per block on Layer 1. This comprehensive report meticulously examines the technical underpinnings of EIP-7691, elucidates its profound implications for Ethereum’s transactional throughput and cost structure, and analyzes its broader strategic impact on the evolving Ethereum ecosystem, including potential challenges and future synergistic developments such as Verkle Trees and PeerDAS.

1. Introduction

Ethereum’s journey from its inception has been characterized by a persistent tension between its core tenets of decentralization, security, and the imperative for scalability. The network’s original design, prioritizing robust security mechanisms and a decentralized consensus, inherently imposed limitations on its transaction throughput, leading to periods of acute network congestion and prohibitively high transaction costs, commonly referred to as ‘gas fees’. These systemic bottlenecks not only hampered user experience but also constrained the potential for widespread adoption of decentralized applications (dApps) and various decentralized finance (DeFi) protocols (Ju, 2025).

In response to these challenges, the Ethereum community and development ecosystem embarked on a multifaceted approach to scaling, with Layer 2 solutions emerging as a cornerstone strategy. L2 technologies operate by offloading the bulk of transaction processing from the resource-intensive Layer 1 mainnet, subsequently submitting a compressed summary or cryptographic proof of these off-chain operations back to Ethereum for finality. Among these, rollups have gained prominence, bundling numerous off-chain transactions into a single, succinct Layer 1 transaction, thereby amortizing the cost across many users.

The evolution of L2 efficiency has been inextricably linked to the method by which they post their transaction data back to Layer 1. Initially, L2s relied on CALLDATA, an existing data field within Ethereum transactions, which proved inefficient and costly due to its permanent storage requirement on all Ethereum nodes. A paradigm shift occurred with the Dencun upgrade (EIP-4844, often referred to as Proto-Danksharding), which introduced ‘data blobs’. These ephemeral, specialized data segments offered a significantly more efficient and cheaper mechanism for L2 solutions to post data to Layer 1. Blobs, designed for temporary storage and optimized for data availability, were a crucial precursor to Ethereum’s long-term sharding vision.

Building directly upon the foundational capabilities established by EIP-4844, EIP-7691, incorporated into the forthcoming Pectra upgrade, represents a crucial next step in enhancing this data availability layer. By effectively increasing the number of data blobs that can be included in each Ethereum block, EIP-7691 aims to further amplify the transactional capacity of L2 networks. This augmentation is projected to directly translate into enhanced scalability, significantly lower transaction costs for end-users interacting with L2 protocols, and a more robust and accessible Ethereum ecosystem. This paper delves into the technical specifics of this proposal, its immediate and long-term implications, and its position within Ethereum’s broader scalability roadmap.

2. Background

Many thanks to our sponsor Panxora who helped us prepare this research report.

2.1 Ethereum’s Scalability Challenges: A Deep Dive

Ethereum’s architecture, while pioneering in its ability to support decentralized applications and smart contracts, has historically faced profound scalability limitations. These limitations stem from its design philosophy, which prioritized maximal decentralization and security through a single, globally replicated state machine. Every transaction processed on Layer 1 must be validated and stored by every node in the network, a design choice that inherently caps throughput.

The core constraints on Ethereum’s Layer 1 scalability include:

• Block Size and Block Time: Ethereum blocks are created approximately every 12-15 seconds. While there isn’t a fixed ‘block size’ in bytes like Bitcoin, there is a ‘gas limit’ per block (currently around 30 million gas). This gas limit dictates the maximum computational work a block can contain. When demand for block space exceeds this capacity, transactions compete via a fee market, leading to higher gas prices.
• Sequential Processing: Transactions within a block are processed sequentially by the Ethereum Virtual Machine (EVM). This synchronous execution model prevents parallel processing, a common strategy for scaling traditional computing systems, further bottlenecking throughput.
• Data Storage and State Growth: Every transaction, particularly those involving contract interactions, contributes to the growth of Ethereum’s state – the aggregate collection of all account balances, contract code, and contract storage. This ever-growing state must be stored and accessed by full nodes, increasing hardware requirements and synchronization times, which can deter new node operators and threaten decentralization.
• Proof-of-Work (PoW) Era Limitations: Prior to The Merge, Ethereum relied on a PoW consensus mechanism. While robust for security, PoW was energy-intensive and inherently limited block production frequency due as a result of the random nature of finding valid hashes. The transition to Proof-of-Stake (PoS) with The Merge (ConsenSys, 2025) removed this particular constraint, enabling deterministic block times and paving the way for further upgrades like Danksharding.

These technical limitations have had significant economic and experiential consequences, including persistent high gas fees during periods of network congestion, slow transaction finality, and a barrier to entry for users and developers who cannot absorb the costs. This situation highlights the ‘scalability trilemma,’ a concept often attributed to Vitalik Buterin, which posits that a blockchain can only optimally achieve two out of three desirable properties: decentralization, security, and scalability. Ethereum’s initial focus on the former two necessitated innovative solutions to address the third.

Many thanks to our sponsor Panxora who helped us prepare this research report.

2.2 Layer 2 Solutions: Architectures and Mechanics

Layer 2 solutions represent a crucial paradigm shift in Ethereum’s scaling strategy. Instead of attempting to increase Layer 1’s inherent transaction processing capacity, L2s offload the majority of computation and storage off-chain, leveraging Layer 1 only for security guarantees and ultimate data availability (Memo D Foundation, 2022). This hybrid approach allows Ethereum to maintain its core security and decentralization while achieving significantly higher transaction throughput.

2.2.1 Rollups: The Dominant L2 Strategy

Rollups are currently the most prominent and widely adopted L2 scaling solution. They operate by executing transactions off-chain, batching hundreds or thousands of these transactions together, and then posting a compressed summary or cryptographic proof of these batches back to Layer 1. The key advantage of rollups is that all transaction data (or a commitment to it) is eventually made available on Layer 1, allowing anyone to reconstruct the L2 state and verify its correctness, thereby inheriting Layer 1’s robust security. There are two primary types:

• Optimistic Rollups:

  • Mechanism: Optimistic rollups assume that all transactions processed off-chain are valid by default. They publish the new state root (a cryptographic hash representing the L2 state) to Layer 1 along with a compressed version of the transaction data.
  • Fraud Proofs: To ensure security, optimistic rollups implement a ‘challenge period’ (typically 7 days). During this window, anyone can submit a ‘fraud proof’ to Layer 1 if they detect an invalid state transition. If a fraud proof is successful, the invalid batch is reverted, and the sequencer (the entity that proposed the batch) is penalized.
  • Benefits: Relatively simpler to implement and achieve high EVM compatibility.
  • Drawbacks: The challenge period introduces a significant delay for withdrawals from the L2 to Layer 1, impacting capital efficiency. Users often rely on ‘fast bridges’ or liquidity providers to circumvent this delay, incurring additional fees.
  • Examples: Arbitrum, Optimism.

• Zero-Knowledge (ZK) Rollups:

  • Mechanism: ZK-rollups use sophisticated cryptographic proofs, specifically Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs or zk-STARKs), to validate off-chain transactions. Instead of assuming validity, they cryptographically prove the validity of every state transition off-chain. This proof is then submitted to Layer 1 alongside a new state root. Layer 1 smart contracts can quickly verify these proofs, confirming the correctness of thousands of off-chain transactions in a single L1 transaction.
  • Validity Proofs: Unlike fraud proofs, validity proofs are generated before the batch is finalized on Layer 1, meaning the correctness is assured immediately upon L1 inclusion.
  • Benefits: Instant finality (relative to optimistic rollups) for L1 withdrawals, higher capital efficiency, and stronger cryptographic security guarantees. They also offer privacy potential in some constructions.
  • Drawbacks: Historically complex to build, particularly achieving full EVM compatibility (ZK-EVMs). The computational overhead for proof generation can be significant, though this is amortized across many transactions.
  • Types of ZK-Rollups:
    • ZK-EVMs: Aim to be fully compatible with the Ethereum Virtual Machine, allowing existing Ethereum dApps to be deployed with minimal changes. Different ‘types’ exist based on their degree of EVM equivalence (e.g., Type 1, 2, 3, 4 ZK-EVMs).
    • Validiums: Similar to ZK-rollups in using validity proofs, but they store transaction data off-chain with a trusted committee or data availability committee (DAC) rather than directly on Layer 1. This offers even higher scalability but sacrifices some of Layer 1’s data availability guarantees, making them slightly less secure (Huang et al., 2024).
    • Volitions: Hybrid solutions that allow users to choose between a ZK-rollup (data on-chain) or a Validium (data off-chain) model, offering flexibility between security and scalability.
  • Examples: Polygon zkEVM, zkSync Era, Scroll, StarkWare’s Starknet (which uses a ZK-STARK based Validium/Rollup hybrid).

2.2.2 Other L2 Solutions: State Channels and Plasma

While rollups are currently dominant, earlier L2 designs laid important groundwork:

• State Channels:

  • Mechanism: State channels allow participants to conduct an arbitrary number of off-chain transactions directly between themselves without interacting with Layer 1 for each transaction. Only the initial channel opening and the final state settlement require Layer 1 interaction.
  • Use Cases: Ideal for high-frequency, peer-to-peer interactions like gaming, micropayments, or frequent trades between a fixed set of participants.
  • Limitations: Do not scale for general-purpose smart contracts or open participation, as they require all participants to be online and agree on the final state. Capital is locked within the channel for its duration.
  • Examples: Raiden Network, Connext (though Connext has evolved to also support various L2s).

• Plasma:

  • Mechanism: Plasma chains create a tree of ‘child chains’ that periodically commit their root hash to the main Ethereum chain. Transactions occur on these child chains, with fraud proofs (similar to optimistic rollups) used to ensure correctness. Funds can be moved between the mainnet and Plasma chains.
  • Limitations: Complex to implement, particularly for general-purpose smart contracts. The ‘mass exit problem’ – where many users try to withdraw funds simultaneously in response to a security threat – was a significant challenge. Handling complex state transitions and fraud proofs for arbitrary EVM operations proved difficult.
  • Examples: Polygon Plasma, OmiseGo (OMG).

The limitations of State Channels and Plasma, particularly their difficulty in handling general-purpose EVM computation and potential for mass exit challenges, contributed to the industry’s shift towards rollups as the preferred L2 scaling paradigm. Rollups offer a better balance of scalability, security (by keeping data on Layer 1), and composability with Ethereum’s existing ecosystem.

Many thanks to our sponsor Panxora who helped us prepare this research report.

2.3 Data Availability and Blobs (EIP-4844 / Dencun Upgrade)

Data availability is a paramount concern for the security and functionality of L2 solutions. For a rollup to be truly secure, users must be able to access the data necessary to reconstruct the L2 state and verify that all transactions and state transitions are valid. Without reliable data availability, a malicious L2 operator could censor transactions or publish an invalid state, and users would have no way to detect or prove this fraud. In the context of optimistic rollups, accessible data is essential for submitting fraud proofs; for ZK-rollups, it allows users to verify that the cryptographic proofs accurately reflect the underlying transactions.

Prior to the Dencun upgrade (encompassing EIP-4844), rollups relied on CALLDATA to publish their transaction data to Layer 1. CALLDATA is an input field for transactions on Ethereum, and while it could be used to post rollup data, it suffered from several significant drawbacks:

• Permanent Storage: Data posted via CALLDATA is stored indefinitely by all Ethereum full nodes as part of the blockchain’s history. This contributes directly to Ethereum’s ever-growing state size, increasing storage requirements for nodes and potentially hindering decentralization.
• High Cost: Storing data permanently is expensive. The gas cost for CALLDATA was relatively high, especially for non-zero bytes, meaning that as rollup usage increased, so did the costs for L2 operators, which were then passed on to users.
• Inefficient Use Case: CALLDATA was not designed for this specific purpose. It’s meant for function parameters, not for bulk, ephemeral data availability.

2.3.1 EIP-4844 (Proto-Danksharding): The Introduction of Blobs

EIP-4844, colloquially known as Proto-Danksharding, was the centerpiece of the Dencun upgrade and represented a foundational step towards Ethereum’s full sharding vision. Its primary innovation was the introduction of ‘data blobs’ (also called ‘blob-carrying transactions’ or ‘beacon blobs’) (Everstake, 2025).

• Ephemeral Data Storage: Unlike CALLDATA, blobs are designed for temporary storage. While they are fully propagated and available to all nodes for a period, they are ultimately pruned from the network after a defined duration, currently specified as 4,096 epochs (approximately 18 days). This ephemeral nature is crucial because it significantly reduces the long-term storage burden on Ethereum nodes, addressing a key scalability bottleneck.
• Dedicated Data Channel: Blobs provide a purpose-built data channel specifically optimized for the data availability needs of rollups. They exist alongside regular Ethereum transactions but are handled differently by the network.
• KZG Commitments: Blobs utilize Kate-Zaverucha-Goldberg (KZG) polynomial commitments. Instead of placing raw blob data directly into the execution payload (the part of the block processed by the EVM), the execution layer only sees a cryptographic commitment (a short, fixed-size hash) to the blob’s data. The actual blob data is handled by the consensus layer (beacon chain). This separation allows for efficient processing and future integration with data availability sampling (DAS).
• New Fee Market (blob_gas): EIP-4844 introduced a separate fee market for blob inclusion, distinct from the existing base_fee for regular transaction gas. This blob_gas market operates with its own blob_base_fee, which adjusts dynamically based on blob demand. This allows blob prices to rise and fall independently of execution gas prices, providing more stable and predictable costs for rollups.
• Initial Capacity: Dencun initially set the target number of blobs per block to 3, with a maximum of 6 blobs per block. This provided an immediate increase in data throughput capacity for L2s at a reduced cost compared to CALLDATA.

The introduction of blobs via EIP-4844 was a landmark achievement, providing L2s with a significantly cheaper and more scalable way to post data to Layer 1. This mechanism immediately lowered costs for rollup users and laid the essential groundwork for more ambitious scaling efforts, including EIP-7691 and ultimately full Danksharding.

3. EIP-7691: Doubling Blob Throughput in Pectra

Many thanks to our sponsor Panxora who helped us prepare this research report.

3.1 Overview of EIP-7691 and the Pectra Upgrade

EIP-7691, formally titled ‘Increase max_blob_gas_per_block’, is a critical component of the upcoming Pectra upgrade (BlockNuggets, 2025). The Pectra upgrade itself is a multifaceted hard fork that continues Ethereum’s post-Merge development roadmap, focusing on further enhancing scalability, improving validator experience, and paving the way for future protocol advancements. EIP-7691 specifically targets the data availability layer introduced by EIP-4844, recognizing the growing demand for blob space from Layer 2 solutions.

The core proposal of EIP-7691 is straightforward yet impactful: to increase the permissible number of data blobs that can be included in a single Ethereum block. Specifically, it proposes:

• Raising the Target Number of Blobs per Block: From the initial 3 (set by EIP-4844) to 6.
• Increasing the Maximum Number of Blobs per Block: From the initial 6 (set by EIP-4844) to 9.

This adjustment effectively doubles the ‘target’ blob throughput of the Ethereum network. The ‘target’ is a crucial parameter in the EIP-1559-like fee market for blobs; maintaining the target number of blobs causes the blob_base_fee to remain stable. Surpassing the target causes the blob_base_fee to increase, while falling below it causes the blob_base_fee to decrease. By raising this target, EIP-7691 directly increases the steady-state capacity for blob data, allowing L2s to publish significantly more information to Layer 1 without triggering an exponential increase in blob_gas prices. This expansion is designed to proactively accommodate the escalating data requirements of a thriving L2 ecosystem, ensuring continued cost efficiency and scalability.

Many thanks to our sponsor Panxora who helped us prepare this research report.

3.2 Technical Details and Mechanism of Action

To fully appreciate the impact of EIP-7691, it is essential to understand the technical underpinnings of blobs and their fee market.

3.2.1 Blob Structure and Processing

Each data blob consists of a fixed amount of data, approximately 128KB. When an L2 rollup submits a batch of transactions, it bundles the necessary data into one or more blobs. These blobs are then attached to an Ethereum transaction. This transaction, instead of including CALLDATA directly, includes KZG commitments to the blob data.

The process unfolds as follows:

1. L2 Batching: An L2 sequencer batches numerous off-chain transactions.
2. Blob Creation: The sequencer packages the necessary transaction data (e.g., compressed transaction inputs, state diffs) into one or more data blobs.
3. KZG Commitment: A cryptographic KZG commitment is generated for each blob. This commitment is a small, fixed-size proof that cryptographically links to the entire blob data without revealing it directly.
4. Transaction Submission: An L2 transaction is constructed that includes these KZG commitments and a blob_gas payment. This transaction is sent to the Ethereum Layer 1 mempool.
5. Block Inclusion: Ethereum validators select transactions and blobs for inclusion in a new block. The actual blob data is transmitted across the beacon network, separate from the execution payload, but the KZG commitments are included in the execution payload. This means the execution layer knows which blobs are part of the block, but the raw data is handled by the consensus layer, optimized for data availability.
6. Ephemeral Storage: Full nodes (specifically beacon nodes) download and store the blob data for the ~18-day period, making it available for verification by anyone. After this period, the data is pruned, reducing storage burden.

EIP-7691 modifies the parameters that govern how many such blob-carrying transactions can be included in a block. The core parameter MAX_BLOB_GAS_PER_BLOCK is the total blob_gas limit for a block, and TARGET_BLOB_GAS_PER_BLOCK is the target for the EIP-1559-like pricing mechanism. With EIP-7691, TARGET_BLOB_GAS_PER_BLOCK increases from 2 * GWEI_PER_BLOB * 3 to 2 * GWEI_PER_BLOB * 6, and MAX_BLOB_GAS_PER_BLOCK increases from 2 * GWEI_PER_BLOB * 6 to 2 * GWEI_PER_BLOB * 9, where GWEI_PER_BLOB represents the gas cost per blob. This effectively allows for a sustained throughput of 6 blobs per block and bursts of up to 9 blobs.

3.2.2 Impact on the blob_gas Fee Market

The blob_gas pricing mechanism, introduced with EIP-4844, operates similarly to EIP-1559 for execution gas. It features a blob_base_fee that adjusts dynamically based on the demand for blob space. If the average number of blobs over a series of blocks exceeds the TARGET_BLOB_GAS_PER_BLOCK, the blob_base_fee increases, making blobs more expensive. Conversely, if demand falls below the target, the fee decreases.

By doubling the TARGET_BLOB_GAS_PER_BLOCK (from 3 to 6 blobs), EIP-7691 significantly expands the ‘equilibrium’ point of the blob market. This means that L2s can now post twice as much data on average before the blob_base_fee begins to aggressively increase. This has several crucial implications:

• Lower Average Costs: With increased capacity, the likelihood of the blob_base_fee spiking due to temporary high demand is reduced. Rollup operators will face more stable and generally lower blob_gas prices, which they can pass on to their users.
• Reduced Volatility: The expanded buffer zone between the target and maximum capacity will help smooth out blob_gas price fluctuations, providing more predictable operational costs for L2s.
• Enhanced Throughput at Stable Prices: L2s can maintain a higher average data publication rate without significantly impacting their cost structure, leading to sustained higher throughput for the entire ecosystem.

This technical adjustment directly translates into tangible benefits for L2 users, as the primary cost component for rollups (data availability on L1) is substantially mitigated.

Many thanks to our sponsor Panxora who helped us prepare this research report.

3.3 Impact on Layer 2 Solutions

EIP-7691’s increase in blob capacity directly addresses the most significant operational cost for Layer 2 rollups: posting transaction data to Layer 1. The implications are far-reaching and predominantly positive for the L2 ecosystem.

3.3.1 Enhancing Data Availability

The most immediate benefit is the substantial enhancement of data availability. With more blobs available per block, L2s can publish more comprehensive and frequent state updates or transaction batches to Layer 1. This improves the fundamental security guarantee of rollups:

• For Optimistic Rollups: More available blob space means that the data required for fraud proofs is more readily and cheaply published on Layer 1. This strengthens the security model by ensuring that potential fraudulent state transitions can be challenged effectively and affordably. It also allows for potentially larger batches, further reducing per-transaction costs.
• For ZK-Rollups: Although ZK-rollups rely on cryptographic validity proofs for security, they still need to publish data (or commitments to data) to Layer 1 for users to reconstruct their local state and for general data availability. Increased blob capacity means they can post more data more frequently, facilitating faster finality and potentially allowing for more detailed state information to be available on Layer 1, improving overall transparency and user experience.

3.3.2 Reducing Transaction Costs

This is perhaps the most celebrated and direct benefit for end-users. The cost of transacting on an L2 is primarily a function of two components:

1. L2 Execution Fees: The cost of processing the transaction on the L2 itself.
2. L1 Data Availability Fees: The cost of posting the transaction data (or proof) to Layer 1 via blobs.

Prior to blobs, L1 data availability fees were the dominant and often prohibitive component of L2 transaction costs. EIP-4844 dramatically reduced this, and EIP-7691 further compounds this reduction by:

• Increased Supply, Reduced Price: By doubling the ‘target’ capacity for blobs, the increased supply meets a growing demand, effectively lowering the equilibrium blob_base_fee. This translates directly into cheaper rollup transactions for users (Gate.com, 2025).
• Amortization of Fixed Costs: L2 operators pay for blob space. With more capacity, they can consolidate even larger batches of transactions into a single blob or set of blobs, further amortizing the fixed cost of L1 data posting across more individual transactions. This drives down the per-transaction cost even further.

These cost reductions are pivotal for wider adoption, enabling micro-transactions, more frequent interactions with dApps, and making DeFi accessible to a broader user base that might be priced out by high Layer 1 fees.

3.3.3 Improving Overall Scalability and Throughput

While L2s handle the majority of transaction execution, their ultimate throughput is still bottlenecked by the rate at which they can commit data to Layer 1. By doubling the blob throughput, EIP-7691 effectively doubles the theoretical peak data commitment rate for L2s. This means:

• Higher Transaction Volume: L2s can process and finalize a significantly higher volume of transactions per second, as their ability to ‘settle’ on L1 is less constrained.
• Smoother Operations: L2 sequencers will experience less pressure and fewer delays in publishing batches to L1, leading to more consistent and faster transaction finality for users.
• Enabling New Use Cases: The combination of lower costs and higher throughput opens the door for new types of dApps and services that were previously economically unfeasible on Ethereum, such as high-frequency trading platforms, large-scale gaming environments, and more complex social applications.

In essence, EIP-7691 empowers L2s to fully realize their scaling potential, allowing them to process more transactions at a lower cost, thereby making the entire Ethereum ecosystem more performant and accessible.

4. Implications for Ethereum’s Ecosystem

EIP-7691 is not merely a technical tweak; it is a strategic advancement that carries broad implications across the Ethereum ecosystem, touching upon economic structures, technical considerations, and future developmental pathways.

Many thanks to our sponsor Panxora who helped us prepare this research report.

4.1 Economic Impact

4.1.1 Enhanced Adoption and Market Expansion

The reduction in transaction fees, primarily driven by the increased blob capacity, is a powerful catalyst for wider adoption of Ethereum’s L2 solutions. When costs decrease, the barrier to entry for users, especially those in developing economies or those with smaller transaction sizes, is significantly lowered. This can lead to:

• Increased User Base: More users will be able and willing to interact with dApps, DeFi protocols, and NFTs on L2s.
• Growth of Micro-transactions: Small-value transactions, previously uneconomical on Layer 1 due to high gas fees, become viable on L2s. This could foster new applications in areas like gaming, content monetization, and social media.
• Developer Incentives: Lower costs on L2s make it more attractive for developers to build and deploy dApps, as they can expect a larger and more engaged user base. This increased activity drives further innovation within the ecosystem.
• Competitive Advantage: Ethereum’s L2 ecosystem, with its robust security inheritance from Layer 1 and now enhanced cost-efficiency, becomes even more competitive against alternative Layer 1 blockchains, solidifying its position as a leading smart contract platform.

4.1.2 Impact on Layer 1 Gas Fees and Economic Value

The relationship between L2 activity and L1 gas fees is nuanced. As L2s become more efficient and absorb a greater share of transactional volume, direct user activity on Layer 1 for simple transfers or contract interactions might decrease. This could lead to a stabilization or even a gradual reduction in the base_fee for traditional Layer 1 transactions, as demand shifts to the cheaper L2 channels.

However, L2s still rely on Layer 1 for security and data availability, meaning they pay Layer 1 for blob space and for settling validity/fraud proofs. This implies a shift in Layer 1’s economic value proposition: from processing individual user transactions to becoming a secure, decentralized settlement and data availability layer for other chains and protocols. The economic value for Ethereum’s Layer 1 would then increasingly be derived from the ‘rent’ paid by L2s for its security and data guarantees, rather than direct user-to-user transactions.

This shift supports the ‘rollup-centric roadmap,’ where Layer 1 focuses on its core competencies of security, decentralization, and data availability, while L2s handle application-specific logic and high throughput (PANews, 2025). The overall economic activity within the Ethereum ecosystem is expected to grow substantially, with Layer 1 capturing a significant portion of this value through its role as the ultimate arbiter.

Many thanks to our sponsor Panxora who helped us prepare this research report.

4.2 Technical Considerations and Challenges

While EIP-7691 offers substantial benefits, its implementation, and the broader increase in data throughput, present several technical considerations that must be carefully managed.

4.2.1 Node Storage Requirements

Despite the ephemeral nature of blobs (pruned after ~18 days), the increased number of blobs per block means that full nodes must process, validate, and store more data concurrently during the temporary availability window.

• Temporary Peak Storage: While not contributing to the permanent state growth as CALLDATA did, a node must temporarily store up to 9 blobs (each ~128KB) for approximately 18 days. This translates to roughly 9 blobs/block * 128 KB/blob * 240 blocks/hour * 24 hours/day * 18 days which equates to several terabytes of data that a full node must be able to ingest and store for the retention period. While modern storage devices can handle this, it still represents a non-trivial increase in I/O and storage requirements, especially for consumer-grade hardware.
• Impact on Decentralization: A significant increase in hardware requirements could potentially raise the barrier to entry for running a full node, leading to a reduction in the number of node operators. This could subtly impact network decentralization, a core tenet of Ethereum. Developers are actively working on strategies to mitigate this, such as improved client syncing, stateless clients (which only need to verify a proof of state rather than storing the entire state), and Verkle Trees (discussed below).

4.2.2 Network Bandwidth and Latency

Propagating more data blobs with each block inevitably increases the network bandwidth requirements for Ethereum nodes. Every node participating in the P2P network needs to download and relay these blobs.

• Increased Traffic: The aggregate data traffic across the Ethereum P2P network will rise. For nodes with limited internet bandwidth, this could lead to increased latency in block propagation, slower synchronization, and potentially a higher rate of ‘orphan blocks’ (blocks that are valid but not adopted by the network because another valid block was propagated faster). While Ethereum’s P2P network is generally robust, continuous increases in data load require ongoing optimization and monitoring.
• Validator Performance: For validators, timely receipt of new blocks and their associated blobs is critical for optimal performance and maximizing rewards. Any delays due to bandwidth constraints could lead to missed attestations or block proposals.
• Mitigation Strategies: Ongoing research into P2P network optimizations, such as better block propagation algorithms (e.g., GOSSIP) and specialized data distribution techniques (e.g., data availability sampling, DAS), are crucial to address these concerns. Client diversity is also important, as different client implementations might handle network load differently, providing resilience.

4.2.3 Client Development and Upgrade Complexity

Implementing EIP-7691 requires coordinated upgrades across all Ethereum client software (execution and consensus layers). Ensuring smooth deployment without introducing vulnerabilities or breaking existing functionality is a significant engineering challenge. Thorough testing, client diversity (encouraging multiple independent client implementations), and a phased rollout are crucial for successful hard forks like Pectra. The complexity of managing these upgrades increases with each new feature, demanding continued diligence from core developers.

Many thanks to our sponsor Panxora who helped us prepare this research report.

4.3 Future Developments and Roadmap Synergy

EIP-7691 is not an isolated upgrade but a synergistic component of Ethereum’s long-term scalability roadmap. It directly contributes to the vision of a sharded Ethereum and paves the way for further advancements.

4.3.1 Verkle Trees

Verkle Trees are a proposed data structure designed to replace Ethereum’s existing Merkle Patricia Tries for state representation. Their adoption is a critical step towards achieving statelessness on Ethereum’s Layer 1.

• Mechanism: Verkle Trees offer significantly smaller ‘proof sizes’ compared to Merkle Patricia Tries. A ‘witness’ (a cryptographic proof that a specific piece of data exists within the state) in a Verkle Tree is much smaller.
• Benefits:
  • Reduced State Size: While blobs address temporary data, Verkle Trees tackle the permanent state size. Smaller witnesses mean that light clients and even full nodes would need to store less data to verify state transitions.
  • Faster Syncing and Verification: With smaller proofs, nodes can synchronize faster and verify blocks more efficiently, reducing the burden on node operators.
  • Enabling Statelessness: Crucially, Verkle Trees are a prerequisite for ‘stateless clients’ and ‘stateless validators.’ In a stateless model, validators would no longer need to store the entire Ethereum state. Instead, they would receive a block along with a ‘witness’ (a small proof generated by block proposers) that allows them to verify the block’s validity without having the entire state locally. This drastically lowers the hardware requirements for running a validator, further enhancing decentralization and resilience.
• Synergy with Blobs: While blobs address data availability for L2s, Verkle Trees address the efficiency of Layer 1’s own state management. Both are crucial for scaling the overall network and reducing hardware requirements for participation.

4.3.2 PeerDAS (Polynomial-Commitment-based Data Availability Sampling)

PeerDAS is an advanced data availability sampling (DAS) protocol that represents the next major step after Proto-Danksharding (EIP-4844) towards full Danksharding.

• Data Availability Sampling (DAS): In a sharded Ethereum, data will be spread across many ‘shards.’ Full nodes would be unable to download all data from all shards. DAS allows light clients and even full nodes to probabilistically verify that data is available across all shards by downloading only a small, random sample of the data. If enough random samples are available, it’s highly probable that all the data is available.
• Mechanism: PeerDAS specifically leverages the KZG commitments already introduced with EIP-4844. It uses erasure coding to encode blob data in a redundant way, allowing for reconstruction even if parts of the data are missing. Nodes can then perform random sampling on these encoded data segments.
• Benefits:
  • Massive Scalability: PeerDAS will enable Ethereum to handle truly enormous amounts of data throughput (potentially hundreds of thousands of transactions per second across all shards), making it a global-scale settlement layer.
  • Decentralized Data Availability: It ensures that even with massive data volumes, light clients can securely verify data availability without needing to download all data, maintaining decentralization.
  • Full Danksharding: PeerDAS is a prerequisite for the full implementation of Danksharding, where the target number of blobs per block could increase to 64, significantly expanding Layer 1’s data throughput.
• Synergy with EIP-7691: EIP-7691 increases the current blob capacity within the Proto-Danksharding framework. PeerDAS builds on this by providing the infrastructure and sampling mechanisms to securely and efficiently scale blob throughput to a much higher order of magnitude in the future.

4.3.3 Other Pectra EIPs and Broader Roadmap

The Pectra upgrade includes other EIPs, such as EIP-7251 (increasing the MAX_EFFECTIVE_BALANCE for validators to 2048 ETH), which aims to reduce the validator queue and enhance staking efficiency. While not directly related to blob throughput, these EIPs collectively contribute to the network’s overall health, security, and decentralization, which are foundational for sustaining and scaling the L2 ecosystem.

In essence, EIP-7691 is a pragmatic and immediate enhancement within a larger, well-defined roadmap. It leverages existing infrastructure (EIP-4844 blobs) to deliver tangible benefits today while simultaneously setting the stage for more ambitious, long-term scaling solutions that will further cement Ethereum’s role as the backbone of the decentralized economy.

5. Conclusion

The Ethereum blockchain’s evolution is a continuous testament to its commitment to overcoming inherent technical limitations while preserving its core values of decentralization and security. The introduction of EIP-7691 within the Pectra upgrade represents a pivotal and strategic advancement in this ongoing journey, building directly upon the foundational capabilities established by the Dencun upgrade’s EIP-4844. By significantly increasing the number of data blobs that can be included in each Layer 1 block – doubling the target throughput from 3 to 6 blobs and raising the maximum to 9 – Ethereum materially enhances the capacity for Layer 2 rollup solutions to post transaction data.

This augmentation translates into concrete and far-reaching benefits for the entire Ethereum ecosystem. Foremost among these is a substantial reduction in transaction costs for users operating on L2 networks. The expanded blob space mitigates competition for inclusion, leading to lower blob_base_fees and more stable pricing, thereby making decentralized applications and services more accessible and affordable. Concurrently, the increased data availability per block allows L2s to process and finalize a higher volume of transactions, bolstering overall network scalability and fostering greater throughput. These improvements are critical for driving wider adoption of Ethereum-based solutions, enabling new categories of dApps, and solidifying Ethereum’s position as a robust and efficient global settlement layer for decentralized finance and web3 innovation.

However, the benefits conferred by EIP-7691 are not without their corresponding technical considerations. The increased temporary data load, while carefully managed through the ephemeral nature of blobs, necessitates ongoing attention to node storage requirements and potential impacts on network bandwidth and peer-to-peer propagation efficiency. Ensuring that these increases do not inadvertently raise the barrier to entry for running a full node or degrade network performance remains a critical area for continuous research, optimization, and client implementation development.

Ultimately, EIP-7691 is best understood not as an isolated upgrade, but as a crucial, incremental step within Ethereum’s ambitious, long-term scalability roadmap. It perfectly complements future developments such as Verkle Trees, which promise to revolutionize Layer 1 state management and enable statelessness, and PeerDAS, which will unlock full data availability sampling for sharding. These interconnected advancements collectively underscore Ethereum’s iterative approach to scaling, where immediate improvements are harmonized with a visionary trajectory towards a highly scalable, secure, and decentralized global computing platform. The ongoing commitment to innovation and careful balancing of trade-offs are essential to ensure the continued growth, resilience, and efficiency of the Ethereum ecosystem for years to come.

References

• BlockNuggets. (2025). EIP-7691: Boosting Ethereum Blob Throughput in Pectra! Retrieved from blocknuggets.com
• BlockScholes. (2025). Ethereum’s Pectra Upgrade and the Market’s Cautious Reaction. Retrieved from blockscholes.com
• ConsenSys. (2025). Ethereum Pectra Upgrade: Everything You Need to Know. Retrieved from consensys.io
• Ethereum Foundation. (2025). Pectra Mainnet Announcement. Retrieved from blog.ethereum.org
• Everstake. (2025). Pectra Upgrade: What Changed in Ethereum After Its Biggest Update Since the Merge. Retrieved from everstake.one
• Gate.com. (2025). Coin Metrics: The Subsequent Impact of the Ethereum Pectra Upgrade. Retrieved from gate.com
• Gate.com. (2025). Ethereum Pectra Upgrade: The Maximum Staking Limit for Validators Has Been Raised to 2048 ETH, and the Layer-2 Scaling Capacity Has Been Doubled. Retrieved from gate.com
• Huang, C., Song, R., Gao, S., Guo, Y., & Xiao, B. (2024). Data Availability and Decentralization: New Techniques for zk-Rollups in Layer 2 Blockchain Networks. arXiv preprint arXiv:2403.10828. Retrieved from arxiv.org
• Ju, Y. (2025). How Layer 2 Solutions Scale Ethereum: Complete 2025 Guide. Retrieved from blog.ju.com
• Memo D Foundation. (2022). Layer 2: Scaling Solutions for Ethereum. Retrieved from memo.d.foundation
• PANews. (2025). What Impact Will the Ethereum Pectra Upgrade Have on the Ecosystem? Retrieved from panewslab.com
• TokenDailies. (2025). EIP-7691: The Ethereum Pectra Upgrade That Rocks! Retrieved from tokendailies.com