Thread by @TimBeiko

Wrapped up another @ethereum #ACDE today: covered Shapella on Sepolia, set a date for Goerli, and also touched on the scope of the next upgrade, as well as deprecating some non-consensus functionality in clients 😄

Agenda: github.com/ethereum/pm/is…
Stream:

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

@ethereum Recap posted in the R&D discord:

@ethereum Now, let's dive in! First on the call, we covered the Sepolia Shapella (🎶) upgrade that happened Tuesday. In short, everything went smoothly ✨

@ethereum @parithosh_j explained that several BLS credential updates were sent during the fork and were processed without issues. The participation on the network dropped slightly because of unupgraded EL clients, but recovered after these were updated.

@ethereum @parithosh_j Because the validator set on Sepolia is quite small, only a single full withdrawal was tested (but partial ones are processed automatically).

@ethereum @parithosh_j @nethermindeth also reported they were looking into an issue where they produced a small number of bad blocks, but that it wasn't related to Shanghai code. They are still investigating the regression, but don't expect it will cause delays on their side.

@ethereum @parithosh_j @nethermindeth We also discussed a bug that appeared in MetaMask, where the balance wasn't being updated properly to account for withdrawals. It seems to work now, and may have been caused by a caching issue:

https://twitter.com/FrederikBolding/status/1630885511567998977

@ethereum @parithosh_j @nethermindeth Client teams will make sure that their JSON RPC responses work as expected, but if anything is found there it should be a minor fix.

@ethereum @parithosh_j @nethermindeth Client teams felt comfortable moving forward with Goerli, which we agreed to fork on March 14, 10:25pm UTC. I've opened a PR to update the specs accordingly: github.com/ethereum/execu…

Expect client releases & an announcement early next week 👀

@ethereum @parithosh_j @nethermindeth We didn't agree to a mainnet date explicitly, but assuming things go well on Goerli, we'd probably set a date on the next ACDE (Mar 16).

@ethereum @parithosh_j @nethermindeth Teams were suggesting roughly 4 weeks after that for a potential mainnet fork, giving them 1 week to put out + test a release, and then 2+ weeks of heads up for people to upgrade their nodes.

@ethereum @parithosh_j @nethermindeth Next up, we started discussing things related to the next upgrade: Cancun. The first of these was the various approaches to bring SSZ into the EL more comprehensively. Etan from Nimbus gave a recap of yesterday's breakout room on the topic: github.com/ethereum/pm/is…

@ethereum @parithosh_j @nethermindeth For background, the EL and CL currently use two different encoding formats: RLP (EL) and SSZ (CL). With EIP-4844, we'll be introducing some SSZ on the EL, it's worth thinking about how to approach this more broadly. Here's some more context:

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

@ethereum @parithosh_j @nethermindeth One neat thing we can get with a more wholesale move to SSZ is the ability to prove a single field of a transaction or receipt without having to download the entire transaction. This is particularly useful for low bandwidth/storage use cases, like light clients

@ethereum @parithosh_j @nethermindeth Etan from Nimbus wrote a doc summarizing the various proposals and their open questions: hackmd.io/y1MCA5Q-R4eMVy…

@ethereum @parithosh_j @nethermindeth Most folks didn't have a ton of context on this, so will be reading up in the next few weeks. Expect it to come up again in the next few calls!

@ethereum @parithosh_j @nethermindeth Then, I gave a bit more context re: Cancun planning. We have a Cancun Meta thread up on @EthMagicians: ethereum-magicians.org/t/cancun-netwo… 🧙‍♀️

If you have strong opinions on what the scope of the upgrade should be, that's the place to voice them 😄

@ethereum @parithosh_j @nethermindeth @EthMagicians I'll compile what gets posted there and bring it up in the next ACDE. Similarly, if you'd like to propose an EIP for Cancun, there's a `cancun-candidate` tag you can add to your EIP thread so it shows up here: ethereum-magicians.org/tag/cancun-can…

@ethereum @parithosh_j @nethermindeth @EthMagicians Two EIPs that were mentioned on the call by clients as candidates were EIP-4788, which adds an opcode to access the beacon state root (eips.ethereum.org/EIPS/eip-4788) and EIP-2537, which adds precompiles for the BLS-12381 curve.

@ethereum @parithosh_j @nethermindeth @EthMagicians EIP-4788 is a small change and seemed relatively uncontentious (although no decision was made!)

@ethereum @parithosh_j @nethermindeth @EthMagicians For 2537, we briefly discussed whether it would make make more sense to move away from precompiles towards more fundamental "building blocks" for crypto curves, as proposed here: ethereum-magicians.org/t/eip-5843-evm…

@ethereum @parithosh_j @nethermindeth @EthMagicians Two other EIPs had also been added to the agenda, although the champion didn't show up: EIP-5920 (PAY opcode) and EIP-6190 (Verkle-compatible SELFDESTRUCT)

@ethereum @parithosh_j @nethermindeth @EthMagicians We didn't really discuss 5920, but there was a conversation around 6190. @gballet wanted to better understand the complexity it introduces, especially when paired with eips.ethereum.org/EIPS/eip-6189

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad then asked about the value of introducing such complexity, and we move the conversation back up a bit.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad In short, we want to get rid of SELFDESTRUCT, as it is not compatible with Verkle Tries, which are required for stateless. SELFDESTRUCT is therefore being deprecated as of Shanghai. On-chain semantics won't change, but people should expect them to in near-future upgrades.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad A previous proposal, EIP-4758, suggested converting it to a SENDALL, where the funds would still be sent to the caller, but the contract code or storage aren't deleted: eips.ethereum.org/EIPS/eip-4758

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad The challenge with this is that many contracts rely on CREATE2 to SELFDESTRUCT a contract and recreate one at the same address. @j_wasinger did an analysis on the impact a while back: hackmd.io/X-waAY49SrW9i3…

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger So, finding a design which is Verkle-compatible (meaning that it can't actually delete the storage), but also doesn't break those contracts, is critical. @alexberegszaszi had another proposal: EIP-6046 eips.ethereum.org/EIPS/eip-6046

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi 6046 is clever in that it uses the nonce to mark a contract as "SELFDESTRUCTed", but then allows redeploys at the same address. The downside is that it does not clear the storage, which could lead to exploits.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi So, it's important to keep exploring this design space in the next weeks/months as Cancun shapes up, to hopefully get a proposal which is Verkle compatible, doesn't break contracts, and hopefully isn't too complex.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi Lastly, @peter_szilagyi had three topics he wanted to discuss on the call, related to long-term client maintenance. The first was whether the `pending` blocks should be dropped.

https://twitter.com/peter_szilagyi/status/1631314582378541058

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi The idea is that in a world where blocks building is optimized, the "pending" block you get from your local transaction pool isn't really a good estimate of the next block in the chain, so the value of exposing this is diminished.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi I'd recommend watching the livestream here if you care about the nuances & tradeoffs of client maintenance/optimization!

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi Then, we discussed whether to deprecate eth/66. With EIP-4844, we'll be introducing eth/68 and Peter was wondering if clients felt comfortable dropping the older version of the p2p protocol.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi Again, interesting back and forth on the livestream, but we utilmately decided against it for now, as eth/66 is the last protocol version to support getNodeData, which is required for Fast Sync.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi And, even if/when Geth does drop this, other clients likely will maintain it to remain compatible on private networks.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi We finished with a similar discussion: deprecating the ability to sync pre-merge networks. Again, here, while we might want to do this, Geth would likely be most aggressive because other clients need to support non-merged network for the foreseeable future.

@ethereum @parithosh_j @nethermindeth @EthMagicians @gballet @dankrad @j_wasinger @alexberegszaszi @peter_szilagyi And that was it! We ended a bit early (sorry @lightclients), and will be back two weeks from now, on March 16, 14:00 UTC! Note that by then, DST will be over in some places, so double check your local time ⏰