Everything you need to know about Pectra: the new Ethereum Upgrade
The first step of the next Ethereum upgrade is set to happen today!
Live on Holesky on 24th of February
Live on Sepolia on 5th of March
Once these implementation will be successful then a date for mainnet update will be set. We can expect this anywhere between 3-9 months after testnet implementation.
Pectra is quite a hefty upgrade, which introduces several EIPs at once:
We can categorize these improvements into three key areas:
Improving Ethereum Accounts
Improving the UX of Ethereum Validators
Scaling blobs
Let’s dive into some of the EIPs that will be introduced and how they benefit the Ethereum protocols and its users.
Improving Ethereum Accounts: EIP-7702
EIP-7702 moves Ethereum closer to account abstraction at the protocol level. It does so by extending Ethereum’s Externally Owned Accounts (EOAs) with smart contract functionalities, including:
Transaction Batching: executing multiple operations in one transaction
Gas sponsorships: allowing accounts without ETH to get their fees sponsored
More authentication and recovery mechanisms
Improving The UX of Ethereum Validators: EIP-7251/7002/6110
EIP-7251: raises the maximum balance of validators to 2048 ETH and allowing them to compound rewards on a bigger active stake automatically. Previously, rewards only took into account their balance of 32 ETH. Furthermore, bigger validators can now consolidate multiple 32 ETH validators into a single one.
EIP-7002: reduces trust assumptions by allowing execution layer addresses to trigger withdrawals, as long as it is set as a “withdrawable credential”. Before, only validators could trigger exits.
EIP-6110: removes the 2048 block delay between validators' deposits and when they are added to the queue. The times are expected to be reduced from 9 hours to 13 minutes.
Scaling Blobs: EIP-7691
As blobs are becoming more expensive, the need to scale them emerges. Through EIP-7691 blob capacity will be extended by 50%: currently, each Ethereum block can accommodate about 3 blobs (up to 6 in high-demand periods). With EIP-7691, this will increase to 6 blobs on average and 9 in times of high demand.
The next step to scale blobs further is to reduce the need to store all blobs and move to a subnet, which can still be used to verify the blob data.
Other EIPs in Pectra include:
EIP-2537: increasing the security bits for operations up to 120+, to the current 80+ bits.
EIP-2935: to prepare for the prospect of stateless clients, this EIP proposes to store the historical block hashes in the state as part of the block processing logic. By doing so through a contract storage, this EIP allows for a soft transition without impacting the block hash logic. Rollups will be able to benefit from a longer history and directly query the storage contract.
EIP-7549: this AIP focuses on making Casper clients more efficient. It does so by removing the number of pairings required to verify consensus. In particular, it removes one of the three elements of the Attestation message of Casper clients: the committee index. By removing this outside the Attestation message, consensus votes can now be aggregated into blocks more efficiently, increasing the number of votes in a block from 2 slots to 8.
EIP-7623: one of the most impactful developments (especially for L2s) is the increasing calldata costs proposed by EIP-7623. The proposal wants to adapt the call data costs to address the disparity between the average (100kb) and the maximum block size (7.15 MB).
This will not impact regular users and only involve transactions that are mostly posting data.
The increase will be introduced via a floor cost which is dependent on the ratio of gas spent on calldata operations: reduction of the block size to allow more blobs, or gas limit increases.
EIP-7685: introduces a framework to store requests triggered by smart contracts. This allows validators controlled by smart contracts to delegate the administrative operators to the latter, reducing the need for intermediaries.
EIP-7840: introduces a way to “dynamically adjust the target and max blob counts per block” through the object “blobSchedule”, instead of passing all of these value over the engine API.
The focus of this upgrade is quite the signal from Ethereum; we know these things were set in process a long time ago and are not a response to the recent criticism. Nonetheless, the focus placed on making it easier to secure the network, improving accounts on Ethereum, and scaling blobs are in line with some of the most critical developments needed.