Deneb-Cancun Upgrade

Ethereum, aspiring to be the world’s computer, has paved the way for decentralized applications by creating a new paradigm for digital transactions and contracts. However, great popularity can bring great challenges—notably in scalability. Enter the Deneb-Cancun upgrade, poised to significantly enhance Ethereum’s data capacity and efficiency. This upgrade holds massive implications for Ethereum investors; creating the foundation to support a transaction throughput orders of magnitude greater than Ethereum’s current capabilities.

Ethereum as a Scalable Database

Ethereum functions not only as a distributed ledger, storing blocks of transactions, but also as a distributed database that stores data vital to the functioning of other blockchains. Viewing Ethereum through the lens offered by a distributed database is a useful analogy in the context of this upgrade because Ethereum is currently scaling through other blockchains (Layer 2s). 

Ethereum Improvement Proposal 4844 (EIP-4844) is the highlight of the Deneb-Cancun upgrade and will be the focus of this piece. The implications of this specific proposal are most important for investors to consider. For the full list of EIPs included in Deneb-Cancun, see the Appendix.

Understanding Key Terms

First, we define some key terms that are necessary for understanding the changes introduced by EIP-4844.

Layer 1 (L1)—The primary Ethereum blockchain (a higher level of security and decentralization than other layers).

Layer 2 (L2)—A supplemental blockchain that posts data to the Ethereum (Layer 1) blockchain. L2 blockchains have a mechanism that is verifiable on-chain to prove that the batches of transactions posted to Ethereum happened and are valid. As a reminder, the purpose of L2s is to handle most of the transaction executions. Rather than have all transactions occur on Ethereum’s main chain, most transactions can be done via a “layer up” and settle to Ethereum later. L2 transactions are batched together and periodically submitted to the main chain, thus amortizing the single Ethereum transaction fee across hundreds of batched transactions. This is a core reason why L2 transactions provide a cheaper alternative to transactions occurring on the main Ethereum chain.

Gas—The unit that quantifies the computational effort needed to perform transactions on Ethereum. Users pay gas fees and a tip in ether (ETH) for each transaction. Ethereum’s blocks have a gas limit of 30 million, meaning that there are only so many operations that can fit into one block.

Batch—A grouping of transaction data that lives on Ethereum for any interested party to verify. A batch is equivalent to a block of transactions. L2s process transactions and submit them in batches to the Ethereum L1.

Sequencer—A sequencer is like an Ethereum validator, but its only duty is to receive and process transactions that happen on L2s. Every minute or so, the sequencer will batch the most recent transactions together and send the data to an address on Ethereum.

Calldata—The transaction component where data are stored. When L2 sequencers post their batches to Ethereum, it is in the form of calldata, which have a cost associated with the size of the data being stored. Calldata can be any type of arbitrary data that get stored on the blockchain forever and are currently an expensive data storage option when compared with blobs.

Blob—A new container for data being introduced in the Deneb-Cancun upgrade. Its sole function is to temporarily hold substantial amounts of data at a cheaper cost than calldata. 

Fraud Proof—Proves that data submitted by the sequencer is inaccurate (i.e., it looks for fraud). When L2 sequencers submit batches of transactions, there is a waiting period before final confirmation to allow anyone to submit a fraud proof. When a discrepancy in the data posted is found and a fraud proof is submitted, the L2 blockchain reverts to the most recent state before the inaccuracy. This ensures that the data that L2s post to Ethereum originated on the L2 blockchain. Fraud proofs are only used for optimistic rollups, which are most common today, yet other rollup designs have different mechanisms for proving that the data they post to Ethereum are correct.

Below is a breakdown of the lifecycle of a transaction on an Ethereum L2.

1. User sends a transaction on an L2.
2. Transaction is processed by the sequencer and included in an L2 batch.
3. L2 sequencer sends the batch of transactions to Ethereum as calldata.
4. A waiting period of at least seven days must pass to allow any nodes to submit fraud proofs.
5. Waiting period ends, transaction is submitted and considered irreversible.

The third step in this process is programmed to change slightly with the upcoming Deneb-Cancun upgrade. Instead of sequencers posting batches of calldata to Ethereum, they will post them as blobs. Blobs are more efficient than calldata because their gas costs are lower and they are only temporarily stored on Ethereum to ensure they persist no longer than necessary to support fraud proofs.

The efficiency differences between blobs and calldata are at the core of this upgrade. Allowing L2s to post their data to Ethereum at lower fee rates will allow platforms to pass on cost savings to users. Additionally, bounding the time for which Ethereum nodes must store this data allows substantial amounts of data to be stored without causing long-term strain on node storage requirements. 

EIP-4844 Scales Ethereum While Remaining Relatively Decentralized

While the Deneb-Cancun upgrade is making L2s more cost-efficient for scaling, the way it is done ensures that the resource requirements for running Ethereum do not increase significantly. Keeping the rate at which a blockchain’s requirements increase below the rate of technology improvements is an important measuring stick to help figure out the blockchain’s trajectory on the decentralization scale. 

For example, in cases where a blockchain requires 1 terabyte (TB) of additional solid-state drive (SSD) space per year, but the cost per TB of SSD is not dropping at an equivalent rate, a centralizing force is created on the node set because running the blockchain becomes less affordable over time. In the opposite case where blockchain requirements increase at 1 TB per year, but the cost per TB of SSD drops at a faster rate, a decentralizing force is created on the node set due to the increased affordability of the technology needed.¹

Incremental improvements that track or slightly lag the improvements in technology are at the core of the reason scaling Ethereum through data efficiency was chosen. These improvements have helped to solidify Ethereum as one of the most secure and decentralized networks. The prioritization of these two characteristics is what makes Ethereum unique in an industry with thousands of different blockchains and is one reason why we believe Ethereum will outcompete others that have sacrificed some security or decentralization for greater transaction throughput. 

Below is a table highlighting the changes in resource requirements resulting from EIP-4844. Keep in mind that this is a fixed requirement and does not increase with time. The temporary nature of blobs prevents the requirements from expanding beyond the thresholds below; nodes will remove any blobs once they become 18 days old. 

Current hardware specifications for the Ethereum blockchain call for at least 2 TB of SSD storage and 25 megabytes (MB)/s bandwidth, so the incremental increase in requirements (100 GB and 64KB/s) is small. Additionally, there are future upgrades that are expected to take further advantage of this asymmetric increase in data and requirements by making blob data easier to verify. Therefore, future versions of Ethereum will be able to store more than the six-blob maximum being implemented in Deneb-Cancun and thus benefit further from this asymmetric scaling design.

What Does “Scaling Through Data” Mean?

If we view Ethereum as a database that stores transaction batches from other blockchains, we can quickly understand what “scaling through data” means. The more data Ethereum can store per block, the more transactions can occur on L2s within that same time. However, Ethereum is already at a point where it can store all the transaction data appearing on L2s, but these platforms currently pay a relatively high cost for doing so, which is then passed on to users. 

Each byte of data that L2s store on Ethereum costs roughly 16 gas. The introduction of blobs and a new fee market designed for blob data drops the gas cost down to 1 per byte of data stored.² This is a maximum gas cost reduction of 94%! However, this will not result in an equal decrease in fees on L2s because the price you pay for gas changes based on blob usage.

This upgrade acts as a steppingstone toward future developments by implementing all of the scaffolding needed to make future upgrades to Ethereum’s database much easier. The success of this upgrade should foster organic user growth on L2s because the most common transactions on Ethereum today could take place there for pennies on the dollar.

Currently, L2s account for roughly 10% of the total L1 fees. This should drop significantly once the upgrade has been implemented. L2s are the main players in the ecosystem that have a need for temporary data storage on Ethereum, but this may not stop speculators from using this new solution for unintended things. 

In the short term, it is expected that L2s will not be fully using blobs, which means that there is extra cheap storage for people to use however they wish. As with the BRC-20 innovations seen on bitcoin in 2023, it will be interesting to watch how the secondary effects of cheap data unfold.

Scenario Analysis: Will Blobs Be Fully Used?

In this section, we consider a few basic scenarios to find out at what point blobs will be fully used and, therefore, reach the maximum efficiency gains possible from this upgrade. Once the full potential of blobs is captured, it may result in continuous increases in blob price (as a reminder, there will be a competitive market for blob space), up to the point where it does not provide cost benefits when compared with normal calldata usage.

First, we assume that all L2 platforms use one blob per batch and that none of the blob space is being shared. Second, we assume a fixed batch submission time schedule to make the analysis cleaner when, in reality, L2 responses to data costs on the base layer (Ethereum) will be much more flexible.

In the above chart, we analyze how many blobs will be used based on how many L2s are submitting blobs at various frequencies. If blob usage is above 50%, this means that the price of blob data in the next block will increase. If blob usage is below 50%, the price of blob data will decrease—just as normal transactions behaved before Deneb-Cancun. 

In the middle of the chart, we see that if 15 L2 platforms submitted one blob of transactions per minute, then there would be an equilibrium in blob price because it is exactly at the target of 50% usage. 

This analysis supports the idea that blobs will be underused by L2s shortly after the Deneb-Cancun upgrade. However, it is likely that while blobs are underused by L2s, other participants of the Ethereum ecosystem will step in to take advantage of cheap blob space.

Frameworks for Measuring Success

To gauge the success of EIP-4844 and its impact on Ethereum’s investment thesis, several frameworks can be applied:

Integration and Adoption

The primary metric for this framework is the usage of blob transactions by L2 platforms. This would show the economic benefits gained by L2s and, as a result, improve L1 network congestion. 

It is expected that all L2s will use blobs fully until the cost of blobs becomes greater than that of using calldata (which they currently use).

In addition to blob usage being high for L2s, it would be an even larger success to see other types of transactions fill the block space that had once been used for L2 submissions.

The significant risk to blob usage is that newer L2 platforms might adopt other data availability options for storing their data. If these competing data availability layers offer substantially lower storage costs than Ethereum, the incentive to use other solutions to boost margins or offer lower fees to users could be tempting. 

Cost Reduction Analysis

It is also expected that the availability of L1 gas to be used for other activities will increase because L2s are expected have a separate gas and fee market in which to compete. If L1 transactions continue to remain steady, this would have meaningful implications for the future usage of the platform, signifying high demand in the face of other low-fee transaction options. 

User and Developer Growth

EIP-4844 should support an increase of users on Ethereum’s L2s and, arguably more importantly, the developer activity to retain those new users. This would signal a growing ecosystem. 

We expect to see an initial surge in users’ taking advantage of the lower fees—especially on L2 platforms that have not released tokens. This is likely to result in a positive feedback loop in which more users attract more developers who make applications that attract more users.

Implications for Ether’s Investment Thesis

Ethereum’s time as a general purpose blockchain may be taking a backseat to the new paradigm in which Ethereum serves as a global database. Instead of primarily serving end users, it is likely that the Ethereum network will continue the transition to serving other blockchains or applications. Moreover, this emerging shift in the Ethereum customer base may help to propel it forward and set it apart from competitors.

The main implications of this shift include:

1. User adoption of L2s, or a proxy to this, like active addresses, forms the main metric for this upgrade’s success. Each user added to the network exponentially adds to its value (due to network effects). The ability of L2 platforms to design for specific applications will improve the user experience and probably attract new and more consistent users and developers.
2. While blobs are still underused, it is expected that the extra blob space will be used for experimental purposes (just as inscriptions on Bitcoin create unforeseen demand).
3. Although this upgrade may lower fee revenue and burn from L2s in the medium term, EIP-4844 provides the level of scaling necessary to support millions of users on L2 platforms. Ultimately, this makes it a more fitting distributed database for other blockchains. Given that these improvements are likely to bring substantially more users into the Ethereum ecosystem, the Deneb-Cancun implementation seems synonymous with sacrificing short-term revenues in hopes of expanding Ethereum’s total addressable market.

Conclusion

The Deneb-Cancun upgrade is the first step toward enabling Ethereum’s rollup-centric roadmap. It creates the bedrock that L2 platforms will use to build their ecosystems. EIP-4844 allows Ethereum to function as a proper database for L2s to store data more efficiently. Ethereum’s improvement as a database unveils the opportunity for near-zero transaction fees for users of L2s, which may attract new users. 

However, this upgrade will not have many direct effects on Ethereum users themselves. The fee decrease promised to L2 users will not have any impact on those transacting on Ethereum L1. In the short term, users who wish to benefit from this fee change must sacrifice some decentralization and security by transacting on L2s instead of Ethereum. This will certainly spur more users to bridge assets elsewhere. However, we strongly believe that transacting on Ethereum for application-specific purposes will still be considered the best option (especially for high-value transactions) in the medium term as L2 platforms continue to mature.

Appendix

EIPs:

• 1153: Transient Storage Opcodes—Implements transient storage opcodes for temporary state changes in smart contracts, enhancing efficiency and security.
• 4788: Beacon block root in the EVM—Allows applications to verify validator state, which may reduce trust assumptions in staking protocols.
• 4844: Shard Blob Transactions—Creates the transaction type, enabling blobs, called blob-carrying transactions. Blob-carrying transactions are included in Ethereum blocks and have a cryptographic link that points to the data stored in the associated blob.
• 5656: MCOPY—Memory Copying Instruction—Introduces a new instruction to efficiently copy memory areas, aiming to lower gas costs and enhance execution speed for certain transactions.
• 6780: SELFDESTRUCT only in same transaction—Alters the way the selfdestruct function works to make it future-proof for verkle tree implementation.
• 7044: Perpetually Valid Signed Voluntary Exits—Simplifies staking operations, specifically for exiting the validator set.
• 7045: Increase Max Attestation Inclusion Slot—Increases time allowed for attestations to be sent. Enhances security of the Proof-of-Stake system.
• 7516: BLOBBASEFEE opcode—Creates the fee market for blobs; similar mechanism to current gas structure (1559).⁵

Interested in learning how Fidelity Digital Assets℠ custody and execution services or investment solutions could be right for you?

Fill out this form and a member of the Fidelity Digital Assets℠ team will reach out to you.