PectraPectra Upgrade
LiveMajor upgrade introducing account abstraction, validator experience improvements, and blob scaling.
Account abstraction, validator upgrades, and 2x blob throughput - making Ethereum faster and cheaper.
Pectra Proposals
SWAPN, DUPN and EXCHANGE instructions
This adds three new EVM instructions (DUPN, SWAPN, and EXCHANGE) that allow smart contracts to access and manipulate stack items beyond the current 16-item limit, reaching up to 256 items deep. Currently, the EVM stack can hold 1024 items but only the top 16 are easily accessible. These new instructions help compilers write more efficient code for complex functions with many variables by providing better stack management capabilities. The feature only works with the new EOF bytecode format, not legacy contracts.
EOF - EVM Object Format v1
This introduces EVM Object Format (EOF), a new standardized container for smart contract bytecode that gets validated once when deployed rather than every time it runs. EOF separates code from data, making contracts more structured and analyzable. It enables future EVM improvements like better jump instructions, multibyte opcodes, and function representations. The format is extensible and versioned, allowing gradual introduction of new features. Only new contracts can use EOF - existing contracts remain unchanged. This is the foundation that makes other EOF-related improvements possible.
EOF - Code Validation
This adds strict validation rules for EOF smart contracts when they're deployed. It rejects contracts with invalid bytecode, such as incomplete PUSH instructions or undefined opcodes. It also removes deprecated instructions like CALLCODE and SELFDESTRUCT from EOF contracts. This validation only happens once at deployment time and only affects new EOF contracts - existing legacy contracts remain unchanged. The goal is to make bytecode more predictable and easier to reason about, while ensuring all EVM implementations handle code the same way.
EOF - Static relative jumps
This introduces three new jump instructions (RJUMP, RJUMPI, and RJUMPV) for EOF contracts that use relative addressing instead of absolute addressing. These instructions are more gas-efficient than traditional JUMP/JUMPI instructions, don't require JUMPDEST markers, and make code analysis easier. RJUMP does unconditional jumps, RJUMPI does conditional jumps, and RJUMPV provides jump tables for switch-case scenarios. The relative addressing means code can be moved around without breaking, and the static nature allows for better optimization and validation at deployment time.
EOF - Functions
This introduces proper function support to EOF contracts by allowing multiple code sections, each representing a separate function. It adds two new instructions: CALLF to call functions and RETF to return from them. Functions have defined input/output parameters and their own isolated stack, improving code organization and analysis. Dynamic jumps (JUMP/JUMPI) are completely removed in favor of static function calls, making contracts more predictable and easier to optimize. A return stack tracks function call history, and JUMPDEST becomes a simple NOP instruction since jump analysis is no longer needed.
EOF - Stack Validation
This adds comprehensive stack validation to EOF contracts at deployment time, ensuring that stack underflow and overflow cannot happen during execution. By analyzing all possible code paths and tracking stack heights, it eliminates the need for most runtime stack checks, making execution faster and more predictable. Only CALLF and JUMPF instructions need runtime stack overflow checks. The validation also prevents deployment of unreachable code and ensures proper function termination. This creates guarantees that enable better compiler optimizations and ahead-of-time compilation while maintaining linear validation complexity.
EOF - JUMPF and non-returning functions
This introduces the JUMPF instruction for EOF contracts, enabling tail call optimization by jumping to code sections without adding return stack frames. It also introduces non-returning functions - sections that never return control to their caller. This is particularly efficient for error handling helpers that end with REVERT, allowing compilers to generate more optimal code with reduced gas costs and smaller bytecode size. Functions can jump to other functions with fewer outputs, and non-returning functions don't need to clean up extra stack items before terminating.
EOF - Data section access instructions
This introduces four new instructions for EOF contracts to access their data section: DATALOAD (loads 32-byte word), DATALOADN (optimized version with compile-time offset), DATASIZE (returns data section size), and DATACOPY (copies data to memory). These replace the deprecated CODECOPY instruction for data access in EOF contracts, enabling proper separation between code and data. The instructions follow the same pattern as existing data access instructions like those for calldata and returndata, with zero-padding for out-of-bounds access and validation to ensure safe operation.
Inclusion lists
Introduces inclusion lists so proposers can require that specific transactions be included promptly, improving censorship resistance.
Precompile for secp256r1 Curve Support
This adds support for a widely-used cryptographic curve called secp256r1 (also known as P-256) to Ethereum. Currently, Ethereum only supports the secp256k1 curve for signatures, but many devices and systems use secp256r1. This change allows Ethereum to verify signatures from devices like iPhones, Android phones, hardware wallets, and other systems that use this standard curve, making it easier to integrate with existing infrastructure. Note: This EIP supercedes [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md).
Precompile for BLS12-381 curve operations
A new precompile for the BLS12-381 curve, a native function built in clients that smart contracts can use to verify signatures and perform certain operation more cheaply and securely.
Serve historical block hashes from state
Store and serve last 8191 block hashes as storage slots of a system contract to allow for stateless execution
Supply validator deposits on chain
New way how validator deposits are processed between CL and EL, more simple and native to merged Ethereum enabling better UX and features.
Execution layer triggerable withdrawals
A new system contract that lets the withdrawal credential owner trigger a validator exit onchain without the need for BLS validator key on CL.
Increase the MAX_EFFECTIVE_BALANCE
Introduces new validator maximum effective balance of 2048 ETH, instead of exactly 32 ETH, allowing compounding into larger individual validators that reward on each extra ETH above 32.
Move committee index outside Attestation
Simplifies the structure of validator attestations by moving the committee index field outside the signed message, making verification and aggregation cheaper.
Increase calldata cost
Calldata gas costs is increased to limit state growth and incentivize more efficient blobs to store data.
eth/69 - history expiry and simpler receipts
A change to EL networking that changes how receipts are handled and removes old data from node synchronization, saving approximately 530GB of bandwidth during sync.
General purpose execution layer requests
Creates a standard way to communicate messages from EL contracts to CL, providing space to various request types in the future.
Blob throughput increase
Doubles the target number of blobs per block (and raises the max) to increase L2 data capacity until future upgrades enable even more blobs.
Set Code for EOAs
Enables an address to delegate its control to an existing smart contract, creating an account abstracted wallet with new programmable features.
Add blob schedule to EL config files
Adds a new blob related parameters to client config so targets, maximums, and fee adjustments can be easily configured.