Thread by @TimBeiko

Wrapped up @ethereum #ACDE earlier: covered the lastest on Shapella, some 4844 transaction changes, SSZ, RPC and SELFDESTRUCT 🤖

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

Recap below ⤵️

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

@ethereum First on the call, @vdWijden shared he had found a Shapella bug that showed up during full sync for empty blocks (no txns or withdrawals)

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

@ethereum @vdWijden Other clients also had this issue (except @nethermindeth 🫡), but given it's fairly easy to test for, everyone felt confident they could patch it quickly. We'll also be adding an additional Hive test for this case.

@ethereum @vdWijden @nethermindeth Teams didn't feel like this should affect the timeline for the Sepolia upgrade, so we're still on for Feb 28, 4am UTC. github.com/eth-clients/se…

Expect client releases and a blog announcement early next week 😄

@ethereum @vdWijden @nethermindeth @BarnabasBusa then gave an update on the latest withdrawal devnet (#7!!), whose goal was to stress test Shapella. The devnet had 600k validators, and 360k of them perform withdrawal credential updates right at the fork.

@ethereum @vdWijden @nethermindeth @BarnabasBusa Clients saw a spike in RAM + CPU usage, and the devops team will be monitoring the devnet in the coming days to see how many credential update messages were included vs. lost.

@ethereum @vdWijden @nethermindeth @BarnabasBusa This test also revealed a Prysm <> Besu issue, where Besu limits the number of responses it sends via RPC to prevent DoS, but Prysm expected a higher number of responses than Besu's current limit. The Besu team is currently looking into this.

@ethereum @vdWijden @nethermindeth @BarnabasBusa Overall, the network stopped finalizing for 1 epoch and was fully recovered 3 epochs after the fork. The devops team seemed happy with this, given this setup is harsher than what we'd expect on mainnet, and clients still have time to address some of the issues found.

@ethereum @vdWijden @nethermindeth @BarnabasBusa We're also planning another mainnet shadow fork, on which we'll be doing doing some mev-boost testing 🔜

@ethereum @vdWijden @nethermindeth @BarnabasBusa Next up, we discussed EIP-4844. On this week's implementers' call (see the recap here:

https://twitter.com/terencechain/status/1625566598294835200

), we were somewhat blocked on whether to allow 0-blob 4844 transactions or not.

@ethereum @vdWijden @nethermindeth @BarnabasBusa In short, if we can assume blob transactions always come with a blob, clients know they will be larger, have different semantics (i.e. max 4 per block with the current spec), and can treat them differently in the mempool.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi previously put together a good doc re: the mempool design constraints with 4844: gist.github.com/karalabe/e1c4e…

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi That said, allowing 0 blob transactions might make it simpler for L2 infra, which could sign a single type of txn for all of its updates, whether or not they contain blobs.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi There was also the option of banning blobless 4844 transactions from the public mempool but not on-chain, so you could use a builder to submit them.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi After some back and forth, we agreed to completely ban them for now. This will make things simpler for clients in their initial implementation, and it's always easier to relax a constraint than add a new one.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi Next up, we had a conversation about moving more/all of Ethereum's transaction encoding to SSZ. There was a breakout call about this earlier this week, which Etan from Nimbus summarized today: github.com/ethereum/pm/is…

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi Vitalik had a proposal for what this could look like: notes.ethereum.org/@vbuterin/tran…

Most of the breakout focused on the implementation details of the SSZ encoding. Here's are comparison of the two approaches by Etan for various transaction types:

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi Over the next two weeks, Etan will try and prototype various use cases using each encoding approach to help us decide which way to go. We'll be continuing the conversation on another SSZ-focused call: github.com/ethereum/pm/is…

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi Next up, we had another SSZ topic: the withdrawal root. We agreed to RLP-encode this value for Shanghai to not bring in SSZ to the EL as part of the upgrade, but the CL uses SSZ for this. Etan and @mkalinin2 have an EIP to switch it to SSZ: eips.ethereum.org/EIPS/eip-6465

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 I mentioned that this discussion probably makes the most sense in the context of Cancun as a whole.

Discussions about this have already started on @EthMagicians and will pick up in the next calls ethereum-magicians.org/t/cancun-netwo…

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians Next up, there was a discussion about the CL minimal preset specs potentially affecting the EL. In short, minimal presets are smaller constants used by the CL for spec testing and rapid iteration devnets.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians For example, instead of using 12s for slots and 32 slots/epoch, which are the mainnet configs, the minimal presets use 6s slots and 8 slots/epoch. This has historically been a CL-only setting, but with 4844, one constant is "leaking into" the EL via the Engine API: the blob size

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians Blobs have 4096 field elements, but the preset uses blob sizes of 4 field elements. This constant is exposed in the BlobsBundleV1 Engine API call (github.com/ethereum/execu…).

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians We discussed several ways to deal with this on the call, and tentatively leaned towards using the mainnet value for the minimal presets as well (see: github.com/ethereum/conse…). The one downside is this would slow down CL spec tests, some of which go from <1s to ~30s to execute.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians The number of tests may be small enough that this is fine, but expect some debate on the PR linked above :-)

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians Then, @wslyvh had a proposal to introduce new transaction pool RPC APIs to help standardize implementations across clients: github.com/ethereum/execu…

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh Clients seemed on board with this change, but need to review it further. Additionally, we agreed that if we do this, we'll mark the existing APIs as deprecate them, and alias them to the new names before removing them from the spec.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh Lastly, we had @j_wasinger back to discuss SELFDESTRUCT deprecation. This is something everyone wants to do, but the path forward is unclear. There are currently 3 proposals: EIP-4758, a modified version of it, and EIP-6046.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger EIP-4758 (eips.ethereum.org/EIPS/eip-4758) converts SELFDESTRUCT to SENDALL, meaning that it sends back the funds to the caller, but doesn't actually clear the code or storage. This would break contracts, notably those relying on CREATE2 to SELFDESTRUCT & redeploy at the same address.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger So, one proposed alternative is 4758+allow the edge case of "SELFDESTRUCT + CREATE2 within a single transaction". This is good because it fixes this issue, but doesn't fix _all_ affected contracts, and adds implementation complexity.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger Another proposal is EIP-6046 (eips.ethereum.org/EIPS/eip-6046). In this proposal, we don't clear either the storage or code, but instead set the nonce of the contract to the max possible value, and allow redeployment using CREATE2 if the nonce matches that value.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger The challenge here is it opens up a nasty attack vector: deploy a contract, fill storage in a certain way, and when you redeploy the contract, the old storage is still there, and could be accessed in malicious ways.

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger So, we'll be exploring the design space here in the next few weeks. If you have ideas or suggestions for Verkle Trie-compatible SELFDESTRUCT deactivating options that don't break things, now is the time to speak up 😄

@ethereum @vdWijden @nethermindeth @BarnabasBusa @peter_szilagyi @mkalinin2 @EthMagicians @wslyvh @j_wasinger And that was it! Next ACDE is scheduled for March 2, 14:00 UTC - see you then 👋