// Blog
What Is the Ethereum Pectra Upgrade?
Rob Behnke
May 21st, 2024
Ethereum hard forks continue. Following the Dencun upgrade, the ETH community is already gearing up for the next one, which supposedly reimagines wallet UX.
What if your regular cryptocurrency wallet can do much more than just send and receive transactions — like automating payments, setting spending limits, and even having innovative ways to recover your account if you lose your keys?
Unlike previous large-scale overhauls like "The Merge," Pectra focuses on targeted user-centric improvements.
This upgrade underscores Ethereum's commitment to continuous progress. By prioritizing practical user benefits, streamlining staking procedures, and setting the stage for long-term growth, Pectra positions Ethereum to remain a driving force in the ever-evolving world of decentralized technology.
What Is the Pectra Upgrade?
Pectra derives its name from the combination of two simultaneous upgrades occurring across different layers of Ethereum:
Prague: Updates to the execution layer, responsible for enforcing protocol rules.
Electra: Enhancements to the consensus layer, ensuring block validation.
Scheduled to go live in late 2024 or early 2025, the Pectra upgrade would enhance UX by introducing new opcodes (a machine code instruction), improve staking efficiency, speed up cryptographic operations, and more.
While not finalized yet, the community has proposed 26+ Ethereum Improvement Proposals (EIPs) to be implemented in the Pectra hard fork:
EIPs | Title | Description |
Precompile for BLS12-381 curve operations | Integrates BLS12-381 curve operations into Ethereum, enhancing multi-party computation (MPC) by simplifying multi-sig functionalities. Unlike ECDSA and EdDSA, BLS supports direct threshold signing and key generation, reducing complexity and security risks in wallets using Account Abstraction (EIPs 4337 & 3074). This transition marks a significant step towards a more robust and efficient MPC. | |
Precompile for BN256 HashToCurve Algorithms | Introduces a new precompiled contract. This contract implements two cryptographic operations:
| |
AUTH and AUTHCALL opcodes | Enhance the capabilities of Externally Owned Accounts (EOAs) on Ethereum by allowing them to delegate transaction authorization to smart contracts. It introduces AUTH and AUTHCALL opcodes to delegate authorization to smart contracts. This EIP is a significant step towards achieving account abstraction, which would make EOAs and contract accounts functionally equivalent. | |
EOF - EVM Object Format v1 | Introduces the EVM Object Format (EOF), a new container format for Ethereum smart contracts. It's designed to be extensible and versioned, allowing for easier upgrades and improvements to the EVM in the future. Separating code and data makes it easier to analyze and validate smart contracts, and also enables future changes to the EVM without breaking existing contracts. It doesn't introduce any immediate changes to the way existing contracts function, but it enables future upgrades. | |
EOF - Code Validation | Introduces code validation at the time of contract creation for smart contracts formatted according to the EVM Object Format (EOF) defined in EIP-3540. This means that when a new contract is deployed, its code is checked for validity before it is added to the blockchain. | |
Static relative jumps | Is an EOF-related proposal that introduces new jump instructions that use relative addressing. This means the jump destination (location or address in the code) is calculated relative to the current instruction's position, rather than using absolute addresses. The new opcodes introduced by EIP-4200 are:
| |
Bound Historical Data in Execution Clients | Alleviates the issue of rapid data size growth of Ethereum issue by reducing the storage requirements for nodes. Proposes a change to the way Ethereum clients handle historical blockchain data. It suggests that clients should not be required to store or serve block headers, block bodies, and receipts older than one year. Older data could be pruned, meaning it would be removed from the node's local storage. | |
Statelessness gas cost changes | Adjusts gas costs in Ethereum to better align with the Verkle tree design, a new data structure planned to replace the current Merkle Patricia Trie for storing state data. It restructures the gas costs for reading storage and code to reflect the gas costs incurred under the Verkle tree model. This includes setting specific costs for accessing chunks (WITNESS_CHUNK_COST) and branches (WITNESS_BRANCH_COST) within the Verkle tree. | |
EOF - Stack Validation | In this proposal, the EVM is enhanced to validate the size of the operand stack at every point during the execution of an EOF contract. This ensures that the stack neither exceeds its maximum size nor becomes empty when data should be present. This upgrade would prevent stack-related errors and greatly reduce the attack surface for malicious actors who might try to exploit such vulnerabilities. | |
PAY opcode | This EIP introduces the PAY opcode, a dedicated instruction for sending Ether (ETH) within smart contracts. It simplifies the process of transferring ETH between contracts and externally owned accounts (EOAs) by consolidating multiple operations into a single opcode. The PAY opcode includes built-in security checks to prevent common vulnerabilities like reentrancy attacks, where a malicious contract could repeatedly withdraw funds. | |
EOF - JUMPF and non-returning functions | Introduces new instructions (JUMPF and RJUMPF) to the Ethereum Virtual Machine (EVM) for contract code that adheres to the EVM Object Format (EOF). The key aspect of this proposal is the optimization of function calls, especially for functions that don't return values to their caller.
| |
SSZ Transactions Root | Transitions the representation of the transactions root from the existing Merkle Patricia Trie (MPT) format to the Simple Serialize (SSZ) format. This change is motivated by the desire to align the encoding of the transactions_root with the more modern SSZ format, which is already used for other components of the Ethereum protocol. | |
SSZ Withdrawals Root | It aims to align the encoding of withdrawal roots with other components of the beacon chain and execution payload, which already use SSZ. The proposal includes a transition plan to ensure backward compatibility with existing MPT-based withdrawal roots. It suggests transitioning from the Merkle Patricia Trie (MPT) format to the Simple Serialize (SSZ) format for withdrawal roots. | |
SSZ Receipts Root | This EIP combines the transaction root and withdrawal root into a single root to streamline state management and optimize data availability sampling (DAS). DAS is a key component of the stateless Ethereum vision, where nodes don't need to store the entire blockchain history. By combining roots, EIP-6466 reduces the complexity of DAS and improves network efficiency. | |
Ethereum state using a unified verkle tree | Proposes a fundamental change in how Ethereum stores its state data. It suggests transitioning from the existing hexary Patricia tree structure to a new Verkle tree structure. The single-layer design of Verkle trees presents challenges in handling entire storage trees as single objects. Due to this, EIP-6800 proposes removing most of the functionality of the SELFDESTRUCT opcode, which allows contracts to self-destruct. | |
Preimage retention | It deals with preimage retention during a critical period called the "verge," which marks the boundary between the two consensus mechanisms (PoW and PoS). The proposal mandates that execution clients (the software responsible for processing transactions and maintaining the state of the Ethereum network) must retain certain preimages (original data) related to addresses and storage slots accessed during the verge. | |
SETCODE instruction | Modifies the Beacon Chain to handle withdrawals as "operations" rather than individual objects. This change improves the efficiency and security of the withdrawal process, making it easier for validators to process large numbers of withdrawals simultaneously. Withdrawals are now treated as a new operation type on the Beacon Chain, similar to block proposals or attestations. | |
Reuse Withdrawn Validator Indices | Optimizes the Ethereum Beacon Chain by allowing the reuse of validator indices that have been fully withdrawn from the network. By reusing indices, the proposal helps to keep the size of the validator list in check, reducing the storage burden on nodes. Reusing indices can lead to more efficient processing of validator data and contribute to Ethereum’s long-term sustainability. | |
Execution layer triggerable withdrawals | It modifies how validator exits are handled in the Ethereum proof-of-stake (PoS) system. Presently, validators who wish to exit the system and withdraw their staked Ether (ETH) must wait for a long period in an exit queue. EIP-7002 addresses this by allowing validators to initiate an exit directly from the execution layer (EL), the layer where smart contracts and transactions are processed. | |
Precompile for secp256r1 Curve Support | This EIP introduces a precompiled contract for efficient verification of signatures using the secp256r1 elliptic curve. This curve is commonly used in security hardware and online services. This change is expected to lower gas costs for signature verification and improve compatibility with existing infrastructure. | |
Migration Transaction | It enables EOAs to deploy code to their address just once. This transforms the EOA into a smart contract account, inheriting its balance, nonce, and storage. By transitioning to a smart contract account, users can benefit from the enhanced security features offered by smart contracts, such as multi-signature wallets and account recovery mechanisms. | |
Verkle proof verification precompile | Adds a precompiled contract to the Ethereum Virtual Machine (EVM) to facilitate Verkle proof verification in a stateless Ethereum context. This aims to streamline the process of verifying state proofs, enhancing the efficiency and security of stateless Ethereum. | |
Inclusion lists | This EIP works to enhance censorship resistance by introducing an inclusion list mechanism. The core idea is to allow block proposers to specify a list of transactions that must be included in subsequent blocks for them to be considered valid. When a validator proposes a block, they can optionally include an inclusion list containing transactions they want to prioritize. This list is summarized and included in the block header, along with a cryptographic commitment to the full list. Other validators who build upon this block are required to include the transactions from the inclusion list. If they fail to do so, their block will be considered invalid. | |
Separated Payer Transaction (SPT) | It allows the separation of the transaction payer (who pays the gas fees) and the sender (who initiates the transaction and signs it). This separation can improve security by enabling more complex access control mechanisms, such as multi-signature wallets or account abstraction, where a user's account can be managed by a smart contract. | |
Peer Data Availability Sampling | EOF6 introduces dynamic relative jumps, which are computed during runtime. These jumps can provide more flexibility than static jumps, potentially enabling the creation of more complex and sophisticated smart contracts. | |
Supply validator deposits on chain | Currently, when a user wants to become a validator, they deposit 32 ETH into a deposit contract on the EL. This deposit is then picked up by the CL after several hours, during which it's vulnerable to potential exploits. EIP-6110 proposes to streamline this process by allowing deposits to be processed directly on the CL by introducing an in-protocol mechanism, enhancing security and user experience. | |
Increase the MAX_EFFECTIVE_BALANCE | A proposal to increase the maximum effective balance (MaxEB) for validators in Ethereum's proof-of-stake (PoS) system. Currently, the MaxEB is set at 32 ETH, meaning that each validator can only have a maximum of 32 ETH actively participating in the consensus process, regardless of how much ETH they have staked. EIP-7251 proposes raising the MaxEB to 2,048 ETH. This means validators could have a much larger portion of their staked ETH actively earning rewards and participating in block proposal. |
Of these EIPs, EIP-3074 is deemed to be the most significant. Read more about EIP-3074 here.
Conclusion
At its core, the Pectra upgrade represents a commitment to practical, user-focused improvements within the Ethereum ecosystem.
While the community is still on the fence about the pros and cons of EIPs that would be implemented in this upgrade (specifically EIP-3074), the outlook seems to be positive as the community is working actively to address any persisting issues.
Largely, EIP-3074 would complement Ethereum’s goal of full account abstraction. How the community addresses the increased attack surface with the implementation of EIP-3074 is yet to be seen.