Ethereum Core Devs Meeting 145 Agenda

[timbeiko]

Meeting Info

• August 18, 2022, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/jJaCaS0WbIw
• Zoom: shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge Updates
  • Sepolia post-merge upgrade
  • Mainnet Shadow Fork
  • Mainnet 5GB DAG size & hashrate
  • Tentative mainnet TTD execution-specs#585
  • mev-boost relay censorship (& censorship resistance more broadly, see below)
  • Kiln deprecation

[MicahZoltu]

While I suspect many don't want to talk about these two things on the call, I think it is necessary given how close we are to The Merge.

Censorship at launch by MEV-Boost relays.

The Flashbots operated relay censors transactions from/to certain Ethereum addresses and plans to continue to do so indefinitely. Bloxroute is building and planning on operating both censored and uncensored relays. Manifold is building uncensored relays but won't be ready by The Merge. I believe censoring relays goes against the ethos of Ethereum and the core principals of what we are trying to build. While we cannot stop individual builders/proposers from censoring, we can at least make it difficult for censoring tools to gain wide community adoption.

If there are no non-censoring relay operators as of The Merge, we can launch with clients that have the MEV-Boost integration disabled or removed so anyone wanting to use it would need to run custom software, not something from the Core Devs. If there are some ethos-aligned relay operators relays as of The Merge, we can make an effort to promote those (e.g., in documentation, blog posts, etc.) and suppress/discourage the usage of any censoring relays.

We cannot control who runs a relay or how they behave, but we can at least not support/encourage any groups that are building censoring relays.

Credible commitment to punish censors.

Recent events have increased the probability that we will see pressure from state actors for validators to censor transactions, possibly including reorging out blocks containing certain transactions. While this is far from a certainty, the state actor involved in the recent events is one that has jurisdiction over some of the largest centralized validators which combine to make up enough staking share to effectively censor transactions (if my math is correct) due to the current proposer boost settings.

It would go a long way to preventing this kind of censorship if a significant portion of the Ethereum Core Devs made a credible commitment to develop and support a fork of Ethereum that kicked and penalized any censorship cabals that arise. I don't think it is necessary to nail down the specific conditions on which any individual developer would support such a fork, just make it clear that a majority of the Core Devs have an internal threshold across which they will support such a fork. I think the credible threat alone will be enough to cause any staking entity that is pressured by the government to quit staking rather than comply.

What would be even better is if we pre-specced or even pre-coded the ability to do this so that if the time comes where we need to deploy it is just a matter of filling in an array of validator IDs (thus reducing the time they have to exit after decision is made but before the fork happens).

[parithosh]

I'd like to bring up the topic of deprecating Kiln earlier than expected. It seems like we just see 1-2 tx's on it every few mins, so it has low usage. Besides that, we have 3 merged testnets for people to test deposits, syncing, etc. This would save some time and money, resources that could be allocated to other merge testing.

[tfalencar]

Tangentially related to what @MicahZoltu mentioned above, if time permits, I would suggest devs at least think/reconsider the implications of the current events with regards to the priority of inclusion of "withdrawal EIPS", such as EIP-4895 into Shanghai. Although no one made promises as to when withdrawals will be available, given major pools might wish to halt operation, i.e., do a "voluntary exit" (a big one already mentioned this path if it gets critical), having this re-prioritised accordingly might be a good idea as a friendly off-ramp path for those who decide to stop staking/validating, avoiding more expensive/harmful conflicts of interests leading to forks due censorship. Therefore it is my opinion that prioritising this EIP is a low hanging fruit in helping to keep the network secure and healthy (also keeping social layer more cohesive) in light of recent events.

[timbeiko]

Closed in favour of #609.

@tfalencar sorry, I missed your comment, but EIP-4895 is already CFI'd for Shanghai. It can't be "more prioritized" beyond starting the work, which will happen soon after the merge 😄