EIP-4844: Shard Blob Transactions
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.
Learn more about EIP-4844 in the recordings below ⤵️
Bankless Overview Optimism Deep DiveRollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum. L1 transaction fees are a significant blocker for new users and applications. EIP-4844 will help facilitate an ecosystem-wide move to rollups.
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.
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.
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.
Blobs are 4096 field-elements of 32 bytes each, with a long term maximum of 16 blobs per block. 4096 * 32 bytes * 16 per block = 2 MiB per block maximum. The blob cap per block can start low and grow over multiple network upgrades.
Blobs are pruned after ~2 weeks. 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.
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.
Prototypes of the modifications that are going to be necessary in both the consensus layer and execution layer clients. You can follow progress on this front here.
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.
Devnets
To demonstrate the feasability of EIP-4844, a developer network testing environment is now available with an initial implementation of the changes. Instructions to launch a network are available here.
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.
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!
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.
Written by Vitalik Buterin
Several teams have contributed to EIP-4844 in addition to core developers, each of them wanting to onboard a large number of users to Ethereum without compromising on affordability or security.
EIP-4844 is widely supported by Ethereum core developers, optimistic rollup and zk-rollup teams, dapp developers, cross-chain bridge implementers, exchanges, and more.