How Ethereum’s Fusaka upgrade changes block builder competition

The expansion of block capacity

The block gas limit reached 60 million. This default follows the Fusaka upgrade and replaces the previous 45 million limit. This increase allows more transactions and complex smart contract operations in each block. Developers and DeFi users expect this capacity expansion to ease network congestion. The upgrade pushes Layer 1 capacity toward 40 to 60 transactions per second. This expansion works alongside EIP-7825 and prevents a single transaction from dominating a block. EIP-7935 coordinated client teams to test higher limits on devnets before they shipped 60 million as the Fusaka default. The network also implements EIP-7934, which sets a 10 MiB ceiling on RLP-encoded execution block size. This includes a 2 MiB safety margin for beacon-block framing. If a block exceeds this limit, clients reject it to prevent DoS attacks. EIP-7823 also limits MODEXP input numbers to 8192 bits. This provides security and DoS protection without affecting user experience. EIP-7939 adds a new CLZ opcode for efficient bit operations. EIP-7951 adds support for the secp256r1 curve to aid hardware-secure logins for WebAuthn and passkeys.

Builder competition and the MEV landscape

Block building involves a small number of participants. Titan Builder holds 47.6% of the market share, and BuilderNet holds 26.0% of the market share. Builders use the 12-second block time to optimize transaction ordering and extract value. They submit bids to relayers to have their blocks included by validators. Beaverbuild saw a drawdown in MEV-Boost value because it partnered with BuilderNet to share transaction flow across block builders. Searchers scan DeFi protocols and public transactions to find profitable opportunities. They combine the original transaction with their own into a bundle for block builders. Builders aggregate these bundles with transactions from the public mempool and private order flow. The auction occurs every 12 seconds through MEV-Boost. Builders pay relayers to coordinate bids with validators. You already know the basics, so I will focus on the specific technical shifts affecting builder auctions. Searcher competition follows submodularity, which means the value of a block built from bundles in set A and set B is less than or equal to the sum of values from A and B minus their intersection.

Technical safeguards and validator stability

EIP-7825 imposes a cap of 16,777,216 gas for every transaction. This limit provides proactive DoS hardening. It makes validation and propagation easier to model. EIP-7883 also changes MODEXP pricing to match computational costs. The minimum charge increases from 200 to 500 gas. If the exponent input exceeds 32 bytes, the gas charge rises faster. PeerDAS, or EIP-7594, reduces the data load for validators. Nodes verify small, random samples of blob data instead of downloading the whole set. This reduces bandwidth requirements for typical validators by 8x. However, the upgrade caused a significant issue for Prysm validators. Participation in attestations fell from 97% to 77% because nodes struggled with stale attestations and outdated state regeneration. This failure caused many nodes to switch away from the builder API to produce blocks locally. A block in slot 13164887 arrived 4.65 seconds late, which caused a reorg because the parent block received only two head votes. Dasmon probes also reported missing data, which analysts link to late blob deliveries.

Data availability and the based rollup model

EIP-7917 allows the Beacon Chain to see upcoming block proposers for the next epoch. This feature enables based rollups. In this model, Ethereum validators take over the sequencing responsibility for L2s. This shift redirects MEV and tip revenue from centralized sequencers to ETH stakers. PeerDAS divides the network into 128 subnets. A validator with 32 ETH participates in 8 subnets. For every additional 32 ETH, the validator participates in one more subnet. This reduces bandwidth use for typical validators. A validator using 16KB of bandwidth per blob is much more efficient than the previous model. PeerDAS uses Reed-Solomon encoding to expand the data size twofold. This makes it possible to recover the original data from 50% of the expanded data. As the network accommodates more data through PeerDAS, validators only need to verify small, random samples of information rather than downloading the complete datasets that were previously required for the validation process. EIP-7918 sets a reserve price for blob fees to prevent them from dropping to 1 wei. This ensures blob fees remain a price signal even when L1 gas is high.