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 137 Agenda #514

Closed
timbeiko opened this issue Apr 15, 2022 · 6 comments
Closed

Ethereum Core Devs Meeting 137 Agenda #514

timbeiko opened this issue Apr 15, 2022 · 6 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Apr 15, 2022

Meeting Info

Agenda

@CryptoBlockchainTechnologies

This comment was marked as off-topic.

@lightclient
Copy link
Member

lightclient commented Apr 29, 2022

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

Added @lightclient !

@djrtwo
Copy link
Collaborator

djrtwo commented Apr 29, 2022

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

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

Closed in favor of #518

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

4 participants