The Ethereum Dencun upgrade is officially scheduled to launch on March 13th. This article will explain the technical details of the Dencun upgrade in simple language and provide context between this upgrade and data availability (DA) and Layer 2 solutions.
EIP-4844 is the most important proposal in the Dencun upgrade, marking a significant step for Ethereum in decentralizing the expansion of its ecosystem. Currently, Ethereum Layer 2 needs to submit transactions occurring on Layer 2 to the calldata of the Ethereum mainnet for node verification. However, this approach incurs high costs for Layer 2 nodes and users due to the large transaction volume and expensive storage costs on the mainnet. This cost factor may cause many Layer 2 users to move to sidechains.
EIP-4484 introduces a cheaper storage option called Binary Large Object (BLOB) and a new transaction type called “BLOB-Carrying Transaction” to replace the need to store transaction data in calldata before the upgrade. This helps Layer 2 solutions on the Ethereum ecosystem save on gas costs.
The reason BLOB data is cheaper than regular Ethereum calldata is because the Ethereum Execution Layer (EL) cannot directly access the BLOB data. EL can only access references to the BLOB data, while the actual data is downloaded and stored by the Ethereum Consensus Layer (CL), also known as beacon nodes. The storage requirements for BLOB data are much smaller compared to regular Ethereum calldata, and BLOB data has a limited storage period (usually around 18 days) to prevent unlimited expansion.
Unlike the permanent ledger of the blockchain, BLOB storage is temporary and lasts for approximately 4096 epochs, or about 18 days. After expiration, most consensus clients will no longer be able to retrieve specific data from the BLOB. However, evidence of its previous existence will be stored permanently on the mainnet in the form of KZG commitments.
The choice of 18 days as the storage duration is a compromise between storage costs and effectiveness. For Optimistic Rollups, which have a 7-day fraud proof time window, the stored transaction data in the BLOB is necessary for initiating transaction challenges. Therefore, the expiration of BLOB data must ensure that Optimistic Rollups’ fraud proofs can access the required data. The Ethereum community chose 2^12 epochs (approximately 6.4 minutes per epoch) based on simplicity.
Understanding the relationship between EIP-4484 and BLOB is crucial for understanding the role of BLOB in data availability (DA). EIP-4484 introduces a new transaction type, while BLOB can be seen as a temporary storage location for Layer 2 transactions. Most of the data in EIP-4484 (Layer 2 transaction data) is stored in BLOB, while the remaining data, which is the commitment of BLOB data, is stored in the mainnet’s calldata and can be read by the Ethereum Virtual Machine (EVM). The commitment is constructed by building a Merkle tree from all the transactions in the BLOB, and only the Merkle root, or commitment, can be accessed by contracts.
Rollup solutions achieve data availability on the Ethereum mainnet by uploading data, but this does not mean that L1 smart contracts directly read or verify the uploaded data. The purpose of uploading transaction data to L1 is to allow all participants to view the data. Before the Dencun upgrade, Op-rollups released transaction data as calldata on Ethereum, allowing anyone to use this data to replicate states and verify the correctness of the Layer 2 network.
It is clear that rollup transaction data needs to be cheap and publicly transparent. Calldata is not a suitable place for specifically storing Layer 2 transaction data, but BLOB-Carrying Transaction is tailored for this purpose.
The importance of transaction data may be questioned, as it is only used in a few cases. For Optimistic Rollups, transaction records uploaded by Rollups are useful in cases of potential dishonesty, allowing users to initiate transaction challenges (fraud proofs). For ZK Rollups, zero-knowledge proofs have already proven the correctness of state updates, and uploaded data is only used for users to calculate the complete state themselves and activate the escape hatch mechanism in case Layer 2 nodes fail to operate correctly.
Therefore, the actual usage of transaction data by contracts is limited. Even in Optimistic Rollup’s transaction challenge, only evidence of the transaction’s existence is required, not the detailed transaction information stored on the mainnet in advance.
By storing transaction data in BLOB, although contracts cannot access the specific content of the BLOB, the contract can store the commitment of the BLOB. In the future, if the challenge mechanism requires a specific transaction, we only need to provide the data corresponding to that transaction. This can convince the contract and provide the transaction data to the challenge mechanism.
By recording only the commitment, the cost is optimized while achieving verifiability of transaction data. This is a clever and efficient solution for rollup technologies to upload transaction data.
It should be noted that in the actual implementation of Dencun, a different method called the Kate-Zaverucha-Goldberg (KZG) algorithm is used instead of a Merkle tree like Celestia. The KZG algorithm generates KZG proofs, which are more compact and easier to verify compared to Merkle tree proofs. However, KZG proofs require a trusted setup (ceremony.ethereum.org has already concluded) and do not have resistance against quantum computing attacks (Dencun uses the Version Hash method and can be replaced with other verification methods if necessary).
Celestia, a prominent DA project, uses a Merkle tree variant, which to some extent relies on node integrity but helps lower the computational resource requirements among nodes, maintaining the decentralized nature of the network.
EIP-4844 introduces cost-efficient Layer 2 expansion but also raises security concerns, creating new opportunities. To address this security gap, a trustless storage solution with a positive economic feedback loop is needed. Ethstorage aims to fulfill this requirement and has received funding from the Ethereum Foundation.
Ethstorage provides a fully decentralized way to extend the availability of DA BLOB, filling the security gap in Layer 2 after EIP-4844. Additionally, most existing Layer 2 solutions focus on expanding Ethereum’s computational capacity and increasing TPS. However, there is an increasing demand for secure storage of large amounts of data on the Ethereum mainnet, especially with the popularity of NFTs and DeFi dApps. Ethstorage can address the storage needs of on-chain NFTs, eliminating the need to trust third parties for storing images associated with NFT contracts.
Furthermore, Ethstorage can meet the demand for decentralized front-ends of dApps. Existing solutions often rely on centralized servers with DNS, making websites vulnerable to censorship, DNS hijacking, hacking attacks, server crashes, and other events. Ethstorage provides a solution that eliminates these issues by decentralizing the storage of dApp front-ends.
Ethstorage is currently in its early network testing phase, and users interested in its potential can try it out.
Related News:
– Understanding the ERC-404 protocol and its impact on the Ethereum NFT revolution
– Ethereum domain registration leader GoDaddy partners with ENS, resulting in a 15% jump
– Franklin Templeton applies for Ethereum spot ETF, embraces the crypto community, and praises the huge potential of SOL.