This isn’t great, as both of these are somewhat hard to find, each of them uses a separate “format” and it results in duplication. With ERC and EIPs now separate, I suggest (going back to) using Meta EIPs to track EIPs included in network upgrades.
For coupled upgrades, the EL + CL could share a single Meta EIP, and for de-coupled upgrades, they could each have their own. If an upgrade goes from coupled to de-coupled or vice-versa, we can simply create a new Meta EIP which superceeds the previous one.
Lastly, as a “stretch goal”, we should agree on what to do with “Considered for Inclusion”. This “proto-status” was created to provide more legibility to EIP champions about which EIPs may be included in an upgrade. That said, it can be argued the lack of commitment associated with CFI causes more confusion than it removes. Additionally, CFI is only used on the execution layer.
If it isn’t useful, we should consider modifying or removing it, or potentially harmonizing its definition and usage across both the EL & CL processes.
There may be some minor change to the precompiles and gas schedule but this will all be together in time for serious inclusion discussions for Prague/Electra.
AFAIK previous concerns around this EIP have been resolved (e.g. hardened BLS12-381 implementations in production, esp. given that this code is used in EIP-4844 in Cancun/Deneb) and there is plenty of demand from both rollups and cryptography use cases.
One of my top priorities for this hard fork will be championing for inclusion of BLS12-381 precompiles and it seems like prime time
are we talking about the next major HF or the “small” one between Dencun and the former? Because if it’s the next major HF, the complexity of verkle trees won’t leave much room for anything else.
And if it’s a smaller one, I don’t think we should call it Prague, in the hope that we can pull smaller hardforks faster than we can have devcons. Note that we can no longer add devconnect names, as Instanbul already exists as a fork.
I’m personally not really a believer in “small” forks. Historically, the only times we’ve had truly small or quick forks were either emergencies, or simple difficulty bomb pushback. For example, Shanghai was a “small” fork relative to The Merge, and it still shipped 6-7 months after it.
If we are considering any non-trivial EIPs, I’d call this Prague for simplicity. Whether it’s a 6-9 month fork like Shanghai or a 9+ month one like Cancun can only be very roughly predicted based on what EIPs we decide to include.
That said, I agree that we should make a call about whether we include Verkle or not ASAP, as it will dictate how much extra capacity there is for other EIPs.
Right, assuming we didn’t do Verkle, we could choose to only do a set of smaller EIPs, but I just want to make sure we don’t do that thinking “it will be done in 3 months” when it’s likely to take 2x+ longer
At this point the EOF proposals represent some seven years of research and development. They are solid. They are needed. They are really not that difficult to implement. And the researchers and developers are burning out. It’s time to get them into an upgrade.
I believe EIP-7002 is one of the best candidates for inclusion in the next hardfork.
My team and I are working on designing and developing Lido Community Staking Module (CSM). This module is aimed to offer permissionless entry to the Lido on Ethereum validator set. EIP-7002 greatly influences the risk profile of CSM and any other permissionless staking solution. With EIP-7002 in place, CSM will become more attractive for Lido DAO to increase its staking share. Hence, more independent operators will be able to join Ethereum validation.
If EIP-7002 wasn’t included, it’s predictable that protocols trying to build a permissionless validator set (e.g., requiring bonds) would try to rely on joining the set with a pre-signed exit message intent. The message then should be stored and split in a distributed way. However, as the messages will have an infinite expiration time, it would pose a risk of falsely ‘losing’ the pieces or, in contrast, firing up exits spuriously, potentially leading to turbulence or fund losses.
In contrast, if EIP-7002 is implemented, the trust level built into the staking protocols would be reduced, not expanded.
Finally, EL triggerable exits are akin to Account Abstraction direction: getting rid of UX and trust issues with a smart contract that’s where Ethereum is great.
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