Ethereum is constantly evolving. In March 2024, 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). However, Ethereum core developers are already working on the next major upgrade called Pectra.
What are the goals of the Pectra hardfork, and when can we expect it to be delivered?
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, as the name of EL upgrade (which are named after Devcon cities);
- Electra, as the name of CL upgrade (which are named after celestial stars).
In the greatest version of Pectra, 24 Ethereum Improvement Proposals (EIPs) were proposed.
During the Core Developers Meeting 142, which took place on September 19th, it was agreed that the Pectra upgrade must be split to reduce its complexity and the risks of introducing exploitable bugs or vulnerabilities. The scope was more than halved from the previous 24 EIPs to 11 EIPs, of which two are still being considered at the time of writing. 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.
The complexity split allows the Pectra upgrade to be delivered sooner than planned. Based on the latest estimates, Pectra could be live on the mainnet in Q2 2025 (around May).
The Ethereum Pectra upgrade makes the network faster, more efficient, and easier to use with improvements for wallets, validators, and smart contracts.
Summary of Pectra
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 enabling dynamic blob count target (EIP-7742).
- 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 be ideally 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:
- 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).
- Transaction is trying to look like a regular transaction.
- The user doesn’t recognize the transaction is not safe and signs it.
- 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, 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:
- 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.
- Because the constructor is not invoked, the user’s EOA is left uninitialized.
- 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
While not completely finalized yet, the Pectra upgrade (EIP-7600) will very likely include the following nine EIPs marked as “Scheduled.”
Scheduled
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 smart contract (SC) directly to CL. This channel allows 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 by decentralization.
EIP-6110 Validator deposits on-chain
Transfers responsibility for staking 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 these 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 committee index (identifier of validator group) outside 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 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 developing in the last few years.
EIP-7742 Uncouple Blob Count Between CL and EL
Enables dynamic management of the blob target count parameter from CL to EL, which is currently hardcoded on both layers. This change makes future adjustments to the target blob count easier to perform.
Considered
At the time of writing, the following two EIPs are still being considered, which means they will probably be included, but it’s not confirmed yet.
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 using blobs (the preferred way) and decrease space growth.
EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
Increases the minimal price for using blobs. The key goals of this change are to make the price for blobs more accurately reflect the demand, speed up the price discovery, and reduce the time it takes for the blob base fee to adjust (especially during periods of high demand).
