# Lodestar Proposals for next Electra/Cancun Fork

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](https://www.paradigm.xyz/2024/01/ethereum-2024) and commendation of this method at [AllCoreDevs Execution Meeting 179](https://youtube.com/live/FhMBatolkOM).

## 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 that 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](https://eips.ethereum.org/EIPS/eip-6110)
- [EIP-7002: Execution layer triggerable exits](https://eips.ethereum.org/EIPS/eip-7002)
- [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251)
- [EIP-7549: Move committee index outside Attestation](https://eips.ethereum.org/EIPS/eip-7549)
- [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105)
- SSZification
- [EIP-7495: SSZ StableContainer](https://eips.ethereum.org/EIPS/eip-7495)
- [EIP-6493: SSZ Transaction Signature Scheme](https://eips.ethereum.org/EIPS/eip-6493)
- [EIP-6404: SSZ Transactions Root](https://eips.ethereum.org/EIPS/eip-6404)
- [EIP-6466: SSZ Receipts Root](https://eips.ethereum.org/EIPS/eip-6466)
- [EIP-6465: SSZ Withdrawals Root](https://eips.ethereum.org/EIPS/eip-6465)
- [EIP-3074: AUTH and AUTHCALL opcodes](https://eips.ethereum.org/EIPS/eip-3074)

## 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](https://eips.ethereum.org/EIPS/eip-6110)

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 delay between deposit submission and processing, eliminate dependencies on JSON-RPC API data polling, and a reduction in the complexity between the execution and consensus clients.

### [EIP-7002: Execution layer triggerable exits](https://eips.ethereum.org/EIPS/eip-7002)

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.

The inclusion of this EIP will allow for better control of validators with improved security in custody arrangements. This is especially useful for liquid staking operators and smart contract controlled validators, reducing trusted, centralized management. In additon to simplifying the process of exiting validators, a validator who loses access to their active key, they 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](https://eips.ethereum.org/EIPS/eip-7251)
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 both small and large validators, allowing for more flexible staking increments and compounding rewards.

Although there are still discussions happening and optimizations being made to the specification, we feel 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](https://eips.ethereum.org/EIPS/eip-7549)

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

We believe the simplicity of this implementation and optimizing the attestation process justify inclusion for performance of the Beacon Chain.

### [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105)

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 of the following EIPs for full competion:
- [EIP-7495: SSZ StableContainer](https://eips.ethereum.org/EIPS/eip-7495)
- [EIP-6493: SSZ Transaction Signature Scheme](https://eips.ethereum.org/EIPS/eip-6493)
- [EIP-6404: SSZ Transactions Root](https://eips.ethereum.org/EIPS/eip-6404)
- [EIP-6466: SSZ Receipts Root](https://eips.ethereum.org/EIPS/eip-6466)
- [EIP-6465: SSZ Withdrawals Root](https://eips.ethereum.org/EIPS/eip-6465)

We are supportive of the consistency of SSZ data structures and would like to see that we continue moving forward in transitioning towards SSZing these structures, even if slowly. Efficient merkle proofs will help to 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 EIPs for Cancun Inclusion
Although some EIPs listed below are generally Execution changes, Lodestar would like to signal support for these EIPs for Cancun inclusion, with input from other execution client teams:

### [EIP-3074: AUTH and AUTHCALL opcodes](https://eips.ethereum.org/EIPS/eip-3074)

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 through the use of two new opcodes, AUTH and AUTHCALL.

We support the inclusion of this EIP, or some flavor of it to enhance user interactions with Ethereum. As presented at [Execution Layer Meeting 179 by f00bar](https://www.youtube.com/live/FhMBatolkOM?si=9qT7ZyGOc8VCEQ2-&t=1882), we believe the inclusion is important for continued growth of the Ethereum ecosystem.