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

Allow setting a minimum gas used value to determine whether or not to use a block supplied by the builder API #653

Open
antonydenyer opened this issue May 21, 2024 · 3 comments

Comments

@antonydenyer
Copy link

antonydenyer commented May 21, 2024

In a similar spirit to #273

I think users should be able to express an opinion about the fullness of a block. Currently, block builders will often leave transactions out of a block when volatility is high. The reasons for this are not fully known, however what is know is that blocks have a lower gas used than would otherwise be the case.

One of the purported benefits of delegating block building is that the block builder should be able to fill the block with more transactions than a solo validator.

This would allow solo validators to express their opinions.

@ralexstokes
Copy link
Collaborator

validators registered in mev-boost already declare a gas limit preference, and the builder must build a block that is in line w/ this preference, subject to protocol constraints (gas limit can only change 12.5% from block to block)

if you wanted a feature like this, I think a better place for the discussion would be in the https://github.com/ethereum/beacon-APIs as this is where clients essentially handle the logic to select a remote vs. local block

I would suggest keeping mev-boost as minimal as possible to avoid complexity spilling out into this part of the stack

@antonydenyer
Copy link
Author

That's interesting. I didn't think of doing it during registration. To be specific, if a block builder builds a block that only uses 1m gas, then I would like to build the block myself, in the same way that I can say if there's only 0.1 eth of priority fee rewards on the block, then I'll build the block. So, I ended up following that way of thinking about it.

Do you think the mid-bid param should be in the beacon apis too?

@ralexstokes
Copy link
Collaborator

consensus clients have a "builder boost" factor that controls how much the remote block should exceed the local block to address differences in value

I'm saying builders should be respecting the gas preference in which case it would be a violation of the mev-boost protocol for them to build a block with 1M gas when the validator preferred e.g. 15M gas (up to the protocol limits I mentioned above). Monitoring and enforcement of conformance to this registration is a different question -- right now I think the best anyone has is just manual inspection (although the intent is for the relay to be validating this value)

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

2 participants