Thread by @TimBeiko

We just wrapped up another @ethereum #AllCoreDevs.

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

FYI, this one is a bit less "recap-able" because most of the call was going over merge docs ⛓. Recording strongly recommended if you care about the Merge!

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

@ethereum First up on the call, we went over @mkalinin2's Consensus <> Execution layer communication API doc, which you can find here: hackmd.io/@n0ble/consens…

@ethereum @mkalinin2 We had already covered part of it in a Merge call last week () and continued going over the details. Mikhail went over some of the comments on the doc and explained the most recent changes.

@ethereum @mkalinin2 Specifically, the engine_assemblePayload was "split" into engine_preparePayload and engine_getPayload.

@ethereum @mkalinin2 He also shared some updates done to how events are defined on the consensus side, see: github.com/ethereum/EIPs/…

@ethereum @mkalinin2 Then, there was a discussion about the API call which would return the latest HEAD from the beacon chain, and what states that block can have, see:

@ethereum @mkalinin2 And we stopped the discussion at the start of the transition process. One thing that was noted is most of the transition code could likely be removed from clients post-merge. We'll have another call to keep discussing at 13:00 UTC next Thursday (before the Eth2 call)!

@ethereum @mkalinin2 Next up, we had Felix from the Geth team present a spec for post-merge syncing. Again, he walked through the doc in great detail on the call, so worth watching if this will affect you: github.com/fjl/p2p-drafts…

@ethereum @mkalinin2 The doc does a great job of explaining how sync would work, so I won't summarize it here. It's very well written, and even has custom graphics!

@ethereum @mkalinin2 After Felix's presentation, there were discussions about how clients could store intermediate states for non-finalized blocks, both looking forward (until next finalization) and backwards (to handle re-orgs).

@ethereum @mkalinin2 One big concern is that while finalization happens relatively quickly on average in Eth2, in the worst case, it could take days/weeks. A lot of implementations for storing intermediate states don't scale to that extent, so the biggest open question is now how to handle this.

@ethereum @mkalinin2 The Geth team has a proposal in the doc, but it would require a lot of engineering work and more discussion will be had across client teams to see if this is the ideal approach.

@ethereum @mkalinin2 It's also worth noting that different clients use different state storage models, specifically @ErigonEth. We'll keep looking at the feasibility of this approach across all models and discuss again on the next ACD.

@ethereum @mkalinin2 @ErigonEth Those two topics took all but 10 minutes from the call! We had one more big topic on the agenda: EIP-3756, which proposes a Gas Limit Cap: eips.ethereum.org/EIPS/eip-3756

@ethereum @mkalinin2 @ErigonEth @lightclients explained that, when planning London, we considered having a fixed gas limit (EIP-1559, then 3382 eips.ethereum.org/EIPS/eip-3382), but decided against it, partially to leave miners with the ability to lower the gas limit during attacks on the network.

@ethereum @mkalinin2 @ErigonEth @lightclients Another reason against the fixed gas limit that was brought up when planning London was that, historically, miners had acted in accordance with what would be best for the network. So, not capping it was a "backwards looking" argument.

@ethereum @mkalinin2 @ErigonEth @lightclients Looking forward, though, there are and will be increasing economic incentives for miners to raise the gas limit, and that's something we should consider.

@ethereum @mkalinin2 @ErigonEth @lightclients We didn't have a ton of time, but there were a few comments/questions!

@ethereum @mkalinin2 @ErigonEth @lightclients First, @Shamatar was concerned that the EIP didn't have a ton of data backing it. For example, what is the current state growth rate? How does it vary by clients? What is acceptable? Is the main blocker DoS risks on the network or something else?

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar Second, @adietrichs asked whether this is just a concern with PoW mining, or if it would apply post-merge. @dannyryan said this would still be valid post-merge.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan Third, Andrew (can't find twitter handle!) from @ErigonEth said they were opposed to this, but would not die on this hill. His reasons were (1) if we need a specific hard fork for this, it can distract from the merge and (cont'd)...

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan (2) that fees on Ethereum _are_ very high, and raising the gas limit could act as an incentive for client developers to improve performance.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan There were some pushback on both of these points. On (1), this could be done as a soft fork, and potentially in December as the difficulty bomb is pushed back.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan For (2) @vdWijden from Geth disagreed. He said all client teams are already working on better managing state and more pressure won't make things quicker. He also added that state growth isn't the main factor right now, but rather some DoS vectors on the network.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan @vdWijden We were already past the official end of the call, so we wrapped up the conversation 😅 We had a few final announcements.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan @vdWijden First, two EIPs which are already live (and one deprecated) are still in Draft but should be updated. They are: EIP-2364: eth/64: forkid-extended protocol handshake &
EIP-2464: eth/65: transaction announcements and retrievals. Will coordinate offline to do so.

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan @vdWijden Second, we have another London Infrastructure call to discuss EIP-1559 scheduled next week. If you are a wallet/app/etc. and have questions or updates about 1559, please join! Info here: github.com/ethereum/pm/is…

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan @vdWijden And last, if you are an application using Web3js and have not upgraded to a 1559-compatible version, that may be costing your users money. Please upgrade! More info in this thread:

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

@ethereum @mkalinin2 @ErigonEth @lightclients @Shamatar @adietrichs @dannyryan @vdWijden And that was it! Next call Sept 17, 14:00 UTC - I'll be away from Twitter for a week starting today. See you then 👋🏻

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