Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 141 Agenda #551

Closed
timbeiko opened this issue Jun 14, 2022 · 8 comments
Closed

Ethereum Core Devs Meeting 141 Agenda #551

timbeiko opened this issue Jun 14, 2022 · 8 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Jun 14, 2022

Meeting Info

Agenda

@mkalinin
Copy link
Contributor

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

@jflo
Copy link

jflo commented Jun 23, 2022

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

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

@paulhauner
Copy link

paulhauner commented Jun 24, 2022

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.

@qizhou
Copy link

qizhou commented Jun 24, 2022

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

@lightclient
Copy link
Member

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

@daniellehrner
Copy link

@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
Copy link
Contributor

@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
Copy link
Collaborator Author

closed in favour of #562

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants