Ethereum: Pectra's most important EIPs

Foreword: This article is partly based on our 2024 year-end report on the cryptocurrency market. We encourage you to read it for free or get a physical copy to support our work.

---

What is the Pectra Upgrade on Ethereum?

The Pectra upgrade is the next major milestone in the evolution of the Ethereum network. Scheduled for the first quarter of 2025, it is set to be the most significant and ambitious update in Ethereum’s history to date, surpassing even The Merge.

To delve a bit deeper, Pectra is divided into two main components. These were initially planned as separate updates but were eventually merged into a single package by the developers:

• Prague, addressing changes to the execution layer.
• Electra, introducing updates to the consensus layer.

After being tested by developers on several devnets over the past few months, Pectra was successfully deployed on a public testnet (Mekong) in November 2024. This allows validators to familiarize themselves with the upcoming changes and wallet developers to prepare for the mainnet launch.

The Pectra upgrade impacts all aspects of Ethereum, from the consensus layer to the execution layer. It brings improvements for users through various new features, for developers with extensive planned technological advancements, and, consequently, for validators and stakers.

As of the time of writing, Pectra consists of a set of eight major Ethereum Improvement Proposals (EIPs) and a few minor ones. In this article, we will explore these proposals to better understand their implications for the future of the ecosystem.

---

EIP-2537

Before diving into EIP-2537, let’s revisit a few basic principles. Cryptography lies at the heart of blockchain technology. This branch of mathematics is used to secure information through coded algorithms, hashing, and signatures. Complex functions, particularly elliptic curves, are employed to achieve strong data encryption while reducing key sizes and computational complexity—both of which are critical for network performance.

There are many types of elliptic curves, but BLS12-381 has become something of a superstar in this field. The issue is that it was designed in 2017 and is not natively integrated into Ethereum. Some developers manually include it in their smart contracts due to its advantages, but this approach incurs high gas costs for execution.

Thus, EIP-2537 proposes adding a “precompile” to Ethereum to natively support the BLS12-381 elliptic curves. Its main benefit lies in improving BLS signatures (Boneh-Lynn-Shacham), the cryptographic signature system used to verify the authenticity of a signer, which is particularly critical for staking. Currently, BLS signatures rely on the BN254 curve, which is much less efficient.

While BN254 curves have been useful for Ethereum so far, they provide a lower security level (80 bits) compared to BLS12-381, which offers 120-bit security. In general, this implementation will primarily interest protocol and application developers, enabling them to perform various operations, including:

• Standard arithmetic operations on analytical point curves, such as additive and multiplicative functions. These applications, which do not require pairing, are relatively simpler and more general while remaining suitable for common protocols and DApps.
• Pairing operations that utilize curves with specific properties. These are essential for protocols leveraging complex signature schemes or Zero-Knowledge Proofs (ZKPs).
• Mapping operations on curves, allowing messages or their hashes in the standard 32-byte format to be mapped to points on an elliptic curve.

In summary, here are the potential beneficiaries of the operations listed above:

• zkSNARK users, in contexts such as Validity Rollups or privacy solutions. Adding BLS precompile (via EIP-2537) enables the generation of more computationally secure proofs.
• BLS signature users, in cases like Optimistic Rollups, Plasma Rollups, DAOs, or inter-chain communication protocols. These actors can leverage this EIP for efficient batch aggregation and signature verification.

---

EIP-2935

EIP-2935 is a proposal to include the hashes of the last 8,192 blocks in the storage of a system contract on Ethereum. This update aims to address a critical challenge for Ethereum's future: the transition to stateless clients.

Currently, the EVM (Ethereum Virtual Machine) assumes that the hashes of recent blocks are always accessible to clients during execution cycles. While this assumption holds true for now, it will no longer be valid with the introduction of stateless clients, which, by definition, lack access to historical state data.

With EIP-2935, block hashes would be directly included in the state storage, enabling their aggregation into compressed witnesses. These witnesses would be transmitted to stateless clients at each epoch, facilitating block verification and access to historical data.

This EIP is particularly useful for node operators, as it introduces significant changes to block validation logic. Let’s explore its key benefits:

• Improved synchronization for light clients: By integrating block hashes into the state, light clients can more easily access essential data without requiring full synchronization with the network's history.
• Transition to the stateless model: This proposal lays the groundwork for implementing Verkle Tries, a critical step toward achieving a fully stateless Ethereum network.
• Extension of the BLOCKHASH opcode: Currently, the BLOCKHASH opcode retrieves hashes for the last 256 blocks. EIP-2935 extends this capability to 8,192 blocks, providing a much wider range for validating historical blocks.
• Retention of hashes in state: Hashes will be recorded through a dedicated SSTORE instruction, updating the storage with each new block and ensuring reliable and structured access to historical data.

During technical discussions, client teams such as Reth and Erigon have expressed measured support for this proposal. While relatively simple to implement, it requires adjustments to block validation logic. The inclusion of EIP-2935 in the Prague update (one of Pectra's stages) will also depend on the complexity of the other planned EIPs.

---

EIP-6110

EIP-6110 proposes a significant change in the management of validator deposits on Ethereum. By shifting this function from the consensus layer to the execution layer, this proposal aims to simplify the protocol while improving its security and efficiency.

Validators play a fundamental role in the Ethereum ecosystem. They are responsible for validating transactions, maintaining the network state, and ensuring the chain's reliability by participating in block and P2P message propagation. One lesser-known but essential function is their role in verifying deposit transactions for new validators, allowing these validators to join the network.

However, this process is not without challenges. Two major limitations hinder Ethereum's continued decentralization:

• Complexity of P2P messaging: As the number of validators increases, P2P traffic grows, complicating communication and creating bottlenecks.
• State and history growth: Deposit verification contributes to increased block space usage, raising the hardware and software requirements to operate a validator node.

EIP-6110 introduces a protocol-integrated mechanism to handle validator deposits, removing the need for the P2P polling process. By integrating this functionality directly into the execution layer, the proposal significantly simplifies network operations. Key benefits include:

• Reduced processing delays: Currently, a deposit transaction can take up to 12 hours to be validated due to geographical latencies and distributed consensus. With EIP-6110, a transaction becomes usable as soon as it is finalized, which occurs at the end of an epoch.
• Lower P2P traffic: By eliminating the requirement for validators to distribute deposit snapshots, this proposal reduces network traffic and lowers the minimum hardware specifications needed to operate a node.
• Improved security: The integrated mechanism eliminates risks associated with a malicious majority validating incorrect deposits. The guarantee is encoded directly into the protocol, strengthening the network’s resilience.

This update greatly simplifies the validator experience by reducing technical and operational demands. By optimizing deposit management, EIP-6110 represents a significant advancement for the network. It aligns with the vision of a more robust Ethereum, capable of meeting the growing needs of its ecosystem while maintaining a high level of decentralization and efficiency.

---

EIP-7002

EIP-7002 proposes a mechanism allowing Ethereum validators to trigger full exits or partial withdrawals of their balances or rewards using their withdrawal credentials linked to the execution layer. This change aims to address current system limitations by offering more flexibility and control to validators.

In Ethereum, each validator is required to have two distinct keys:

• Active key: A BLS-type key (refer back to the earlier section if you need a refresher), used to sign messages and perform the validator's primary tasks.
• Passive key: A key that can be either BLS or ECDSA, also known as "withdrawal credentials." Its main function is to manage ownership and withdrawals of the validator’s staked ETH.

The protocol assigns rewards to the passive key, but under the current model, only the active key can initiate withdrawals or exits. This design assumes that the validator is always managed by a single entity, an assumption increasingly at odds with reality.

With the rise of liquid staking protocols, restaking, and services operating nodes, the relationship between active and passive keys has grown more complex. In these setups, the active key is often managed by a smart contract or a third party, leaving the owner of the passive key unable to withdraw rewards or manage balances independently.

This imbalance creates what is known as a principal-agent problem, where the holder of the withdrawal credentials (the principal) depends on a third-party operator (the agent) to perform critical actions.

EIP-7002 addresses this by introducing a mechanism that allows withdrawal credentials (passive key) to autonomously and securely modify staked ETH balances through exit messages. These messages are added to blocks on the execution layer, ensuring a smooth and direct interaction between the validator and their funds.

---

EIP-7251

EIP-7251 proposes increasing the maximum effective balance (maxEB) for Ethereum validators from 32 ETH to 2,048 ETH, while maintaining the minimum activation threshold at 32 ETH. This modification aims to reduce network complexity by allowing node operators to consolidate multiple validators into a single entity, often referred to as a super-validator. This update could represent a strategic step forward for the network's scalability and efficiency.

With over 830,000 active validators (as of October 3, 2023), Ethereum is one of the most decentralized Proof of Stake (PoS) networks in the world. However, this level of decentralization comes at a cost. Such a large number of validators generates increased complexity in P2P communications and additional latency, which can limit the network's overall performance.

The current maximum effective balance of 32 ETH is a legacy of the initial sharding design, which required equal distribution among validators to ensure security. However, with the transition to models like proto-danksharding, this constraint is no longer relevant. Now, only contributions from an honest minority are necessary, allowing for a rethinking of how validators are organized.

The main idea behind EIP-7251 is to strike a balance between efficiency and decentralization while maintaining an infrastructure suited to the needs of an increasingly complex network. By increasing the maximum effective balance to 2,048 ETH, the proposal allows node operators with significant funds to consolidate their validators into a single entity. This reduces the total number of validators required, which in turn lowers P2P communication overhead and historical storage requirements.

This change is designed not to impact perceived decentralization at the entity level. Small stakers can still participate in the network with the minimum balance of 32 ETH, while large operators gain the opportunity to streamline their operational management.

Although EIP-7251 is presented as a minor change, some voices in the community have raised concerns about the potential for increased concentration of validation power. The fear is that large operators, such as Lido or Coinbase, could use this update to expand their influence.

However, analyses suggest that this change will not significantly affect the likelihood of block proposer selection. The protocol remains structured to maintain a high level of decentralization, measured in terms of independent entities rather than individual nodes.

---

EIP-7549

EIP-7549 aims to optimize the efficiency of Ethereum clients by simplifying the process of verifying consensus rules, specifically by reducing the number of pairings required to validate attestations from Casper-FFG clients.

In the Ethereum protocol, after a block is proposed by the slot leader, other validators, called "attesters," must issue votes every six minutes. These votes reflect their view of the chain according to the LMD-GHOST (branch choice rule) and Casper-FFG (finality rule) protocols and are encapsulated in a data structure called an "attestation." This attestation includes the slot for which the votes are issued and a committee index to which an attester is assigned.

The inclusion of the index makes each attestation unique, which was essential in the initial sharding designs. However, with the evolution toward proto-danksharding, this specificity is no longer necessary, as all attesters now belong to the same set, eliminating the need for distinct committees.

EIP-7549 proposes moving the index out of the attestation message. This change allows the minimum number of attestations required to reach a two-thirds threshold to be reduced from 1,366 to just 22—a 62-fold reduction. Here are the expected benefits:

• Vote aggregation: By moving the index out of the attestation, it becomes possible to aggregate votes more efficiently, improving the performance of light clients and reducing the complexity of P2P communications.
• On-chain efficiency: This modification allows up to 8 slots of votes to be included in a single block, compared to 2 currently, thereby increasing the protocol's resilience to liveness and finality failures.

By simplifying the structure of attestations and optimizing their aggregation, EIP-7549 enhances the efficiency of the Ethereum network while improving its resilience and capacity to handle an increasing volume of transactions.

---

EIP-7685

EIP-7685 proposes a general framework to store requests triggered by contracts from the execution layer and share them with the consensus layer for processing. This functionality aims to improve interoperability between the two layers and provide better coordination for entities whose responsibilities span both, such as block producers.

To implement this proposal, EIP-7685 extends the execution layer header by adding a dedicated field. This field is designed to store information related to requests generated by smart contracts before being transmitted to the consensus layer for validation and processing.

Over time, validators have increasingly relied on smart contracts to delegate certain functions. This practice helps mitigate failures caused by human error while maintaining a level of administrative oversight. These contracts are often managed by specialized third parties, introducing an additional layer of complexity.

However, this setup can lead to delegation issues, including conflicts of interest between the involved parties (e.g., the "principal-agent" problem discussed earlier in this article). EIP-7685 addresses these issues by allowing validators to delegate functions to smart contracts while ensuring smooth and reliable interaction between the execution and consensus layers.

EIP-7685 aligns with Ethereum’s vision of becoming more modular and resilient. By enabling better coordination between the execution and consensus layers, this proposal not only simplifies the work of validators but also paves the way for more sophisticated architectures where smart contracts play a central role in operational management. In short, it represents a key technical advancement for the Ethereum ecosystem.

---

EIP-7702

EIP-7702 introduces an innovative mechanism enabling Externally Owned Accounts (EOAs) to more fully leverage Ethereum’s capabilities. The idea is to allow EOAs to sign a “wrapper” transaction that establishes a predefined permanent link with a smart contract. This smart contract can then take control of certain functions, such as managing permissions.

Reminder: EOAs are a type of account on Ethereum controlled by users rather than by code, as is the case for smart contract accounts. EOAs can initiate transactions, send and receive ETH or Ethereum-based tokens, and interact with smart contracts. These accounts are typically held by regular Ethereum users and interact with the blockchain via wallets.

One of the key advantages of EIP-7702 is its significant improvement to the user experience. For instance, with support for transaction batching, users can now group multiple transactions into a single one. This reduces the number of signatures required, such as in ERC-20 token exchanges, which traditionally required separate approval and swap transactions. Now, a single signature is sufficient to execute these actions atomically.

Another key feature is gas sponsorship. Currently, EOAs must pay gas fees in native tokens for every transaction, which can complicate the use of decentralized applications (dApps) for users who don’t hold these tokens. EIP-7702 allows another account to cover these fees, making it possible for dApps themselves to sponsor user transactions, particularly helpful for beginners.

By consolidating these improvements, EIP-7702 represents a crucial step toward better integration of EOAs into the Ethereum ecosystem. By expanding their capabilities while preserving their ease of use, this proposal enhances the network’s accessibility and adoption, making it more appealing to both users and developers.

---

Other Important ERCs

Beyond Pectra, 2024 was marked by the adoption of ERC-4337 for smart contracts on Ethereum. Now deployed on Layer 2 solutions such as Base and Polygon, as well as on the mainnet, this development introduced the highly anticipated account abstraction without requiring changes to Ethereum's core protocol mechanisms.

Let’s briefly revisit the concept of account abstraction. The idea is to simplify the user experience by replacing wallets with smart contracts. Initially introduced in 2021 as EIP-4337, this proposal is now referred to as ERC-4337, having become the new standard for account abstraction on Ethereum, enabling the creation of smart contract accounts. This unlocks advanced features for users:

• Increased programmability: EOAs can now delegate certain tasks to smart contracts, enabling them to function as smart accounts.
• Simplified interactions: Users can batch multiple transactions into one, eliminating the need to sign each step (e.g., approval followed by a swap for ERC-20 tokens).
• Gas fee sponsorship: Decentralized applications (dApps) can cover transaction fees for their users, simplifying the experience for newcomers.

The introduction of ERC-4337 has significantly improved the user experience on Ethereum. Wallets compatible with this standard now enable features such as social recovery, allowing users to regain access to their wallets through a dedicated smart contract. This reduces the risks associated with losing private keys, a major barrier to mainstream adoption. Notably, this feature has been natively implemented for several years in the Argent wallet, widely used on Starknet.

Additionally, by enabling more complex interactions with reduced costs and friction, ERC-4337 opens the door to new or enhanced use cases, including:

• Decentralized Finance (DeFi): Automation of complex strategies for users.
• Blockchain gaming: Integrated payments without requiring players to manage native tokens directly.
• Commerce and NFTs: A streamlined experience for end users, where gas fees can be absorbed by marketplaces.

Despite its benefits, ERC-4337 is not without limitations. Its off-protocol nature introduces added complexity, particularly regarding mempool fragmentation. Each transaction must be verified by separate infrastructures, which can slow processing times and increase congestion risks.

To address these challenges, the Ethereum community is considering a solution through the RIP-7560 standard, which would integrate ERC-4337’s functionalities directly into the protocol. This would enable faster and smoother execution of userOperations while eliminating current bottlenecks.

ERC-4337 represents a pivotal step toward Ethereum's ultimate goal: making account abstraction accessible to everyone, in what some call the ecosystem’s "endgame." By facilitating more intuitive interactions, reducing user friction, and enhancing programmability, this standard is preparing Ethereum for broader adoption.

However, to maximize its potential, integrating ERC-4337’s functionalities directly into Ethereum via RIP-7560 remains a priority. This would ensure that this technological advancement is both sustainable and scalable, reinforcing Ethereum's position as a leader in blockchain innovation.