I would like to re-propose EIP-3074: AUTH and AUTHCALL opcodes
3 Likes
Earlier, Meta EIP used to list proposals considered for an upgrade. “CFI” was created to fill the gap and provide visibility on the list of proposals under consideration for an upgrade where devs are preparing for multiple upgrades in parallel.
With “Upgrade Meta Thread” and the “Meta EIP” for an upgrade getting back in, I do have places to look for EIPs list rather than depending on “CFIs”.
To keep the EIP status harmonized across layers, type & categories. I’d support removing “CFI”.
For Core EIPs we can have standard statuses as explained in EIP-1 with a high-level understanding of when to change the status as below:
Draft = 1st PR
Review = Whenever ready for clients’ review/implementation/devnet
Last Call = When moved to 1st Public Testnet
Final = When deployed on the Mainnet
1 Like
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.
2 Likes
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:
- JSON-RPC is no longer used to query deposit contract logs
- no constant load on an EL client induced by CL today
- no pain for node operators, EL and CL client devs in resolving issues with deposit log querying
- Eth1Data voting is no longer the case
- no design flaw undermining security of the core protocol (fixes consensus-specs#1632)
- no potential bugs in Eth1 bridge implementations in CL clients leading to liveness issues on the mainnet
- no need for entire history of deposits and deposit contract snapshots to bootstrap CL
- Instant deposit processing, no need to wait for ~12 hours to see your deposit is processed by CL
13 Likes
1 Like
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.
7 Likes
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 
8 Likes
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.
3 Likes
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.
6 Likes
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.
1 Like
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…
5 Likes
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.
6 Likes
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.
4 Likes
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.
2 Likes
EIP-5920: PAY opcode, it was punted on for cancun because of potential complexity but otherwise was considered “good-to-have” in the EVM
2 Likes
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
3 Likes
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
2 Likes
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.
1 Like
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.
2 Likes