Introduction to the Ethereum Pectra Hard Fork

Pectra includes 11 EIPs:

• 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

The following sections group related EIPs for clarity, rather than numerical order.

Prerequisites

Ethereum is divided into two layers:

• ​Consensus Layer (CL): Manages network consensus and block validation.
• ​Execution Layer (EL): Handles transaction execution and smart contracts.

Staking-related EIPs:

EIP-6110: Supply validator deposits on chain

Simplifies the staking process and reduces waiting time.

Users participate in staking by depositing 32 ETH into a ​Deposit Contract on the Execution Layer (EL), which is recorded via event logs. Consensus Layer (CL) nodes then parse these event logs from the EL blocks to detect and register staking activities, allowing users to become validators.

However, CL validators must first reach consensus on ​which specific EL block's deposit data to parse. Without this agreement, discrepancies may arise (e.g., some validators might see 5 new deposits, while others see only 3). To resolve this, CL validators vote on ​which EL block (referred to as eth1data) to reference, ensuring all validators observe the same EL block.

Original Design Constraints:

• To prevent chain splits caused by critical EL errors, eth1data references EL blocks that are ​~10+ hours old.
• This ensures CL developers have sufficient time to react to major issues.
• However, this introduces a ​minimum 10+ hour delay for staking activations.

CL block 10,900,000 references EL block 21,683,339 (10 hours older)

Post-EIP-6110 Improvements

• Deposit data from the Deposit Contract is ​directly embedded into EL blocks.
• Since CL blocks inherently include EL blocks (distinct from eth1data), CL validators no longer need to coordinate on "which EL block to reference."
• Once a CL block is finalized (achieving >2/3 validator votes), all validators inherently trust the ​same EL block data.

Result:

• Staking activations occur ​around ~13 minutes (time for EL blocks to finalize).
• CL clients can ​remove complex logic previously used to process deposit events.

EIP-7002: Execution layer triggerable exits

Enhances the process for validators exiting or withdrawing stakes and rewards.

When a user participates in staking, they require two keys:

• ​Validator Key: Used for validator duties (e.g., block proposals, attestations).
• ​Withdrawal Credential: Specifies the address where staked funds and rewards are sent upon exit.

Current Risks:

• ​Lost Validator Key:
  • Cannot perform validator duties or initiate exits.
  • Penalties accumulate until the validator is forcibly exited (due to low balance).
• ​Lost Withdrawal Credential:
  • Permanent loss of all staked funds and rewards.
• ​Third-Party Staking Services (e.g., Lido):
  • Users retain Withdrawal Credentials, but Validator Keys are controlled by the service provider.
  • Providers can threaten users with ransom demands by withholding exit approvals.

​Post-EIP-7002 Improvements

Users can now trigger exits or withdrawals directly via the ​Withdraw Contract (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) using their Withdrawal Credential, bypassing third-party control.

Key Features:

1. ​Parameters:
   • validator_pubkey: The validator’s public key.
   • amount: The withdrawal amount (partial or full exit).
2. ​Authorization:
   • The Withdrawal Credential must match the validator’s registered credential.
3. ​Fee Mechanism:
   • Transaction fees (in ETH) scale with ​the number of pending withdrawal requests currently queued in the network.
   • ​For Contracts: Query the Withdraw Contract for real-time fee estimates before submitting requests.
   • For EOAs: Overpay fees (no refunds) to ensure transaction success.

Benefits:

• Eliminates reliance on third-party services for exits.
• Enables self-custody validators to recover funds even if the Validator Key is lost.

Note: If your Withdrawal Credential is still in BLS public key format, remember to switch it to the EL address format.

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

Reduces validator count and enables auto-compounding by raising the staking cap.

​Current Limitations:

• Validators must stake ​exactly 32 ETH (the current MAX_EFFECTIVE_BALANCE).
• Large stakers (e.g., 1,024 ETH) must run ​32 separate validators, increasing network load.
• Over ​1 million validators exist today, straining the CL’s state data and P2P layer:
• Each slot (12 seconds) requires transmitting and aggregating ​tens of thousands of validator signatures.

Post-EIP-7251 Improvements

• ​Lower Bound: MIN_ACTIVATION_BALANCE remains ​32 ETH.
• ​Upper Bound: MAX_EFFECTIVE_BALANCE increases to ​2,048 ETH.
• Validators can stake ​any amount between 32–2,048 ETH.
• Auto-Compounding: Rewards automatically compound without manual withdrawals.

​Validator Consolidation:

• Existing validators can merge stakes ​without exiting and re-entering.
• Use the ​Consolidation Contract (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb):
  • Triggered via the validator’s Withdrawal Credential.

Request Parameters:

• source_pubkey: Validator key of the source validator (to be merged).
• target_pubkey: Validator key of the target validator (receiving the merged stake).

Requirements:

• The Withdrawal Credential ​must belong to the source validator.

Fee Mechanism:

• Transaction fees (in ETH) scale with ​the number of pending consolidation requests in the network.
• ​For Contracts: Query the Consolidation Contract for real-time fee estimates.
• ​For EOAs: Overpay fees (no refunds) to ensure transaction success.

Note: BLS-formatted Withdrawal Credentials must be converted to ​Execution Layer (EL) address format.

EIP-7685: General purpose execution layer requests

Establishes a formal EL→CL communication channel for users and staking services.

​Purpose:

• Enables direct requests from the Execution Layer (EL) to the Consensus Layer (CL).
• Enhances decentralization for staking services (e.g., Lido):
  • Users no longer need to trust third-party providers to execute actions like exits (EIP-7002) or consolidations (EIP-7251).
  • Requests are initiated via ​EL smart contracts and embedded in EL blocks.

​Mechanism:

• Requests are written into EL blocks and parsed by CL nodes.
• Request Types eliminate the need for custom parsing logic on the CL.

​Integration with Other EIPs:

EIP-7685 defines the framework for the following request types:

Request Type	EIP	Contract Address	Description
0	EIP-6110	0x00000000219ab540356cbb839cbe05303d7705fa	Deposit Requests
1	EIP-7002	0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA	Withdrawal/Exit Requests
2	EIP-7251	0x00431F263cE400f4455c2dCf564e53007Ca4bbBb	Stake Consolidation Requests

User experience improvement EIPs:

EIP-7702: Set EOA account code

Enables EOAs to morph into smart contract accounts, significantly improving user experience.

​EOA Limitations:

• ​Private Key Dependency: Requires secure storage of private keys/mnemonic phrases, raising onboarding barriers.
• ​Single-Operation Transactions: Complex interactions (e.g., Uniswap swaps) require multiple sequential transactions.
• ​No Granular Permissions: Users must manually sign every operation.
• No Recovery Mechanisms: Loss of private keys/mnemonics results in permanent asset loss.

​Smart Contract Account Advantages:

• ​Keyless Onboarding: Use secure hardware (e.g., TPM) or email-based authentication instead of private keys.
• ​Batch Operations: Execute multiple actions in a single transaction.
• ​Granular Permissions Control: Delegate partial account control with constraints (e.g., spending limits, allowed contracts).
• Recovery Options: Safeguard assets even if private keys/phones/emails are lost.

​EIP-7702 

Users sign a ​morphing message with their EOA private key, containing:

• ​chain_id: Prevents cross-chain replay attacks. Use 0 to enable morphing across all chains.
• contract_address: Target contract address (e.g., Safe). Use address(0) to revert to EOA.
• nonce: Prevents signature replay (invalidates old signatures after nonce increments).

​Critical Considerations:

​1. EOA Private Key Persistence
Even if a user’s EOA morphs into a smart contract, they can still use their account in the original EOA manner. For example, if your EOA morphs into a Safe contract, you can: Use the Safe interface and follow Safe transaction workflows. Continue sending transactions by signing with your original EOA wallet.

However, this also means the ​account’s security remains tied to the private key. The EOA’s private key is still the sole safeguard for the account, and its compromise would jeopardize the entire account, regardless of its morphed state.

2. Security Remains EOA-Based
Even if a user’s EOA morphs into a multi-signature (multi-sig) contract, ​the account’s security remains entirely dependent on the EOA’s private key. Retaining the private key or mnemonic phrase does not elevate the account’s security to that of a true multi-sig. Users must still securely manage their private keys or mnemonics, as the account’s safety fundamentally hinges on them.

3. EOA Storage Persistence
When an EOA morphs into a contract and writes data to its storage, ​the data persists unless explicitly deleted. This means that even if the EOA morphs into another contract or reverts to its original state, the storage data remains intact. Developers must ensure that their contracts do not inadvertently read outdated data from previous morphing cycles. For guidance, refer to ERC-7201

4. EIP-7702 Lacks Built-in Initialization

Typically, smart contract accounts require an ​initialization step during deployment to register the owner’s information (e.g., public key or address). This prevents frontrunning attacks that could hijack account ownership. Initialization is usually handled by a ​Factory contract that performs both deployment and setup.

However, EIP-7702 enables ​direct morphing without a Factory contract. This creates a ​frontrunning risk: attackers could intercept a user’s morphing signature, submit it first, and initialize the account under their control. To mitigate this, developers should implement safeguards, such as ​verifying the EOA’s signature during initialization. This ensures that even if the request is frontrun, the attacker cannot forge the EOA’s signature to complete the initialization.

5. Wallet Security Warnings

Wallets must ​intercept and warn users about suspicious morphing requests. For example, if a malicious DApp prompts a user to sign a morphing transaction, the wallet should block the request and alert the user. If users unknowingly sign malicious morphing transactions, their assets could be ​instantly drained.

​Example Implementations

• ​Modified Safe
• ​Ithaca Account

DApp related EIPs:

EIP-2537: Precompiles for BLS12-381 curve operations

Lowers costs for BLS-curve-based zero-knowledge proof applications.

EIP-2537 introduces several precompiled contracts to provide cost-efficient BLS curve operations, making it more feasible to develop zero-knowledge proof applications based on the BLS curve.

EIP-2935: Save historical block hashes in state

Allows developers/nodes to read past block hashes directly from system contract storage.

To prove the contents of a past block—for example, in an Optimistic Rollup fraud challenge requiring proof that a transaction existed in block 9000 (1,000 blocks prior)—a challenger cannot simply assert its existence. Instead, they must ​sequentially verify the chain backward, one block at a time, from the latest block (e.g., block 10,000) to the target block (block 9000).

​Example:

1. Start with block 10,000’s hash.
2. Prove block 10,000 links to its parent block 9,999.
3. Repeat this process backward until reaching block 9,000.
4. Finally, prove transaction X exists in block 9,000’s content.

△ Every block points to a parent block, allowing proof of any block in history by following the chain backward. source

Post-EIP-2935 Improvements

The system contract (deployed at 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) maintains a rolling window of the ​most recent 8,192 block hashes in its storage. Here’s how it works:

​Automatic Updates: When a new block is added (e.g., block N), the system contract overwrites the ​oldest stored hash (from block N-8192) with the hash of the ​newly added block (N).

This creates a circular buffer where only the latest 8,192 block hashes are retained.

​Fraud Proof Optimization

​Case 1: Proving a Block Within 8,192 History

To prove the hash of block 9,000 (1,000 blocks before block 10,000):

​Direct Reference: Since block 9,000 is within the 8,192-block window of block 10,000, its hash is stored in the system contract’s storage at the state of block 10,000. The challenger can directly reference the storage slot corresponding to block 9,000 to retrieve its hash.

​Case 2: Proving a Block Beyond 8,192 History

To prove the hash of block 1,000 (9,000 blocks before block 10,000):

Step 1: Find the Closest Stored Hash

Calculate the oldest block hash stored at block 10,000: 10,000 - 8,192 = 1,808. The system contract at block 10,000 stores hashes from block 1,808 to block 10,000.

​Step 2: Prove Block 1,808’s Hash

Verify the hash of block 1,808 using the system contract’s storage at block 10,000.

Step 3: Prove Block 1,000’s Hash

Since block 1,000’s hash is stored in the system contract’s storage at block 1,808. Retrieve block 1,000’s hash directly from this storage.

​Stateless Client Support

This paves the way for ​stateless clients:

• Light nodes no longer need to store all historical block headers.
• When historical data is required, proofs can be requested on-demand using the fraud-proof mechanism described above.

EIP-7623: Increasing calldata cost

​EIP-7623: Raising Calldata Costs to Enable Safer Increases in Block Gas Limits and Blob Capacity

​Background

With the increasing demand for data publication by Rollups, ​EIP-4844 introduced blobs, enabling Rollups to publish data at significantly lower costs. Since then, the Ethereum community has advocated for ​increasing blob counts and ​raising block gas limits to accommodate higher throughput.

However, these upgrades risk amplifying network strain and spam attack efficiency unless data publication costs are adjusted.

△ An increasing number of validators are expressing support for raising the Block Gas Limit.  source

EIP-7623 increases calldata costs by 2.5x to mitigate risks while enabling scalability improvements:

• ​Original Calldata Pricing:
  • Zero byte: ​4 gas
  • Non-zero byte: ​16 gas
• ​Post-EIP-7623 Pricing:
  • Zero byte: ​10 gas
  • Non-zero byte: ​40 gas

​Impact on Attack Efficiency:

• ​Pre-EIP-7623:
  • A block filled entirely with non-zero calldata:
    • At ​30M gas limit: 30,000,000 / 16 = 1,875,000 bytes ≈ 1.79 MB.
    • At ​40M gas limit: 40,000,000 / 16 = 2,500,000 bytes ≈ 2.38 MB.
  • Average block size: ~100 KB.

• ​Post-EIP-7623:
  • Attackers’ maximum data capacity drops:
    • At ​30M gas limit: 30,000,000 / 40 = 750,000 bytes ≈ 0.72 MB.
    • At ​40M gas limit: 40,000,000 / 40 = 1,000,000 bytes ≈ 0.95 MB.
  • This reduction in spam efficiency allows safer increases to block gas limits and blob counts.

​Dual Gas Calculation to Protect Regular Users

To avoid unintended impacts on non-data-publishing users, transactions are priced using ​two parallel calculations, with the ​higher value applied:

• ​Legacy Calculation:
  • Calldata priced at original rates (4 gas/zero byte, 16 gas/non-zero byte) + execution/deployment gas.
• ​New Calculation:
  • Calldata priced at new rates (10 gas/zero byte, 40 gas/non-zero byte), ​excluding execution/deployment gas.

​Why Regular Users Are Unaffected:

• For typical transactions (e.g., token swaps), most gas is consumed by ​execution logic (e.g., contract interactions), not calldata.
• The new calldata costs (even at 2.5x) rarely exceed execution costs under the dual calculation, leaving regular users unaffected.

The ​most affected will be ​small-scale Rollups. Since blobs have ​fixed sizes and costs, they are inefficient for small data batches, making calldata a more cost-effective option for these Rollups. However, after EIP-7623, calldata costs will increase by ​2.5x, significantly raising expenses for small Rollups. As a result, they may need to:

• ​Switch to blobs despite their inefficiency for small data.

• ​Collaborate with others to share a single blob and split the costs.

EIP-7691: Blob throughput increase

Increases the number of Blobs, providing more data publishing capacity for Rollups.

EIP-7691 raises the Blob count from "Target: 3 Blobs, Maximum: 6 Blobs" to "Target: 6 Blobs, Maximum: 9 Blobs", expanding the available space for Rollup data publication.

Note: There are still some design adjustments needed for the Blob fee market, such as improving the speed of fee adjustments and raising the minimum fee, but these issues are not within the scope of this EIP.

Miscellaneous EIP

EIP-7549: Move committee index outside Attestation

Adjusts validator voting content for easier aggregation and reduced p2p network pressure.

​Current Mechanism:

• Validators are randomly assigned to ​committees each epoch and vote on blocks.
• Votes within the same committee can be ​aggregated, reducing the volume of data transmitted over the p2p network.

However, each vote includes the ​committee index (i.e., which committee the validator belongs to), preventing aggregation of votes from ​different committees—even if they vote on the same block.

​Improvements:

• The ​committee index is moved outside the attestation content.
• Votes from different committees can now be ​aggregated if they share the same content (e.g., voting for the same block).
• This further reduces the volume of attestation data transmitted over the p2p network, alleviating network pressure.

EIP-7840: Add blob schedule to EL config files

Simplifies blob parameter access for EL nodes by creating a dedicated configuration file.

​Current Limitations:

• Blob-related parameters are stored in ​CL nodes.
• EL nodes occasionally need these parameters (e.g., for eth_feeHistory RPC calls), requiring them to query CL nodes.

​Improvements:

• A ​configuration file for blob-related parameters is added to the EL layer.
• EL nodes can now directly access these parameters from the config file, eliminating the need to query CL nodes.

Related Readings:

• https://pectra.wtf
• https://x.com/binji_x/status/1874422557992263720
• https://www.galaxy.com/insights/research/pectra-upgrade-and-other-eth-catalysts/
• https://gaslimit.pics/
• https://x.com/spire_labs/status/1881445292815597913