Ethereum News
Ethereum Pectra upgrade: Blob capacity and fee dynamics

Pectra increased the target blob capacity from 3 to 6 per block and set the maximum at 9. This expansion grows weekly target capacity from 150,000 blobs to 300,000 blobs. Because each blob contains 4096 field elements of 32 bytes each, the total size reaches 131,072 bytes. With 12-second slots creating 7,200 blocks daily, the network achieves 5.3 GiB of daily throughput at the 6-blob target. Pushing to the 9-blob maximum yields 7.9 GiB of daily throughput. I see that rollups used 25.6k blobs daily in the first five days post-launch, which represents a 20.8% increase over the pre-fork 21.2k daily average. Base captures about a third of the capacity, ranging from 50k to 60k blobs weekly. Taiko, World Chain, and Arbitrum compete for this space. Validators must manage more short-lived data between prune windows. Total retained data peaked at 44.6 GB just after the May 7, 2025, launch.
Metric
Pre-Pectra Value
Pectra Value
Target Blobs per Block
3
6
Max Blobs per Block
6
9
Weekly Blob Capacity
150,000
300,000
Daily Throughput (Target)
~2.7 GiB
~5.3 GiB
Daily Throughput (Max)
~4.1 GiB
~7.9 GiB
Fee responses to demand and calldata costs
Fee responses to demand changed with the May 7, 2025, activation. Full blobs increase the fee by 8.2%, while empty sections drop the fee by 14.5%. These new parameters ensure prices drop faster when demand falls below the 6-blob target. I find that the system responds more aggressively to low demand than the previous 11.1% dip. If a rollup pushes 2 MiB of compressed data every minute, it needs 16 blobs per minute. Ethereum produces 5 blocks every minute, requiring 3.2 blobs per block. This stays well below the 6-blob target. I think the decision to increase calldata costs was the right move for network stability. EIP-7623 raised the calldata floor price to 10 gas for zero bytes and 40 gas for non-zero bytes. This prevents data-heavy blocks from increasing execution layer load. If you want to calculate the exact cost for your specific batch, you must multiply the constant GAS_PER_BLOB value of 131,072 by the current blob_gas_price found in the block header to find the final fee.
| Fee Type | Parameter |
|---|---|
| Target Blob Gas | 786,432 |
| Max Blob Gas | 1,179,648 |
| Gas per Blob | 131,072 |
| Calldata Floor (Zero Byte) | 10 gas |
| Calldata Floor (Non-zero Byte) | 40 gas |
Validator and wallet functionality
EIP-7702 allows externally owned accounts to act as smart contract accounts for one transaction. This enables gas sponsorship, transaction batching, and custom asset access. Users opt in to programmable wallets that allow features like gasless transacting. EIP-7251 raises the maximum effective validator balance from 32 ETH to 2048 ETH. This allows stakers to consolidate multiple validators into one to reduce network overhead. Large stakers, including custodians and exchanges, benefit because they can let rewards compound without spinning up new validators. EIP-7002 allows stakers to trigger exits using execution layer withdrawal credentials. This removes the dependency on active validator keys or Beacon Chain access. EIP-6110 moves validator deposits to the execution layer, reducing the delay to about 13 minutes. EIP-2537 adds precompiles for BLS12-381 curve operations. This makes multi-signature verification and proof checks more efficient. You should keep track of blob gas settings in your client configuration to avoid dropping batches during spikes.
Data availability and future scaling
EIP-2935 saves 8192 block hashes in state to support stateless execution. This assists the protocol as developers move toward Verkle trees. Previously, the BLOCKHASH opcode only provided access to the last 256 blocks. EIP-7840 adds blob schedule fields to execution layer configuration files. This simplifies network tuning for different forks. EIP-7685 provides a framework for moving requests between the execution and consensus layers. This helps handle deposits, withdrawals, and validator consolidations. PeerDAS will increase blob space without overloading nodes. This change bridges the gap until higher blob counts arrive. Will PeerDAS fully solve the data availability pressure for all L2 scaling paths?