Thread by @TimBeiko

We wrapped up another @ethereum #ACDE today! Covered the steps to Shapella testnets, lots of 4844 specs discussion, and the path to SSZing the EL.

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

Recap below 😄

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

@ethereum First up, @BarnabasBusa from the EF's devops team shared that a new Shapella Devnet is now live: Zhejiang zhejiang.ethpandaops.io

@ethereum @BarnabasBusa There were some config issues in launching the network, but the devops and client teams are looking into it. The Shapella fork is planned for Tuesday 3pm UTC 👀

@ethereum @BarnabasBusa The network has a faucet, block explorer and staking launchpad support: if you want to run a validator through the Shapella transition, this is a great opportunity to try it! You can get 33 ETH via the faucet, start your validator, and be ready for Shapella Tuesday!

@ethereum @BarnabasBusa Based on this, I asked client teams if, assuming the Zhejiang fork goes well, they would be ready to move to public testnets, and in what order. We quickly agreed that Sepolia should be first, as the validator set is smaller than Goerli.

@ethereum @BarnabasBusa This will leave more time for tooling & docs to be ready for the Goerli upgrade, which will be the last "dress rehearsal" prior to mainnet!

@ethereum @BarnabasBusa As for timing, every EL + CL team on the call agreed that they were pretty much good to go and that, assuming the Zhejiang fork goes smoothly, we could pick a Sepolia fork time on next Thursday's ACDC call!

@ethereum @BarnabasBusa TL;DR: withdrawals are coming 💸! If all goes well, Sepolia time is picked next week, once that goes well, we pick Goerli, and after that transitioned successfully, we move to mainnet 🚢

@ethereum @BarnabasBusa Then, we spent the bulk of the call discussing various EIP-4844 things: gas pricing, transaction validity rules, transaction pool testing, and blob/block coupling for sync & gossip.

@ethereum @BarnabasBusa On the gas pricing side, @imapp_pl ran a full set of benchmarks comparing the execution time of the 4844 point evaluation precompile to other calls, across all clients. Their results are available here: github.com/imapp-pl/bench…

@ethereum @BarnabasBusa @imapp_pl @jacekglen walked through their methodology on the call: every precompile for every EL client was tested. Their benchmarks found that the gas price proposed for the 4844 precompile, 50000 gas, was reasonable ✅

@ethereum @BarnabasBusa @imapp_pl @jacekglen Next up, we discussed whether 4844 transactions without any blob data should be allowed. The discussion stemmed from a transaction pool design document @peter_szilagyi recently shared: gist.github.com/karalabe/e1c4e…

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi In short, if we assume 4844 transactions have data blobs with them, we can treat them differently from other transactions in the pool, and make optimizations around that. If 4844 transactions can be blobless (?), it changes the assumptions we can make.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi That said, there might be some use cases for blobless 4844 transactions to be valid in protocol (i.e. an L2 uses specific signing infra to submit both blob data and non-blob transactions, which would rely mostly on SSZ rather than RLP).

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi Allowing blobless 4844 transactions would also be a good way for users to first familiarize themselves with SSZ, given it would be the only transaction type on the EL to support it.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi Given the overlap with the SSZ proposals later on the agenda, we paused the conversation here and moved to other topics before coming back to SSZ later on!

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi Next, we briefly discussed whether it would make sense to have any sort of shared transaction pool testing infrastructure. Given it's not under consensus rules, clients historically have tested this quite independently.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi That said, with extra constraints on the mempool that 4844 introduces, it may be worth having some testing infra to make sure certain edge cases are handled uniformly across clients.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi After some back and forth, we agreed that there isn't much value in bringing this into common infrastructure. Clients may want to have different behaviour here. While critical things such as DoS vectors should be part of common testing infra, it's not worth "enshrining" the rest.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi Next up we discussed whether blobs and blocks should be coupled on the P2P network. Early on, the 4844 spec had them decoupled, then we coupled them for simplicity, and now we have some intuitions that decoupling may lead to better performance 😄

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi Here's an overview of the decoupling proposal by @jcksie hackmd.io/cmYisgxkRuGe9N… 📃

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie In short, decoupling, where blobs and blocks would be gossiped on separate subnets, could lead to performance improvements as each message type could be optimized independently. This may be a way to (eventually) raise the blob per block limit, too!

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie Separate gossip is also more compatible with full-danksharding erasure coding and data availability sampling. That said, it adds complexity in the short term, and could have some repercussion in the cryptographic libraries used for blob verification.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie Currently, the libraries do batch-verifications of blobs. There were concerns that if we moved to decoupled gossip, we'd have to rework the libraries to individually verify blobs.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie After some discussion, this didn't seem necessary, because, AIUI (not 100% sure I got that part...!), the blobs are gossiped with the proposer signature, which is considered a sufficient check for other gossiped items...!

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie That said, the @TXRXResearch team is running some networking simulations for 4844, focused on blob/block gossip. They hope to have preliminary results by next week's ACDC call, so we agreed to wait until we had those to continue the conversation.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch After this, @lightclients brought up a new JSON RPC method the geth team would like to get merged: eth_accounts github.com/ethereum/execu…

The method returns the account info (balance, nonce, storageroot, codehash) if the account exists, and null if not.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients There didn't seem to be objections by other EL teams about this, so assuming nothing comes up in the next couple days, it will be merged into the execution APIs spec.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients Finally, the last big topic on the call was the SSZing of the EL. We've been discussing this a bit over the past few weeks, and @VitalikButerin had a new proposal: notes.ethereum.org/@vbuterin/tran…

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin Vitalik's proposal introduces 5 new transaction types: 3 that correspond to existing transaction types, and two more for blob and blob-less 4844 transactions. All of them would use SSZ for encoding, and legacy RLP transaction could be converted to SSZ, and vice-versa.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin We spent a lot of time on the call going over the intricacies of the transaction format and conversion details. I won't recap it all here: the livestream has the entire back and forth if you want all the details 📺

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin Etan from @ethnimbus also had a similar proposal in the form of a draft EIP: github.com/ethereum/EIPs/…

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin @ethnimbus There seemed to be general agreement about the overall direction towards SSZ, but there are still a lot of details to figure out. We'll continue that conversation in the R&D discord, and likely have some breakout calls focused on this topic.

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin @ethnimbus If you have an opinion about this as a tooling or smart contract developer, now is a good time to pay attention and make it known 😄! You can either do so in the R&D discord, or on the @EthMagicians thread for 6404: ethereum-magicians.org/t/eip-6404-ssz…

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin @ethnimbus @EthMagicians Lastly, @vdWijden made a quick announcement about a block benchmarking tool he built. This feeds compute-intensive blocks to all clients and gathers benchmarks on execution performance. He'll be reaching out to teams to run experiments 🔜

@ethereum @BarnabasBusa @imapp_pl @jacekglen @peter_szilagyi @jcksie @TXRXResearch @lightclients @VitalikButerin @ethnimbus @EthMagicians @vdWijden And that was it! We have a bunch of calls next week: 4844 + EOF breakouts, as well as ACDC. Next ACDE is set for Feb 16, 14:00 UTC 👋