Note: The original text comes from a blog post published by Phil Ngo, compiled and translated by Mars Finance.
As work on the Deneb/Cancun implementation draws to a close, client teams are being asked to propose what the next Electra/Prague hard fork should look like. This blog post will outline the combined consensus of the main Lodestar contributors, inspired by a post from Paradigm’s Reth team, and praise for this approach from AllCoreDevs executive meeting 179.
A brief description
Ethereum’s client teams generally agreed at the 179th AllCoreDevs Executive Meeting to leverage the momentum of the upgrade to conduct a smaller fork during 2024, before mainnet delivery of the Verkle tries (a major effort expected to be completed in 2025). Other teams can also work on parallel workstreams at the same time. For a consensus client like Lodestar, it makes sense to advocate for the inclusion of the following EIPs:
EIP-6110: Provisioning validator deposits on-chain
EIP-7002: Execution layer can trigger exit
EIP-7251: Increase MAX_EFFECTIVE_BALANCE
EIP-7549: Move committee index outside of proofs
EIP-7594： PeerDAS
SSZification
EIP-7495: SSZ stable containers
EIP-6493: SSZ transaction signature scheme
EIP-6404: SSZ Transaction Root
EIP-6466: SSZ Receipt Root
EIP-6465: SSZ Extraction Root
EIP-3074: AUTH and AUTHCALL opcodes
Support for inclusion of Electra’s consensus EIP
Here are the Ethereum Improvement Proposals (EIPs) we think should be included in Electra:
EIP-6110: Provisioning validator deposits on-chain
The proposal aims to attach validator deposits to the execution layer block structure. This change will move the responsibility for deposit inclusion and verification to the execution layer, removing the need for deposit (or eth1data) votes at the consensus layer. The list of validator deposits in a block will be obtained by parsing the deposit contract log events generated by each deposit transaction in a particular block.
Adding this feature will improve the security of deposits, reduce latency between deposit submission and processing, eliminate reliance on JSON-RPC API data polling, and reduce complexity between execution and consensus clients.
EIP-7002: Execution layer can trigger exit
EIP-7002 proposes to add a new stateful precompile that allows validators to trigger a beacon chain exit using their execution layer (0x01) exit credentials. This mechanism appends these new execution layer exit messages to the execution layer block for the consensus layer to read.
The inclusion of this EIP allows for better control over validators and improved security of custodial arrangements. This EIP is particularly useful for liquid staking operators and smart contract controlled validators to reduce trusted central management. In addition to simplifying the exit process for validators, if a validator loses access to their activation key, they can still exit and recover their funds using their exit credentials. The inclusion is justified by the large number of improvements to the user experience (both collectively and individually).
EIP-7251: Increase MAX_EFFECTIVE_BALANCE
EIP-7251 proposes to increase MAX_EFFECTIVE_BALANCE to reduce the size of the validator set, thereby reducing the number of P2P messages, BLS signature aggregation, and BeaconState memory footprint. This change will benefit both small and large validators, allowing for more flexible scaling increments and compounding rewards.
While discussions are ongoing and refinements to the specification are ongoing, it is important to have the latest information available to make an informed decision about what to include in the specification. We believe this EIP is critical to ensuring maximum decentralization and optimizing network bandwidth and node computational overhead, as the "Big Boy" (Holesky) testnet of more than 2.1 million validators has determined that there is a theoretical upper limit on validator state.
EIP-7549: Move committee index out of Attestation message
The main purpose of EIP-7549 is to move the committee index field out of the signed "attestation" message. This change is intended to allow aggregation of identical consensus votes, thereby improving the efficiency of consensus rule verification.
The simplicity of this implementation and the optimization of the verification process justify its inclusion in the beacon chain performance.
EIP-7594： PeerDAS
PeerDAS aims to leverage well-known, battle-tested p2p components already in production on Ethereum to scale data availability beyond that provided by EIP-4844, while keeping the workload for honest nodes similar to EIP-4844 (less than 1MB download per slot).
We believe this proposal could be the largest implementation effort of the next consensus hard fork. Data space is perhaps one of the most important commodities in a blockchain. The benefits of improved scalability will justify this effort. By reusing proven components, we can make this more easily possible while keeping the workload manageable for individual nodes of all sizes.
SSZification
This section includes the following EIPs for full completion:
EIP-7495: SSZ stable containers
EIP-6493: SSZ transaction signature scheme
EIP-6404: SSZ Transaction Root
EIP-6466: SSZ Receipt Root
EIP-6465: SSZ Extraction Root
We support the consistency of SSZ data structures and hope to continue the transition to SSZ-ification, even if it is a slow transition. Efficient Merkle proofs will help further enable light nodes/clients and bring more optimizations in data storage, network transmission, and code complexity. We recommend supporting StableContainer first and migrating BeaconBlockBody and ExecutionPayload, as these structures are more likely to be modified in each hard fork.
Support for Prague's inclusion of execution EIP
While the EIPs listed below are generally considered implementation changes, Lodestar would like to express support for inclusion of Prague's EIPs with input from other implementation client teams:
EIP-3074: AUTH and AUTHCALL opcodes
EIP-3074 aims to allow EOAs to delegate control to contracts, effectively making them act like smart contract wallets without having to deploy the contract. This delegation is achieved through two new opcodes AUTH and AUTHCALL.
We support inclusion of this EIP or some form of it into Ethereum to enhance user interactions with Ethereum. As f00bar presented at the 179th Executive Level meeting, inclusion of this EIP is critical to the continued development of the Ethereum ecosystem.
