A Brief History of EIP-4844: Creating a Blobspace World

Compilation of the original text: The Way of DeFi

Compilation of the original text: The Way of DeFi

EIP-4844 (proto-danksharding) is gaining more attention, and with its development, memes, and community support, EIP-4844 is expected to be the next major upgrade of Ethereum. But what exactly is it? In short, it is a new transaction (tx) type that makes it easy to write cheap and ephemeral data on (Ethereum) L1. Data represented as blobs relies on some nifty new cryptography to ensure that it remains available to L2 for a long enough time. There are many resources on this topic. In this post, we describe our overall effort to advance EIP-4844.

EIP-4844 Development History

EIP-4844 started as a hackathon idea during the ETHDenver 2022 conference, with early prototypes created by our team's protolambda, Prysm's terencechain, and several others. This involves a fork of geth that adds the blob transaction type and implements the new crypto needed to secure the blob.

The real entry into development of EIP-4844 started later this spring with the immediate goal of fully implementing consensus and executing a client prototype. We knew early on that bringing an EIP of this scale to mainnet would not have been possible without the full support of the Ethereum community. We are currently at least nine months away from the target hard fork, and that time frame will be critical to pinpoint any major issues in the spec prior to testnet. Our first milestone was achieved in early summer with the Prysm and geth forks of EIP-4844. This is the first time we have a fully compliant execution and consensus client.

We learned a lot from this exercise, including where the specification needed more detail, how to reduce implementation complexity, and the causes of performance issues. One notable thing we are still improving is the speed of verifying blobs (transactions). Thanks to researchers at the Ethereum Foundation, we propose a new application of almost forgotten mathematics from the 70s to update the specification to improve the efficiency of blob verification. Vitalik has written about this here. In short, we are able to amortize the cost of expensive blob validation using the following formula:

a community collaboration

Developing a critical upgrade like EIP-4844 (and including it in an upcoming hard fork) required the skill and effort of many communities. We teamed up with developers from Coinbase, Prysm, and Worldcoin to test, implement, and release EIP-4844. The first fully implemented EIP-4844 developer testnet (devnet) was presented on the EIP-4844 community call, which provides a testing environment for researchers and developers to see what we are building.

While the community call was helpful, we were still missing critical feedback from client developers - especially given that EIP-4844 was developed in parallel with The Merge. Devcon VI in Bogota was a pivotal moment for EIP-4844, giving us the opportunity to present and discuss the upgrade with the core developers of the Ethereum Foundation as well as the client team. We released devnet v2, which implements the latest specification of EIP-4844, giving client developers the opportunity to become more familiar with the proposal. Devnet v2 was also used to build the Blobs browser during the ETHBogota Hackathon.

Thanks to several R&D workshops hosted by the Ethereum Foundation, not only were we able to write code together, but we also had new core developers join the development of EIP-4844. Therefore, we have developed a roadmap to include EIP-4844 in the next mainnet upgrade.

development progress

For a long time, the development process of EIP-4844 was roughly as follows:

• implementation specification

• Test Specification

• Update specifications based on test results

• repeat

Due to the constant changes to the specification, developer testnets (devnet) are our primary means of testing EIP-4844 because they are easy to launch. Now that the spec is mostly complete, we're moving towards production, which includes hive testing, tx fuzzing, test vectors for client interoperability, and a testnet. Our goal is to make it easier for client developers to implement EIP-4844 and be confident that their implementation complies with the specification.

EIP-4844 covers consensus and execution, so its complexity is between EIP-1559 and The Merge. Additionally, we expect EIP-4844 to be released alongside the Shanghai hard fork. This gives us about a month or so to prepare a fully functional EIP-4844 testnet. Most importantly, this happened while client developers were busy implementing withdrawals for the Shanghai hard fork. Since the merger, client developers have focused on fixing client bugs, cleaning up the code, and processing withdrawals. We have two very important features right now: withdrawals and EIP-4844, and the developers are working on them for the next hard fork. Execution of this function will be a true test of the efficiency and resources of the Ethereum community.

Merger aside, EIP-4844 is probably the largest community leadership effort to date. With so many talented developers working on EIP-4844 right now, we can make this happen.

A Blobspace World

Once EIP-4844 is deployed to the Ethereum mainnet, and data availability (called blobspace) is unlocked for L2 use, we expect to reduce the cost of rolling up L1 transactions by at least 20x. We want all rollups to take advantage of blobspace to reduce transaction costs for their users. Excited to see what the Ethereum community will come up with for blob transactions. From "blob splitters" to NFT metadata, EIP-4844 will create a new class of applications that require access to cheap and usable data without compromising security.