Ethereum Pectra upgrade follows testnet recovery and Sepolia updates

The testnet recovery and client issues

The Holesky testnet recovered finality on March 10, 2025, at 19:21 UTC at epoch 119090. This follows the February 24, 2025, incident where Pectra activation on Holesky caused instability. A misconfiguration in Geth, Nethermind, and Besu clients used incorrect deposit contract addresses. The correct address for Holesky is 0x4242424242424242424242424242424242424242. Because some clients used the mainnet address or an empty address, they processed deposit transactions with an empty requests list. This caused a network split. Erigon and Reth rejected the invalid blocks, but Geth, Nethermind, and Besu accepted them. The incident caused a drop in finalization rates and a rise in transaction validation errors. Developers postponed the mainnet release because of this. The Sepolia testnet also saw an issue on March 5, 2025, at epoch 222464. A custom deposit contract on Sepolia blocked execution clients from processing transactions for several hours. Client teams released updates for Geth (v1.15.3), Nethermind (v1.31.2), and Besu (25.2.1) to fix these issues. I find the speed at which the Sepolia issue resolved itself impressive. The Holesky incident showed that misconfigured execution layer clients like Geth, Nethermind, and Besu could cause a network split by accepting invalid blocks that other clients like Erigon and Reth rejected, which forced a coordinated validator slashing event to restore network integrity. PandaOps initiated a coordination effort that succeeded on the evening of March 10. Blockdaemon ran 2,500 validator keys to maintain stability during these network conditions. The initial attempt to coordinate mass slashing at slot 3737760 failed because slashing and coordination did not reach the 66% threshold.

Account abstraction and user experience

EIP-7702 introduces account abstraction for Externally Owned Accounts (EOAs) by letting these accounts act as smart contracts for a single transaction. This change allows transaction batching where users execute multiple operations in one transaction, such as an approval and a swap. Gas sponsorship is another part of this update where third parties pay transaction fees for a user. This helps people who do not hold ETH. Alternative authentication uses passkeys or hardware security modules to authorize operations. Spending controls allow users to limit how many tokens an application uses or set daily outflow caps. Recovery mechanisms provide new ways to safeguard assets without moving to a new account. You can use these tools to make your wallet function more like a smart contract. EIP-7702 uses a signature from the EOA that points to a specific delegation address. This delegation is only valid on a specific chain ID. The authorization is also nonce-bound, which means it invalidates once the nonce increases. The EOA owner can always create a new authorization to revoke or replace the existing delegation code. EIP-2935 allows smart contracts to access historical block hashes in persistent state. This assists smart contracts that rely on older block references for randomness or delayed proofs. EIP-2537 introduces precompiles for BLS12-381 curve operations to help with multi-party computation. This change simplifies the complexity of wallets using account abstraction.

Validator updates and staking efficiency

EIP-7251 increases the maximum effective balance for validators from 32 ETH to 2048 ETH. This lets validators compound rewards automatically. It also lets large operators consolidate multiple validators. Consolidation reduces the total number of validators and the attestation traffic on the network. However, this consolidation might increase centralization risks. EIP-7002 allows for execution layer triggerable withdrawals. This means a validator can initiate an exit or withdrawal using their withdrawal credentials. This reduces reliance on active keys, which are hot keys and can have security vulnerabilities. EIP-6110 moves validator deposit processing to the execution layer. This reduces the time for deposit processing from 9 hours to 13 minutes. EIP-6110 removes the delay between validator deposits and their addition to the deposit queue. Before this, the Beacon Chain had to wait 2048 blocks to account for potential proof-of-work re-orgs. EIP-7685 provides a framework for communication between the execution and consensus layers.

EIP-7251 allows validators to earn rewards on their entire stake up to 2048 ETH. Previously, rewards earned beyond 32 ETH did not count toward active stake. This change means both new and existing validators can be configured to earn rewards on their full balance. Larger operators can now designate a target validator to enable compounding from other source validators. EIP-7002 makes staking more flexible. It allows both partial withdrawals and complete exits to be triggered by the withdrawal credentials owner. This helps reduce trust dependencies for stakers who delegate to providers. I find the shift toward execution layer withdrawals a strong improvement for validator autonomy.

Scaling through blob capacity and Verkle trees

EIP-7691 increases Ethereum’s blob capacity. The average number of blobs per block increases from 3 to 6. The maximum number increases from 6 to 9. This helps Layer 2 scaling. Blobs are ephemeral data used by rollups to submit transaction data. Nodes prune blobs after 4096 epochs. EIP-7623 caps the worst-case block size to manage bandwidth. EIP-7742 enhances Layer 2 throughput. This change, along with PeerDAS, helps the network scale. PeerDAS allows nodes to verify transaction data without storing it entirely. Verkle Trees change how Ethereum manages state data. This new structure combines vector commitments and Merkle Trees. It reduces storage requirements and improves transaction processing. Unlike CALLDATA, which nodes store indefinitely, blobs are pruned from the network after 4096 epochs. This bounds the disk space blobs use. EIP-7623 introduces a cap on the worst-case size of a block to offset the bandwidth increase caused by EIP-7691. Will the increase in blob capacity lower L2 fees enough to offset the bandwidth needs of the network?