Ethereum Pectra upgrade may be divided into two forks

Author: Samuel Haig Source: The Defiant Translation: Shan Ouba, Golden Finance

With Ethereum's upcoming Pectra upgrade becoming the largest upgrade in the network's history, developers are considering splitting its deployment into two hard forks.

After the latest all-core developer execution meeting on June 6, Christine Kim, a researcher at Galaxy Digital, tweeted that developers are exploring executing this upgrade through two hard forks.

Kim pointed out that nine Ethereum Improvement Proposals (EIPs) have been confirmed for inclusion in Pectra, and another five upgrades are under consideration. She added that these upgrades are being implemented in batches in the development network, allowing Pectra's scope to continue to expand before deployment.

"This is too much for one upgrade, so the possibility of Pectra being split is still high," Kim said. “The phased implementation of multiple EIPs on the development network is a new development in the Ethereum governance process, allowing for a changing scope of upgrades.”

Pectra’s upcoming Devnet 1 will include the same eight EIPs tested on Devnet 0.

Disruptive Changes

According to Ethereum Chief Scientist Vitalik Buterin, Pectra is one of the last upgrades expected to introduce disruptive changes.

“Once scaling is complete, we will be at a stage where the hardest and fastest phase of the Ethereum protocol transition is essentially over,” Buterin said during an Ethereum Foundation livestream in April 2023. “Various things need to be done, but those things can be done safely at a slower pace.”

To date, five execution layer upgrades and four consensus layer upgrades have been “finalized” for inclusion in Pectra, covering a wide variety of EIPs from 2020.

Verkle trees and statelessness

EIP-2935 is a key component of Pectra, which aims to introduce Verkle trees and statelessness. Verkle trees will eliminate the need for nodes to store the network state locally, significantly reducing the computational requirements of validators.

According to Kim, developers are also working on three related "parallel upgrades" that may be bundled into Pectra.

These include the development of validator light clients, which do not download the entire Ethereum blockchain. Light clients are intended to increase Ethereum's decentralization by allowing users to verify the network using "resource-constrained devices, such as tablets and mobile phones."

Since nodes no longer need to store Ethereum's entire block history, EIP-4444 will also formalize the removal of historical data from full nodes after a set period of time to further reduce the computational requirements of validators, thereby improving node decentralization.

“With EIP-4444: History Expiration, you don’t have to store much of the history locally,” Buterin said. “The amount of data you need to be a node will go from multiple terabytes to … what you can run a node in RAM.”

DApps and other nodes that need access to deleted block history can query third-party data services after EIP-4444 is deployed.

Sponsored Business Content

Developers are also exploring PeerDAS, which will further provide data availability at Layer 2 following the introduction of proto-danksharding in March.

Consensus Layer Upgrades

Many of the upgrades planned for inclusion in Pectra are designed to improve the functionality and efficiency of Ethereum staking.

EIP-6110 aims to reduce the latency between when a staker deposits collateral at the Ethereum mainnet execution layer and when the corresponding transaction is processed on the beacon chain. It will also reduce the complexity of validator client software.

EIP-7251 aims to slow the growth of Ethereum's validator set and reduce its size to enhance the security of the network. EIP-7002 will expand the number of designs provided for developers to create staking pools.

EIP-7549 aims to improve the efficiency of certification, thereby reducing network load and node bandwidth requirements.

Execution Layer Upgrades

At the execution layer, EIP-2537 and EIP-7865 will enhance the interoperability between the Ethereum mainnet and its beacon chain consensus layer. This will expand the functionality of decentralized staking pools, DAOs, and DApps that communicate with the beacon chain for staking functions.

A group of ten EIPs related to the EVM Object Format (EOF) aims to renovate the Ethereum Virtual Machine (EVM, Ethereum's core smart contract engine). EOF will improve the upgradability of EVM contracts and the efficiency of smart contract code execution.

EIP-7702 is a controversial upgrade that will enable “smart account” functionality for regular externally owned account (EOA) wallets. The upgrade will enable batched transaction execution, transaction fee sponsorship, and delegated wallet security, but critics warn that the upgrade could leave users vulnerable to new attack vectors.

“It is important to note that developers are implementing the Pectra EIP in phases, which means that if EOF, EIP-7702, or PeerDAS fail to make it to the development network in the coming months, developers may remove them from the upgrade entirely or split Pectra into two hard forks,” Kim said.

Unconfirmed Upgrades

Kim noted that developers have not yet confirmed the inclusion of two other consensus layer upgrades in Pectra.

EIP-7688 will make it easier for staking pools to verify whether participating validators have been slashed.

Developers may also consider reducing the rate of new ether issuance. Ethereum Foundation researcher Mike Neuder recently advocated for this move, arguing that the Ethereum network and ecosystem have undergone "seismic changes" since the Ethereum staking reward mechanism was determined in 2020 on the eve of the beacon chain deployment.

However, the proposal quickly became controversial, with many community members expressing opposition to Neuder's suggestion. Some observers worry that this could open the door for Ethereum Foundation researchers to frequently intervene in the network's token economics without the participation of the broader community.