With the upcoming Cancun upgrade, which L2s have made adaptations?
TechFlow Selected TechFlow Selected
With the upcoming Cancun upgrade, which L2s have made adaptations?
Optimistic Rollups are simpler to adapt to EIP-4844, while ZK Rollups are more complex to adapt.
Navigating Web3 tides with focused insightsAuthor: Maggie@Foresight Ventures
TL;DR
-
The Cancun upgrade launches on March 13, 2024, bringing EIP-4844 online. Danksharding is central to Ethereum's roadmap, and this upgrade marks the first step toward achieving Danksharding.
-
After adapting to EIP-4844, Ethereum L2s will see dramatically lower transaction fees and multiplicative increases in TPS. Users will experience faster transactions, lower costs, smoother interactions, and more responsive performance. These L2s will support more complex and large-scale Dapp applications.
-
Optimistic rollups can adopt EIP-4844 more easily than ZK rollups. Ethereum lacks precompiled contracts supporting the BLS12-381 elliptic curve, making certain ZKP verifications difficult and slowing ZK rollup adoption of EIP-4844.
-
This elliptic curve issue can be addressed in two ways: 1. Wait for Ethereum to add precompilation support for BLS12-381; 2. Use an alternative proof method with BN254, an elliptic curve already supported by Ethereum’s precompiled contracts.
-
Currently, Arbitrum, Optimism, Starknet, zkSync, Scroll, Polygon zkEVM, and the new L2 Morph are all working on EIP-4844 integration. Arbitrum, Optimism, and Starknet have announced plans to implement EIP-4844 following the Cancun upgrade. Morph has taken the lead by publishing an innovative zkSNARK zkEVM adaptation, becoming the first zkSNARK zkEVM to integrate EIP-4844.
1. Background
In 2020, Ethereum released its "Rollup-Centric Ethereum Roadmap," followed the next year by Vitalik’s "Endgame" vision describing Ethereum’s ultimate state—establishing a clear direction: optimize Ethereum’s base layer to serve Rollups.
To enhance Ethereum’s capability as a data availability layer, it designed Danksharding, a sharding technique that will significantly reduce L2 transaction fees, increase Rollup throughput (TPS), and enable massive Ethereum scaling.
Now, in 2024, the long-awaited Ethereum Cancun-Deneb (Dencun) upgrade goes live on March 13, introducing EIP-4844. This hard fork represents the first milestone toward realizing Danksharding and sits at the very core of Ethereum’s roadmap.
2. How Does the Cancun Upgrade Benefit L2s?
EIP-4844 introduces a new transaction type called a blob-carrying transaction. Each blob-carrying transaction can “carry” a list of Blobs. A Blob is a data packet of approximately 125 KB. Blobs are stored temporarily—for only 4096 epochs, slightly over 18 days.
-
L2 transaction fees drop significantly. Since Blobs are not permanently stored, they offer larger and cheaper storage compared to block space. With the same gas cost, Blobs can store ten times more data than Calldata. Rollups adopting EIP-4844 can store transaction data in Blobs, reducing transaction fees by an order of magnitude.
-
L2 TPS increases multiplicatively. Currently, each block targets 3 Blobs, with up to 6 allowed. While a standard block is only 90KB, each Blob is about 125KB. Introducing Blobs effectively expands block capacity several-fold for storing Rollup data, enabling proportional increases in Rollup TPS. Furthermore, as proposed by Toni and Vitalik in “On Increasing the Block Gas Limit,” future upgrades may raise the block gas limit and adjust pricing for non-zero Calldata bytes, allowing smaller, more predictable block sizes and paving the way for even more Blobs per block—further increasing available storage.
For end users, once Ethereum L2s adopt EIP-4844, transactions become faster, cheaper, smoother, and more responsive. These L2s will host increasingly sophisticated and large-scale Dapp applications.
3. How Do L2s Adapt to EIP-4844?
How do L2s adapt to EIP-4844? We need to examine this separately for Optimistic Rollups and ZK Rollups.
Optimistic Rollups Adapting to EIP-4844
Optimistic rollups ensure correct execution via fraud proofs. Nodes initially assume state transitions are valid unless challenged within a specified timeframe. If someone submits a valid fraud proof showing an invalid state transition, that transition is reverted.
Adopting EIP-4844 is relatively straightforward for Optimistic rollups compared to ZK rollups. They simply submit L2 transactions using blob-carrying transactions to L1. Additionally, they must eventually update their fraud proof mechanisms to work with EIP-4844—but this part can be implemented gradually. After all, many optimistic rollups still haven’t launched fraud proofs, and those that have seen no fraud challenges in over two years.
Submitting L2 Transactions: When submitting rollup data, use blob-carrying transactions to store data in Blobs. The payload of a blob-carrying transaction is rlp([tx_payload_body, blobs, commitments, proofs]), where:
-
tx_payload_body – The TransactionPayloadBody of a standard EIP-2718 blob transaction.
-
blobs – A list of Blobs. Each transaction can include up to two Blobs.
-
commitments – A list of KZG commitments for the Blobs.
-
proofs – A list of proofs linking each Blob to its corresponding KZG commitment. These proofs are verified by Ethereum nodes.
Updating Fraud Proofs:
-
First, the prover and challenger engage in multi-round interaction to pinpoint the disputed operation.
-
Then, the dispute point is submitted to L1 for resolution. With EIP-4844, it may also be necessary to prove that the disputed data resides within a specific Blob.
-
Since Blob data is deleted after ~18 days, challenge periods must end before deletion. Current optimistic rollups meet this requirement, typically setting challenge windows under 7 days.
ZK Rollups Adapting to EIP-4844
ZK rollups use zero-knowledge proofs (ZKPs) to verify the correctness of L2 state transitions. Their adaptation to EIP-4844 is more complex than for optimistic rollups.
-
L2 Transaction Submission: This step is similar to optimistic rollups.
-
ZK Proof Submission: In addition to proving the validity of state transitions, ZK rollups must now also prove that the blob commitment corresponds correctly to the transaction batch—ensuring the inputs to the state transition proof are accurate.
-
Analogy: A ZK circuit might generate a proof for the computation a + a = b. Both (a=1,b=2) and (a=2,b=4) produce valid proofs. Therefore, we need an additional proof confirming that the input used was (a=1,b=2), not (a=2,b=4).
-
Previously, this wasn't required because data was directly stored in Calldata, which could be read deterministically, ensuring input integrity. With EIP-4844, Blob data isn’t directly readable—so a new circuit must be designed to prove the linkage between inputs and blob commitments.
-
This mechanism is easier to implement for STARK-based ZK rollups (e.g., Starknet). However, SNARK-based ZK rollups face a significant challenge: EIP-4844 uses the BLS12-381 elliptic curve for blob commitments, but Ethereum’s precompiled contracts only support BN254. Due to this mismatch, verifying blob commitments directly within smart contracts becomes difficult.
-
SNARK-based zkEVMs/zkVMs must resolve the issue of generating ZK proofs despite the curve mismatch described in point 2.
-
Wait for Ethereum to introduce precompiled contract support for BLS12-381. This process will likely take a long time.
-
Adopt an alternative proof method. This requires designing a new circuit using BN254—the elliptic curve supported by Ethereum’s precompiled contracts. Morph has adopted this approach, making it the first zkEVM to complete EIP-4844 integration.
For details on Morph’s EIP-4844 zkEVM integration solution, see: Article Link
4. Which L2s Are Adopting EIP-4844?
Among optimistic rollups, Optimism and Arbitrum have both committed to adopting EIP-4844 and are actively collaborating with their communities to test and deploy required updates. Arbitrum is a Stage 1 rollup with relatively strong security, requiring its fraud proof system to be adapted to EIP-4844. Optimism, currently a Stage 0 rollup without active fraud proofs, faces fewer technical hurdles in adoption but offers lower security guarantees.
Among ZK rollups, adaptation difficulty varies based on proof system. STARK-based rollups find EIP-4844 integration simpler—Starknet being the leading example. Starknet has published articles stating it will implement EIP-4844 post-Cancun upgrade. For SNARK-based rollups, zkSync is exploring how blob-carrying transactions can further reduce costs and boost performance. Scroll published a detailed proposal last year outlining its EIP-4844 integration strategy.
The most impressive development comes from Morph—an Optimistic ZK Rollup—that has率先 released a zkEVM solution for EIP-4844 integration, making it the first zkEVM rollup to complete EIP-4844 adoption.
An Optimistic ZK Rollup combines advantages of both architectures. It optimistically accepts sequencer-submitted results but allows challengers to dispute them. Only when challenged does the prover generate a ZKP to verify correctness. This design achieves the efficiency of optimistic rollups while retaining the reliability of ZK proofs from ZK rollups.
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
Foresight Ventures
