Overview of Ethereum's Pectra upgrade
The latest upgrade Pectra on the Ethereum network is planned for mainnet in the near future. Let's learn about the new proposed improvements and the impact of the Pectra upgrade in the following article.
Pectra upgrade overview
Network upgrade in Ethereum
A Network Upgrade, commonly known as a "hard fork", is an activity performed periodically on Ethereum with the purpose of improving various aspects of the Ethereum Protocol to make the protocol better over time.
Proposed changes and additions of new features to the consensus layer (CL, Consensus Layer) and execution layer (EL, Execution Layer) must be thoroughly described in the EIP (Ethereum Improvement Proposal).
These proposals then have to go through various stages to gain consensus from core developers and the Ethereum community at large before being deployed to the mainnet.
Roadmap for bringing new proposals to Ethereum
Starting from 2015 until now, Ethereum has undergone 20 different upgrades. On average, each year Ethereum does:
· 2 - 3 upgrades.
· 1 - 3 large EIPs, 10 - 15 small EIPs.
What is Pectra Upgrade?
Pectra is the latest mainnet upgrade planned for late 2024 or Q1/2025. Pectra is a combination of two upgrades:
· Electra, the name of the consensus layer upgrade (CL, Consensus Layer).
· Prague, name of the execution layer (EL, Execution Layer) upgrade.
Currently, the community and developers are still discussing and proposing EIPs that will be present in Pectra, initially agreeing on 6 EIPs that will be present in Pectra Devnet 0 with a focus and EIP-7251, expected to be released at the end of the year. May 2024. The six EIPs include: EIP-6110, EIP-7002, EIP-7549, EIP-2537, EIP-3074, and EIP-7251.
Proposed EIPs in the Pectra upgrade
EIP-6110: Supply validator deposits on chain
Currently, Ethereum uses a bridge-based design for CL and EL interaction, which is relatively complex. EIP-6110 is an upgrade that simplifies and improves the validator deposit process on Ethereum.
EIP-6110 mainly affects CL. However, it also involves changes to EL to facilitate the processing of validator deposits.
· Change in CL: Delete deposit contract on CL. Validator deposits are put directly into blocks on EL as a list of deposit operations. Consensus clients will process these deposits directly, eliminating the need for deposit contracts.
· Changes in EL: EL adds deposit transaction format (DEPOSIT_REQUEST_TYPE). This format is for validator deposit transactions, adding the necessary information for CL to process. Additionally, the block structure was also modified to accommodate the list of deposit operations.
Besides, the new design that EIP-6110 introduces will also reduce complexity in Ethereum client design, along with EIP-7002, this is also one of the necessary optimizations to move towards Verkle Tree, improving Ethereum EL's next big level.
EIP-7002: Execution Layer Triggerable Exits
When a user stakes ETH to become a validator, the user has two options: operate the validator themselves (solo staking) or delegate it to a third party. Solo staking requires users to manage their own validators, while working through a third party involves trusting the node operator to maintain validators on the user's behalf.
To reduce the reliability of the above process, the validator is designed to operate with two types of keys: active key and withdrawal credentials. These keys are created and held by two parties involved: Staker and node operator (NO, Node Operator).
The active key is used to sign and perform the validator's tasks, including: verifying transactions, authenticating blocks, synthesizing certificates and proposing blocks (verifying transactions, attesting blocks, aggregating attestations, suggesting blocks). Withdrawal credentials represent ownership of the ETH locked in the validator.
However, the process of withdrawing funds from delegated staked operations still requires trust between the parties involved, as NO needs to be signed for stakers to be able to withdraw their funds.
EIP-7002 EIP introduces a new exit mechanism to give stakers more control over their Validator, allowing them to withdraw using withdrawal credentials instead of relying on NO's active key to trigger withdrawals. This enhances the simplicity, security and decentralization of authorized staking activities.
Similar to EIP-6110, EIP-7002 impacts CL but will still require minor changes to be made on EL.
EIP-7549: Move committee index outside attestation
EIP-7549 will make small changes to CL to make aggregating attestations on CL more efficient and can be implemented in a variety of ways, from low to high complexity. In addition, EIP-7549 is also the premise for the development of PeerDAS (EIP-7594).
EIP-2537: Precompile for BLS12-381 curve operations
EIP-2537 recommends adding a Precompile to the EVM. Precompile enables efficient performance of operations on the BLS12-381 curve, including BLS signature verification operations.
Precompile: a piece of code pre-deployed in EVM to perform complex calculations efficiently.
EIP-3074: AUTH and AUTHCALL opcodes
EIP-3074 is an EL related upgrade. EIP adds 2 new opcodes AUTH and AUTHCALL to EVM.
These two Opcodes allow the EOA (Externally Owned Account) to authorize specific smart contracts to act on their behalf, essentially EIP-3074 allows more complex types of transactions directly from the EOA.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
EIP-7251 is an upgrade related to CL. This EIP changes the amount of ETH required to become a validator from a fixed 32 ETH to an amount ranging from 32 ETH to 2048 ETH.
EIP 7251 Specifications
Significance of EIP-7251 (maxEB)
Decentralization or decentralization is one of the important aspects that Ethereum prioritizes. Decentralization helps increase system redundancy and resilience.
After switching to using PoS consensus, Ethereum continues to maintain the vision of decentralizing the system, the network's validator requires quite low hardware configuration and bandwidth when compared to networks in the same segment. At the same time, validators require a fixed financial collateral of 32 ETH/validator.
The main idea of EIP-7251 is to change the ETH balance setting required to become a validator from a fixed 32 ETH to a more flexible setting of 32 - 2,048 ETH. Ethereum will still maintain the minimum amount of Ethereum required to run a validator i.e. 32 ETH, but increase the upper limit to 2,048 ETH to reduce the number of validators needed to operate for users or entities sending large amounts of ETH.
Impacts of EIP-7251 include:
· Reduce the number of validators: Large NOs (Node Operators) can consolidate their capital and operate fewer validators. This makes management easier and allows for compound rewards.
· Reduce bandwidth usage on Ethereum's P2P layer and lay the foundation for future upgrades such as ePBS (enshrine Proposer-Builder Separation) and SSF (Single-Slot Finality).
summary
Pectra's focus is on stabilizing CL after major upgrades like EIP-4844. At the same time, perform the necessary optimizations on CL and EL to prepare for major upgrades on EL like Verkle Tree.
