Ethereum Core Devs Meeting 123 Agenda

[timbeiko]

Meeting Info

• October 1, 2021, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/-8TSQCwITA0
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge Interop Updates EIP-3675: Upgrade consensus to Proof-of-Stake #361
  • Engine API
  • Sync process
  • Specs
• December Fork Planning
• If time permits:
  • EIPs to be discussed [EIP-3436 & EIP-2976] #383
  • Enshrine EIP-3607: Reject transactions from senders with deployed code #390

[timbeiko]

Update about "December Fork Planning":

During ACD122 (#384), we discussed potentially having more than a difficulty bomb in the December upgrade despite having agreed against it previously (see: #356).

On the call, it was suggested that because EIP-3860 addressed a potential DoS vector, it should perhaps be considered for a December network upgrade alongside the difficulty bomb delay. After talking to the 4 client teams, the consensus seems to be that the December upgrade should only contain the difficulty bomb pushback and nothing else. 3/4 of the client teams explicitly preferred this (including the ones most susceptible to issue described in EIP-3860). If any client team/dev disagrees with this conclusion, please comment and/or reach out to me.

Given this consensus, I propose the following:

1. We create a specification for the December Network upgrade under the "Arrow Glacier" name to make it clear that this upgrade only contains the difficulty bomb pushback.
2. We create a placeholder EIP to delay the difficulty bomb and include it in this upgrade.
3. On the October 29th AllCoreDevs call, we agree to both the delay for the bomb, and the fork block for the December upgrade.
4. On the November 12th AllCoreDevs call, all clients have a release for Arrow Glacier that we can share.

As for EIP-3860 and all the other EIPs currently proposed for Shanghai, once the merge is done being implemented, we should go over them and discuss which of these should be in the first post-merge upgrade (whether that is still called "Shanghai" is TBD).

[gcolvin]

all the other EIPs currently proposed for Shanghai

@timbeiko Do we have a list of these somewhere? I've lost track.

[timbeiko]

@gcolvin I believe all of them, except EIP-3074, are open issues here: https://github.com/ethereum/pm/issues

Haven't made it into something more "official" because there was a lot of flux with Shanghai/Difficulty Bomb/The Merge in the past few months.

[MariusVanDerWijden]

As someone who tried pretty hard to push EIP-3860 (limit + meter initcode) into Arrow Glacier, I am also convinced now that we should go for a featureless fork. The issues solved by 3860 are not as pressing as I thought.

[lightclient]

except EIP-3074

I think it's fair to consider EIP-3074 as perpetually proposed for all network upgrades until it's either accepted or rejected at a fundamental level :)

I am also convinced now that we should go for a featureless fork

Good to know, thanks for the comment!

[timbeiko]

@lightclient would you mind opening an issue for 3074 in Shanghai, actually? A lot of people ask the same question as Greg and I always point them to "that list + 3074". You could also just modify the title of #260 and re-open it.

[lightclient]

@timbeiko opened a new issue as Sam created the other one and I couldn't modify it: #394

[paulmillr]

Why don't client teams want hardcoded gas limit to be included? Seems like a solid idea. And simple enough to make it into tiny upgrade

[lightclient]

@paulmillr it's more that they want to forego any changes in the next fork so they can focus 100% of their resources on the merge.

[timbeiko]

@paulmillr to add more color to lightclient's comment: because the difficulty bomb will go off again in December, we will need to have an upgrade then. One notable thing about the difficulty bomb, though, is that it only is present on mainnet and not on testnets.

This means that a bomb-only upgrade does not need to be deployed to testnets, and can be deployed to mainnet directly. This reduces the time it takes to plan, communicate, and roll out the upgrade. We'd already kind of missed the window to have a proper feature fork in December if we wanted a smooth rollout (see: #356), but given the couple EIPs discussed on the last call were very small, we wanted to entertain the idea again.

As shared above, client teams prefer to stick with a bomb-only upgrade to keep things simple while we are working on the merge.

[tjayrush]

I'll just point out here that notwithstanding the fact that the team supporting OpenEthereum has announced end-of-support for that software, that if it's true that setting back of the difficulty bomb is the only breaking change in the next fork, it may be possible to further extend support for OpenEthereum with near zero work.

To say it more clearly -- if there are other things included in the next hard fork, the last nail in the coffin will be nailed in for OpenEthereum. If there are no other changes, I can see the lid staying open for a few more months. I for one would vote for that given that OpenEthereum's only viable replacement (Erigon) is not even officially in Beta status yet.

[timbeiko]

#396