Shanghai Core EIP Consideration

FWIW, I’ve left a note on their previous Github Issue signalling a desire to be included in Shanghai. I would tend to assume they still want it considered but haven’t gotten the memo about shanghai-candidate

Thanks for your comment!

The short answer here is that, with devcon weeks away and basically no code written in clients (or a scope for the upgrade yet), it’s not possible to ship Shanghai before.

I think this sentiment regarding withdrawals’ priority is shared pretty broadly in the community, and, so far, it’s looking very likely that withdrawals are included in Shanghai.

We use Discord mostly as a matter of convenience for client devs and researchers, but it’s worth noting that aside from day-to-day conversations, Discord isn’t the “place of record” for network upgrades. This is one of them, so are multiple Github repos, as well as ethresear.ch. Many discord channels are also bridged to Telegram. If anyone prefers to participate on TG, please ping me and I’ll happily add you.

As for using more “web3 native” platforms, like Urbit or, say, radicle.xyz, it’s definitely we consider from time to time, but currently it feels like the feature set offered + friction of migrating doesn’t warrant it. That said, I agree this isn’t a great answer, and this is an area where we could lead by example. Someone showing what a smooth migration + end state could look like could make a big dent here :slight_smile:

Again, it’s basically impossible to write + release the code, and get people to upgrade in a matter of weeks for a non-emergency release.

Agreed! There are a few glossaries already, some of which are open source. If you see something that’s not listed there, it’s great to make an addition to it :slight_smile:

I think we do an OK job of coupling it right now, even though it spans a few places. One initiative we are working on is trying to harmonize the consensus and execution layer processes, see: Core EIPs in an Executable Spec World

After a few years of working directly on upgrades, I don’t think it’s realistic to have “tiny” upgrades. They have a high fixed coordination, testing and distribution costs, so it makes sense to try and bundle things.

1 Like

@shamatar tagged it already, I think it should be good to go now :thinking:

Yep, it shows in the list now :slight_smile:

Hey @ralexstokes, just wanted to add Rocket Pool’s support behind including EIP-4788 in Shanghai. This EIP is particularly important for developing decentralised and trustless staking pools. As @mcdee said, there are ways that pools are working around it using oracles but it introduces a trust element that we are keen to avoid.

1 Like

I would like to propose EIP-4758 for inclusion into Shanghai.
It changes the semantics of the SELFDESTRUCT opcode and turns it into a SENDALL which sends the balance of the contract to a receiver. This EIP is a prerequisite to Verkle (and a bunch of other changes). It’s very easy to implement and not hard to test, so I would love to see it in Shanghai.

4 Likes

Looks like it already is, though perhaps someone did that since you posted the request.

I don’t believe there is a drafted EIP (I would be happy to help draft one) but I would like to throw in for consideration: 0x01 initiated exits

Decentralised / trustless staking pools currently have some risk management that could be completely avoided if the withdrawal credentials were able to initiate an exit. By including this feature, it opens up a wide design space for new decentralised staking pools and strengthens their risk profiles.

I would prefer a bit more notice before my upgradeable contracts are permanently frozen. If this is included in Shanghai, I would want to also include a SETCODE opcode to provide the functionality I need. I’ve supplied more information in my post in that thread, and would prefer to continue the discussion there.

I also don’t understand why Verkle trees require this specific solution. My current understanding of the problem is that SELFDESTRUCT needs to clear storage (a behavior I don’t need). Perhaps a much less destructive solution for that problem would be to put small bounties on such slots: block producers could flag slots in the block payload to increase the gas limit for their block.

1 Like

Hey All! I just wanted to put in EIP-2537 (BLS precompile) as a potential candidate for the Shanghai fork. This precompile was accepted in Berlin but ultimately ended up being delayed for 1559 and then the Merge. Would be great to get a temperature check from the client developers on their status and understand if there are any new concerns.

5 Likes

It appears it is already a Shanghai candidate (see tags at top of discussions-to thread), however the EIP is itself is currently “Stagnant”. To minimize risk of bureaucratic blockage, I recommend one of the authors (such as yourself) submit a PR to move it back to Draft or Review (probably Review if you don’t have any intention of making changes to it at this point).

2 Likes

I am against including this in Shanghai as there are still a few issues I see with the EIP, refer to my comment in the actual EIP thread: EIP-4758: Deactivate selfdestruct - #22 by Philogy. It does not seem ready for inclusion.

1 Like

What is the reason for such an important update like EIP-2537 to be mentioned so little?

1 Like

Cross-posting an update/proposal I shared today in the R&D discord:

Proposal to include EIP-663, which would aid languages like Solidity.

2 Likes

I would like to propose EIP-5920, should it be advanced to Review.

I would also like to propose EIP-6188, EIP-6189, and EIP-6190 as mostly non-breaking SELFDESTRUCT modifications, should they be merged and advanced to Review.

We agreed on today’s ACD to not add anything more to Shanghai and remove EOF from it, so these would have to go fro the next fork, @Pandapip1

Oh well. I’ll remove them from the category.

@timbeiko suggests EIP-6049: Deprecate SELFDESTRUCT be symbolically included.

For EIP-4895: Beacon chain push withdrawals as operations ,
wrt to withdrawals effects of execution layer state, what happens to balance of eth2 deposit contract for withdrawal operations for exited validators? as spec mentions only the balances are incremented for recipient addresses @timbeiko