In the ever-evolving field of blockchain technology, Ethereum stands as a pioneering force, continually evolving and upgrading its capabilities. Each Ethereum upgrade (executed via hard-fork) inevitably touches many lanes with Ethereum’s roadmap. But every upgrade is usually designed with a primary objective in mind.

With the Deneb + Cancun upgrade, also referred to as Dencun upgrade, there is a clear focus on improving Ethereum’s scalability with the creation of “data blobs”. We will discuss about the main changes in this upgrade, but first lets understand the two layers of Ethereum. 

The Two Layers

Ethereum network is divided into 2 layers : Execution Layer and the Consensus Layer. These layers used to operate independent of one another but after “The Merge”, these layers run parallel.

Execution Layer is responsible for execution of smart contracts & processing transactions as well as maintaining the state of Ethereum network. The hard fork corresponding to this layer is called Cancun.

Consensus Layer ensures that all transactions and smart contracts are validated and agreed upon by all nodes via PoS. The hard fork corresponding to this layer is called Deneb.

We will now discuss the main Ethereum Improvement Proposals (EIPs).

EIP-4844 (Shard Blob Transactions)

This proposal is also known as proto-danksharding. It is the most notable change we will get to see in this upgrade. This upgrade helps Ethereum with its scalability issues.

NOTE : This EIP doesn’t provide full scaling but only minor improvements to scaling.

EIP-4844 introduces a new transaction type called “blob-carrying” transactions, aimed at scaling Ethereum by enabling cheaper data posting to the Ethereum mainnet. Blobs are essentially ‘side-cars’ filled with data that ride alongside blocks. They contain batched transactions executed on Layer 2 rollups.

Rollups are layer 2 scaling solutions for Ethereum that process transactions off-chain to increase network throughput and reduce transaction costs. They compress transaction data into summaries or proofs, which are then submitted to the Ethereum mainnet for validation.

The key feature of blobs is that they do not directly contain data accessible to Ethereum’s execution layer (EL). Instead, they include references to the data stored exclusively on Ethereum’s consensus layer (CL), reducing the computational and storage requirements for Ethereum nodes. Blobs have a limited lifespan of approximately 18 days, after which their data becomes inaccessible, although cryptographic evidence of their existence remains.

Rollup sequencers, among others, will utilize this to post data more affordably. They will use blobs to post data to Ethereum mainnet, achieving the same goal as posting calldata but at a lower cost. The number of blobs per block is dynamic, with pricing incentives similar to EIP-1559. The protocol targets three blobs per block, but this can vary based on market dynamics. Each blob can hold up to 128KB of data, potentially increasing block sizes by up to 40%, but only temporarily.

EIP-4844 lays the groundwork for future scalability upgrades, such as full Danksharding, by introducing blob-carrying transactions and optimizing data availability while preserving decentralization. It represents a step towards a more scalable and decentralized Ethereum network.

EIP-4788

EIP-4788, a proposal set to revolutionize Ethereum’s functionality, aims to bolster communication between its execution and consensus layers. This enhancement is pivotal for applications reliant on Ethereum’s consensus state, like liquid staking protocols and restaking applications.

By embedding the parent (previous) beacon block root, which signifies Ethereum’s consensus state, directly into each execution block, EIP-4788 fundamentally changes how Ethereum operates at its core. Earlier, Ethereum’s layers communicated through limited channels, such as Eth1 data voting and Engine API-intermediated flows. These processes, while functional, posed challenges and limitations. EIP-4788 introduces a groundbreaking approach by integrating the beacon block root into the Ethereum Virtual Machine (EVM). This move effectively establishes an oracle at the protocol level, enabling any smart contract on Ethereum mainnet to access Ethereum’s consensus state without relying on trusted oracle solutions.

Liquid staking pools and restaking applications stand to benefit significantly from EIP-4788’s implementation. These applications, which currently rely on trusted oracle nodes to report Ethereum’s consensus state, will now have access to trust-minimized, cryptographically verifiable data directly from the protocol.

By bridging the gap between its execution and consensus layers and providing decentralized access to consensus state information, Ethereum becomes more robust, secure, and accessible. As the Ethereum ecosystem continues to grow and mature, innovations like EIP-4788 play a vital role in charting its future trajectory.

EIP-7514: Managing Validator Growth

EIP-7514 proposes to cap the per-epoch churn limit at 8, transitioning Ethereum’s validator growth from exponential to linear. Churn limit defines the maximum number of validators that can enter (or exit) the active set of Ethereum validators every epoch (~6.4 minutes) This change aims to address concerns regarding state-size bloat and network strain caused by an excessive influx of validators. Testnet simulations revealed challenges for client software when handling more than 2 million validators, prompting the need for this EIP’s inclusion.

The proposal focuses specifically on controlling the entry of validators into the system while leaving the exit process unaffected. This targeted approach aims to provide a temporary solution while allowing time for research into more comprehensive strategies, such as stake consolidation. The ultimate goal is to find a balance that supports Ethereum’s growth without overwhelming the network.

EIP-1153: Introducing Transient Storage

EIP-1153 introduces transient storage opcodes (TLOAD, TSTORE) to the Ethereum Virtual Machine (EVM). These opcodes allow for the temporary storage of data during transactions, with the data being discarded at the end of each transaction. This concept of transient storage enhances gas efficiency for inter-frame communication, reducing reliance on costly permanent storage.

Transient Storage: It will allow data to persist across different function calls, but within the same transaction. This makes it useful for transactions that involve multiple functions interacting with the same dataset. Transient Storage will be cleared at the conclusion of each full transaction, just like memory, but unlike memory, it allows for persistence and reference across the different function calls within that same transaction.

By introducing transient storage, EIP-1153 creates a third storage form alongside permanent storage and memory. This optimization improves the efficiency of smart contract development by providing developers with a more flexible and cost-effective storage option. It standardizes a previously inefficient process within the EVM, leading to better performance and lower costs for complex transactions.

Other EIPs

There are many other protocol changes that we haven’t covered.

Here is a list of all the changes :

• EIP-5656: MCOPY — Memory copying instruction
• EIP-6780: SELFDESTRUCT only in same transaction
• EIP-7044: Perpetually Valid Signed Voluntary Exits
• EIP-7045: Increase Max Attestation Inclusion Slot
• EIP-7516: BLOBBASEFEE opcode