Title: Shanghai_Core_EIP_Consideration
Category: Magicians

Author: timbeiko
Date: 2022-09-09T15:10:31.123Z

Note: edited after discussing on AllCoreDevs 147 to reflect consensus amongst client teams.
After The Merge, we will have a 5 week period from Sept 23 to Oct 27 without any AllCoreDevs or Consensus Layer calls. Despite not having formal weekly check-ins, it would be good to keep making progress on planning the Shanghai network upgrade. Here is a proposal for how to organize this in a more asynchronous way.


EIP Champions use the shanghai-candidate topic to signal they’d like to be considered for the upgrade. Either by creating a new discussion thread, like this, or adding the label to an existing discussion-to link, like this. This will allow people to quickly see which EIPs want to be proposed. Notify anyone who has signalled on Github that they want their EIP considered to add this tag.


During this period, client teams, researchers and EIP champions are encouraged to use the tagged Ethereum Magicians thread as the main place to discuss the technical details of proposals.


For EIPs which require more synchronous discussions, organize breakout rooms which are advertised on the EIP’s EthMagicians thread, ethereum/pm and the R&D discord.


On Thursdays 14:00 UTC, have optional #party-lounge sessions in the R&D discord to discuss EIPs, general planning, etc. Unlike ACD/CL calls, there is no expectation that all client teams would be present or that the scope of the upgrade would be decided in these, but they should be useful for general context sharing.


It is worth noting that the goal of this month is to move forward the technical specifications of the EIPs and for client teams to familiarize themselves with them, not to update/change the scope of the Shanghai upgrade. Discussions about this will resume on the next AllCoreDevs call, scheduled for Oct 27th.
For reference, the list of EIPs currently Considered for Inclusion in the Shanghai upgrade can be found here:

EIPs Considered for Inclusion
Specifies changes potentially included in the Network Upgrade, pending successful deployment on Client Integration Testnets.

EIP-3540: EVM Object Format (EOF) v1
EIP-3651: Warm COINBASE
EIP-3670: EOF - Code Validation
EIP-3855: PUSH0 instruction
EIP-3860: Limit and meter initcode
EIP-4895: Beacon chain push withdrawals as operations

Author: MicahZoltu
Date: 2022-09-09T15:29:17.405Z

I would also like to see a Discord channel where we can have more fluid discussions around Shanghai planning.

Author: gcolvin
Date: 2022-09-09T16:06:26.483Z

timbeiko:


Use the Ethereum Magicians thread as the main place for client teams & EIP champions to discuss the technical details of proposals.
q=is%3Aissue+breakout) and the R&D discord.



You mean the Discussions-to thread for each EIP?

Author: matt
Date: 2022-09-09T16:57:58.151Z

Proposal to include EIP-3074: Shanghai-candidate: EIP-3074

Author: axic
Date: 2022-09-09T17:16:43.477Z

Added Topics tagged shanghai-candidate to a bunch of Ipsilon-driven proposals.

Author: timbeiko
Date: 2022-09-09T17:28:50.123Z

gcolvin:

You mean the Discussions-to thread for each EIP?


I’m fine with either adding the topic to the existing threads, like @axic just did, or creating a new one if the EIP champion judges that to be better, like @matt did. The important thing, I think, is for all of the candidates to show up here.

Author: ralexstokes
Date: 2022-09-09T18:07:14.213Z

I think this plan makes a lot of sense and I’d support moving ahead with it.
Added shanghai-candidate tag to EIP-4895 discussion: EIP-4895: Beacon chain withdrawals as system-level operations
withdrawals are a must for shanghai

Author: gcolvin
Date: 2022-09-09T20:27:41.128Z

So, can add tag to things to here:  Topics tagged shanghai-candidate.

Author: tvanepps
Date: 2022-09-09T21:06:33.138Z

can’t we just use #allcoredevs ?

Author: ajsutton
Date: 2022-09-10T01:07:48.723Z

Definitely keen to give this a try and evaluate how it worked. More than just being able to make progress in the Devcon period, it is potentially a good step towards making more ACD discussions async. More async means more time zone, family and work schedule friendly while also creating a better record of the discussion.

Author: gcolvin
Date: 2022-09-10T02:25:52.288Z

after the dust settles

Author: gcolvin
Date: 2022-09-10T02:49:49.732Z

They don’t all show up at https://ethereum-magicians.org/tags/c/eips/core-eips/35/shanghai-candidate.  Try https://ethereum-magicians.org/tag/shanghai-candidate.

Author: MicahZoltu
Date: 2022-09-10T05:42:58.463Z

tvanepps:

can’t we just use #allcoredevs ?


I find #allcoredevs to be a good place to ask general protocol questions and get a relatively quick answer.  I am a bit loath to fill that channel with Shanghai planning discussion which I suspect will be a bit voluminous, and potential drown out other protocol questions people have.

Author: gcolvin
Date: 2022-09-10T06:06:50.591Z

Actually, everything except Beacon Chain Withdrawals is an EVM proposal, for which we already have a channel:  Discord

Author: timbeiko
Date: 2022-09-13T00:13:04.567Z

Thanks - updated in the first post of this thread!

Author: timbeiko
Date: 2022-09-13T00:14:14.172Z

MicahZoltu:

I find #allcoredevs to be a good place to ask general protocol questions and get a relatively quick answer. I am a bit loath to fill that channel with Shanghai planning discussion which I suspect will be a bit voluminous, and potential drown out other protocol questions people have.


I’m potentially in favour of this, but I want to make sure it’s something that client teams find valuable and start with what their needs are vs. something that’s first for everyone else and becomes a drag for client teams to keep up with

Author: ajsutton
Date: 2022-09-13T00:38:16.304Z

Personally I would have thought #allcoredevs was where discussions like what goes into the next hard fork belong (ie stuff that would be discussed on an ACD call) and if we need to we’d split out a different channel for asking protocol questions. The challenge is that as part of doing core dev work there’s a need to understand the protocol and asking in #allcoredevs is good for that, but a general “learn about the Ethereum protocol” is not something core devs will be able to keep up with.
A #protocol-questions type channel is likely to become general community support quite quickly and just be too hard to keep up with. Discord just isn’t the way to scale that kind of learning - it needs something more persistent like blogs, talks etc.

Author: timbeiko
Date: 2022-09-14T14:31:21.609Z

I think we’re maybe misunderstanding each other  My rationale for splitting up the channel wasn’t to have somewhere the community can ask protocol questions, but a separate place where we can discuss the “project management” aspect of Shanghai. I’m fine if that’s #allcoredevs, but given that these conversations tend to have high volume, keeping that channel less active might be good.
That said, the risk of another channel dedicated to project management which is open to everyone is that it becomes even higher volume, client teams ignore it, and it’s worse than useless because it’s a productivity drag and paints a picture which doesn’t line up with whaat client teams actually want…!

Author: timbeiko
Date: 2022-09-19T15:39:32.143Z

Re: #shanghai-planning, we agreed to not have it until the ACD calls resume on October 27th, this way people don’t feel they need to monitor a new channel or risk missing changes to the upgrade. We can discuss whether to add the channel on the next ACD.

Author: mcdee
Date: 2022-09-19T16:23:31.391Z

@ralexstokes is EIP-4788 in scope for Shanghai?

Author: ralexstokes
Date: 2022-09-19T16:37:16.392Z

Not at the moment. It was introduced to support “pull” style withdrawals and we have generally agreed to go the “push” route for handling withdrawals from the CL.
Separately, it would unlock a lot of use cases for staking pools, etc. so I’d love to see some version of this EIP land on-chain eventually. I’d also support inclusion into Shanghai but I’d want to hear more demand in the context of the other priorities before putting more time into moving it along myself.

Author: mcdee
Date: 2022-09-19T16:51:47.618Z

Having this available would allow for generic proofs against the beacon node state, which would remove a trust requirement from staking pools (currently fulfilled with oracles) but also allow for individual validators to prove their value.  This could reduce some of the benefit that the current liquid staking has over solo stakers, which seems like a good reason to push for it.

Author: ralexstokes
Date: 2022-09-19T17:03:46.920Z

yeah I fully agree and think there are many use cases unlocked by this EIP.
I’m happy to bring it up on the next ACDs to get a temperature sense for something like.
Perhaps it would not be a huge reach to include alongside the current CFI set
edit: I added the shanghai tag for EIP-4788

Author: QEDK
Date: 2022-09-19T18:59:04.263Z

Is EIP-2537: Precompile for BLS12-381 curve operations not being considered for the Shanghai upgrade?

Author: MicahZoltu
Date: 2022-09-20T03:48:13.018Z

Tell the author of EIP-2537 (BLS12 precompile) discussion thread to add the shanghai-candidate tag to it.

Author: torchhorse
Date: 2022-09-20T20:25:34.242Z

Preface: If a new discussion thread is required linked to here, then please allow time for this to be dissected, but we have concerns as it relates to censorship for the community in general on centralized platforms (hardware machines, web2 platforms, & Sillicon Valley OS’s)
This was brought to our attention by a trusted source with whomst was not be able to have a voice in the conversation, displayed here by a discord UI rug, not uncommon as security of mod ownership and keys can be a concern.

I’m curious to know if there is a reason for the Shanghai fork to occur after Devcon? What was the original thought pattern and possible implications? Apologies here, but new to EIP conversations, I understand moderating can be difficult to accomodate the dialect of multiple sides.

With stake held in centralized exchanges, it seems that providing a voice to partial exits via being able to spend resources on experiences with the relationships they build, to be the purest thing the community has earned for awaiting (although flawless) for the merge to go through.
Is an extra hand required to apply punctuated turning of not only spending application for how communities ‘use’ ones city, while also helping to solve the problem of centralized staking, folks at matter.direct are available.
e.g. it’s good to know, you can rent a car for $100 for 2-3 days, combining with a whl dial, many memories can be formed to for faith reignition if paths are lost.

Contact ~milbyt-moszod (morgan)

https://i.ibb.co/8MwS5KL/Screen-Shot-2022-09-15-at-9-55-46-AM.png, in reference to this link, Shanghai Core EIP Consideration - #14 by gcolvin
For our Judgement: Can we rise to be beyond Discord? Alternatives like Urbit (reasoned through our own tests with the Matter.direct community, a sub-culture of r/NFT, especially after having a community of 60k+ people hacked)
Timing: We think moving slow is important. While rest in this marathon is a good idea, because at the end of the day folks have an obligation to their own personal needs, scheduling the fork (or subset) during devcon might be a good idea. Here as a test of culture, especially geopolitically.
Plutocracy: As key-strokes become information for stakes, & VCs accumulate asymmetric value as a front-runned members bank on Ethereum movements from conversation. This doesn’t align with what we hope to be as a people ‘first’ chain, especially with POS. most of the grife with Ethereum from bitcoin community etc. was early ‘founders’ banked. Might prevent a plutocracy.
For the purpose of onboarding and managing intention: The use of acronyms for new joiners (which is what we expect post merge, with institutions with ESG motivations reducing 0.2% of climate impact) will most likely slow down onboarding. Maybe discourse can use an index of some sort for clearer communication.
Separating Project Management with Protocol conversation: We believe that project management & protocol conversation should be incorporated. depending on platform, dropdown of threads can be used to the advantage. if current platforms do no accommodate, then are alternatives open for conversation?
As a note, some links that stood out during our research, while not exclusive we can dig in more if need be if the arguments are not there:


EIP1153 - case of reentrancy locks, working on ‘till’ contracts which have the feeling of counterfactual, which played out in the real world could have larger impact on getting to a clearer market view


EIP3047 - Removing WETH9? Alternative recommendations, like: preventing weth overload, maybe some folks require a clearer intention with the goals of each EIP? NFT art etc. Might be a disaster for alts, but naming convention clarity might be noice.


EIP2315: relative jump as a philosophy to enable consensus builders to be shepparded into philosophical designs for stronger protocols when placed in context, with also a new OTA of subjective oriented programming becoming a greater standardized, why? As ethereum expands the scope of the weird (Link: EIP-2315 Simple Subroutines for the EVM)


Request: Proposing a breakup (in alignment with this: More frequent, smaller hardforks vs. less frequent, larger ones - #21 by lrettig) of the EIP to allow for a multiple timely releases (call them shanghai-VN-< smaller-city >) of centralized staked funds for those that have / had <32ETH while staking affecting certain exchanges like Kraken. There are mouths to feed & portals to unfold.

Author: timbeiko
Date: 2022-09-20T22:08:48.550Z

MicahZoltu:

Tell the author of EIP-2537 (BLS12 precompile) discussion thread  to add the shanghai-candidate tag to it.


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

Author: timbeiko
Date: 2022-09-20T22:18:01.809Z

Thanks for your comment!



 torchhorse:

I’m curious to know if there is a reason for the Shanghai fork to occur after Devcon? What was the original thought pattern and possible implications?


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.



 torchhorse:


With stake held in centralized exchanges, it seems that providing a voice to partial exits via being able to spend resources on experiences with the relationships they build, to be the purest thing the community has earned for awaiting (although flawless) for the merge to go through.



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.



 torchhorse:

For our Judgement: Can we rise to be beyond Discord? Alternatives like Urbit (reasoned through our own tests with the Matter.direct community, a sub-culture of r/NFT, especially after having a community of 60k+ people hacked)


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 



 torchhorse:

Timing: We think moving slow is important. While rest in this marathon is a good idea, because at the end of the day folks have an obligation to their own personal needs, scheduling the fork (or subset) during devcon might be a good idea. Here as a test of culture, especially geopolitically.


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.



 torchhorse:

For the purpose of onboarding and managing intention: The use of acronyms for new joiners (which is what we expect post merge, with institutions with ESG motivations reducing 0.2% of climate impact) will most likely slow down onboarding. Maybe discourse can use an index of some sort for clearer communication.


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 



 torchhorse:

Separating Project Management with Protocol conversation: We believe that project management & protocol conversation should be incorporated. depending on platform, dropdown of threads can be used to the advantage. if current platforms do no accommodate, then are alternatives open for conversation?


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



 torchhorse:

Request: Proposing a breakup (in alignment with this: More frequent, smaller hardforks vs. less frequent, larger ones - #21 by lrettig ) of the EIP to allow for a multiple timely releases (call them shanghai-VN-< smaller-city >) of centralized staked funds for those that have / had <32ETH while staking affecting certain exchanges like Kraken. There are mouths to feed & portals to unfold.


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.

Author: QEDK
Date: 2022-09-22T13:12:07.606Z

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

Author: timbeiko
Date: 2022-09-22T15:54:38.538Z

Yep, it shows in the list now

Author: langers
Date: 2022-09-25T21:28:15.363Z

mcdee:

Having this available would allow for generic proofs against the beacon node state, which would remove a trust requirement from staking pools (currently fulfilled with oracles)


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.

Author: MariusVanDerWijden
Date: 2022-09-26T08:27:04.366Z

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.


Ethereum Improvement Proposals


EIP-4758: Deactivate SELFDESTRUCT
Deactivate SELFDESTRUCT by changing it to SENDALL, which does recover all funds to the caller but does not delete any code or storage.

Author: MicahZoltu
Date: 2022-09-26T11:20:14.142Z

MariusVanDerWijden:

I would like to propose EIP-4758 for inclusion into Shanghai.


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

Author: langers
Date: 2022-09-27T06:47:41.226Z

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.

Author: wjmelements
Date: 2022-10-14T19:54:17.300Z

MariusVanDerWijden:

It’s very easy to implement and not hard to test, so I would love to see it in Shanghai.


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.



 MariusVanDerWijden:

This EIP is a prerequisite to Verkle


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.

Author: kelly
Date: 2022-10-19T04:17:21.906Z

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.

Author: MicahZoltu
Date: 2022-10-19T11:44:09.326Z

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).

Author: Philogy
Date: 2022-10-19T18:44:34.269Z

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.

Author: OrientusPrime
Date: 2022-10-19T19:38:09.279Z

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

Author: timbeiko
Date: 2022-10-19T20:01:19.902Z

Cross-posting an update/proposal I shared today in the R&D discord:
Screenshot 2022-10-19 at 12.59.17 PM1596×1214 221 KB

Author: axic
Date: 2022-11-24T14:06:22.146Z

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

Author: Pandapip1
Date: 2023-01-05T14:09:33.665Z

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


Ethereum Improvement Proposals


EIP-5920: PAY opcode
Introduces a new opcode, PAY, to send ether to an address without calling any of its functions





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.

Author: timbeiko
Date: 2023-01-05T17:06:14.765Z

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

Author: Pandapip1
Date: 2023-01-05T18:38:53.491Z

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

Author: Pandapip1
Date: 2023-01-05T21:26:37.382Z

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

Author: shantaraam
Date: 2023-02-23T15:27:47.519Z

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

Author: timbeiko
Date: 2023-02-23T15:58:20.359Z

The balance of the deposit contract is unchanged.