With the implementation of Deneb/Cancun almost complete, client teams were asked to provide suggestions on inclusions to the next Electra/Prague 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.
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:
- 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-7594: PeerDAS
- EIP-3074: AUTH and AUTHCALL opcodes
Supportive Consensus EIPs for Electra Inclusion
These are the following Ethereum Improvement Proposals (EIPs) we believe should be included for Electra:
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 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 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.
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.
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.
This section comprises the following EIPs for full completion:
- EIP-7495: SSZ StableContainer
- EIP-6493: SSZ Transaction Signature Scheme
- EIP-6404: SSZ Transactions Root
- EIP-6466: SSZ Receipts Root
- EIP-6465: SSZ Withdrawals Root
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
ExecutionPayload first, as those structures are more likely to be modified through each hard fork.
Supportive Execution EIP for Prague Inclusion
Although the EIP listed below is generally considered to be an Execution change, Lodestar would like to signal support for this EIP for Prague inclusion, with input from other execution client teams:
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,
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.
Contribute to Lodestar! 🌟
To get involved, visit our GitHub repository
Lodestar is built and maintained by ChainSafe, a leading blockchain R&D firm.