Ethereum Evolved: Dencun Upgrade Part 4, EIP-7514 & EIP-1153

Continuing this series, Part 4 touches on two disparate EIPs. Below we will explain the consensus layer specific EIP-7514, which will alter the validator churn limit, and EIP-1153, which will introduce transient storage op-codes in the EVM (execution layer).

• Part 1 of this series explored the opcode-focused EIPs 5656 and 6780.

• Part 2 of this series focused on two staking and validator upgrades: EIP-7044 and EIP-7045.

• Part 3 detailed the implications of EIP-4788, and how communication between the consensus and execution layers has evolved.

Ethereum EIP-7514: Add Max Epoch Churn Limit

EIP-7514 will establish a cap on the per-epoch churn limit at 8, thereby transitioning the maximum growth rate of Ethereum validators from exponential to linear. Ethereum’s churn limit defines the maximum number of validators that can enter (or exit) the active set of Ethereum validators every epoch (~6.4 minutes). The churn limit is currently a variable that has a minimum value of four and increases by one each time a specific number of validators (65,536 or the churn limit quotient) joins the active set.

This proposal – to cap Ethereum’s churn limit at 8 – aims to slow down the growth of the validator set and is desirable because having too many active validators can lead to state-size bloat, which places additional strain on each node as they strive to keep track of their peers. Implementing EIP-7514 should allow time for research into more comprehensive solutions and for community consensus around them to emerge. Testnet simulations prompted this EIPs inclusion, in which client software struggled to adequately perform past 2 million validators. 

At the time this EIP was decided for mainnet inclusion, there were ~800K active validators. It was, however, the rate of this increase, and not the total number of validators, that was concerning and the impetus for this EIP’s inclusion. The situation appears less dire with the benefit of retrospect; at the time of writing, the validator entry queue has shortened considerably. Still, validator growth is correlated with the overall market, which is wont to change on a whim.

Entry, not Exit

Importantly, this churn limit change will be limited to entry into Ethereum’s active validator set, and will not be applied to exiting validators. This follows the rationale for EIP-7514, as the primary concern is validator bloat.

Changing the churn limit is, to some degree, a change in Ethereum’s monetary policy as it alters the growth of total ETH staked, and therefore the consensus layer rewards issued per block. By limiting the rate that new validators may enter the beacon chain, we’re slowing the rate that new ETH issuance may increase. Of course, this is a secondary effect and not the intended purpose of the EIP.

The below chart shows the proposed change (green) against various projections. Note: before the implementation of EIP-7514 the entry churn limit could theoretically, given consistent validator demand in the queue, grow indefinitely. In the limit, this scenario was widely panned as potentially disastrous, with some projecting the complete breakdown of Ethereum’s ability to finalize.

The Network Health of Ethereum

From the perspective of decentralization and network health, increasing the number of validators on the beacon chain presents a paradox. Ideally, more validators mean greater redundancy, a broader range of proposers, a wider array of attestors, and overall increased resilience. However, the reality is more complex, as a high number of validators can also lead to state-size bloat, placing additional strain on each node as they strive to keep track of their peers. As the client software is currently written, Prysm, Lighthouse, etc., struggle to maintain adequate performance past 2 million validators.

The acceptance of this EIP by both core developers and the community is implicit upon a more agreeable long term solution that allows the amount of staked ETH to increase without ‘growing pains’. 

As an example, under EIP-7251, a draft EIP without a guarantee of inclusion, node operators with multiple validators would have the opportunity to consolidate their stake into fewer validators, potentially alleviating the need for a cap on the churn rate. If not EIP-7251, it’s possible that some other form of validator consolidation will be pursued, although this could take many forms. Alternatively, other more creative solutions may be pursued that do not require any form of validator consolidation.

In any case, the hope is that the need to govern and throttle new validator entrants will eventually be greatly diminished or removed.

The ability to resume a high entrance churn rate will aid in the growth of new staking protocols, a broadly endorsed goal as Ethereum aims to reduce its dependence on large staking pools and further its decentralization. In fact, many Ethereum researchers cited the bias against new staking entrants as a primary negative consideration for EIP-7514. 

Look for some such solution in Electra & Prague–the hard forks following Cancun & Denub- and consider EIP-7514 to be a temporary solution.

EIP-1153: Transient Storage Opcodes

Completely unrelated to the validator churn limit, EIP-1153 introduces a concept called "transient storage" to the EVM. Specific to the execution layer, transient storage will operate similarly to existing storage opcodes in the EVM, but with a key difference: they will be discarded at the end of each transaction, much like how a computer's RAM is cleared when it's no longer needed.

EIP-1153 will introduce two transient storage opcodes: TLOAD and TSTORE. Together they will provide a more gas-efficient solution for inter-frame communication during a transaction by discarding the associated values after every transaction.

A Third Type of Storage

In Ethereum, a transaction may involve multiple "frames" of execution. For example, if a transaction calls a smart contract, which in turn calls another smart contract, each of these calls represents a different frame of execution.

Currently, communication between these frames can only be done through the EVM's storage, which is costly in terms of gas. EIP-1153's introduction of transient storage provides a more gas-efficient solution for this inter-frame communication, as data can be temporarily stored and accessed across different frames within a transaction without the need for costly writes to the EVM's permanent storage.

EIP-1153 will create a third form of storage to go along with the two currently existing forms.

Permanent Storage (also known as Contract Storage): This is "long-term memory" where each contract stores its persistent data. Data written here stays indefinitely, across transactions and blocks, until explicitly overwritten or deleted. It's comparatively expensive in terms of gas costs due to its persistent nature, but necessary for data that must persist as part of the contract's long-term state.

Transient Storage (proposed in EIP-1153): This can be thought of as "medium-term memory.” 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.

Memory: or "short-term memory," is used to store temporary data during the execution of a single function or operation (interframe). The data found in this memory type does not persist from function to function within the same transaction. It is inexpensive to write to but resets and is cleared after each contract function executes - making it highly transient and great for temporary calculations or data manipulation within a single function call.

The below image created by Pascal Marco Caversaccio and posted in the Ethereum Magicians forum further puts this evolving memory and storage landscape into the appropriate context.

We’d be remiss to omit that the equivalent of transient storage is technically feasible within the EVM as is, but only in roundabout, expensive, and patchwork ways via writing and explicitly removing storage across frames. EIP-1153 will standardize this ‘hacked’ process that is, in the best case inefficient, and in the worst case, unknown to Ethereum developers.

Charting the Future of Ethereum—One EIP at a Time 

In summary, we see one EIP in 7514 as a proactive and precautionary measure to prevent untenable consensus layer bloat, and a second in EIP-1153 as a significant improvement to the EVM code base that will benefit dApp developers, and ultimately end users, by way of reducing the gas costs of more complex transactions.

Our next and final post in this series, Part 5, will cover Proto-Danksharding in EIP-4844, a major milestone in scaling Ethereum that will greatly improve the efficiency of all Layer 2s transactions settling on Ethereum by allowing ‘blobs’ to rideshare alongside blocks.

Additionally, check out this course on "Understanding Ethereum Network Upgrades," hosted by the Education DAO. It's free, with donations encouraged to support more course content like this!

To continue to part five, Ethereum Evolved: Dencun Upgrade Part 5, EIP-4844, please click here.