Ethereum's Dencun Upgrade: Part One

Blockchain data storage

Ethereum’s extensive DeFi ecosystem relies on a network of smart contracts, executed by validators, who are tasked with updating the network’s state with transaction results appended to blocks every 12 seconds. The computational effort (measured in “gas”) required to compute the results and include them in blocks on the chain is rewarded in ETH. 

Transaction fees are quoted in the amount of ETH paid per unit of gas (or unit of computation). Each block has a maximum gas limit of 30M units and a target size of 15M units (set by the Ethereum Foundation), designed to represent typical network activity. One portion of the fee per unit of gas depends explicitly on network congestion (base fee). For a full breakdown on fees paid per unit of gas, we refer the reader to the “Gas Mechanics” report, here.

What is the problem?

Ethereum boasts a relatively high capacity for blockchain activity compared to other blockchains with smaller block size limits and longer block intervals. On the Ethereum mainnet, all nodes must validate and reach consensus on each transaction. Since Ethereum has initially decided to optimise for security and decentralisation, block sizes have been deliberately limited in order to maximise the number of nodes which must reach consensus. This introduces latency and limits transaction throughput compared to other faster, but less secure/decentralised blockchains. 

L2 solutions are widely considered the only scaling solution for the Ethereum network. They address this problem by processing transactions faster compared to the Ethereum mainnet, moving some of the transaction processing off the Ethereum blockchain while maintaining its security guarantees. L2 rollups, such as Optimism and Arbitrum, have significantly reduced fees compared to the Ethereum base layer, making transactions more affordable, but are still too expensive. However, spikes in network activity, such as the FTX collapse, can lead to transaction congestion, delays, and high gas fees.

Currently, L2 transactions are settled periodically on-chain by posting batches of transactions. As the ecosystem has grown, blocks regularly approach their full capacity, beyond the target block size. This leads to an increase in gas fees. Furthermore, space to grow the network is limited, preventing widespread adoption since the fees paid per transaction do not scale linearly with the amount of users.

So, how does the upgrade help L2s post more data for less ETH?

What is the solution?

A new type of transaction

The Dencun update adds a new type of transaction to the Ethereum network that will provide a dedicated method for users to store data onchain. This new transaction type will still live in the execution layer (like all other transaction types), where L2s submit an entire block of data in the current solution.

However, instead of containing the full block of data within each transaction, it will instead hold only a hash of the full data. The execution layer transaction containing the hash serves as a reference to the blob of data that it paid for.

The implication is that a blob hash transaction has to pay to live on the execution layer while the full data lives offchain in a “blob”, and so will still need to compete in the regular mempool by bidding regular gas fees to be included onchain. However, it will be a negligible amount as it will need to pay for the storage of just the blob-space hash, rather than the full contents of each blob.

Hosting only the hash in the block (and not the full data) is justified because it is not the Ethereum validators responsibility to check the validity of transactions on the L2, it is the job of validators on the L2 chain. The Ethereum network needs only to make the data available for the L2 validators to check once now, in order to challenge its validity (on the L2 chain). Later, a user can use the hash to verify that any data sent to them by a node or centralised data provider matches the data that was shown when the hash was created onchain.

The question then, is “where will the full data live?”

Where does the full data live?

When producing an Ethereum block, proposers send their candidate block as a message to the peer-to-peer network of validators and nodes. The network of validators checks the proposing staker’s work to see if the block is valid. If they agree that it is valid, they submit a vote in its favour that is included in the next block. For an in depth discussion, read the consensus layer report, here.

If the block that has been proposed contains blob transactions, each validator must check that the data in each blob has been referenced correctly in the execution layer. To do so, they must have seen the blob data by the time that they are asked to vote on the block. Therefore the proposer must also send the blob data alongside their proposed block to the same network of all validators – something they must already do when L2s submit data via regular transactions.

Note that validators do not need to check that the contents of the data are valid transactions on whichever rollup they concern – only that the data was made available to them and was referenced correctly on the execution layer by the proposer of the block. Validators are also asked to hold onto that data for 4096 epochs (~18 days, allowing for a sufficient challenge period for rollups), but this requirement appears to be enforced in a very weak way – validators that do not provide blocks to a peer when asked can be disconnected from the peer on the peer-to-peer network. In practice, what incentive does a validator have to ensure that they can deliver blob data for 4096 epochs?

Ensuring that the data was referenced correctly with a hash allows later users who ask for that blob data from an archive node (or any other data provider) to check that the blob data that they are given matches what was originally attested to on the network. They can do this by computing the hash of the blob data they are sent – as long as this matches the hash that was attested to on the network, they can be reasonably (cryptographically) sure that it was not later changed by the data provider. Whether that data was valid at the time of submission is up to the consensus mechanism of the rollup.

Storage space in the current solution

Before the upgrade, L2s stored data on the Ethereum chain by attaching it to regular transactions. There, an L2 must use 16 units of gas to store 1 byte of data. Therefore, in the extreme case where a regular Ethereum execution layer block contains nothing but L2 data storage, the limit of 30M gas units per block means that the limit on the amount of data that can be stored is just 1.875MB.

Blob space data storage

In the new “blob space”, an L2 must only use 1 unit of “blob gas” per byte that they store. Note that this does not mean that storage in the new blob space is 16 times cheaper than on the regular network – blob gas is paid for in ether, and its ether-denominated price floats freely, independent of the regular gas market.

The new section contains six spaces in which L2s can store data, each with space for 2^17 bytes of data, or 1.31MB. As there are six spaces, a block can hold a total of 7.86MB of data in its blob space. L2s must pay for the whole space that they use, even if the data that they wish to store in it does not take up the full 1.31MB allotment.

The price per unit of regular gas and blob gas (whether it is spent on storage, transactions, or computation) is not prescribed by the protocol, but is instead determined by the market (with some details that we will cover soon). However, storage in this new “blob” space will be cheaper for 3 reasons:

1. There is space for more data. This means that storage space is less competitive, and that L2s do not need to bid as high to be included onchain.
2. The new space is only used for data storage. This means that data storage transactions do not need to compete against other transactions that require more complex computation, such as interactions with smart contracts or transfers of ether.‍
3. The new space stores data temporarily. After a short delay (to allow for the validity of the data to be checked and challenged on the L2 chain), Ethereum node operators are permitted to delete the full blob of data. Only the hash lives onchain, and therefore only the hash must be stored forever.

In the extreme case where the ether price per byte of data storage on the new blob space is equal to the ether price per byte of storage on the regular network, L2s will have a choice of which space to use to store their data. If high pricing pushes L2 transactions back to the regular network, the lower demand for the blob gas market will mean that it becomes cheaper once more. This acts to bound the price of data storage from above by the price on the existing network.

New gas, new market, new mechanics

Before diving into the specifics of the new blob gas market, we recommend refreshing your knowledge of Ethereum’s regular gas market, introduced in EIP-1559, here.

Blob Spaces

Despite introducing an independent gas market, the mechanism is largely very familiar to the “regular” gas market, with each blob-space parameter entirely independent of it’s mainnet equivalent:

• Each unit of gas used by the transaction is paid for with ETH. 
• The maximum amount of ETH spent per unit gas is specified by the sender of the transaction.
• The fee paid per transaction is split into a base fee, burnt forever from the supply of ether, and a priority fee, paid to block proposers as a tip for including the transaction in a block.
• The base fee varies according to the amount of gas used in the previous block.

One difference in the new mechanism is that users do not need to specify a maximum amount of gas used by their transaction. The amount of gas used is known, owing to the requirement that the user pays for an entire 1.31MB data blob at a time.

Like its mainnet equivalent, the blob base fee changes from block to block to incentivise data storers to maintain an equilibrium amount of blob gas used to lighten the data storage requirement load on validating nodes. However, the details of its update function are slightly different to the regular base fee.

Excess blob gas

Instead of calculating the blob base fee for the current block based only on the gas used in the block immediately previous, the blob base fee is determined based on a running total of the excess blobs used in all blocks in the chain previous to it.

Each block targets the use of 3 out of the 6 available blobs. As each blob requires the user to pay for the entire blob space, this means a target blob gas usage of 3 times 2^17 gas units, or 0.39MB bytes of data stored. Any blobs used above this target increase the running total, and any blobs used below this target decrease it – the running total is never negative (as per the hardcoded update rule).

Let’s see an example of blobs used in a series of three consecutive blocks (that are the first three in their chain), which use 3, 4, and 2 of the available 6 blobs respectively. 

In the first block above, the number of blobs used hits the target of 3, and so the excess running total of excess blobs remains at 0. The second block uses 4 of the available 6 blob spaces. All four of the blobs and their data are included onchain in this block. This is one more than the target of 3 blobs, and so increases the running total of excess blob gas used by 1 blob.  The third block in the series uses only 2 of the 6 available blob spaces. This reduces the running total of excess gas used by 1 blob, bringing the running total of excess blob gas used back to 0.

The running total of excess blob gas can be also distributed over multiple subsequent blocks, as shown by the below example, which displays 4 consecutive blocks that use 6, 2, 2, and 1 blob spaces respectively.

The first block uses all 6 available blob spaces, increasing the excess blob gas used by 6 blobs (assuming that the net excess blob gas used in all of the blocks before it is zero). The second and third blocks both use only 2 of their 6 spaces, decreasing the excess blobs by 1 in each case. The final block uses only one of its 6 available slots, allowing the excess blob gas to return to zero – note that it is not negative, as the running total of excess blobs is bounded below by zero.

The blob base fee calculation

The blob base fee that applies to transactions in a block is calculated directly from the running total of excess blobs used in the previous block. As we noted above, each blob uses 2^17 blob gas. Therefore the blob base fee (in units of giga-wei per unit of blob gas used) is given by

This is akin to the mechanism that determines the base fee in Ethereum’s execution layer, which calculates the base fee from the amount of gas used in the previous block. In a similar manner to the limits on the regular base fee changes, the blob base fee can change by a maximum of (around) 12.5% in each block as a result of the choice of denominator, 3338477. To see this, we expand and rewrite in terms of the blob base fee in the previous block

The final equality follows by taking Excess Blobs Used = 3, achieved when all 6 blob spaces are used in a block. This implies a similar bound on the maximum decrease in blob base fee between consecutive blocks: the running total of excess blobs can fall by at most 3 when the block is empty of blobs, giving a maximum fall of -11.11%.

Conclusion

The Ethereum network’s solution to its scalability issues is moving transactions and computation onto third party “layer 2” blockchains called rollups. These L2s already account for around 2M units of the 15M target gas usage in each block by using regular Ethereum transaction types to store rollup data on Ethereum’s execution layer.

The Dencun upgrade, specifically EIP-4844, is an attempt to make storing that data cheaper by creating an independent gas market that exclusively prices data storage and by relieving the requirement that Ethereum stakers must store that data indefinitely. The new gas market mechanics borrow heavily from the regular gas market, while introducing innovations in the calculation of the base fee burnt in each block.

Here, we have covered why the network is in need of this upgrade and how it will work. Next, we will look at the implications of removing more than 10% of the gas usage in each block on the base fee, the amount of ether burnt, and the rates earned by Ethereum stakers in each block.