Ethereum researchers are again looking at how to make the network lighter to run, this time by questioning one of its most basic assumptions: what a block should actually contain.
In a recent research post titled Blocks Are Dead. Long Live Blobs, co-authored by Toni Wahrstatter and other Ethereum contributors, describes EIP-8142, also referred to as “Block-in-Blobs,” a draft proposal first introduced earlier this year. The idea is to encode transaction data directly into blobs rather than requiring validators to download and re-execute full execution payloads.
That may sound like an internal engineering debate, but it touches a real constraint. Validators today need to handle large amounts of execution-related data, and that creates a burden that can become more visible as the network scales and data demands keep rising.
Blobs, introduced with Ethereum’s EIP-4844 upgrade, were designed as a more efficient data format. The new proposal would push that logic further. Instead of treating blobs as an additional lane for certain kinds of data, the researchers are exploring whether blobs could become the main vehicle for transaction data itself.
In simple terms, the proposal tries to reduce the amount of heavy lifting validators must do just to stay in sync.
The pitch behind EIP-8142 is not that blocks disappear in a literal sense. It is more that the current model of full execution payload distribution may no longer be the cleanest way to organize Ethereum’s data flow.
By moving transaction data into blobs, the researchers believe Ethereum could ease a structural bottleneck and lower validator data requirements. That could help with efficiency and network scalability, especially as Ethereum continues trying to balance decentralization with growing usage.
At the same time, proposals like this tend to open broader questions. When core data handling changes, everything around it matters too, from node design to execution workflows to how quickly the ecosystem can adapt. That is why the idea is still framed as research, not as an imminent protocol change.
]]>
