As we close out the year, and with 12 months since the last one (!), I’m overdue for another AllCoreDevs update. This post details the evolution and scope of the Pectra network upgrade. Expect a follow-up 🔜 covering what’s after Pectra, as well as ACD’s evolution over the past year!

Pectra

This time last year, we began seriously discussing the scope for the Prague/Electra network upgrade, eventually portmanteaued into “Pectra”.

Through the first few months of the year, as Dencun went live without issues, client teams came to consensus on an initial set of EIPs for the upgrade, including BLS precompiles, EIP-3074, an increase to validators’ MAX_EFFECTIVE_BALANCE and several other protocol improvements .

These EIPs served as the target for our Nyota interop event. Over 5 days, ~120 attendees from client and research teams came together in Kenya to launch over 100 devnets to test Pectra, PeerDAS, Verkle, SSZ, EOF and more. 80% of the attendees said the week was one of their most, if not the most, productive of the past year! After interop, teams felt emboldened to think bigger… perhaps too big 😅

Even prior to the event, it was clear that parts of Pectra had to be rethought, most notably EIP-3074, which eventually got replaced by EIP-7702. After making more progress than expected on PeerDAS and EOF in Africa, teams felt confident they could bundle both changes alongside the already ambitious Pectra. By mid-June, Pectra had grown to include 20 EIPs, with more still under consideration.

As we spent the summer working on implementations, it became clear that bundling all of this in a single fork would be unworkable. In September, we decided to split the fork, even though there were concerns that moving EOF and PeerDAS out of Pectra would lead these important features to also be delayed.

PeerDAS’s removal from Pectra created urgency around considering a blob count increase for the fork. Several research posts analyzed the issue.

After months of back and forth, teams eventually agreed to double the blob target from 3 to 6 per block, and raise the maximum from 6 to 9. To prevent potential networking issues caused by large blocks, EIP-7623 was also included in Pectra. On the last AllCoreDevs of 2024, with the inclusion of EIP-7840, the final adjustments to Pectra’s scope were completed!

Now, let’s unpack exactly what is in this network upgrade.

EIP-7600

First, EIP-7600 defines the feature set for Pectra. While there have been exceptions, most network upgrades have a Meta EIP to track the individual EIPs they include. For Pectra, these are:

• EIP-2537: Precompile for BLS12-381 curve operations

• EIP-2935: Save historical block hashes in state

• EIP-6110: Supply validator deposits on chain

• EIP-7002: Execution layer triggerable exits

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

• EIP-7549: Move committee index outside Attestation

• EIP-7623: Increase calldata cost

• EIP-7685: General purpose execution layer requests

• EIP-7691: Blob throughput increase

• EIP-7702: Set EOA account code

• EIP-7840: Add blob schedule to EL config files

  • Note: still not merged in the Meta EIP.

While I encourage you to read all of the actual EIPs (many of them are mostly words and not code!), here is a layman’s summary for each one.

EIP-2537

This EIP, first proposed for Berlin in 2020, holds the record of being considered for the most upgrades before its eventual inclusion. It introduces BLS12-381 cryptographic operations as precompiles on Ethereum’s execution layer. This curve is notably used by validators on the consensus layer, meaning that its inclusion allows smart contracts to validate proofs of validator signatures.

This is especially useful for use cases such as liquid staking or preconfirmations. Even beyond that, BLS provides higher security and cheaper verification than existing cryptographic primitives on Ethereum’s execution layer.

EIP-2935

This EIP sets the stage for Ethereum’s eventual transition to statelessness by storing the last 8192 block hashes in a contract. This will allow block hashes to be included in witnesses provided to stateless clients. Additionally, the EIP extends the range of block hashes available to applications from 256 (via the BLOCKHASH opcode) to 8192 in the 2935 system contract at 0x0aae40965e6800cd9b1f4b05ff21581047e3f91e.

EIP-6110

To account for potential proof-of-work reorgs, validator deposits are subject to a 2048 block wait prior to entering the Beacon Chain activation queue. Since The Merge, this has been unnecessary, as the execution layer stays in sync with the consensus layer each block. EIP-6110 updates the deposit mechanism to remove the delay between deposits being executed on the EL and added to the CL’s activation queue.

EIP-7002

Validators have two keys: an “active” BLS key, which is regularly used to sign attestations and other messages, and a withdrawal key, which is either a placeholder BLS key or the destination Ethereum address for the funds. Historically, only the active BLS key could initiate exits. EIP-7002 allows validators with Ethereum addresses as withdrawal credentials to initiate withdrawals.

This enables more trustless delegated staking arrangements, either via onchain pools or other custody setups. Today, delegators need to rely on the validator operator to initiate a withdrawal. With 7002, the controller of the withdrawal credentials can trustlessly exit their validators.

EIP-7251

This EIP raises the MAXIMUM_EFFECTIVE_BALANCE for validators from 32 ETH to 2048 ETH. This allows smaller validators to compound their rewards. Today, if a validator’s balance has increased beyond 32 ETH, the additional ETH is ignored when calculating rewards. With EIP-7251, rewards will compound up to 2048 ETH. The EIP also allows existing validators sharing a withdrawal address to consolidate their validators, hopefully reducing bandwidth usage on the network. For a deeper dive into the EIP, see Paul Harris’s Devcon Talk.

EIP-7549

When validators vote on blocks, they currently sign three pieces of information: their vote on finality (FFG vote), their vote on the current chain head (LMD-GHOST vote), and their committee assignment. By removing committee assignments from what gets signed, validators making the same votes can combine their signatures. This reduces the work needed to cryptographically verify consensus by about 60x!

This change has no impact on security - it just makes the same security guarantees more efficient to verify. This is especially important for light clients and future zero-knowledge proofs of consensus.

EIP-7623

The biggest factor in the size of an Ethereum block is how much CALLDATA it uses. While the vast majority of Ethereum transaction senders use a relatively small amount of data relative to the computation they execute, a small subset of transactions are extremely CALLDATA-heavy. In the worst cases, data-heavy blocks can severely disrupt the peer-to-peer network.

This EIP introduces a two-tiered gas price scheme for CALLDATA, based on how much gas a transaction spends on computation vs. data. By doing so, it effectively applies higher costs to extremely data-heavy transactions while leaving the vast majority of end user ones unaffected. An ethresear.ch post by the author goes into more detail here.

EIP-7685

This EIP extends execution layer block headers with a new requests_hash field to communicate information from execution layer system contracts, used in EIPs 2935, 4788, 6110 and 7002, with the consensus layer. In essence, this sets up a universal “request bus” for the execution layer to pass data to the consensus layer. The EIP is intentionally minimal, specifying only the base mechanism for storing and verifying requests, so that it can hopefully be used in all future similar cases.

EIP-7702

As mentioned earlier, this EIP is the successor to EIP-3074. Its design was the result of extensive discussions between client teams, account abstraction researchers, wallet maintainers and application developers. In short, the EIP allows EOAs (Externally Owned Accounts) to execute code stored at a delegated address, effectively turning it into a smart-wallet for the duration of a transaction.

Much has been written about 7702. To better understand the design and its implication, see a deep dive by one of the authors, this panel on how the EIP affects wallets, or one of the many explainers for it. You can even try a live demo!

EIP-7840

EIP-7840 replaces a previous proposal, EIP-7742, that tried to decouple blob counts entirely from the execution layer. This would have allowed consensus layer-only forks to increase the blob count. After getting deeper in their implementations, teams realized that the blob count could not easily be abstracted from the execution layer.

Instead, EIP-7840 formalizes how EL clients will track the evolving blob target/maximum across forks in their config files, replacing EIP-7742’s approach of decoupling. This ensures the execution layer reliably references each fork’s blob constraints. In a scenario where the consensus layer was ready to raise the blob count and the execution layer needed to follow, all clients would need is a “one line change” in their genesis configurations.

Next Steps

Even with its reduced scope, Pectra is still shaping up to be one of the largest upgrades to Ethereum in history. It’s hard to believe that only 8 months ago we didn’t even have blobs live! With the feature set for the upgrade now finalized, teams have a more stable implementation target to kick off the year.

It’s hard to predict timelines, but hopefully after devnet-5, we only have another devnet or two before moving to testnet forks. As always, security remains the top priority. If the devnets or other testing reveals issues, teams will of course address them before moving forward.

Until then, expect another ACD update covering post-Pectra updates, AllCoreDevs process changes and more 🔜