The economics of Ethereum’s Pectra upgrade and blob throughput

The Pectra upgrade changes how Ethereum handles data availability through EIP-7691. This community-driven proposal increases the target number of blobs from 3 to 6 per block and raises the maximum capacity from 6 to 9. These blobs are 128 KB chunks of binary data composed of 4096 32-byte blocks. This expansion targets the data availability needs of Layer 2 networks like Optimism and Polygon. These solutions rely on the main Ethereum chain to provide data, so higher capacity allows for better performance and lower costs. After the Dencun upgrade, Optimism transaction fees dropped to 0.009 USD and Arbitrum fees fell to 0.064 USD. EIP-7691 builds on this by using optimized node communication and gossipsub IDONTWANT messages to save bandwidth. The proposed increase in blob capacity from 3 to 6 per block aims to provide much-needed data availability for Layer 2 solutions that rely on Ethereum for settlement and security. The new target to maximum ratio of 2:3 affects how the base fee responds to demand. A full blob count increases the base fee by about 8.2%, while no blobs reduces it by 14.5%. I find the stability concerns for single-stakers and smaller nodes regarding larger blocks quite legitimate. If the network pushes too much data, smaller nodes might struggle to keep up with the increased bandwidth requirements. The transition involves updating consensus and execution clients across the Electra and Prague branches to replace old values with these new parameters. The current target blob gas per block is 786432, which corresponds to 6 blobs * 131072 bytes. The blob gas market operates through a mechanism similar to EIP-1559, ensuring that mainnet congestion does not affect blob transaction fees.

The economic relationship between execution gas and blob gas creates significant friction for rollup operators. EIP-7918 proposes bounding the blob base fee by execution cost to create a functional fee market. This proposal addresses the negative cross-elasticity of demand where high execution gas prices reduce the demand for blob space. Because blob-carrying transactions require both resources, they act as complementary goods. If execution costs spike because of a DeFi boom or a massive airdrop, the demand for data availability might not increase at the same rate. This creates a situation where blob fees could rise even when data resources remain underutilized. I think this creates a double burden for blob consumers when execution costs are high and increasing. Current rollups must calculate fees based on the base fee, the blob base fee, and the priority fee. The proposed change aims to simplify this by removing the need to reason about a third fee during periods of congestion. One argument suggests that execution gas acts as a price dampening mechanism, but I find that this could prevent the blob fee market from accurately reflecting supply and demand. This logic is like saying that rising electricity prices should not affect the demand for appliances. In a multidimensional gas roadmap, fee markets can either be independent or bound together. If they are independent, resource prices reflect only their own demand. Companies often employ strategies like pricing printers low and ink cartridges high to maximize profits. Will this binding of markets actually simplify the fee calculation for the OP stack, or will it just introduce more complexity for developers?

Arbitrum is countering the pressure of lower L2 costs by introducing Stylus, a WASM-based execution environment. Stylus allows smart contracts to run in languages like Rust, C, C++, and AssemblyScript. This provides a significant performance advantage over the standard Arbitrum EVM. While the EVM provides full bytecode compatibility and access to $2B+ in DeFi liquidity, Stylus targets high-performance applications. I view the EVM as the better choice for developers who need to port protocols like GMX or Uniswap V3 with minimal friction. However, Stylus provides up to 10x faster execution for CPU-intensive tasks like zk-proof verification or complex game logic. The Stylus runtime uses ahead-of-time (AOT) compilation to achieve near-native speeds.

Metric Arbitrum EVM Arbitrum Stylus
Execution Speed 200-300 ms 50-100 ms
Avg. Compute Cost per Tx $0.10 – $0.30 $0.01 – $0.05
Language Support Solidity, Vyper Rust, C, C++, AssemblyScript
Peak Theoretical TPS 4,500 10,000

You should stick to the EVM if you need the maturity of the existing Hardhat or Foundry toolchains. Stylus remains a more specialized tool for developers seeking maximum computational efficiency. The gas for a SHA256 opcode is significantly lower in Stylus, at roughly 5 gas, compared to 60 gas in the EVM. The time to finality for both environments remains between 0.5 and 1.5 seconds.

Optimism addresses the centralization risks inherent in the rollup space through its focus on decentralized sequencers. Most popular optimistic rollups, including Arbitrum, run centralized sequencers that create a single point of failure. This centralization threatens censorship resistance and fairness in block production. Because Optimism remains a US-based project, a centralized sequencer might feel pressure to censor transactions that do not comply with OFAC rules. A decentralized sequencer network, run by multiple entities across different countries, would improve resistance to such censorship. This architecture would also provide faster finality for external actors like bridges and exchanges. Optimism also works toward cross-rollup sequencer interoperability. This allows the sequencer network to extend to any other Ethereum rollup, which improves the security of the whole network. Developers currently use abigen to generate Go bindings for smart contracts on L1, but this process can be difficult. Optimism’s focus on building a shared sequencer standard will likely change how rollups interact with the main chain. A sequencer’s job includes ordering transactions from users, building L2 blocks, and signing blocks on the P2P network. This multi-entity approach ensures there is no single point of attributability for the sequencer.

Newsletter