-
Notifications
You must be signed in to change notification settings - Fork 215
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
MEV-Boost Direct builder connection #648
Comments
in this model, wouldn't the validator's IP information be exposed from the incoming getHeader request to the builder? |
yes, unless they take some steps to obscure this -- the relay today acts as a bit of a shield privacy-wise as proposers already trust relays to some extent and so we can justify this additional marginal ask (acting as privacy provider) |
Yeah this is the most shaky part. You can probably back out the proposers IP after it has proposed a few blocks. If we could get some kind of IP rotation or similar it wouldn’t be a problem. Open to ideas another fun idea is to have some other entities (maybe relays) create noise that correlates with validators to obscure their IP. |
as the endpoint is unauthenticated, builders will probably obscure the validator IP when querying for each other's bids. Its possible that builders could ddos the getHeader endpoint to prevent proposers from getting a competitor bid and end up having to submit through the relay. |
I don’t see why the DoS concern is any different than with relay endpoints?
…On Wed, Apr 24, 2024 at 8:45 PM shana ***@***.***> wrote:
as the endpoint is unauthenticated, builders will probably obscure the
validator IP when querying for each other's bids. Its possible that
builders could ddos the getHeader endpoint to prevent proposers from
getting a competitor bid and end up having to submit through the relay.
—
Reply to this email directly, view it on GitHub
<#648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALHKJ2Z4RJMQKNLEQV3G5TLY7BGZPAVCNFSM6AAAAABGXV4QXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZWGEYDSNBUGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Currently, relays are in a critical path as bids flow from builders to proposers. This adds a little latency and places relays in a (permissioned) position to significantly impact the functioning of the (permissionless) block auction. However, looking at optimistic relaying, we see that relays often don't need to be in this privileged position.
I wrote a small proposal for how MEV-Boost could be changed to skip relays where they are not necessary by first querying information about optimistic builder endpoints and then interacting with those directly. This change does not require CL or EL changes.
More details here
The text was updated successfully, but these errors were encountered: