Pectra Rundown

Written by Mohammad Jahanara.

We would like to thank Christine Kim and Marius van der Wijden for their thoughtful reviews and comments on an initial draft of this post, and acknowledge contributions from other Scroll team members Péter, Ye, and Alejandro.

Pectra, the next big Ethereum hardfork is only few weeks away form hitting the mainnet. It implements 11 EIPs with a really broad scope! We will first describe the key impacts of the upgrade and then go in depth and explain technical details of included EIPs.

The Impact Summary

Core Protocol Enhancements

Ethereum’s path to the merge wasn’t a direct one. The complicated history and the ever changing design goals have left their mark and fair share of technical debt in all corners of the protocol. Pectra takes a big step towards addressing the technical debt.

EIP-6110 removes a notoriously bug-prune and unnecessary bridge between CL and EL, making consensus clients easier to maintain and faster to sync! More importantly, it relaxes the security assumptions of the protocol even further.
EIP-7251 increases maximum allowed stake per validator, and introduces a simple mechanism for validators to consolidate. Big node operators can use this mechanism to consolidate their nodes, to simplify their setup and reduce their costs. An important consequence is there are going to be fewer logical validators (estimated reduction of 10-50 times) and as a result significantly lower over-head of attestation aggregation.
EIP-7691 doubles blob capacity from a target of three blobs per slot to six. This is a much needed adjustment considering that blob consumption has been at capacity for the past few month, despite colder market conditions. Moreover, there have been many discussions about scaling L1 execution, and any none incremental solution for scaling L1 execution that doesn’t make the block validation centralized has to rely on data sharding i.e. blobs.

Several UX improvements in Staking

Roughly 30% of the total supply of ETH is staked. Staking is not only the corner-stone of network’s security but also it is one of the most popular use cases of ETH the asset. Pectra includes several EIPs that enhance the UX and DevX of staking. First of all, EIP-6110 significantly reduces deposit processing time, from several hours to minutes. Moreover, with EIP-7002 validator cold credential addresses can request a withdrawal, significantly simplifying the threat model in protocols like Lido and RocketPool that rely on non-standard custody relationships. Before they had to rely on off-chain components to custody pre-signed exit messages, but after Pectra they can replace that with a simple trustless on-chain contract. Also, stakers can withdraw even if they lose their active key (e.g. corrupted hard drive and no backup). Finally, EIP-7251 increases maximum effective stake to 2048 ETH, allowing solo stakers to compound their stake, and enables big stakers to simplify their setup by consolidating their nodes. A side effect of this EIP is fewer logical validators that would reduce the withdrawal delay (due to faster validator sweeps); shorter withdrawal delays implies better UX for stakers and lower cost to maintain the peg for LSTs.

A Big Push for Account Abstraction Wallets

Today, scaling is no longer the biggest hurdle to bring the next billion users on chain, it’s the UX! Web2 users are not used to thinking about gas fees when interacting with applications. They are used to using freemium services, not worrying too much about safeguarding credentials, and enjoying convenient authentication and account recovery methods. Account Abstraction (AA) provides a solution for all of these problems and more. However, it has been proven extremely hard for AA wallet providers to convince users with EOA wallets to migrate to AA wallets. Without adoption, there’s not much incentive for apps to build AA-based services.

EIP-7702 gives AA a big push by providing a one-transaction solution for EOAs to effectively upgrade to AA wallets. Popular wallet providers (e.g. MetaMask, Rainbow, TrustWallet, …) can give their users an option to augment their EOAs with code effortlessly. Moreover, apps that rely on AA to provide services such as gas sponsorship can request their EOA-based users to upgrade instead of turning them away. As a result, it is fair to anticipate a major rise in AA adoption. This will turn the flywheel of AA and incentivize builders to build more AA-based services. After Pectra, it is much easier for wallets and dapps to offer a familiar web2 experience, while maintaining self-custody, composability, and strong property rights.

Technical Deep Dive

Proof-of-Stake Security and Validator UX Improvements

(EIP-7685, EIP-6110 , EIP-7002, EIP-7251)

This group of EIPs are specifically designed to simplify and enhance the proof-of-stake consensus and its relation to the execution layer.

From ELI5: Ethereum Validator Exits by Mike Neuder and Mallesh Pai

EIP-7685 enables all other EIPs in this group. It introduces a simple format for the execution layer (i.e. smart contracts and EOAs) to send requests to the consensus layer. The execution block header is extended to include a commitment to all requests included in that block. The protocol designers can instantiate this EIP with new request types to allow smart contracts to modify the state of the beacon chain.

EIP-6110: processing validator deposits in execution layer

Beacon chain (formerly known as Eth2.0) was initially introduced as a network separate from the execution chain (Eth1) but to become a validator on the beacon chain you had to deposit stake on execution chain … there had to be a mechanism (essentially a bridge) for the beacon chain to be informed about validator deposits to the deposit contract! To do so each beacon block proposer has to include a ETH1Data field in the block header, which includes the total number of deposits and the recent state root of the deposit contract from its execution chain point-of-view (with roughly 8 hours delay to ensure finality of the deposit on PoW chain). If a majority of proposers over 2048 slots period (~ 6.8 hours) agree on ETH1Data , then beacon chain adopts that view of the deposit contract. Finally, the beacon block proposers have to include new deposit transactions (with a churn limit) along Merkle proofs against the voted-in ETH1Data. Now that the beacon chain and the execution chain have merged, this process seems utterly complicated and unnecessary.

EIP-6110 deprecates ETH1Data polling and instead instantiates an EIP-7685 request type for deposits. The execution client takes on the responsibility of extracting a list of deposit transactions from block logs and including them in the execution payload. All execution clients will check the validity of the deposit lists so the consensus clients don’t have to provide Merkle proofs or do any verification anymore, they just consume the list from the execution payload. ETH1Data polling has been historically a source of bugs and it has proven to be hard to get right! Currently consensus clients have to maintain full state of the deposit contract, but with EIP-6110 that will not be necessary anymore.

Furthermore, new deposits are processed as soon as the corresponding block is finalized (~13 minutes), rather than with 12 hours delay. Also, the EIP significantly relaxes the safety assumptions; under the previous polling mechanism an adversary with only slightly more than half of the total stake could vote-in an incorrect ETH1Data and start processing fake deposits to further inflate their share of the stake. With the new in-protocol deposit processing an adversary needs at least 2/3 of the stake to finalize a block with an incorrect list of deposits.

EIP-7002: trigger validator withdrawals in execution layer

Each validator has an active key and a withdrawal credential. The active key is a BLS key that is used to carry-out validator responsibilities such as singing attestations. The withdrawal credential is an Ethereum address that effectively owns the stake and receives the rewards periodically and the stake after validator exits. The separation of active key from withdrawal credential facilitates non-standard custody relationships, where the entity that owns the stake is different from the node operator. However, currently only an exit message signed by the active key can initiate a validator full withdrawal. As a result, it’s necessary for stakers who delegate the node operation to others, to keep a pre-signed exit messages off-chain, or risk the stake to be taken hostage by rogue node operators!

EIP-7002 is another instantiation of EIP-7685, that enables withdrawal credential addresses to request withdrawals of any of their corresponding validators. Since the execution layer doesn’t have a mapping from BLS keys to withdrawal credentials, the requests can not be fully validated on the execution layer. This increases the risk of grieving/DoS attacks, and to combat it the EIP introduces an EIP-1559 like mechanism that adaptively adjusts the request fee according to the number of pending requests; that will turn any such attack prohibitively expensive.

EIP-7251: increase the MAX_EFFECTIVE_BALANCE

To be a validator you need to deposit at least 32 ETH as stake. A big reason for this is to limit the number of validators, because having too many validators would make attestation aggregation too slow. But why can’t a validator stake more than 32 ETH? After all, currently many entities run more than one validator, often on the same machine with no physical decentralization. This limitation is a relic of the past … the Merge was initially supposed to include or at least pave the way for execution sharding. The safety of the proposed sharding design relied on an honest-majority assumption in small random subsets of validators, and having a low MAX_EFFECTIVE_BALANCE would decrease the odds of an attacker with less than 1/3 of the total stake to have majority in any subcommittee. However, we moved-on from sharding, and in the new design we don’t have any subcommittees with honest-majority assumption, so we could increase the maximum stake!

EIP-7251 maintains the minimum required balance at 32 ETH and increases the max to 2048 ETH. Moreover, it introduces a way for existing nodes to consolidate their stake without going through the lengthy exit and deposit queues. The EIP instantiates EIP-7685 requests to introduce a consolidation request type, the withdrawal credential address of any validator can send a request for it to be consolidated with any other validator. Similar to EIP-7002, consolidation requests can’t be validated on the execution layer, so in order to mitigate DoS risk the EIP introduces an EIP-1559 like fee mechanism.

Big stakers can use consolidation to aggregate their nodes and reduce their cost of operation. Small validators can benefit from the compounding effect of the staking rewards easier. And maybe most importantly, it is expected that this EIP reduces the total number of validators significantly (currently hovering well over whopping 1M). The nice sides-effects of fewer validators are lower load on the p2p network and faster sweeping through validators for processing partial/full withdrawals (currently around 9 days!!!).

Account Abstraction feature for EOAs

(EIP-7702)

AA has been at the forefront of blockchain UX improvement for a very long time. Smart contract wallets (like safe.global) equip wallets with new features such as support for social recovery, arbitrary signature schemes, multi-signer control, transaction batching, transaction sponsorship and so on. Most of these features are absolutely crucial to offer an experience acceptable by most users coming from web2. ERC-4337 was introduced a few years ago to standardize smart contract wallets and bundlers infrastructure, with the hope to boost adoption of AA without any protocol changes, but it had no widespread adoption because most users are used to EOAs and the migration to smart contract wallets isn’t easy. There has been many attempts at designing a mechanism to “upgrade” existing EOA accounts to smart contract wallets (like now deprecated EIP-3074).

EIP-7702 finally enables EOAs to be equipped with code and benefit from AA features. The EIP introduces a new transaction type, that is a typical EIP-2718 transaction with the addition of a new authorization_list field. Each individual authorization contains a delegate address signed by an EOA denoted as authority, (partially) delegating control over authority to the code in address. This means that any call to the EOA authority will be executed with code from address in the context of the authority. An authorization will remain effective indefinitely, although it is possible to change the delegate of an authority or completely remove it at any time with a new authorization. Moreover, authority remains functional as an EOA account.

This primitive is extremely powerful and should be used with utmost care. If a user delegates its account to a rogue address, it could easily get rugged. The wallet applications are expected to take on the responsibility of either offering their own wallet implementation or providing users with reputable options. The EIP is explicitly designed so that most of the existing smart wallet implementations would work out of the box for EOAs as well, so we can expect a smooth and quick adoption curve.

It is important to note that EOA private keys remain active, so users are still responsible for safe guarding that; moreover, this EIP can not be used safely lock user resources off-chain or to upgrade to quantum safe signature schemes.

You can read a complete technical explainer by my colleague Colin here.

Increase blob capacity and make calldata more expensive

(EIP-7691, EIP-7623)

EIP-7691: doubling blob throughput target

Currently blobs are very cheap, almost free. However, since November 2024 the blob consumption was hovering around the target capacity (checkout this dune dashboard). Any increase in consumption would trigger the fee mechanism and elevate the price. In the short-term this means, if we give more cheap blobs to rollups they will likely consume and expand the Ethereum-verse. On the other hand, if there’s any interesting event happening on any rollup, it could quickly price out all other rollups and their users with potentially lower willingness to pay for fees. On a slightly longer-term horizon, rollups with centralized sequencers are positioned to scale their execution throughput massively but to be economically feasible more DA capacity is a required. While Peer-DAS is the real long-term solution, EIP-7691 intents to provide a temporarily relief by doubling the blob target from 3 to 6 per slot.

EIP-7623: increase calldata cost

With the introduction of blobs, using calldata for data availability is now considered inefficient use of blockspace. EIP-7623 increases the cost of calldata to reflect this change in priorities, without affecting most applications. To do so, the EIP introduces a calldata cost floor for each transaction. The fee will be calculated as 21000 + max(regular execution fee, TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata), for TOTAL_COST_FLOOR_PER_TOKEN = 10 comparing to STANDARD_TOKEN_COST = 4. This way transactions that relatively do execution far more than consuming calldata will not be affected, but the ones that indeed consume a lot of calldata comparing to execution will end up paying a much higher price.

Curve operations and pairing precompile for BLS12-381

(EIP-2537)

Several years ago in 2017, EIP-196 and EIP-197 introduced two precompiles for curve operations and pairing check over the curve bn254 (aka alt_bn128). The motivation was primarily to pave the way for verification of zkSNARK proofs on-chain, which indeed panned-out perfectly! The curve BN254 was originally designed to have 128 bits of security for EC cryptography (reminder: n bits of security implies breaking DLH over the curve requires 2^n operations). However, with the introduction of new attacks, it is now conservatively believed to offer only 80 bits of security.

EIP-2537 brings similar precompiles for another pairing-friendly curve, BLS12-381. For BLS12-381 offers 120 bit security, a significant upgrade from BN254. The BLS curve is uniquely useful for BLS signatures that have nice aggregation features and are used in many places such as the beacon chain. The precompile makes on-chain verification of those signatures significantly cheaper. Moreover, it’s possible to instantiate zkSNARK protocols with higher bit-security over this curve rather than BN254.

Misc. technical debt and preparation for future upgrades

(EIP-2935, EIP-7549, EIP-7840)

EIP-7549: move committee index outside of the signed attestation message

EIP-7549 doesn’t have any conspicuous impact on the protocol or applications, however, it prepares us for the SNARKification of the consensus layer. Each slot, validators that have attestation responsibility are grouped into committees. The goal is to reduce communication complexity of attestations by aggregating them at committee-level and then broadcasting to the network. Attestations are BLS signed messages, and one could aggregate multiple signatures of the same message. Currently, the attestation data includes the committee index of the validator, this would make it impossible to aggregate attestations of validators from different committees, even if they are in complete agreement. Note that the inclusion of committee index in attestation data is not necessary at all. Verifying each BLS signature requires a pairing check operation, which are costly particularly in SNARK circuits. If we could aggregate attestations beyond committee-level, we could potentially reduce the cost of verifying consensus rules in-circuit. That is the goal of EIP-7549!

Concolusion

Pectra represents a significant step forward in Ethereum’s ongoing evolution. It addresses important technical debt, enhances protocol security, double down on rollup-centric roadmap, and paves the way for significantly better user experience.