Ethereum Core Devs Meeting 137 Agenda

[timbeiko]

Meeting Info

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

Agenda

• Merge Updates
  • Shadow Fork Updates
  • lastestValidHash issues
  • RFC: Engine API response status when merge transition block is INVALID execution-apis#212
  • JSON-RPC: Add finalized and safe blocks execution-apis#200
  • Gas Limit & Block Builders (see here)
  • Post-Merge testnets #460 (comment)
• Shanghai Planning #450

[CryptoBlockchainTechnologies]

You guys have been doing amazing work preparing for the merge. It seems to already be a given that we will not make June for the merge based on some of the recent comments from the team. This is okay and important to ensure we don't merge until everyone is ready.

That being said this next meeting is extremely critical in producing an output that will nail down the new merge date. There are a lot of people on both the POW and POS side that have planned financially for the June merge. POW miners have stopped expanding and some even removing equipment. While POS stakers have been locking up more ETH with recent ques going above 2 weeks.

If June has to be pushed back even though we are very close, the community needs to see the confidence from the team in setting a firm new date, at this meeting, for the merge. Failure to do this could cause great harm to the future confidence in the teams and their ability meet goals even though this may not be true.

[lightclient]

I have a merge question that I would like to briefly discuss:

Post-merge, a large portion of validator will be proposing blocks that they do not explicitly build. This is because proposers who delegate their block building duties to specialized builders will earn more via the extraction of MEV. Since the proposer technically has the final say on what block it proposes, it has some power to dictate what the block looks like.

The "target" gas_target is something that validators might desire to control themselves. If we expect the number of builders to be relatively small, with only a few highly sophisticated builders winning the majority of blocks, we find ourselves in a similar situation as that we currently are where a few mining pools can collectively decide what gas_target the network will settle on.

The question I would like to answer is, are builders equally trustworthy custodians of this power? Or should we design the external block production protocols in a way that bestows the responsibility onto individual validators?

[timbeiko]

Added @lightclient !

[djrtwo]

@lightclient Why do you not also register your gas_target value with builders. Similar to fee_recipient. Builders do not have the same incentives wrt network properties, consumer node validation, etc.

Validators don't ahve same incentives as end user nodes, but builders diverge even more imo

EDIT: nonetheless, if anyone abuses this, it can be soft-forked out.

[lightclient]

@djrtwo right, this is why I would like to have ACD weigh in. We can definitely include that in the registration, but I think it is a departure from our current situation with miners. One benefit that has been touted of miners controlling the limit is that they could scale it down during a network issue. If we move this into validator registration, I think we will need more coordination to achieve something similar - communicating with 10-20 actors vs. 2-3.

[timbeiko]

Closed in favor of #518