Thread by @TimBeiko

The first @ethereum #AllCoreDevs of the year just wrapped up 🎊 Updates on The Merge, as well as what Shanghai could look like 👀

https://twitter.com/TimBeiko/status/1469398948171292672

@ethereum First, updates on the Kintsugi 🍵 devnet! There was a lot of testing over the holidays, and @vdWijden managed to break the network again 💥

@ethereum @vdWijden He tweeted about it earlier:

https://twitter.com/vdWijden/status/1479414817551261699

TL;DR: his fuzzer created a block which replaced certain fields by others, and because of caching+validation issues, some clients accepted an invalid block as valid.

@ethereum @vdWijden The issue happened both on the EL, with Besu and Nethermind each forking to a different branch than geth, and on the CL with Teku forking off. The root cause was found in Nethermind and Besu, with a fix already out in Nethermind. Still TBD for Teku 👀

@ethereum @vdWijden This means that Kintsugi hasn't been finalizing for a while (~13 hours, iirc). This will be an interesting exercise in network recovery as we release patched clients and get the network to finalize! Of course, more test cases will also be added to check for these types of issues.

@ethereum @vdWijden In terms of next steps for merge work, there are some minor spec changes in the works. Along with that, progress on Optimistic Sync is going well: it's now spec'ed, with edge cases having been worked through, and is being implemented.

@ethereum @vdWijden One outstanding feature we'd like to have for The Merge is an authentication mechanism between paired EL & CL nodes. We'll be looking into that next week!

@ethereum @vdWijden Once we have all this, we expect to launch one more merge testnet, which may be the last one prior to existing testnets going through The Merge! In parallel, there is an effort to shadow-fork Goerli and replay its txns on devnets. We are also working on automated transition tests

@ethereum @vdWijden That was it for The Merge. If you haven't tried it yet, I recommend using Kintsugi to get a feel for post-merge Ethereum: blog.ethereum.org/2021/12/20/kin…

@ethereum @vdWijden Next up on the call, @sendmoodz presented EIP-1153, which would introduce transient versions of SLOAD and SSTORE: TLOAD and TSTORE eips.ethereum.org/EIPS/eip-1153

@ethereum @vdWijden @sendmoodz Because of changes in refund behavior with EIP-3529, some smart contract patterns where you store a value, and then clear it to get a gas refund, have become less effective. Refunds can now only represent 20% of gas used, rather than 50% before.

@ethereum @vdWijden @sendmoodz Because TLOAD and TSTORE wouldn't need to ever store something to disk, they could be priced cheaper than SLOAD and SSTORE and be used for this write/clear pattern.

@ethereum @vdWijden @sendmoodz Moody explained that this would be valuable for @Uniswap in their next version, and even leaked some details on the call about their planned design 👀

@ethereum @vdWijden @sendmoodz @Uniswap There were a few questions on the call. First, @mhswende recalled different variants of such an idea being proposed when this EIP was originally written (2018). He asked about the tradeoffs between them, but people didn't have a great memory of the other options.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende Second, there were some questions about exactly how much gas savings would something provide to users, and how strongly applications want this. Because the EIP introduces new opcodes, it means contracts need to be re-written to take advantage of the savings.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende Moody said Uniswap would benefit greatly, but unfortunately can't share the code publicly. If your application would benefit from this, MAKE YOURSELF KNOWN ✨

Best place to share feedback is @EthMagicians -> ethereum-magicians.org/t/eip-1153-tra…

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians Lastly, there was some discussion about whether Verkle Tries, which provide some gas cost savings with certain access patterns, could provide similar benefits as 1153 and make it redundant? Moody seemed to think it wouldn't be a perfect replacement, and VTs are much more complex.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians So, for next steps, we'll try and analyze the impact this can have on applications, whether this design is the best one, and the pros/cons of waiting for VTs.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs also had a comment about setting realistic expectations w.r.t. hard fork inclusion: given the amount of other proposals for Shanghai, and the number of open questions with this, if we want to see it included, it will require a lot of work & outreach, and soon!

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs And this transitioned us into discussing what Shanghai could look like! @yperbasis had posted a comment on the agenda highlighting the long list of potential things we need to prioritize from (a few are missing, too!):

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis Some of the larger WIP items, such as Verkle Tries or EIP-4444 might also overlap in ways and require client teams to do large refactorings. We therefore want to think deeply about how to best stagger these initiatives.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis Several people shared their opinions on the call, as well as in the chat, about what they see as the highest/lowest priorities. I recommend the livestream to get a feel for them. A few ideas that were shared:

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis 1. History Expiry should be higher priority than Verkle Tries, and can be worked on in parallel to a fork given most of the work is outside of consensus.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis 2. How important are Beacon Chain withdrawals in Shanghai? There seems to be a pretty strong consensus they are very important. There is a PR for the CL side of them already, but we need an EIP for them on the EL side 🔜 @dannyryan is on it!

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan 3. How important is it for Shanghai to be a "feature fork", where EIPs that benefit application developers are prioritized over long-term protocol changes? Seems to be some agreement towards wanting to do this.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan 4. How big or small should Shanghai be? Should we include as many EIPs as possible, or potentially even split it into two smaller forks? Testing EIPs' interactions can grow exponentially in complexity, so we want to be mindful of that.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan @dannyryan suggested the approach of "withdrawals and release valve", where we have withdrawals as the main "special" feature, and then add several of the EIPs the community has been waiting on for a very long time.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan There was some support for this (I personally really like it!), and several folks expressed their desire to see EVM improvements, BLS support, and maybe even 3074, finally be live on mainnet!

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan While this is definitely not the last time we're discussing Shanghai, and we still have some time to plan it (we still haven't fixed all the merge consensus issues!!), one thing I added is that we *already* many more EIPs than we can realistically include.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan This means that new proposals need to both appear soon, and provide a strong rationale for why they should be prioritized over the existing backlog of improvements.

If you have something you are dying to see on mainnet, this is your cue!

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan I'm happy to work with folks who want to champion and EIP to walk them through the process, set realistic expectations and have it considered for Shanghai. DMs are open!

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan Finally, I briefly brought up naming *cough* bikeshedding *cough* the EL client releases for The Merge. The CL side has settled on Bellatrix for the name of their release, but we don't have anything yet on the EL side.

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan As I see it, we want "The Merge" to refer to the entire process of releasing clients, hitting the terminal total difficulty, having validators produce blocks, and seeing the chain finalize. It doesn't seem accurate to call the release of EL clients with TTD "The Merge"

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan So... suggestions welcome 😁! I've just opened an @EthMagicians thread to discuss this: ethereum-magicians.org/t/el-merge-cli…

@ethereum @vdWijden @sendmoodz @Uniswap @mhswende @EthMagicians @adietrichs @yperbasis @dannyryan And that was it! Next call is Jan 21st, 14:00 UTC. See you then 👋🏻