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

Support block value in engineGetPayload #6327

Closed
tbenr opened this issue Oct 16, 2022 · 4 comments · Fixed by #6878
Closed

Support block value in engineGetPayload #6327

tbenr opened this issue Oct 16, 2022 · 4 comments · Fixed by #6878
Assignees

Comments

@tbenr
Copy link
Contributor

tbenr commented Oct 16, 2022

ethereum/execution-apis#307

We could start comparing locally produced payloads with bids coming from builder endpoint and prefer local one if it has higher or similar value of the received bid. We could add percentage diff as well, so if let's say bid isn't at least 50% more valuable than local we fallback to local.

@benjaminion
Copy link
Contributor

I think this is a duplicate of #6140. Also see #6344.

General view seems to be that this is better done in MEV-Boost than in the consensus client. But happy to consider other views.

@tbenr
Copy link
Contributor Author

tbenr commented Oct 27, 2022

Well, not exactly. This will enable the a value comparison between local el block and builder bid. Previous issues where about applying an absolute cutoff\threshold on bids (which indeed has been recently implemented in mev-boost). The motivation behind that is to enable\encourage to choose locally produced payloads when there is "not enough rewards difference" to choose the bid. Moreover, non censored local blocks censored tx can start competing with censoring builder bids.
In the current sidecar model, mev-boost can't "see" local produced block and so the only place where it can happen is in CL.

@benjaminion
Copy link
Contributor

Ah, ok. Got it.

@tbenr
Copy link
Contributor Author

tbenr commented Dec 16, 2022

We can start working on this since we have #6614

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

Successfully merging a pull request may close this issue.

4 participants