Feature Request: Let validators compromise between gas usage and fees.

[jhoenicke]

Correct me if I'm wrong, but I believe validators only see the value of the block in the bids but not other important properties like the used gas. Thus it cannot compromise between gas usage and fee. Since larger blocks increase the orphan risk, a validator may want to specify a minimum miner tip per gas.

I propose two changes.

1. Publish gas usage in addition to value in the bids (and for EIP4844 also the extra data usage). A validator can then choose the block where value - minimumtip*gasusage is maximal.
2. Let the validator publish his preferences to the block builder, i.e., the minimumtip it uses. This will help block builders to optimize for the wishes of the validator.

Otherwise, we will see more and more transaction with just 1 wei miner tip. Block builders have no incentive not to include them (their orphan risk is negligible as they will still have the best bid in the next block). And validators don't even see the size of the block before accepting the bid.

[metachris]

Correct me if I'm wrong, but I believe validators only see the value of the block in the bids but not other important properties like the used gas

That is incorrect, the bid already provides this information:

1. ExecutionPayloadHeader, with all the header fields, including gas_used (https://github.com/ethereum/beacon-APIs/blob/1741560a920615480b7a7e1bc04060428abc469c/types/capella/execution_payload.yaml#L45)
2. Value
3. Signature from the relay

See also a concrete implementation here: https://github.com/attestantio/go-builder-client/blob/master/api/capella/builderbid.go#L26-L30

[jhoenicke]

the builder bid provides ExecutionPayloadHeader, with all the header fields, including gas_used

Good, so validators can already implement change 1 if they want.

Allowing validators to publish their preferences so that builders can optimize is still something desirable. Otherwise builders would have to guess what the validators want. Would the way forward be to add this to a ValidatorRegistrationV2?

[ralexstokes]

@jhoenicke do you have data on how often 0 or 1 Wei priority fee transactions are included in a block and that block also being orphaned? or more generally the orphan rate from using the builder network?

if a builder is including transactions that are not adequately compensating for orphan risk then they also lose out on the opportunity of the proposal so they have strong incentive to not take on too much risk here

[jhoenicke]

Luckily 1 wei transactions are currently still too seldom to be statistically significant. They all were added to the blockchain and many builders include them, e.g., this address has most of their transaction included within 1-2 blocks: https://etherscan.io/address/0x634438d879a90a25437b87168252c2b983734391
It can be, of course, that they use off-chain payments with all the different builders that included them, but it seems unlikely.

I'm collecting statistics for recent blocks. About 48 % of all gas is used for transactions with less than 0.5 Gwei priority fee, while paying only 1% of what validators earn for those block. About 97 % of the blocks contain such transactions. Collecting these statistics is slow, I can give more precise values when I'm done.

Getting statistics of orphaned blocks is much more difficult, as they are not preserved. I have no idea how I would even start here.

[ralexstokes]

thanks for the response, it would be good to see some data here...

that being said, it seems like sub-gwei priority fees is fine if users still get their transaction included? I don't really see the problem, esp if e.g. a norm of paying 1-2 Gwei is 'overpaying'

[jhoenicke]

Here is a CSV file for blocks 169000000-16939400 (the last 5-6 days): https://jochen-hoenicke.de/misc/tipstat.csv (all numbers in columns D-W are in wei or gas units; you may need to find spreadsheet software that can handle large numbers). There are a few 0 wei transactions that are clearly MEV transactions, but the 1 wei transactions are usually from the mempool.

It looks like at least Flashbots builder, rsync-builder, BloxRoute builder, eth-builder, Manta-builder accept 1 wei transactions.

A notable exception is builder0x69, which doesn't mine below 0.1Gwei. Also Eden and Titan often don't mine low fee transactions at all. beaver-build had only mined two 1 wei transactions in the last 5 days, so it seems they also ignore most of them.

One can argue whether anything above 1 Gwei is overpaying, but currently 0.000000001 Gwei is good enough for high-priority fee (< 1min in normal cases) and anything above that is just a voluntary donation to the validators. Given that some people start paying a maximum base fee of 100 Gwei with 0.000000001 Gwei miner tip, one cannot argue that they are expecting medium or even low priority handling of their transaction. It's probably not yet common knowledge that 1 wei is high-priority, but it's just a matter of time until more and more wallets switch their fee policy.

My feeling is that 1 Gwei is a fair price for high priority and 0.1 Gwei for low-priority (that's less than 1% that goes to validators and more than 99 % burned). But the ideal solution is to let each validator decide what fee he wants to leave on the table for the next validator and what he is willing to include producing larger blocks. If we let block builders decide the minimum fee, that would increase centralization.

It seems the maximum miner tip have changed over time. In November (around block 16000000) only 25 % of the gas was used for transactions below 0.5 Gwei, even though the base fee was lower at that time.

[ralexstokes]

awesome on the data!

But the ideal solution is to let each validator decide what fee he wants to leave on the table for the next validator and what he is willing to include producing larger blocks. If we let block builders decide the minimum fee, that would increase centralization.

there is a trade-off b/t expressivity and complexity in this protocol; I do think the auction design is very much an open question but the idea now is that validators see a bid value and the gas used -- if they wanted to choose a lower value bid with lower gas used they could do so but the current design assumes validators are rational actors who will always choose the most valuable bid (even if more valuable by 1 wei)

this seems like a thing where if a given builder took on too much orphan risk it would be outcompeted by those builders who do -- by encouraging competition, we maintain decentralization