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
As an Ethereum validator and user, I’d like to see Verkle trees and anything else that unblocks state expiry and stateless clients prioritized above all else. I prefer a delay in the next hard fork over shipping other EIPs. PeerDAS is also very interesting, as long as it does not interfere with shipping Verkle trees. And increasing the max validator size is great for solo validators as well.
As an EVM developer, I am opposed to EOF. I am not convinced of the value in creating a new version of the EVM while still forever maintaining past versions. Even if it’s an order of magnitude more efficient, unless there is a plan to disable, remove, or (impossibly?) migrate older code, my main concern is the developer overhead for working with multiple versions of the EVM as well as the increased risk of client bugs.
Upgradeability of EOF contracts could limit this to a small number of versions, but older versions will always exist and will also stop receiving improvements, and minor improvements in efficiency of EOF execution will not be sufficient to encourage a large scale migration.
EOF is not a new version EVM. It is a container format around the existing EVM model and a number opcodes to fix several issues related to technical debt: static jumps, code validation, subroutines, removing code introspection, and removing gas introspection. The core model of the EVM remains the same, and Legacy EVM and EOF can freeley call each other with the exact same semantics. Your traces will look mostly the same (new opcodes aside) and the same techniques you use to develop will be the same. To most smart contract developers it will be nothing more than toggling a switch in solidity or vyper, and your code will also be a little smaller once you do.
The biggest immediate advantage that EOF unlocks it the ability to safely uncap or significantly raise the smart contract size limit (but the block gas limit will always be a mainnet cap). Because of JUMPDEST analysis we have to limit the sizes or open the legacy EVM up to significant DOS attacks. Code validation fixes this.
As for the legacy EVM, deprecating it is totally in my roadmap. But first we need to get EOF out and used before we can ramp up discussion about deprecating new deployments and examining ways to migrate legacy EVM code, if such migrations are required. This would start with closing off deployments of new legacy contracts, or possibly making them progressively more expensive. I see this only ocuring at create transactions, factory contracts (like pools) would necessarily remain as-is.
