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.
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.
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.
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 
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
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.
@shamatar tagged it already, I think it should be good to go now 
Yep, it shows in the list now
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.
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.
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.
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.
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).
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.
What is the reason for such an important update like EIP-2537 to be mentioned so little?
Cross-posting an update/proposal I shared today in the R&D discord:
