Ethereum Pectra upgrade scope

The largest Ethereum upgrade, in terms of EIPs included, is approaching despite some challenges faced on testnets.

I've put together a concise thread covering the core changes that will be implemented during the Pectra upgrade.

This overview of the key EIPs should give you a clear understanding of the main concepts driving the upcoming changes to Ethereum.

Here’s what to expect in Ethereum Pectra ????

https://preview.redd.it/it6o8swg98oe1.png?1200&format=png&auto=webp&s=1ed29b743b436c92820cf3d7c73efbce9485cbb4

1/ EIP-2537: Precompile for BLS12-381 curve operations

???? https://eips.ethereum.org/EIPS/eip-2537

???? Authors: Alex Vlasov, Kelly Olson, Alex Stokes, Antonio Sanso

???? The current cryptographic tools in Ethereum, particularly the BN254 precompile, are not robust enough for applications that require enhanced security. The BLS12-381 curve provides stronger cryptographic features and is being more widely adopted across blockchain platforms for improved security.

2/ EIP-2935: Save historical block hashes in state

???? https://eips.ethereum.org/EIPS/eip-2935

???? Authors: Vitalik Buterin, Tomasz Stanczak, Guillaume Ballet, Gajinder Singh, Tanishq Jasoria, Ignacio Hagopian, Jochem Brouwer, Sina Mahmoodi

???? Ethereum currently depends on clients for recent block hashes, which is not a future-proof approach. This proposal addresses the limitation by embedding block hashes in the state, enhancing accessibility and enabling features like extended proof validation and rollup interaction.

3/ EIP-6110: Supply validator deposits on chain

???? https://eips.ethereum.org/EIPS/eip-6110

???? Authors: Mikhail Kalinin, Danny Ryan, Peter Davies

???? The current mechanism relies on the complex deposit voting process in the Consensus Layer. This proposal removes deposit voting from the Consensus Layer, shifting the responsibility for deposit inclusion and validation to the Execution Layer. The goal is to improve security, simplify client design, and reduce validator deposit processing delays

4/ EIP-7002: Execution layer triggerable exits

???? https://eips.ethereum.org/EIPS/eip-7002

???? Authors: Danny Ryan, Mikhail Kalinin, Ansgar Dietrichs, Hsiao-Wei Wang, lightclients

???? Currently, validators need their active "hot" keys to initiate exits. The proposal addresses the restriction where only the active validator key could trigger withdrawals, ensuring that withdrawal credential holders have full control over their staked ETH securely and independently.

5/ EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

???? https://eips.ethereum.org/EIPS/eip-7251

???? Authors: Mike Neuder, Francesco, dapplion, Mikhail Kalinin, Aditya, Justin Drake, lightclients

???? Currently, validators are limited to 32 ETH, which forces large stakers to operate many redundant validators, and that increases network overhead and inefficiencies. This proposal would reduce the validator count, optimize resource use, and improve efficiency for both solo and large-scale stakers.

6/ EIP-7549: Move committee index outside Attestation

???? https://eips.ethereum.org/EIPS/eip-7549

???? Authors: dapplion, Mikhail Kalinin

???? The current mechanism of attestations in Ethereum's Beacon Chain leads to increased computational and storage requirements for validators and ZK circuits.

The proposal's goal is to optimize Casper FFG (Friendly Finality Gadget) mechanisms that will enhance gas efficiency, scalability, and cryptographic verification.

7/ EIP-7623: Increase calldata cost

???? https://eips.ethereum.org/EIPS/eip-7623

???? Authors: Toni Wahrstätter, Vitalik Buterin

???? Ethereum’s calldata costs have remained unchanged since EIP-2028, leading to inefficiencies as rollups generate large, data-heavy blocks. This proposal adjusts calldata costs to reduce inefficiencies and align with EIP-4844's data availability changes.

8/ EIP-7685: General purpose execution layer requests

???? https://eips.ethereum.org/EIPS/eip-7685

???? Authors: lightclients

???? Smart contract-controlled validators often rely on external intermediaries for administrative actions, introducing inefficiencies and risks. This proposal allows direct requests from smart contracts to the CL, streamlining operations and improving safety, scalability, and cross-layer communication for governance automation.

9/ EIP-7691: Blob throughput increase

???? https://eips.ethereum.org/EIPS/eip-7691

???? Authors: Parithosh Jayanthi, Toni Wahrstätter, Sam Calder-Mason, Andrew Davis, Ansgar Dietrichs

???? This proposal addresses current data availability limitations, offering a short-term scalability improvement for Layer 2 rollups while long-term solutions like peerDAS are being developed.

10/ EIP-7702: Set EOA account code

???? https://eips.ethereum.org/EIPS/eip-7702

???? Authors: Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclients

???? EOAs are less programmable than smart contracts, limiting their efficiency and flexibility. This proposal introduces a mechanism to extend EOAs' functionality, improving gas optimization, security, and interoperability by bridging the gap between EOAs and contract accounts.

11/ EIP-7840: Add blob schedule to EL config files

???? https://eips.ethereum.org/EIPS/eip-7840

???? Authors: lightclients

???? Currently, execution clients depend on blob configuration data for some features. Storing this data only in the consensus client leads to inefficiencies and extra API calls between clients for each block. This proposal improves performance by offloading the need for execution and consensus layers to perform excessive data handshakes.