What can we expect after Ethereum’s Dencun upgrade? | Posted by: Jin Ming | Coins | January 2024

We’ve all heard how Dencun upgrades can help lower call data costs from L2 to L1, but is that all there is to it? Apart from that, the Dencun upgrade introduces several important features that improve the developer experience and make Ethereum more suitable for future improvements.

These two EIPs serve to enhance Ethereum’s execution layer. EIP-6780 disables the use of opcode SELFDESTRUCT. This will help with future Verkle tree implementations that will make it impossible to execute SELFDESTRUCT opcodes before EIP-6780. This may be a blessing in disguise, as the OP code SELFDESTRUCT can be dangerous and is often part of metamorphic smart contracts that end up being rug-pulled. The self-deterministic nature of SELFDESTRUCT makes it difficult for developers to use, and often leads to an incomplete state where data is not completely deleted as intended. This upgrade eliminates the negative consequences of future SELFDESTRUCT references! Existing contracts that currently use SELFDESTRUCT are not affected.

EIP-5656 serves to improve the efficiency of the memory copy method within the EVM, which is an important feature for various tasks such as building data structures and copying objects. The introduction of the MCOPY opcode in EIP-5656 essentially combines MLOAD and MSTORE to transfer data from one location to another more efficiently. Currently, copying 256 bytes of data using MLOAD and MSTORE costs at least 96 gas, while MCOPY costs 27 gas. This reduces gas fees for smart contracts that use memory copy and improves the readability and maintainability of smart contracts. After implementation, developers will not be required to use MCOPY and existing references to MSTORE or MLOAD will not be affected.

These two upgrades are staking and validator focused.

EIP-7044 allows for pre-signed voluntary terminations that are effective in perpetuity. This means that pre-signed voluntary terminations will remain valid indefinitely, rather than remaining valid only for the current and previous fork versions, as is currently the case. This is a significant upgrade for stakers, a delegated staking solution that puts signing keys in the hands of validator operators who carry out the responsibility of proving and proposing blocks. This can be problematic in the current model in scenarios where validator operators refuse to respect a staker’s voluntary decision to leave (unstake). This upgrade ensures that stakers can voluntarily submit voluntary terminations to the Ethereum consensus client and independently terminate validators.

EIP-7045 increases the limit on maximum attestation-containing slots. A proof can be considered a vote to approve the ‘correctness’ of that block. An epoch, a unit of time in Ethereum, consists of 32 slots, each with a time limit of 12 seconds to propose and verify a block. Currently there are 32 slots where validators can broadcast their proofs for inclusion in a specific slot. However, the new upgrade expands the maximum limit to 64 slots. This upgrade sees the benefit of making it easier to identify standard blocks, allowing nodes to easily resolve conflicts when two or more competing forks appear, resulting in faster transaction finality.

After the merge, communication between the execution client and the consensus client is mediated by a component called the Engine API. EIP-4788 aims to integrate beacon block roots within smart contracts in the EVM, allowing dApps to natively pull data from the execution layer to gain minimal trust access to the consensus layer. This supports use cases that improve trust assumptions for staking pools, re-staking pools, smart contract bridges, MEV mitigation, and more.

This upgrade is especially important for the ETH liquid staking protocol. This is because these protocols rely on oracles to fetch data, such as the balances of validators, from the consensus layer that are currently needed for execution (reward distribution). The introduction of EIP-4788 enables the implementation of a new design mechanism built on the ‘untrusted oracle’ configuration. This reduces risk points and improves the efficiency of liquid staking protocols as well as other protocols such as bridges and re-staking solutions.

EIP-7514 changes validator exit limits, while EIP-1153 introduces transient storage opcodes in the EVM.

With the release of EIP-7514, the maximum number of validators per epoch will be limited to 8, switching the maximum growth rate from exponential to linear. The rationale for this is that if the size of the set of active validators grows exponentially without limit, the state size will swell, placing additional burden on each node as it has to keep track of its peers. Testnet simulations show that the client software struggles to perform over 2 million validators. Having a large number of validators helps decentralize the network, but too many can lead to country-sized bloat.

EIP-1153 introduces two temporary opcodes: TLOAD and TSTORE. Ephemeral storage is a welcome solution because it allows data to be temporarily stored and deleted after each transaction without requiring costly writes to the EVM’s persistent storage. EIP-1153 complements today’s existing storage types, providing a gas-efficient solution for inter-frame communication during Ethereum transactions.

Lastly, there is EIP-4844, also known as “proto-danksharding”. This implementation reduces the rollup cost of posting data to Ethereum via “blobs”. Currently, the cost of posting data to Ethereum is still prohibitive. As these scalability solutions aim to become platforms for mainstream adoption, the cost of publishing rollup data will also increase significantly. By introducing a “blob carrying” transaction type, rollup sequencers can publish transaction data up to 100 times cheaper than is currently possible. Imagine the massive cost savings for these L2s, in addition to maintaining scalability and decentralization!

But what exactly is a stain? A blob can be thought of as a ‘compressed’ data structure, like a zip file, containing up to 128KB of data. Currently, a block on Ethereum contains all bundled transactions that are verified and recorded on the blockchain. After the Cancun-Deneb fork, blocks will consist of these typical Ethereum transactions and blob carrying transactions.

It is important to note that a blob transport block does not contain all blob data, but only a hash of the KZG promise for the blob. As a result, L2 Blob data cannot run on the execution layer of Ethereum (also known as EVM). The actual data that makes up a blob is only stored in Ethereum’s consensus layer for a limited time, up to 18 days. After that, the blob will no longer exist and proof of its existence will be in the form of a KZG promise proving that the blob data existed and was included in the Ethereum mainnet.

After EIP-4844 is enabled, each block can accommodate up to 6 blobs, but 3 is recommended due to the blob dynamic pricing structure, which makes publishing data on Ethereum increasingly more expensive when more than 3 blobs are connected. However, this limitation is temporary, as the final danksharding upgrade may increase the maximum number of blobs up to 16! Nonetheless, the upgrade takes Ethereum functionality to new milestones, enabling it to support publishing up to 5400 MB of data per day and significantly reducing transaction fees.

That’s it for today. I hope you like it~

https://dune.com/niftytable/rollup-economics