Shanghai Core EIP Consideration

[timbeiko]

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.