Ethereum’s Pectra Upgrade: Security Implications and Insights

Ethereum’s long-awaited upgrade, named Pectra, has finally been precisely scheduled to go live. Pectra will activate on May 7, 2025, at epoch 364032, approximately 10:05:11 UTC. It has been over a year (March 2024) since a significant upgrade for scalability with the name Dencun was delivered. Its most famous change for improving L2 scalability is Proto-Danksharding using Blobs (EIP-4844).

 

What are the goals of the Pectra hardfork?

And what is the view from a security perspective?

What are the details of the improvements that it will bring?

Let’s find out.

Evolution of Pectra

Since the Merge in 2022, Ethereum’s upgrades to the consensus layer (CL, ensures consensus using PoS) and execution layer (EL, holds state and process transactions) are being delivered simultaneously. That is also reflected in the upgrade naming. Pectra is a combination of words:

• Prague – the name of the EL upgrade (named after Devcon cities);
• Electra – the name of the CL upgrade (named after celestial stars).

In the greatest version of Pectra, 24 Ethereum Improvement Proposals (EIPs) were proposed to be included, but the scope was more than halved to 11 EIPs. The remaining EIPs, including two resonating proposals, PeerDAS (Peer Data Availability Sampling) and EOF (new EVM Object Format), are postponed at least to the next upgrade called Fusaka or even later, but that is yet to be re-evaluated.

What remained in Pectra, and what will the upgrade bring?

Summary of Pectra 

The Ethereum Pectra upgrade makes the network faster, more efficient, and easier to use with improvements for wallets, validators, and smart contracts.

With the reduced scope, the Pectra upgrade can be summarized in the following five bullet points:

• Establish a cross-layer system (EIP-7685) to communicate requests from smart contracts to the CL client, such as staking (EIP-6110) and deposits (EIP-7002).
• Staking with more flexible increments and compounded rewards (EIP-7251) with more secure on-chain deposits (EIP-6110) and withdrawals (EIP-7002).
• Enable smart accounts for EOAs (EIP-7702) that are compatible with ERC-4337.
• Increase Ethereum’s scalability by reducing validators’ count (EIP-7251), improving signature aggregation and checking (EIP-7549), and prioritizing blobs by increasing their targets values (EIP-7691) and increasing calldata cost (EIP-7623). 
• Add new precompiles for more secure on-chain BLS signature verification (EIP-2537) and for retrieving recent block hashes to reduce CL state (EIP-2935).

Security perspective on Pectra EIPs

This section will examine improvements affecting the EL layer with SC auditing expertise.

EIP-2935 Precompile for historical block hashes

While this improvement adds a new system contract to the SC layer that anyone can utilize, its primary use case will become viable after the successful transition to stateless clients. What has not yet been mentioned is that L2 rollups can benefit from the longer history window by directly querying this contract.

The new precompile can also be helpful for protocols or applications utilizing the BLOCKHASH opcode, for example, for some time-dependent verification. The opcode can access only the last 256 block hashes, so if some application requires something older, it can utilize the new precompile for up to 8192 historical block hashes.

The change in this proposal is simple and doesn’t introduce new direct attack vectors.

EIP-2537 Precompile for BLS12-381 curve

The second precompile, which adds operations that can be performed over the elliptical curve, is helpful for Ethereum dApps that utilize zero-knowledge proofs (for example, zkEmail). Zero-knowledge can be beneficial for increased security, privacy, or improved scaling (as we can see in ZK rollups).

As mentioned, operations in this precompile will provide 120+ bits of security, meaning the input and output are variable. This variability is adequately mitigated in the gas calculations. Because this EIP also contains detailed information on how to implement the curve operations effectively and handle edge cases, the possibility of a potential Denial of Service (DoS) or other attack vectors is minimal.

EIP-7702 New transaction type for loading SC code into EOA

This EIP brings the most impactful UX improvement in years. The initial vision of Ethereum was to create a SC platform where all accounts function as SC with programmable logic. However, for ease of implementation, EOAs were introduced early as the only way to start transactions, which created the most significant usage difficulties (like seeds or gas payments) for new users adopting the technology.

This change brings many fascinating benefits:

• Existing EOA as SA – Not only can new wallets use SA (as with ERC-4337), but existing EOAs can also be transformed into SAs through the new delegation transaction. This transformation possibility is exciting because the main factor slowing down SA adoption is the requirement to create a new wallet.
• Infrastructure reuse – EOA can delegate code to an ERC-4337 smart wallet to utilize the existing architecture built around it.

• Deployment efficiency – Multiple EOAs can be delegated to the exact (audited) implementation, reducing the already steep state growth and simplifying deployment.

• Metamorphosis – The transaction is designed so that EOA can change its implementation anytime or delegate to zero addresses to remove the configured delegation.

On the other hand, this change brings some undeniable security risks:

• Secure Delegation
  Delegate contracts must implement robust security measures and should ideally be verified by an independent audit. These measures include replay protection and requiring signatures from the account’s authority for critical operations involving value, gas, target, and calldata. Failure to do so could grant malicious actors access to all user funds or even near-complete control over a user’s EOA. That’s why users must pay especially focused attention to which contract they are delegating when signing this type of transaction.

A possible attack scenario for malicious protocols, utilizing phishing or disguise techniques, could work like this:

1. The delegation transaction to SC (controlled by the malicious protocol) is proposed to a user for signing during a typical interaction (e.g., token swap).
2. The Transaction is trying to look like a regular transaction.
3. The user doesn’t recognize that the transaction is not safe and signs it.
4. The protocol gets control over the user’s EOA and all assets using the delegated SC.

Wallet providers must mitigate this attack scenario. They should implement this new feature carefully, highlighting the potential risks when signing the delegation transaction. It would also be nice to see some info about the latest audit of the target SC, which could even utilize on-chain audit representation (EIP-7512).

• Breaking tx.origin invariant
  EOA can delegate to SC and then call a method on itself, effectively calling SC’s method. The tx.origin and tx.sender are the same inside this call, which will also propagate to nested calls. On the one hand, this makes batching transactions possible. On the other hand, it makes reentrancy checks and atomic sandwich protections, relying on require(tx.origin == msg.sender), exploitable by this exact technique. Although protections utilizing tx.origin are not used often, this exploit may be used on already deployed protocols. There is no workaround except to migrate these protocols to a new version, where the protection is not needed or archived differently.
• Front-Running Initialization
  Compared to traditional contract deployment, delegation to SC does not initialize the storage because the constructor is not invoked. That makes the delegation prone to front-running initialization, which could be achieved as follows:

1. The user sends a delegation transaction to an SA that does not correctly guard initialization or contains a vulnerable method that does not check if initialization has already been done. 
2. Because the constructor is not invoked, the user’s EOA is left uninitialized.
3. A malicious actor can call the initialization method or the vulnerable method on the user’s EOA, gaining an advantage over the user’s account. 

SA developers must mitigate this attack scenario by performing initialization checks in every (possibly prone) method and ensuring that initialization can only be performed by the EOA owner.

EIP-7685 SC requests to CL (EIP-7002 withdrawals, EIP-6110 deposits)

At first glance, the new communication channel for requests from SCs to CL may seem like a new field for exploits. But thanks to the requirement of CL and EL to be able to run independently, these requests are not processed immediately. However, they are processed sometime in the future within an unspecified timeframe (depending on the request). That means the result of the request (withdrawal/deposit) is not available synchronously but in some next call, making it uncomposable and hard to use in any exploit scenario.

Thanks to these EIPs introducing new features to the SC layer, there is no need to worry about existing protocols handling deposits/withdrawals off-chain being exploited by this particular protocol change. Instead, they could migrate their logic on-chain to provide users with more transparency, security, and decentralization.

Because this EIP also contains detailed gas calculations of how the withdrawal and deposit requests will be priced, the possibility of a potential DoS there is also minimal.

Closer look to EIPs

The Pectra upgrade (EIP-7600) will include the following eleven EIPs:

Scheduled for inclusion

EIP-2935 Precompile for historical block hashes

Adds a new precompile for returning the latest 8192 block hashes. This change towards stateless clients will allow the CL client to load block hashes from the EL client. In the current implementation, EVM assumes the CL client has the recent blocks available, which is not future-proof for Ethereum’s stateless scaling vision.

EIP-2537 Precompile for BLS12-381 curve

Adds a new precompile with 120+ bits of security for verifying BLS signatures on-chain. The existing BLS precompile is kept but provides only 80 bits of security.

EIP-7685 General-purpose execution layer requests

Adds a new communication channel that allows sending requests from the SC directly to CL. This channel enables SCs to control validator deposits (EIP-6110), withdrawals (EIP-7002), and anything else in the future since the communication format is very open. Sending requests from SCs to CL to control stakes can currently be performed only via an off-chain service (or human) that collects and forwards the on-chain requests to the CL. This change will enable fully SC-controlled validators – simplification in the processes of exchanges and protocols (for example, Lido), which interact with deposits while making them more secure through decentralization.

EIP-6110 Validator deposits on-chain

Transfers responsibility for stake deposits from CL to EL. This change makes deposit processing more secure and speeds it up from the current 13 hours to 12 minutes. It also deprecates deposit voting (other validators in CL voting to accept the new one) and the associated Eth1Data poll for storing this data, simplifying the CL implementation.

EIP-7002 Validator withdrawals on-Chain

Transfers responsibility for withdrawing deposits from CL to EL. Similar to the previous one, this change makes the process more secure. It moves the right to withdraw the deposited Ether from the validator to the Ether owner, which can be different entities (and often are) in the real world. That makes depositing trustless because the owner of funds can withdraw them anytime without the validator’s approval.

EIP-7251 Increase MAX_EFFECTIVE_BALANCE

Increases the effective balance (base value used for rewards calculation) from 32 to 2048 Ether. The primary motivation for this change is to reduce the number of validators up to 64 times (corresponding to the 64-time increase in the effective balance). This improvement is motivated by the change in Ethereum’s scaling vision from 64 separate shard chains to rollup scaling utilizing Danksharding with Data availability sampling through stateless clients. It benefits the whole network by reducing the voting overhead and enabling compounding rewards. It also allows large validators to consolidate stakes into fewer validators, reducing the infrastructure requirements and allowing small players to stake in more flexible increments. 

EIP-7549 Move Committee Index outside Attestation

Moves the committee index (identifier of validator group) outside the signed attestation (message attesting block validity). This change allows attestations to be aggregated more effectively, meaning fewer signatures must be verified to reach consensus.

EIP-7702 New transaction type for loading SC code into EOA

Adds a new type of transaction that adds code to the sending EOA. The code that can be loaded to EOA is restricted to a pointer to an address. After successful transaction verification, the EOA will act as if the SC code on the pointed address was natively present in the EOA. This behavior will last until changed by the new transaction from the EOA to a different address or zero address for code removal. This change brings the long-awaited account abstraction to Ethereum, enabling the transition of EOA to smart account (SA) and making features like custom security rules, gas payment delegation, or transaction batching possible. A significant advantage of this approach is that it remains compatible with ERC-4337, the currently used standard for SAs, for which infrastructure and wallets have already been developed in the last few years.

EIP-7623: Increase Calldata Cost

Increase the gas cost of calldata for transactions that do not exceed a certain threshold of gas spent on EVM operations. The main goal is to make transactions more expensive for L2s using calldata for their data availability (DA) to incentivize them to use blobs (the preferred way) and decrease space growth.

EIP-7691: Blob Throughput Increase

Doubles target blobs (3 → 6) and increases max blobs (6 → 9), expanding Layer 2 capacity on Ethereum. Changes target-to-max ratio from 1/2 to 2/3 for more responsive fees: base fee increases 8.2% (previously 12.5%) when blocks are full and decreases 14.5% (previously 11.1%) when empty, optimizing data availability pricing.

EIP-7840: Add blob schedule to EL config files

Introduces “blobSchedule” configuration object storing blob parameters (target, max, base fee fraction) for different network forks in JSON format. Replaces hardcoded constants in execution clients with external configuration, enabling automatic parameter application based on active fork version.