EIP-3068: Precompile for BN256 HashToCurve Algorithms would be amazing (and its counterpart for EIP-2537: Precompile for BLS12-381 curve operations, which @ralexstokes already brought up!).
BN254 and a lot of threshold work is really hamstrung without hash_to_curve.
I am proposing EIP-6110: Supply validator deposits on chain for Prague/Electra
This EIP deprecates Eth1 bridge ā a legacy way to deliver validator deposits to the beacon chain. Upsides of the proposed deposit delivery mechanism:
At Rocket Pool, we would like to +1: EIP-7002 - Execution Layer Triggerable Exit
The combination of EIP-4788 and EIP-7002, gives a fantastic design surface for decentralised / trustless staking protocols, providing the foundation for much needed competition in the space.
Iād like to include EIP-7251 for consideration!
See related documents here: eip7251 related work Ā· GitHub
We are working soliciting feedback for the final set of features from key stakeholders 
This lays foundations for a sustainable validator set size for the network as it is today but also is a prerequisite for single slot finally, ePBS and MEV-burn. The current 32 ETH MaxEB is a relic of the old eth2 roadmap and is a barrier in the way of many other proposals.
Also +1 for EIP-7002: Execution layer triggerable exits for the benefit of non-custodial staking services.
The ability for users to exit of their own accord, without action from their staking provider, is critical for staking services to remain non-custodial in the eyes of regulators. Itās possible with VoluntaryExit messages, but itās very awkward and requires exchange of a āsecret messageā between the user and the staking service. With EIP-7002 the entire interaction can take place publicly on-chain.
EIP-7002 would put the last necessary piece in place for simple and elegant non-custodial staking offerings. While complex liquid staking offerings are clearly appealing, I think thereās also space for ultra-simple, non-liquid, delegated staking directly between node operators and ETH holders. They could offer lower fees due to lower overheads and be attractive to whales looking for a āfixed-term depositā rather than high liquidity.
EIP-7377 would go a long way to getting existing users/EOAs into smart contract wallets. I think it is a cost effective and elegant way to enable this transition.
EOA migration as presented is fairly easy to reason about and low complexity to implement. Given the cost/benefit it should be CFI.
I would like to propose EIP-4444, dependent upon shipping EIP-6110.
We are already seeing discussions/disagreements around how clients today are bounding historical state on disk and in sync. Codifying a behavior in an upgrade will help solo-stakers and node operators at a time when we need more client/hardware diversity, not less. Portal Network has also signaled their readiness to serve historical state data. The cherry on top is that its implementation within clients is optional!
If we can tie 6110 together with 4444, some of the EL/CL complexity goes away. 4444 would allow clients to remove code tied to historical block processing. With EOF, there may be more simplicity in overall maintenance of EVM client code. This change also plays nicely with the Verkle transition as it could allow for more room on disk at the time of the transition, but may need to be shipped in advanceā¦
Iād like to propose EIP-7547: Inclusion Lists as a potential Pectra candidate.
This is a screenshot from mevboost.pics showing what percentage of all blocks come from which individual builder:
As you can see, the top 5 builders control about 80% of all blocks. 4 out of 5 of them are already censoring txs. I think itās important to consider addressing this situation in-protocol with something along the lines of Inclusion Lists.
Iād like to +1 EIP-7547: EIP-7547: Inclusion lists && https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7547.md.
Especially with the advent of builder and relay censorship, getting a forced inclusion mechanism enshrined feels super important! See Toniās excellent https://censorship.pics.
I would also like to propose EIP-7212: Precompile for secp256r1 Curve Support
With the movement towards SC wallets and an ERC-4337 enabled future for users on-chain, this precompile rounds out the toolset for creating amazing wallet experiences and enabling embedded wallets. Native integration with Passkeys, iOS and Android secure enclaves and WebAUTHN opens up great UX for users in a future moving away from passwords / private keys anyways.
We are already considering a ton of precomiples for this hard fork though.
EIP-5920: PAY opcode, it was punted on for cancun because of potential complexity but otherwise was considered āgood-to-haveā in the EVM
FYI the PAY opcode and 3074ās AUTH are both currently allocated to the same opcode. PAY currently has the better claim - https://github.com/ethereum/execution-specs/blob/master/lists/evm/pending-opcodes.md
Proposing a Separated Payer Transaction EIP (EIP-7553 Draft)
Hi William,
Regarding the proposed change to the codesize limit, is there already an EIP for that? Having developed workarounds to deal with contract size limitations I can underscore that even a bump to 2**15 but preferably 2**16 would have a huge positive impact for developers.
Thanks
I just read the summary of the last ACDC made on twitter by lightclient (excellent work by the way), and if it is true that focusing on the transition to Verkle Trees blocks everything else for at least 12 months and probably 24, then I propose to make at least 1 if not 2 intermediate forks both to add some much-needed features and above all to get EOF through first, which seems to me technically much simpler to implement.
EIP-7002 is appearing in a lot of comments here, so it feels like a good opportunity to share a deep dive on EIP-7002 I published recently: EIPs For Nerds #2: EIP-7002 (Execution Layer Triggerable Exits). The article is an attempt to aggregate several perspectives on EIP-7002 Iāve come across (e.g., @TheDZhonās āexecution-layer exits are akin to account abstractionā comment inspired an entire section of the article) and provide a holistic overview of the advantages and potential drawbacks of implementing EIP-7002.
All feedback and comments are welcome.
There is some community push for increasing gas limit. As core devs know this has major drawbacks in latency (network and processing) and storage. Current storage cost is mainly in Blocks and Receipts and not in State. So I propose to prioritise EIP-4444 if we want to consider increasing gas limit in the foreseeable future.
I recently published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).
The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activations, deposits, withdrawals, and slashing penalties to enable validator consolidationāwhile preserving the Beacon Chainās existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251ās auto-compounding rewards feature. All comments/feedback are welcome.