ethereum/pm

Ethereum Core Devs Meeting 141 Agenda

timbeiko opened this issue · 8 comments

timbeiko commented

Meeting Info

Agenda

mkalinin commented

Considering the state and complexity of latestValidHash implementation across EL clients, I would like to discuss alternative options:

  • Does not make full LVH support a requisite for the Merge but commit for it to be implemented soon after the Merge
  • Make LVH while client is SYNCING a recommendation (say SHOULD instead of MUST in the spec) allowing EL clients to choose whether to support it or not
  • 👍1
jflo commented

@timbeiko can we add this as context under the shadowfork 7 status? It explains the besu failure.

https://hackmd.io/@RoboCopsGoneMad/B1reW1G9c

  • 👍1
  • 👀1
paulhauner commented

I'd like to respectfully propose doing this call 24hrs earlier (also open to other times).

This call is:

  • 2am Saturday morning in New Zealand (NZST).
  • Midnight Friday night in Australia (AEST).
  • 11pm Friday night in Korea (KST) and Japan (JST).
  • 10pm Friday night in Taiwan (CST), Singapore (SGT) and China (CST).

I've just hand-picked countries that I know have Ethereum developers with interesting things to say. I certainly missed someone/somewhere, apologies.

I think that Friday nights and Saturday mornings should be treated with the utmost respect, these times are widely accepted to be personal time for social and family events. I argue that infringing on personal time will increase burn-out in our community. Furthermore, scheduling meetings at a time when many cultures normalize alcohol consumption seems like a recipe for poor attendance and engagement from those timezones.

I think this is low-hanging fruit for the Ethereum community to start to address its timezone inclusion issues.

EDIT: I'm proposing future calls should happen earlier, not this particular call 😅
EDIT 2: I'm also open to the change happening after n more sessions at this time.

  • 👍6
  • ❤️3
qizhou commented

We would delay the EIP-5027 discussion to the next call. We found a few issues with warm/cold account access gas metering and need a bit more time to consolidate EIP-5027. Thanks @timbeiko

  • 👍1
lightclient commented

I would like to briefly mention this proposal to standardize the debug namespace across clients: ethereum/execution-apis#247

daniellehrner commented

@mkalinin regarding:

Make LVH while client is SYNCING a recommendation (say SHOULD instead of MUST in the spec) allowing EL clients to choose whether to support it or not

Isn't LVH already always null in PayloadStatusV1 when the status is SYNCING?

mkalinin commented

@mkalinin regarding:

Make LVH while client is SYNCING a recommendation (say SHOULD instead of MUST in the spec) allowing EL clients to choose whether to support it or not

Isn't LVH already always null in PayloadStatusV1 when the status is SYNCING?

Yes, it is. What I meant is that lvh should be returned to newPayload/fcU if during SYNCING client encounters an invalid payload in the chain it is syncing with. This requires parsing and keeping additional information in memory

timbeiko commented

closed in favour of #562