EIP-4844 (Shard Blob Transactions), also known as Proto-Danksharding, is an Ethereum Improvement Proposal (EIP) to implement most of the logic and “scaffolding” (eg. transaction formats, verification rules) that make up a full Danksharding 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]

Overview

On March 14, the Dencun upgrade went live on Ethereum Mainnet. Dencun includes six EIPs related to Ethereum’s execution logic. The most important among these is EIP-4844, which introduces a special resource exclusively for Layer 2s 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 Ethereum which accepts "blobs" 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 blobs are small enough to keep disk use manageable

EIP-4844 helps scale Ethereum by introducing a new “blob-carrying” transaction type. Rollup sequencers (and potentially others) will use this new transaction type to post data to Ethereum mainnet 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 L2 transactions contained in each blob are not, and cannot be, executed by Ethereum’s execution layer (aka, the EVM). This is the reason why blob data of a given size (128KB per blob) can be posted to Ethereum by a rollup 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]

Authors

• Vitalik Buterin
• Dankrad Feist
• Diederik Loerakker
• George Kadianakis
• Matt Garnett
• Mofi Taiwo
• Ansgar Dietrichs