From Chainsafe by Phil Ngo

With the implementation of Deneb/Cancun almost complete, client teams were asked to provide suggestions on inclusions to the next Electra/Cancun hard fork. This blog post is to outline the combined consensus of Lodestar’s main contributors, inspired by the writings of Paradigm’s Reth team and commendation of this method at AllCoreDevs Execution Meeting 179.

TL;DR

The client teams of Ethereum have generally agreed on AllCoreDevs Execution Meeting 179 to utilize the momentum of shipping upgrades to include a smaller fork during 2024 before the delivery of Verkle tries (a big effort estimated for 2025) on mainnet. There are parallel workflows that other teams can concurrently work on. For consensus clients like Lodestar, it makes sense to advocate for the inclusion of the following EIPs:

Supportive Consensus EIPs for Electra Inclusion

These are the following Ethereum Improvement Proposals (EIPs) we believe should be included for Electra:

EIP-6110: Supply validator deposits on chain

The proposal aims to append validator deposits to the Execution Layer block structure. This change would shift the responsibility of deposit inclusion and validation to the Execution Layer, thereby eliminating the need for deposit (or eth1data) voting from the Consensus Layer. The list of validator deposits in a block would be obtained by parsing deposit contract log events emitted by each deposit transaction included in a given block.

The inclusion will increase security for deposits, reduce the delay between deposit submission and processing, eliminate dependencies on JSON-RPC API data polling, and reduce complexity between the execution and consensus clients.

EIP-7002: Execution layer triggerable exits

EIP-7002 proposes adding a new stateful precompile that allows validators to trigger exits to the beacon chain using their execution layer (0x01) withdrawal credentials. This mechanism enables these new execution layer exit messages to be appended to the execution layer block for reading by the consensus layer.

Including this EIP will allow for better control of validators with improved security in custody arrangements. This EIP is especially useful for liquid staking operators and smart contract-controlled validators, reducing trusted, centralized management. In addition to simplifying the process of exiting validators, a validator who loses access to their active key can still use their withdrawal credentials to exit and recover their funds. The massive UX improvements for stakers (pooled and solo) justify this inclusion.

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

EIP-7251 suggests raising the MAX_EFFECTIVE_BALANCE to reduce the validator set size, thereby decreasing the number of P2P messages, BLS signature aggregations, and the BeaconState memory footprint. This change benefits small and large validators, allowing for more flexible staking increments and compounding rewards.

Although discussions are still happening and optimizations are being made to the specification, it is important to get the most up-to-date information to make an informed decision on whether it is in a ready state for inclusion. We believe this EIP is crucial to ensuring maximum decentralization, optimizations in network bandwidth, and computational overhead for nodes as the “Big Boy” (pre-Holesky) testnet of over 2.1M validators determined that there is a theoretical ceiling to the validator state.

EIP-7549: Move committee index outside Attestation

The main objective of EIP-7549 is to move the committee index field outside of the signed Attestation message. This change aims to allow the aggregation of equal consensus votes, thereby making the verification of consensus rules more efficient.

The simplicity of this implementation and optimizing the attestation process justify including it for the performance of the Beacon Chain.

EIP-7594: PeerDAS

PeerDAS aims to leverage well-known, battle-tested p2p components already in production in Ethereum to scale data availability beyond what EIP-4844 offers while keeping the workload for honest nodes similar to that in EIP-4844 (downloading less than 1MB per slot).

We believe that this proposal will potentially be the largest implementation effort of the next hard fork for Consensus. Dataspace is likely one of the most important commodities in a blockchain. The benefits from increased scalability will justify the work. By re-using reliable components, we can more easily implement this feature alongside maintaining a manageable workload for individual nodes of all sizes.

SSZification

This section comprises the following EIPs for full completion:

We support the consistency of SSZ data structures and would like to continue transitioning towards SSZing these structures, even if slowly. Efficient Merkle Proofs will help further enable light nodes/clients and bring more optimizations in data storage, network transmissions, and code complexity. We would propose supporting StableContainer and migrating BeaconBlockBody and ExecutionPayload first, as those structures are more likely to be modified through each hard fork.

Supportive Execution EIP for Cancun Inclusion

Although the EIP listed below is generally considered to be an Execution change, Lodestar would like to signal support for this EIP for Cancun inclusion, with input from other execution client teams:

EIP-3074: AUTH and AUTHCALL opcodes

EIP-3074 is designed to allow EOAs to delegate control to a contract, effectively enabling them to act like smart contract wallets without deploying a contract. This delegation is achieved using two new opcodes, AUTH and AUTHCALL.

We support the inclusion of this EIP or some flavour of it to enhance user interactions with Ethereum. As presented at Execution Layer Meeting 179 by f00bar, the inclusion is essential for the continued growth of the Ethereum ecosystem.