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