Blocks Are Dead, Long Live Blobs: Ethereum researchers explore upgrade to ease validator data burden

Ethereum researchers are exploring a proposed design that moves execution-payload data into blobs published alongside blocks, aiming to cut bandwidth demands while enabling greater scalability.

EIP-8142 (“Block-in-Blobs”) targets validator bandwidth bottlenecks

In a recent research post titled “Blocks Are Dead. Long Live Blobs,” co-authored by Toni Wahrstatter and other Ethereum contributors, the authors outline EIP-8142, or “Block-in-Blobs,” a draft proposal first introduced earlier this year.

The design would encode transaction data directly into blobs—an approach introduced in Ethereum’s EIP-4844 upgrade—rather than requiring validators to download and re-execute full execution payloads.

The researchers point to a bottleneck in Ethereum’s architecture: as block sizes expand and gas limits rise, validators must download and verify an increasing dataset. This increases pressure on bandwidth and limits scalability.

Background: blobs introduced with the Dencun upgrade

Blobs were introduced in March 2024 as part of Ethereum’s data availability roadmap during the Dencun upgrade. Delivered via EIP-4844, also known as proto-danksharding, blobs are designed to carry large chunks of data more efficiently than standard transaction calldata.

Under the blob model, data can be committed cryptographically and verified without requiring full replication across the network, with validators relying on data availability sampling over time.

How “Block-in-Blobs” changes execution-payload handling

EIP-8142 extends the blob concept further. Instead of treating blobs as an auxiliary data layer, the proposal moves core execution-payload data—already encoded in Ethereum’s standard RLP format—into blobs themselves.

Validators would then verify cryptographic commitments to those blobs and, over time, rely on data availability sampling. The goal is to verify that small portions of data exist without downloading the entire dataset.

Relevance for zkEVM verification

The change is described as particularly relevant in a future where zkEVM systems handle execution verification. In that setup, zero-knowledge proofs can confirm that transactions were processed correctly, reducing the need for validators to re-execute every transaction.

However, the researchers note that proofs alone do not guarantee that transaction data is available. Wahrstatter wrote: “Under zkEVM, validators verify proofs, not transactions directly.” He added that without a separate mechanism, data could be withheld while still passing consensus checks.

Block-in-Blobs is designed to address this gap by embedding transaction data into blobs with cryptographic commitments, making data availability explicit rather than implicit. The proposal argues this allows validators to sample data instead of downloading it in full while preserving security guarantees.

Potential shift toward a unified “data gas” model

The proposal also includes broader implications for how Ethereum accounts for data. Today, Ethereum separates execution gas from blob data usage. Under the new model, the researchers say both could be unified into a single “data gas” system.

If implemented, they argue it would align costs across all forms of data availability and avoid overlapping limits.

Related development: ERC-8211 aims to make transactions programmable workflows

Separately, efforts are underway to improve how transactions are structured and executed. Biconomy, in collaboration with the Ethereum Foundation’s UX track, has proposed ERC-8211, a standard that turns transactions into programmable workflows.

Instead of fixed parameters set at signing, ERC-8211 allows transactions to fetch real-time onchain data, validate conditions, and execute multiple steps in sequence with a single signature. The goal is to reduce failed transactions and enable more complex, agent-driven interactions across DeFi protocols, according to Biconomy’s thread on X.

Broader context: ongoing multi-year upgrade experimentation

Both developments sit within a broader wave of experimentation across Ethereum’s ecosystem. Researchers have outlined multi-year upgrade paths through the end of the decade following last year’s double hard-fork rollout.