Thread by @TimBeiko

And @ethereum #AllCoreDevs is back in full swing tomorrow, 14:00 UTC 😄

Lots to cover, see the (packed) agenda here: github.com/ethereum/pm/is…

As always, the call will be livestreamed (), and I'll post a recap here shortly after. See you there 👋

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

@ethereum And we just wrapped up! Covered a lot, so let's get into it 😄

@ethereum First on the call, I asked all the client teams what they had been working on and what their view of priorities was for Shanghai.

@ethereum .@nethermindeth went first, saying it had draft PRs for all Shanghai EIPs currently Considered for Inclusion (list here: github.com/ethereum/execu…)

@ethereum @nethermindeth The team said they were also interested in exploring EIP-1153, which introduces transient storage opcodes, and, EIP-4758, which deactivates the SELFDESTRUCT opcode and converts it to a SENDALL opcode. Links here:
1153:eips.ethereum.org/EIPS/eip-1153
4758: eips.ethereum.org/EIPS/eip-4758

@ethereum @nethermindeth Beyond this, the team had been syncing the newly launched Shangdong devnet (more on this here:

https://twitter.com/EFJavaScript/status/1581003267152412672

), and passing the existing EOF reference tests

@ethereum @nethermindeth In their view, the current CFI EIP list is good, and if we added something big to Shanghai, it would delay shipping Withdrawals. That said, small additions, like the ones above, would be fine.

@ethereum @nethermindeth Then, @ErigonEth gave an update. @yperbasis shared a lot of Nethermind's views, emphasizing that deactivating SELFDESTRUCT would help Erigon simplify its codebase significantly.

@ethereum @nethermindeth @ErigonEth @yperbasis After, @peter_szilagyi gave an update on behalf of @go_ethereum. The Geth team is a bit more split about the best path forward for Shanghai. They see two levels of proposals competing, the smaller ones, like 1153, 4758, etc. and three big buckets: EOF, 4844 and withdrawals.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum For the smaller ones, none of them seem particularly hard to implement, although they will all require extensive testing (that's always the case!). They are open to whatever the community thinks is most valuable.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum As for the larger proposals, they see Withdrawals as a given that should be included. They think 4844 is a relatively simple change on the EL side, though it would require some changes in the networking protocol (see: github.com/ethereum/EIPs/…).

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum For EOF, they see two paths: either we move forward with the two currently CFI'd EIPs (3540 & 3670), which provide a minimal implementation which will need to be extended later on, or we include more functionality and have one "feature complete" EOF release.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum Specifically, these additional EOF EIPs are eips.ethereum.org/EIPS/eip-4200, which introduce static relative jumps, and eips.ethereum.org/EIPS/eip-4750, which introduces special code sections for functions in EOF contracts.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum Then, @HyperledgerBesu shared their thoughts. Echoing Nethermind, they are relatively happy with the current CFI list and have PRs in progress for most EIPs. For 4844, they are still unsure of the actual implementation complexity and would like to have a better view on that.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu They also agreed that EOF warrants more discussions to choose the correct approach, and that changes like 1153 (transient storage) and 4758 (deactivating selfdestruct) would be valuable.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu Re: 4844, the Nethermind team had some questions about the state of the spec. Things have been changing a lot on it recently, and they feel that if we want to consider it for Shanghai, we should finalize it soon, ideally in the next month or so.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu .@adietrichs gave a quick overview of the current moving pieces on the spec. The two biggest ones are (1) finalizing details around the fee market (see: github.com/ethereum/EIPs/…) and potentially exposing one more value in the EL precompile (see: github.com/ethereum/pm/is…)

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs He said that it's reasonable both these things would be finalized in the next month. Beyond this, we still need to set the constants for the blob size, blob retention time, and make some adjustments to the cryptography.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs These last changes would be mostly abstracted from clients, as they would be implemented in the crypto libraries directly. Lastly, there is also the KZG Ceremony which needs to happen. More info on the ceremony can be found here: github.com/ethereum/kzg-c…

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs .@trent_vanepps gave a quick update, but in short the audits for the ceremony are scheduled to start early Nov, and everything is expected to be ready by late Nov. Then, the plan is to have the ceremony run for about 2 months, which should work with any possible Shanghai timeline

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps After, @vdWijden shared his views on EOFs. He stressed that he'd rather see a full EOF implementation rather than a multi-step one because each EOF version must be maintained forever in clients.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden Because both EOF and non-EOF contracts exist in parallel, you can never deprecate pre-EOF EVM implementations from clients. So if we ship the EOF in two steps, EOFv1 and EOFv2, then clients must maintain the pre-EOF, EOFv1 and EOFv2 EVMs forever.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden Echoing this, @tkstanczak said he agrees EOF is valuable, but would rather see a long-lived testnet where we first iterate on it and get to a final version we are happy with before we ship it on mainnet. He argued the work could be parallelized with other efforts quite well.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak We then heard from @alexberegszaszi, one of the EOF EIP authors. He shared that the original reason for splitting the EOF EIPs was to make them easier to review by client teams, and agreed that a full feature set would be ideal.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi That said, he thinks that if we can't commit to all of EOF for Shanghai, then a subset is still valuable. He also shared that the Solidity team was supportive of the effort. Some async comments by Solidity also confirmed this.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi .@yperbasis also liked the idea of bundling all EOF changes together. He had some questions about whether this would affect code chunking for Verkle Tries (@alexberegszaszi confirmed it wouldn't) and about what to do with regards to EIP-2315, another similar proposal.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi .@greg_colvin, the champion for 2315, said he'd be fine to withdraw it in favour of a full EOF implementation. There were more nuances here, for which I recommend watching the full livestream 📺

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin With all of this out there, I asked some of the CL folks present on the call what their general perspective was on all this as well 😅

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin .@paulhauner from Lighthouse said that for them Withdrawals and 4844 are the two main priorities right now. He said that we still need more data & testing for 4844, and so would like to see it implemented "on top" of the Capella/Withdrawal changes, given their higher certainty.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner .@terencechain from Prysm agreed. For him, the biggest unknowns around 4844 were the bandwidth requirement (and thus reasonable blob size), as well as the timing for the KZG Ceremony.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain .@philngo_ from Lodestar +1'd all of this. On the @Teku_ConsenSys side, they see withdrawals as much simpler than 4844 and may want to separate the upgrades in order to do merge-related cleanups in their codebase.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys Grandine said that unless we see something "seriously wrong" during testing, they'd like to see both Withdrawals and 4844 in the next upgrade.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys We then had a brief discussion about whether we should aim for these large updates at all, and whether it wouldn't be better to simply do many small upgrades?

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys This is a topic that's been discussed often (see an old @EthMagicians thread I started on the topic: ethereum-magicians.org/t/more-frequen…), and @peter_szilagyi summarized well what I think the "current view" is (cont'd)...

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians In short, while it always seems appealing to have smaller, more frequent upgrades, the time it takes to get every client to implement things, test extensively, put out releases, fork testnets, and then schedule mainnet, means there's a lot of overhead to each fork.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians He estimated about 3 months or so each time. This means that in a lot of cases, it's probably worth it to add "one more feature" to an upgrade rather than to try and split them up.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians That said, it's worth pointing out this isn't always the case. For ex, we shipped Berlin & London only 4 months apart. This was mostly because work on EIP-1559 had started a long time before and we were able to do most of the implementation & testing while Berlin was on testnets.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians But, at the end of the day, there is likely a tradeoff that looks something like: if we ship withdrawals ASAP, we can probably get them on month X, and say 4844 was a separate fork, it would probably happen at month X+ ~6. If we bundle them, we might get both at X+ ~3.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians Note that these are very rough estimations!! Clearly, if adding 4844 makes us go from X to X+6 anyways, then it's a better approach to split them. The uncertainty around unknown unknowns are what makes this hard 🙃

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians So, to summarize, it seemed like there are 4 main "buckets" we can think of for Shanghai proposals:
1. "Shanghai Core", the things that everyone agrees should go in. These are Withdrawals and a few small "quick wins" EIPs we had CFI'd a while back (3651, 3855 & 3860)

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians TL;DR of the small EIPs:
3651: Treats the COINBASE address as warm for gas pricing, fixing an oversight in EIP-2929
3855: Adds a PUSH0 opcode
3860: caps initcode size and adds gas metering to it

Links to all of them are here: github.com/ethereum/execu…

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians The second "bucket" is EOF, with the two currently CFI'd EIPs (3540 & 3670) as well as the two additional proposals (4200 and 4750).

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians The third one is EIP-4844, and finally the fourth one is other nice-to-have EIPs like 1153 (transient storage) and 4758 (deactivating selfdestruct).

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians In order to keep making progress, we agreed to the following: formally include everything from the first bucket in Shanghai, stand up devnets for both EOF and 4844 to gauge implementation + testing complexity and finalize specs, and then keep discussing the 4th bucket.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians On the 4th bucket, it's worth noting that this call was explicitly made to give client teams most of the space, and we didn't have much input from the broader community. On the next call, we plan to switch this for people to come and advocate for Shanghai EIPs.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians The reasoning to do this was that we can now have this conversation with much better context of where client teams are at and what they see as relative priorities.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians That said, we did spend some time discussing deactivating SELFDESTRUCT, as it does have some implications on existing contracts.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians EIP-4758 proposes to replace SELFDESTRUCT by SENDALL, which, like SELFDESTRUCT, sends all the ETH to the caller when used, but doesn't actually remove the contract form the state.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians There are two reasons why client teams think this is desirable: first, because SELFDESTRUCT is currently the only opcode with a fixed (gas) price but unbounded potential (computation) costs.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians If you SELFDESTRUCT a contract that's empty, it's trivial for the node to process this. But if you SELFDESTRUCT a huge contract, you cause massive to the node for the same cost.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians The second reason is that when we move to Verkle Tries ("The Verge"!), accounts won't be stored in the same way as they currently are, and so it's not as simple to remove something from the state trie (now you can just remove an entire branch up to a certain root node).

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians The current proposal tries to minimize breaking any existing contracts, but there is one pattern which it would break: SELFDESTRUCTing a CREATE2-deployed contract and redeploying a different one at the same address.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians There were different opinions about the best approach to take here on the call, and I recommend watching the livestream for the back and forth 👀

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians At a high level we can either:
- bite that bullet now, and do it ASAP because the # of contracts affected by this will only grow in the future
- come up with a special edge case for these interactions
- do nothing, never remove/neuter SELFDESTRUCT

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians On the second point, a rough idea is that perhaps you allow "true" SELFDESTRUCT if a contract deploy happens in the same transaction. That said, this introduces a lot of additional complexity.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians This isn't something that teams take lightly, as there are serious implications on currently-deployed contracts. @j_wasinger said he would look deeper into what the potential alternatives are in the coming weeks.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger 🚨 IF YOU HAVE A CONTRACT WHICH COULD POTENTIALLY BE AFFECTED BY DEACTIVATING SELFDESTRUCT WITH EIP-4758 🚨 please head to the @EthMagicians thread to share details: ethereum-magicians.org/t/eip-4758-dea…

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger With the EIPs out of the way, we had a few more Shanghai-related topics to wrap up. The first was how to trigger the actual fork activation.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger Pre-merge, EL clients used block numbers to trigger forks (and, as a one off, the TTD to trigger The Merge). Post-merge, this doesn't work if we need EL and CL forks to be coordinated in time, given we don't know how many missed slots we'll see.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger So, we need a way to ensure that the forks happen in sync across the EL + CL. The proposed approach now is to use a timestamp instead of a block number in the EL. The CL uses epoch numbers for fork, which map to a unique timestamp, so we can use that to fork the EL.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger While it's conceptually simple, it does require some rewiring in many parts of EL clients. For example, when setting the Fork ID or when dealing with receipts. It can also cause some weird issues in devnets/private networks which activate many forks on block 0 in their genesis.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger We agreed to use this approach for the Shanghai devnet, and to document standards/best practices and edge cases as we move forward with implementations!

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger Then, we quickly covered two more proposed changes. First, a new p2p protocol version, eth/68, proposed by @vdWijden which allows nodes to announce specific transactions vs. gossip them by default github.com/ethereum/EIPs/…

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger This would be very helpful in a post-4844 world as it would lower bandwidth requirements (you only gossip a blob transaction if asked explicitly, rather than by default to sqrt(peers)). It can also be implemented now, regardless of 4844.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger Lastly, and we were already overtime by this point, we briefly touched on a proposal to add a potential block's total fees to the Engine API getPayload call: github.com/ethereum/execu…

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger This would make it easier for clients to compare locally built blocks' profitability with ones provided by third party relays. There seems to be general support, but we didn't have time to discuss in depth so will add it to the CL call agenda next week.

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger And, lastly, we had Afri on to give a quick update on the Goerli situation and invite us to a call next week to discuss it further: ethereum-magicians.org/t/testnet-work…

GoETH is becoming too scarce, and we need ways to get it in the hands of developers for free. Call: Nov 1, 15:00 UTC 📆

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger And that was it! Next ACD is scheduled for Nov 10, 14:00 UTC! If you have a Shanghai candidate EIP, that's the time to show up 🙋 Also, note that with DST kicking in for North America, the call time may be different for you than today's ⏰ ACD is fixed at 14 UTC 🔐

@ethereum @nethermindeth @ErigonEth @yperbasis @peter_szilagyi @go_ethereum @HyperledgerBesu @adietrichs @trent_vanepps @vdWijden @tkstanczak @alexberegszaszi @greg_colvin @paulhauner @terencechain @philngo_ @Teku_ConsenSys @EthMagicians @j_wasinger ... and I think time changes in the EU this weekend, so watch out if you're European as well!