The Pectra network enhancement is set to launch on Ethereum testnets!
Pectra Overview
It will commence on Holesky at epoch 115968 (Feb. 24, 21:55 UTC) followed by Sepolia at epoch 222464 (Mar. 5, 7:29 UTC). The Pectra testnet client versions are detailed below. After both testnets have successfully transitioned, an activation epoch for the mainnet will be determined.
Pectra follows the previous year’s Dencun enhancement. It brings in innovations to enhance Ethereum accounts, enrich the validator experience, facilitate L2 scaling, and much more!
This article delves into these three significant advancements in depth. For a broader perspective, refer to ethereum.org’s overview of the upgrade.
From EOAs to Smart Accounts
EIP-7702 signifies a significant milestone towards broader account abstraction, permitting users to upgrade their Externally Owned Accounts (EOAs) with smart contract capabilities.
This blended approach fuses the user-friendliness of EOAs with the programmability of contract-based accounts. In practice, it allows for:
- Transaction bundling, facilitating the execution of numerous operations atomically within a single transaction. No more separate transactions for “approve” and “swap”!
- Gas sponsorship, permitting others to cover transaction expenses. This is particularly beneficial when wishing to transact from an account that has no ETH balance.
- Alternative authentication methods, signifying that several hardware security modules (HSMs) present in modern phones can be utilized to authorize actions for the account through technologies like passkeys.
- Spending restrictions, which can restrict how many tokens a specific application can expend, or cap daily withdrawals from a wallet, enhancing security.
- Recovery options, which offer various choices for users to protect their assets, without the need to shift to a new account.
To utilize EIP-7702, an EOA authorizes a signature that specifies a particular delegation address whose code it seeks to execute. Once established, the account acquires the functionalities of the new code (e.g., batching, sponsorship, authentication logic, etc.). Since selecting a delegation target relinquishes considerable control, EIP-7702 enforces an array of safety measures:
- Chain-specific delegations: by default, a delegation is only valid on a specific chain ID, ensuring that the same authorization cannot be applied across different networks.
- Nonce-bound delegations: authorizations can be linked to the account’s current nonce, automatically nullifying them once the nonce increases.
- Revocability: the owner of the EOA can always create another EIP-7702 authorization that revokes or replaces the existing delegation code, preventing an indefinite lock-in if issues arise.
For a more thorough exploration of how this operates, check out @lightclient’s presentation at Devcon on the subject.
Validator UX Enhancements
Three new EIPs within Pectra refine the validator experience: 7251, 7002 and 6110.
The first, EIP-7251, elevates the maximum balance a validator can earn rewards on from 32 ETH to 2048 ETH, via an opt-in modification of withdrawal credential type.
For smaller stakers, this enables automatic reward compounding. Previously, any rewards accumulated beyond a validator’s 32 ETH deposit would not contribute to their active stake. Stakers wishing to stake more than 32 ETH could only do so in fixed increments of 32 ETH, relying on staking pools for anything in between. With EIP-7251, both current and new validators can now receive rewards on the entirety of their stake, up to 2048 ETH per validator.
This EIP also permits larger operators to consolidate multiple validators by joining those with similar withdrawal credentials. This minimizes the bandwidth demands on the network overall. For a comprehensive understanding, watch this talk from Teku’s Paul Harris.
EIP-7002 further expands the capabilities of validators by introducing execution layer-triggerable withdrawals. Prior to this EIP, only a validator’s active signing key could initiate an exit. Now, if an Ethereum address is assigned as a withdrawal credential, it too can effectuate an exit. This diminishes trust assumptions in delegation scenarios, as the fund owner—whether an individual controlling an EOA or a DAO-managed smart contract—can always trustlessly initiate an exit.
Lastly, EIP-6110 eliminates a lingering remnant of pre-merge Ethereum: the delay between validator deposits and their integration into the deposit queue. Before the merge, the Beacon Chain had to wait 2048 blocks before processing validator deposits to account for potential proof-of-work re-organizations. This is no longer essential!
With EIP-6110, deposit processing delays now reduce from around 9 hours to approximately 13 minutes. Teku engineers Lucas Saldanha and Stefan Bratanovreviewed the specifics of EIP-7002 and EIP-6110 during their collaborative Devcon SEA presentation.
Blob Scaling .oO
The last significant modification in Pectra is EIP-7691, which boosts Ethereum’s blob capability by 50%!
Blobs, introduced with the Dencun upgrade, serve as transient data storage for L2s to transmit compressed transaction information and proofs to Ethereum L1. Since their launch, they have multiplied the reduction of L1 fees for L2s by 10 to 100 times, leading to significantly lower transaction costs for L2 users.
Presently, the Ethereum mainnet accommodates an average of 3 blobs per block, with a cap of 6 to handle peaks in demand. Upon implementation of EIP-7691, these figures will rise to an average of 6 and a maximum of 9.
In contrast to CALLDATA, which nodes retain permanently, blobs are discarded from the network following 4096 epochs (~18 days). This limits the overall disk space they can occupy. Instead, the restrictive factor for blobs is bandwidth, as they must be communicated across Ethereum’s peer-to-peer network. To mitigate the bandwidth surge instigated by EIP-7691, Pectra also incorporates EIP-7623, which restricts the maximum size of a block in worst-case scenarios.
To perpetuate the scaling of Ethereum’s data throughput without a proportional increase in bandwidth necessities, we must transition from a scenario where every node keeps every blob to a model where nodes conserve just a selection and sample the network to authenticate the residual blob information. Fortunately, efforts in this direction are already ongoing! Francesco from the Ethereum Foundation research division detailed this scaling roadmap in his devcon keynote.
Pectra Specifications
The compilation of alterations introduced in Pectra is accessible in EIP-7600. For reference, they are as follows:
Moreover, the complete Python specifications for the modifications to the execution and consensus layer standards can be found within the ensuing releases:
Lastly, Pectra also brings updates to the Engine API utilized for interaction between the consensus and execution layer nodes. These specifications can be found in the prague.md file within the repository.
Pectra Activation
The Pectra network enhancement will be activated on Holesky and Sepolia as detailed below:
Furthermore, Pectra has already been activated on Ephemery, a staking testnet that resets after every 28 days. More details can be found here.
Client Releases
The subsequent client releases are appropriate for the Pectra upgrade on both Holesky and Sepolia. Additional versions will enable support on mainnet. Once these are released, a further announcement will be made on this blog.
Consensus Layer Sepolia & Holesky Releases
When operating as a validator, both the Consensus Layer Beacon Node and Validator Client must be upgraded.
Note: the Grandine client was open-sourced in April 2024. Since then, it has been integrated into all Pectra testing phases along with other clients.
Execution Layer Sepolia & Holesky Releases
FAQ
How do Ethereum network upgrades function?
Ethereum network upgrades necessitate explicit consent from node operators on the network. Although client developers reach a consensus on which EIPs are included in an upgrade, they are not the final arbiters of its implementation.
For the upgrade to be implemented, validators and non-staking nodes must manually upgrade their software to accommodate the protocol modifications being introduced.
If they operate an Ethereum client that has not been updated to the latest version (mentioned earlier), it will disconnect from upgraded peers at the fork block, causing a fork in the network. In this circumstance, each segment of the network nodes will only connect with those who share their (un)updated status.
While the majority of Ethereum upgrades are non-controversial, and instances leading to forks have been infrequent, the ability for node operators to coordinate on whether to adopt an upgrade is a fundamental trait of Ethereum’s governance.
For a more comprehensive overview of Ethereum’s governance procedures, refer to this discussion by Tim Beiko.
As an Ethereum mainnet user or $ETH holder, is there anything required of me?
In brief, no.
This notification pertains solely to Ethereum testnets: Holesky and Sepolia. A further announcement will be issued regarding Pectra’s implementation on the Ethereum mainnet, but even then, Ethereum mainnet users and $ETH holders are not anticipated to need to take any measures.
If you wish to observe the upgrade being activated on Holesky, EthStaker is facilitating an online viewing event!
As a non-staking Sepoliaor Holesky node administrator, what must I do?
To ensure compatibility with the upgrade on either testnet, upgrade your node’s execution and consensus layer clients to the versions specified in the table above.
As a Sepolia or Holesky staker, what actions are required?
To remain compatible with the upgrade on both testnets, update your node’s execution and consensus layer clients to the specified versions in the table above. Ensure that both your beacon node and validator client are current.
As a non-Sepolia or Holesky node administrator or staker, what should I do?
Nothing at this moment. Additional information will be provided regarding Pectra’s launch on the mainnet.
As a developer of applications or tools, what actions should I take?
Examine the EIPs included in Pectra to ascertain their impact on your project — numerous exciting new features are being introduced across both the execution and consensus layers!
As a security analyst, what do I need to do?
Stay alert for a post about the Pectra bug bounty competition coming shortly 👀
Why is it called “Pectra”?
Upgrades to the execution layer are linked with names of Devcon cities, while those for the consensus layer utilize star names. “Pectra” is derived from Prague, the venue of Devcon IV, and Electra, a blue-white giant star within the Taurus constellation.
Original cover image by Julia Solonina, modified by Tomo Saito.
