EIP-4844: How Will the New Upgrade Help Rollups Reduce Fees and Increase Throughput?
TechFlow Selected TechFlow Selected
EIP-4844: How Will the New Upgrade Help Rollups Reduce Fees and Increase Throughput?
EIP-4844 has brought tremendous momentum.
Navigating Web3 tides with focused insightsAuthor: Jesse Pollak
Translation: TechFlow
TL;DR
EIP-4844 has gained significant momentum, with multiple high-impact working sessions held during Devcon, identifying minor specification changes and accelerating full-speed implementation.
EIP-4844 will reduce Layer 2 Rollup fees by 10-100x and enable higher transaction throughput. It achieves this by introducing data availability to Ethereum through a Rollup-building mechanism called "Blobspace".
This change is critical for driving Ethereum adoption—for example at Coinbase, "We view EIP-4844 as a key enabler for bringing our customers into the crypto economy with a secure, easy-to-use experience that’s faster and cheaper".
The goal at Devcon was to push all client teams to discuss “how best to deliver EIP-4844.” To achieve this, developers from Ethereum, OP Labs, and Coinbase spent the past five months writing specifications, implementing in Geth and Prysm, launching two devnets, and preparing the KZG ceremony.
During the conference, we held discussions in many different settings: multiple workshops during the pre-Devcon R&D day, conversations during EthMagicians, a half-day working session with client teams, and ad-hoc talks nearly every day.
From these discussions, we identified several small changes to the execution-layer and consensus-layer specifications. We also found that the client teams’ top concern was the network impact of adding Blobs.
On the consensus layer, we decided to couple Blobs with Blocks rather than keeping them separate. This decision was made to simplify implementation, with separation possibly considered only in the next phase of Danksharding.
On the execution layer, to reduce potential DoS vectors, we decided to update the wire protocol so that blob-carrying transactions are only gossiped, not broadcast. This allows clients to safely manage retrieval of Blobs.
The biggest recurring concern from clients centered around network latency: with Blobs, total network bandwidth could increase significantly. While this is expected behavior, there is strong desire to minimize the risks of this change as much as possible.
To address this, we plan to simulate what network behavior might look like by creating a continuous stream of CALLDATA-filled blocks on testnets and mainnet. This will show how nodes across the network handle such load.
Based on test results, we will adjust the target Blob size to fit within bandwidth constraints and add any additional mitigation measures. We’re excited to obtain real-world data to determine the final parameters suitable for 4844.
Finally, discussion covered which libraries to use across execution and consensus layers for implementing KZG commitments. We agreed that c-kzg (depending on Blst) would be the default, though clients may opt for platform-specific libraries.
Throughout Devcon, there was extensive discussion about the exact timeline for 4844. While most client teams prioritize sharding/scalability, there was also strong sentiment that 4844 must receive adequate resources to proceed smoothly.
No formal decision was made regarding including 4844 in the next hard fork, but the idea remains highly open. How best to reflect this in the specifications and client codebases is still being determined.
Based on this feedback, the working group will go all-in over the short term—implementing 2–3 additional clients (Lodestar, Erigon, Nethermind), running bandwidth tests, and launching Devnet 3.
Later this month, we plan to conduct another check-in to assess whether our progress aligns with the Shanghai hard fork timeline. We are optimistic that, given our strong cross-company working group, we’ll be able to deliver 4844 quickly.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
