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.

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 — a data format introduced in Ethereum’s EIP-4844 upgrade — rather than requiring validators to download and re-execute full execution payloads.

The idea targets a bottleneck in Ethereum’s architecture, according to the researchers.

Expanding block sizes, coupled with higher gas limits, mean validators must download and verify an increasing dataset. This increases pressure on bandwidth and limits scalability.

Back in March 2024, blobs were introduced as part of Ethereum’s data availability roadmap during the Dencun upgrade.

Delivered via EIP-4844, also known as proto-danksharding, the blobs are designed to carry large chunks of data more efficiently than standard transaction calldata.

Rather than store all transaction details directly onchain and require validators to process that data, blobs allow data to be committed cryptographically and verified without full replication across the network.

Block-in-Blobs

EIP-8142 extends that idea 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. This way, they can verify small portions of data to ensure the full dataset exists without downloading it entirely.

The change becomes particularly relevant in a future where zkEVM systems handle execution verification.

Zero-knowledge proofs can confirm that transactions were processed correctly, removing the need for validators to re-execute every transaction.

However, those proofs alone do not guarantee that transaction data is actually available. "Under zkEVM, validators verify proofs, not transactions directly," Wahrstatter wrote. He also noted that without a separate mechanism, data could be withheld while still passing consensus checks.

Block-in-Blobs is designed to close that gap, the proposal argues.

By embedding transaction data into blobs with cryptographic commitments, the proposal makes data availability explicit rather than implicit, allowing validators to sample data rather than download it in full while preserving security guarantees.

There are also broader implications for how Ethereum accounts for data.

Today, Ethereum still separates execution gas from blob data usage. Under the new model, both could be unified into a single "data gas" system. If successfully implemented, researchers say it would align costs across all forms of data availability and avoid overlapping limits.

Biconomy’s ERC-8211

Separately, efforts are underway to improve how transactions themselves 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, as explained in Biconomy’s thread on X.

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.