-
Notifications
You must be signed in to change notification settings - Fork 335
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
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
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" 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? |
Added @lightclient ! |
@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. |
@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. |
Closed in favor of #518 |
Meeting Info
Agenda
lastestValidHash
issuesThe text was updated successfully, but these errors were encountered: