EIP-4844 is a proposed change to Ethereum that would introduce a new data availability mode, for data that is associated with a transaction but not available to the execution layer. This thread is for discussing EIP-4844 and how Arbitrum can use it.
24 Likes
Here’s a short summary of what EIP-4844 would do and why we support it.
There would be a new transaction type, which allows “data blobs” to be attached to a transaction. A data blob is a chunk of up to about 110 kBytes of data. Each blob would come with a cryptographic commitment to the blob contents (think of it as a hash of the data if you prefer). Ethereum consensus would verify that the commitment matches the data, and full nodes would keep the data and make it available for a specified period (perhaps four weeks).
The execution of the transaction could see the commitments of its blobs (via a new EVM instruction) but couldn’t see the blob data. (As a result, nodes could confirm the correctness of execution without needing to see the blob data, because only the commitments can be inputs to the execution.)
A new precompile would be added, to confirm a proof that a word of the blob was consistent with the blob’s commitment. This would allow a transaction to confirm a proof of what was in its blob.
The number of blobs per Ethereum block would be limited to 16 max, and 8 on average. I’ll omit the details of how blobs are priced.
This might sound like a quirky definition, but there is a compelling logic to it, for two reasons. First, its API is compatible with the expected API for the future data availability layer that Ethereum is expected to adopt at some point after the Merge. So contracts written to use blobs should continue to work without modification well into the future, and they would automatically start taking advantage of the future data availability features when they arrive.
The second advantage is that the blob functionality is a great match for what rollups need. A rollup like Arbitrum needs to have its L2 transaction data available to all L2 nodes, for a limited period of three weeks or less. After that the L2 data will be made available by L2 nodes that have grabbed it during the initial period. So Ethereum nodes will only hold a rollup’s blob data for a limited period, and after that the data only needs to be stored by actors who care about that particular rollup chain. Rollup data wouldn’t be a long-term burden on Ethereum nodes.
Arbitrum doesn’t need its on-chain L1 rollup protocol contracts to have access to L2 transaction data–it only needs the L1 contracts to know a commitment to the data and to be able to verify proofs of the contents of the data in case there is a dispute. So the shard blob scheme of making commitments available to the L1 execution layer, with a precompile to verify proofs of blob contents, is just what we need. Again, Ethereum nodes are providing the minimum that a rollup needs for efficient execution.
Blob shard data is a near-perfect match for what rollups need, and it should be cheaper for Ethereum nodes to provide and therefore ultimately lower cost for rollups to use. We would switch Arbitrum over to using them once they were available, and our users would benefit.
15 Likes
Why is the timeframe the case for three weeks or less? Is it related to the challenge period?
6 Likes
Yes, the idea is that if there is a dispute between two validators, all other honest validators must be able to get the data within one week of the dispute starting. Three weeks is a safe upper bound on the total elapsed time of that scenario.
7 Likes
EIP-4844 economics and rollup strategies - Arbitrum Research - a new topic for the discussion of the economics of the proposal.
What are the scenarios where these blobs will be needed beyond the 3-weeks period ? Is there a spec detailing how these blobs are encoded for Arbitrium ?
The encoding of Arbitrum data batches in blobs is the same as in the previous calldata batches. Same data, same encoding, just posted to Ethereum in a different way.
The 18 day storage of blobs by Ethereum is more than enough to resolve any disputes or fraud proofs that might be needed, so retention beyond the 18 days would be needed only for archival purposes, for people who want to see the older history of the chain.