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.
3 Likes
I think EIP 7002 (EL-induced exits) deserves a mention. The staking community badly needs a way to trigger exits via smart contracts to finally and fully close the loop on trustless staking protocols.
Some interesting ideas for potentially improving it were tossed around at DevConnect this year, but even if it’s included as-is, Ethereum would be significantly safer.
9 Likes
I think Verkle trees alongside with very few small EIPs (Verkle tree is a big update) such as EIP-2537 is desirable, in alternative we can focus on EOF and many small EIPs
3 Likes
I would divide the discussion into two parts, namely which large EIP (or series of EIPs) to include between Verkle Tree and EOF, and which other ‘small’ EIP to include.
Between Verkle Tree and EOF, a check should be made on the maturity of the project and the opinion of the Core Teams on it.
1 Like
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.
4 Likes
I also feel that including EIP-7002: Execution Layer Triggerable Exits would be a good choice for the network, being crucial not only for liquid staking protocols, and pretty sure not only for Lido.
What I am afraid of is after enabling EIP-7044: Perpetually valid signed voluntary exits in Dencun, there will be a long-term tail risk of storing and distributing the exit messages in staking protocols involving increased trust assumptions.
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.
Thank you for raising this on the topic.
5 Likes
[EDIT]: Not a commentary on the merits of EIP7002.
Lido is currently at 32.28%.
We shouldn’t want any entity to have a share of stake above 33.3% threshold.
2 Likes
Strongly agree with this, but I think the adoption of 7002 is independent of this issue and simply provides a safety benefit for all LSTs. If the recent discussion on adjusting the mechanics pans out, it could even benefit smaller LSTs more heavily.
6 Likes
I was meaning share of CSM within Lido and overall Lido share.
I want to propose EIP-7549: Move committee index outside Attestation
It’s a very simple consensus-only change that reduces the cost of verifying casper FFG by a factor of 64x. As such, it accelerates the viability of ZK trustless bridges on Ethereum.
6 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