3 min read
EIP-4844 was implemented on Ethereum mainnet with the Dencun upgrade on 03/13/2024
EIP-4844, also called proto-danksharding, introduced blob-carrying transactions on Ethereum. Rollups can use blobs to publish data separately from ordinary execution calldata. The upgrade went live with Dencun on March 13, 2024.
This guide explains what blobs provide, how their fee market differs from execution gas, and the limits application developers should understand.
Ethereum Architecture and History
Ethereum separates transaction execution from consensus. The execution client processes transactions and state, while the consensus client participates in proof-of-stake agreement. This architecture replaced Ethereum's proof-of-work consensus during the Merge in September 2022.
Rollups execute transactions outside Ethereum's L1 execution layer and publish data needed for their verification or reconstruction. Posting that data as ordinary calldata consumes execution gas. EIP-4844 added a separate data-availability path for blob data.
Sharding
Sharding broadly describes dividing work or data across participants. Proto-danksharding did not split Ethereum into parallel execution chains. It introduced blob transaction formats and related verification machinery as a step toward scaling rollup data availability.
The Ethereum danksharding roadmap explains the distinction between proto-danksharding and later data-availability scaling work.
What is EIP-4844 (Proto-Danksharding)
EIP-4844 defines a transaction type that carries commitments to blobs of data. The EVM can access versioned hashes associated with those blobs, but it cannot read the full blob contents as ordinary contract calldata.
This design gives rollups a way to publish data without requiring permanent storage of the full blob data by consensus nodes.
How does EIP-4844 work?
A blob transaction links execution-layer information with blob data distributed through the consensus network. KZG commitments and proofs allow nodes to check the relationship between the data and its commitment.
Blob data has a limited availability period in the protocol. Applications that need historical blob contents must arrange to retrieve and retain them; they should not treat blobs as permanent contract storage.
Blob gas has a fee market separate from execution gas. A transaction carrying blobs can therefore incur both execution-gas costs and blob-gas costs. Blob fees vary with demand, and lower data-publication costs do not guarantee a fixed reduction in every rollup user's transaction fee.
See the EIP-4844 specification for the transaction format, commitment verification, and gas accounting rules.
Benefits of EIP-4844
For rollups, blobs provide a data-publication mechanism with pricing separate from ordinary calldata. That can reduce the cost of making rollup data available and enable savings to be passed on to users.
The result depends on blob demand, rollup configuration, and other transaction costs. EIP-4844 does not make all Ethereum L1 operations cheaper or provide a universal fee reduction multiplier.
What is Quicknode?
To build on Ethereum, you'll need access to a node. You're welcome to use public nodes or deploy and manage your own infrastructure; however, you can also leave the heavy lifting to us and get optimized response times by using a Quicknode endpoint.
Create an account and create an endpoint.
Then you can head to Quicknode Docs and use one of the ready code examples to test different RPC methods against the Ethereum network.
Here's a sample request to retrieve transactions within the latest block.
curl <YOUR_QUICKNODE_HTTP_ENDPOINT> \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"eth_getBlockByNumber","params":["latest",false],"id":1,"jsonrpc":"2.0"}'
Remember to replace the YOUR_QUICKNODE_HTTP_ENDPOINT placeholder above with your actual HTTP Provider URL.
Additional Resources
For the specification and ongoing data-availability work, use these resources:
For current implementation details, follow the EIP-4844 specification and your execution and consensus clients’ documentation. Historical interoperability devnets are not a substitute for a supported development network.
Closing Thoughts
Tell us what you think about EIP-4844 on Twitter or Discord!