Ethereum Dencun Upgrade and Potential Opportunities
TechFlow Selected TechFlow Selected
Ethereum Dencun Upgrade and Potential Opportunities
This article will explain the technical details of the Dencun upgrade in simple and easy-to-understand language.
Navigating Web3 tides with focused insightsAuthor: Fishery Isla, Core Contributor of Biteye
Editor: Crush, Core Contributor of Biteye
Community: @BiteyeCN
*Approximately 4,500 words, estimated reading time: 5 minutes
The testnet version of Ethereum's Dencun network upgrade launched on the Goerli testnet on January 17, 2024, and successfully went live on the Sepolia testnet on January 30. The Dencun upgrade is drawing ever closer.
After one final Holesky testnet upgrade scheduled for February 7, the mainnet upgrade will follow. The official date for the mainnet launch of the Cancun upgrade has now been confirmed as March 13.
Each Ethereum upgrade typically brings a thematic market cycle. Looking back, the last major upgrade was Shanghai on April 12, 2023, during which projects related to Proof-of-Stake (POS) were heavily favored by the market.
Based on historical patterns, there may be early-mover opportunities associated with this Dencun upgrade.
However, because the technical aspects behind the Dencun upgrade are relatively complex and cannot be summarized simply like the Shanghai upgrade—such as "Ethereum transitioning from PoW to PoS"—it's harder to identify clear investment focal points.
Therefore, this article aims to explain the technical details of the Dencun upgrade in plain language, helping readers understand the connections between this upgrade and sectors such as Data Availability (DA) and Layer 2 solutions.
01 EIP-4844
EIP-4844 is the most important proposal in the Dencun upgrade, marking a concrete and significant step forward in Ethereum’s path toward decentralized scaling.
In simple terms, current Ethereum Layer 2 networks need to submit their transactions into the calldata field of Ethereum mainnet blocks so that nodes can verify the validity of L2 block production.
The problem with this approach is that even though transaction data is highly compressed, the massive volume of L2 transactions multiplied by Ethereum’s high storage costs still results in significant expenses for both L2 operators and users. High fees alone could drive many users away from Layer 2s and toward sidechains.
EIP-4844 introduces a new, cheaper storage area called BLOB (Binary Large Object), along with a new transaction type known as "BLOB-Carrying Transaction," which replaces the previous method of storing transaction data in calldata. This innovation helps reduce gas costs across the Ethereum ecosystem’s Layer 2 networks.
Why BLOB Storage Is Cheaper
As is well known, lower cost comes at a trade-off. BLOB data is cheaper than equivalent-sized regular Ethereum calldata because the Ethereum execution layer (EL, EVM) cannot directly access the actual BLOB content.
Instead, the EL only has access to references (commitments) of the BLOB data. The actual BLOB data is downloaded and stored solely by Ethereum’s consensus layer (CL), also known as beacon nodes, requiring significantly less memory and computational power compared to standard calldata.
Moreover, BLOBs have a limited retention period—typically around 18 days—and do not contribute to indefinite growth of the blockchain state size like traditional Ethereum ledger data.
BLOB Retention Period
Unlike the permanent blockchain ledger, BLOBs provide temporary storage lasting 4096 epochs—approximately 18 days.
After this period, most consensus clients will no longer be able to retrieve specific data from the BLOB. However, cryptographic evidence of its prior existence—specifically, the KZG commitment—remains permanently recorded on the Ethereum mainnet.
Why 18 days? This duration represents a compromise between cost efficiency and functional necessity.
The primary consideration involves Optimistic Rollups (e.g., Arbitrum and Optimism), whose fraud proof challenge window is set at 7 days.
The transaction data stored within BLOBs is exactly what challengers need when initiating a dispute.
Thus, the BLOB must remain accessible throughout the entire fraud proof period. For simplicity and alignment with Ethereum’s epoch structure, the community chose 2^12 = 4096 epochs (with each epoch lasting about 6.4 minutes).
Relationship Between BLOB-Carrying Transactions and BLOBs
Understanding the relationship between these two components is crucial for grasping how BLOBs function in the context of Data Availability (DA).
The former refers to the overall EIP-4844 proposal—a new type of transaction—while the latter denotes a temporary storage location specifically designed for Layer 2 transaction data.
You can think of it this way: most of the data in a BLOB-carrying transaction—i.e., Layer 2 transaction data—is stored inside the BLOB itself. The remaining piece—the commitment to the BLOB data—is stored in the mainnet’s calldata, where it remains accessible to the EVM.
Think of the commitment as analogous to building a Merkle tree from all transactions in the BLOB, where only the Merkle root (the commitment) is exposed to smart contracts.
This setup allows an elegant outcome: although the EVM cannot see the actual contents of the BLOB, it can still verify the authenticity of the transaction data via the commitment.
02 Relationship Between BLOBs and Layer 2
Rollup technologies achieve Data Availability (DA) by uploading data to the Ethereum mainnet, but not so that L1 smart contracts can directly read or validate this uploaded data.
Rather, publishing transaction data on L1 ensures that all participants can independently access and verify it.
Prior to the Dencun upgrade, as mentioned earlier, OP-Rollups published transaction data as calldata on Ethereum. This allowed anyone to reconstruct the state and verify the correctness of the Layer 2 network.
Clearly, Rollup transaction data needs to be both cheap and publicly transparent. Calldata was never ideal for storing large volumes of L2 transaction data, whereas BLOB-carrying transactions are purpose-built for Rollups.
At this point, you might wonder: if this transaction data seems so unimportant, what’s its real use?
In fact, transaction data is only needed in rare cases:
-
For Optimistic Rollups, under the trust assumption, dishonest behavior may occasionally occur. In such cases, the uploaded transaction records become critical—users can leverage this data to initiate a fraud proof challenge;
-
For ZK Rollups, zero-knowledge proofs already guarantee correct state transitions. Uploading data serves primarily to allow users to independently compute full state, enabling escape hatch mechanisms (explained later) when L2 nodes fail.
This means that actual on-chain usage of transaction data by smart contracts is extremely limited. Even in fraud proofs for Optimistic Rollups, only proof that a certain transaction “once existed” is required—not that every detail must be pre-stored on L1.
So if we store transaction data in BLOBs—making it inaccessible to contracts—but retain the BLOB commitment on the mainnet, then during a challenge, we just need to supply the relevant transaction data and prove it matches the commitment.
This convinces the contract to accept the data for use in the challenge mechanism.
This approach leverages public verifiability while avoiding the enormous gas cost of pre-loading all data into contracts.
By recording only commitments, Rollups achieve data verifiability at dramatically reduced cost—an elegant and efficient solution.
It should be noted that in practice, Dencun does not use a Merkle-tree-like structure similar to Celestia to generate commitments. Instead, it uses the sophisticated KZG (Kate-Zaverucha-Goldberg, polynomial commitment) algorithm.
Compared to Merkle tree proofs, generating KZG proofs is more complex, but verification is faster, requires less data, and involves fewer steps. A downside is the need for a trusted setup (ceremony.ethereum.org has concluded), and it lacks resistance to quantum computing attacks (though Dencun employs Version Hash methods allowing potential future migration to alternative verification schemes).
In contrast, popular DA projects like Celestia use variants of Merkle trees. While they rely somewhat on node honesty, this design lowers hardware requirements for running nodes, helping preserve network decentralization.
03 Opportunities From Dencun
While EIP-4844 reduces costs and improves efficiency for Layer 2s, it also introduces new security concerns—which in turn create fresh opportunities.
To understand why, let’s revisit the concept of the “escape hatch” or forced withdrawal mechanism.
When a Layer 2 node becomes non-functional or malicious, this mechanism allows users to safely withdraw funds back to the mainnet. To activate it, users must obtain the complete Layer 2 state tree.
Under normal conditions, a user requests data from a full L2 node, generates a Merkle proof, and submits it to a mainnet contract to prove rightful withdrawal.
But remember: users resort to the escape hatch precisely because L2 nodes are acting maliciously. If nodes are corrupt, they’re unlikely to provide the necessary data.
This is what Vitalik often refers to as a data withholding attack.
Before EIP-4844, Layer 2 records were permanently stored on the mainnet. So even without cooperative L2 nodes, users could spin up their own full node, sync historical data published by the L2 sequencer on Ethereum, reconstruct the required Merkle proof, and securely exit their assets.
After EIP-4844, however, Layer 2 data resides only in BLOBs held by Ethereum full nodes—and historical data older than 18 days is automatically deleted.
Therefore, the method described above—reconstructing the full state tree from mainnet history—is no longer viable. To obtain the complete Layer 2 state tree, users would now depend on rare third-party nodes that have retained expired BLOB data (which should have been purged after 18 days), or native L2 nodes (which are few).
As a result, after EIP-4844 launches, it will become extremely difficult for users to obtain the full Layer 2 state tree through fully trustless means.
Without reliable access to the Layer 2 state tree, users cannot perform forced withdrawals under extreme conditions. Thus, EIP-4844 introduces a notable security gap in Layer 2 systems.
To close this security gap, we need a trustless storage solution with a sustainable economic model. Here, “storage” refers specifically to preserving Ethereum data in a trustless manner—distinct from prior storage projects due to the added requirement of “trustlessness.”
Ethstorage can solve this trustless storage challenge and has received funding from the Ethereum Foundation in two separate rounds.
Indeed, Ethstorage is perhaps the only project truly aligned with and capable of addressing the challenges introduced by the Dencun upgrade—a sector worthy of close attention.
First and foremost, Ethstorage directly addresses the issue by extending the availability period of DA BLOBs in a fully decentralized way, effectively patching the weakest link in Layer 2 security post-EIP-4844.
Additionally, most existing L2 solutions focus on scaling Ethereum’s computational capacity—increasing TPS. Yet demand for secure on-chain data storage is surging, especially due to the popularity of dApps like NFTs and DeFi.
For example, the need to store NFTs on-chain is evident—users want not only the token but also the image itself to reside on-chain. Ethstorage eliminates the extra trust assumptions introduced by storing images on third-party services.
Finally, Ethstorage can also meet the needs of decentralized dApp frontends. Currently, most are hosted on centralized servers (with DNS), making them vulnerable to censorship, DNS hijacking, website breaches, or server outages—events like Tornado Cash serve as cautionary examples.
Ethstorage is still in its early testnet phase, and users interested in this space are encouraged to explore it firsthand.
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
@BiteyeCN
