With the recent @arbitrum and @optimismFND airdrops + @0xPolygonLabs ZK-EVM release, we have finally entered the peak Layer 2 era! However, the single most important upgrade for Ethereum roll-ups has yet to release...Here's everything you need to know about EIP-4844 🧵👇
1/ EIP-4844 is an Ethereum Improvement Proposal (EIP) that introduces a new transaction type called "blob-carrying transactions."These new txns will have the same structure as existing txns, but will include an additional field specifically for storing roll-up data.
2/ Currently, L2 roll-ups post their state updates or compressed transaction bundles into the "calldata" section of transactions. The issue is, calldata storage is:
1. Expensive
2. Permanent
3. Used for purposes outside of roll-ups
3/ By introducing a new temporary data storage field, L2s can reduce the costs of posting roll-up batches by 10-100x -> making micro txns economically feasible, as well as catering to a larger retail user base.
4/ Reducing gas fees from around $0.30 to less than a penny will make roll-up txn fees competitive with side chains (@0xPolygonLabs PoS chain) and alt L1's (@avalancheavax & @solana), all while inheriting the superior decentralization and security of ETH main net.
5/ So why is the blob data storage so much cheaper than call data storage?First, the blob data is not accessible by the L1 EVM execution layer. This data is simply stored on the Beacon Chain which is responsible for consensus + settlement, but *not* execution.
6/ By posting the L2 data to the consensus layer, the data cannot be used within txns or verify anything directly on chain.BUT, being posted on the consensus layer does ensure L2 data availability, which means if needed, the data can be used to arbitrate validity disputes.
7/ Even though all nodes need to store this added blob data, it does not need to be stored indefinitely. Since optimistic roll-ups have a ~14 day challenge period to submit fraud proofs the data only needs to be stored by nodes temporarily.(ZK roll-ups have no challenge period).
8/ For call data: the gas fee = a node's expected cost of perpetual storage for the dataFor blob data: the gas fee = ... cost of 2 week storage for the dataThese two time-periods are simply magnitudes different which is why blob data will have its own unique gas cost formula.
9/ In this set up, the data can be *cheaply* available during the challenge period, while just the merkle roots of the txns & the L2 state get posted directly to mainnet via calldata. This ensures that the "commitment" of the L2 can still be accessed by the EVM execution layer.
10/ In the current proposal format, the EIP sets a target of just 2 blobs per block (.25MB) in order to limit the increase in storage requirements for node operators.Increasing the storage requirements can lead to higher hardware requirements, which can hamper decentralization.
11/ However, there is a long term plan to allow for a max of 16 blobs per block, which would enable a new efficient frontier for validators to earn gas fees via the proposed blob data gas calculations.
12/ Currently, 2 blobs should suffice given the existing oligopoly of L2s.Yet in a roll-up centric future, we will likely see greater competition for "blob" space across different L2s.
13/ Though ZK-roll ups are able to condense more txns into roll-ups currently, with the intro of EIP-4844, Optimistic roll-ups will likely have noticeably cheaper fees since the ZK-proofs are much more computationally intensive to generate, which is a cost external to gas prices.
14/ This may explain why @optimismFND and @coinbase have been contributing to the research and development of EIP-4844 so heavily.Important to note this approach to scaling is part of "proto-danksharding" which has been lead primarily by @protolambda and @dankrad !!
15/ Now you may be asking, why don't they just make the gas fees cheaper for the calldata?Well, it was already tried in the similar numbered EIP-4488.The answer lies in analyzing the "worst case scenario."
16/ If the calldata field had 10x lower gas fees, then the average block size would remain around the existing block size (90KB), but the *worst case scenario* (a full block) would balloon from 1.8MB to 18MB, which would be far too large for the ETH network to handle.
17/ Given Ethereum has committed to a roll-up based future for scaling to >100,000tps, it appears EIP-4844 is the only way to balance the design limitations of Ethereum, while also promoting the use of L2 roll-ups.
18/ Be on the look out for EIP-4844 coming in late 2023 (hopefully) or possibly 2024 if delayed!Big thanks to @chapterone for enabling me to work on this and feedback from @danxtao and @nonieengel.
19/ To learn more, check out the resources I used for research:
EIP-4844: Shard Blob TransactionsShard Blob Transactions scale data-availability of Ethereum in a simple, forwards-compatible manner.https://eips.ethereum.org/EIPS/eip-4844
EIP-4844: Shard Blob TransactionsEIP-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.https://www.eip4844.com/#why
Danksharding | ethereum.orgLearn about Proto-Danksharding and Danksharding - two sequential upgrades for scaling Ethereum.https://ethereum.org/en/roadmap/danksharding/
Optimistic Rollups | ethereum.orgAn introduction to optimistic rollups—a scaling solution used by the Ethereum community.https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/
EIP-4844 L2 TX usage & blob lifetime - HackMD# EIP-4844 L2 TX usage & blob lifetime ## Lifetime of a blob TX  is a planned upgrade to the Ethereum protocol that lowers fees and increases the protocol’s transaction throughput.https://academy.binance.com/en/articles/what-is-eip-4844-in-ethereum-and-how-can-it-benefit-users