EIP-4844: Shard Blob Transactions

Proto-Danksharding

EIP-4844introduces 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.

Learn more about EIP-4844 in the recordings below ‡️

Bankless EIP Overview →Optimism Deep Dive→

Why?


Rollup Future

Rollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum. Transaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups.

Low Fees Now

Full data sharding will take a considerable amount of time to finish implementing and deploying, yet rollups are here now. EIP-4844 can bring rollup fees down by orders of magnitude and enable ethereum to remain competitive without sacrificing decentralization.

Forwards Compatible

Blobs are committed to with KZG: an efficient vector commitment scheme, with fixed-size proof data, and forward-compatible with data-availability-sampling. These commitments are used in the same scaffolding as the full "danksharding" proposal.

Beacon Node

Blobs are persisted in beacon nodes, not in execution layer (e.g. in prysm, not in geth). Future sharding work only requires changes to the beacon node, enabling the execution layer to work on other initatives in parallel.

Manageable Disk Use

Blobs are 4096 field-elements of 32 bytes each, with a maximum of 16 blobs per block. 4096 field elements * 32 bytes * 16 per block = 2 MiB per block maximum. A 1559-style mechanism is used to target 1 MiB/block on average.

Short Lived

Blobs are pruned after ~1 month. Available long enough for all actors of a L2 to retrieve it, short enough to keep disk use manageable. This allows blobs to be priced cheaper than CALLDATA, which is stored in history forever.

How?


Full Specifications

Changes to the execution (i.e., geth, erigon, etc.) and consensus (i.e. prysm, lighthouse, etc.) layer are specified in EIP-4844 and the beacon chain specifications.

Prysm & Geth Prototype

A prototype of the modifications that are going to be necessary in both the consensus layer and execution engine. You can follow along to the progress of that here.

KZG Trusted Setup

Part of EIP-4844 involves using KZG commitments. To generate the seed for these these, a browser-based widely distributed ceremony will be run so everyone has a chance to ensure it is generated correctly and securely.

✨NEW✨: Devnet v1

To demonstrate the feasability of EIP-4844, an initial developer network testing network is now live with an initial implementation of the changes. Instructions to join the network are available here.

Testnet

Once the devnet has been shown to work and the contributors have confidence in it, a testnet will be started to show the community how everything works and to allow anyone to be a validator, run a node, etc.

Open Issues

To ensure the design of the EIP is sound and all potential issues have been addressed, a public list tracks these concerns and potential solutions here. These are great entry points for new contributors!

Want to help?

EIP-4844 is project-neutral and being developed 100% in the open by a wide mix of developers across different teams. Any contributions, big or small, are very much welcomed. The best way to help technically is to understand what's going on and dive into one of the repos or discussion groups linked below.

Frequently Asked Questions

Written by Vitalik Buterin

Community Support

EIP-4844 is widely supported by ethereum core developers, optimistic rollup and zk-rollup teams, dapp developers, cross-chain bridge implementers, exchanges, and more.