Shanghai Core EIP Consideration

can’t we just use #allcoredevs ?

1 Like

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.


after the dust settles

They don’t all show up at Try

1 Like

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.

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

Thanks - updated in the first post of this thread!

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 :sweat_smile:

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.

I think we’re maybe misunderstanding each other :sweat_smile: 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…!

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.

@ralexstokes is EIP-4788 in scope for Shanghai?

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.

1 Like

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.

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


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

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

1 Like

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.

  1. 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.
  2. 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 are available.
  3. 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), 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 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.


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 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,, 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