EIP-4844 (Shard Blob Transactions), also known as Proto-Danksharding, is an to implement most of the logic and “scaffolding” (eg. transaction formats, verification rules) that make up a full spec, but not yet actually implementing any sharding. In a proto-danksharding implementation, all validators and users still have to directly validate the availability of the full data.[1]


On March 14, the went live on . Dencun includes six related to Ethereum’s execution logic. The most important among these is EIP-4844, which introduces a special resource exclusively for s that will reduce transaction fees. Blobspace is the biggest thing since The Merge.[3][4]

EIP-4844 introduces a new kind of transaction type to which accepts "" of data to be persisted in the beacon node for a short period of time. These changes are forwards compatible with Ethereum's scaling roadmap, and are small enough to keep disk use manageable

EIP-4844 helps scale Ethereum by introducing a new “blob-carrying” transaction type. sequencers (and potentially others) will use this new transaction type to post data to Ethereum more cheaply than is currently possible. Further, EIP-4844 preserves decentralization by ensuring that the size and number of blobs included per block is limited, such that the computational and storage requirements of Ethereum nodes don’t drastically increase. In future upgrades, these limitations can be reduced to scale Ethereum further.

Blob data can be less expensive than regular Ethereum calldata of a similar size because the blob data itself is not actually made accessible to Ethereum’s execution layer (EL, aka the EVM). Rather, only a reference to the blob’s data will be accessible to the EL, and the data within the blob itself will be downloaded and stored solely by Ethereum’s consensus layer (CL, aka beacon nodes), and only for a limited period of time (~18 days, typically).

The blob-carrying transaction doesn’t actually include the blob data; only a reference to it in the blob_versioned_hashes field which is a fingerprint that is unique to each blob and that can be used to tie each blob to a blob-carrying transaction. Since only this reference to each blob exists within a given block, the transactions contained in each blob are not, and cannot be, executed by Ethereum’s execution layer (aka, the EVM). This is the reason why data of a given size (128KB per blob) can be posted to Ethereum by a sequencer more cheaply than regular Ethereum calldata of similar size - blob data does not need to be re-executed by Layer 1 (Ethereum, in this case). The actual data that makes up each blob is circulated and stored exclusively on Ethereum’s consensus layer (i.e. beacon nodes), and only for a limited period of time (4096 epochs, or ~18 days).

Through its blob-carrying transaction format, EIP-4844 improves Ethereum’s scalability, preserves decentralization, and most importantly, sets the stage for more complex and impactful scalability upgrades to be implemented in the future; namely, full Danksharding.[2]


  • Dankrad Feist
  • Diederik Loerakker
  • George Kadianakis
  • Matt Garnett
  • Mofi Taiwo
  • Ansgar Dietrichs
See something wrong? Report to us.


Commit Info

Edited By

Edited On

April 15, 2024


Average Rating

No ratings yet, be the first to rate!

How was your experience?

Give this wiki a quick rating to let us know!



Join the IQ Brainlist

Sign up for the IQ Brainlist to get early access to editing on the site!

Join Now

Subscribe to our newsletter

The IQ Ecosystem Report will keep you updated on everything IQ.

Subscribe's vision is to bring blockchain knowledge to the world and knowledge onto the blockchain. A part of Brainfund group


What's IQ?StakingBonds


About usCareersBrandingIQ GPTIQ Dashboard

© 2024 Powered By BrainDAO & IQ