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.
thanks for writing this Emmanuel! it pulls everything together in a really comprehensive way! 
We at OpenZeppelin are also interested in EIP-7212 since we’re already considering to add a Solidity implementation
Hallo, Paolo from Erigon, We would like to know if there is any opposition in principle to the implementation of EOF by other teams, we believe that EOF is fundamental but we would not like to waste time on a feature that will never be implemented due to the opposition of other development teams. It is not a question of when EOF will be implemented but whether it will ever be implemented.
Following the discussion in the last Execution Layer Meeting (#179), I’d like to discuss EIP-5806. In particular, I’d be open to answerring any questions. I’d also like to have a better understanding of what are the next steps in the development of this EIP.
i’d also like to add reduce transient pricing for common cases by charles-cooper · Pull Request #8158 · ethereum/EIPs · GitHub (draft, benchmarks underway) for consideration
