when in PoS networks, Besu repeatedly builds proposal until the getPayload method is called, in order to try to include new txs that could arrive in the meantime, so when more that one block is created in the interval, we need to have a strategy to select the best one, currently the decision is simply made on the gas used of the block, since we include txs from the most profitable to the least.
So in theory the more the block is filled the more value it should have, but it turns out that there are edge cases where this assumption fails, in particular when the are enough txs to fill the block since the beginning, and following blocks are just a little smaller that the previous in term of gas, they are discarded even if better in term of value.
Real world example:
1st block iteration has cumulativeGasUsed=29988510 and 50 txs
last has cumulativeGasUsed=29984151 and 185 txs with higher value, but since smaller by ~4000 gas is not selected as best.
Calculating the block value, does not add computation time to getPayload, since it was already done to include it in the response, and was refactored to compute it only one and use everywhere it is needed.
Fixed Issue(s)
Thanks for sending a pull request! Have you done the following?
PR description
when in PoS networks, Besu repeatedly builds proposal until the getPayload method is called, in order to try to include new txs that could arrive in the meantime, so when more that one block is created in the interval, we need to have a strategy to select the best one, currently the decision is simply made on the gas used of the block, since we include txs from the most profitable to the least. So in theory the more the block is filled the more value it should have, but it turns out that there are edge cases where this assumption fails, in particular when the are enough txs to fill the block since the beginning, and following blocks are just a little smaller that the previous in term of gas, they are discarded even if better in term of value.
Real world example:
cumulativeGasUsed=29988510and 50 txscumulativeGasUsed=29984151and 185 txs with higher value, but since smaller by ~4000 gas is not selected as best.Calculating the block value, does not add computation time to getPayload, since it was already done to include it in the response, and was refactored to compute it only one and use everywhere it is needed.
Fixed Issue(s)
Thanks for sending a pull request! Have you done the following?
doc-change-requiredlabel to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build./gradlew acceptanceTest./gradlew integrationTest./gradlew ethereum:referenceTests:referenceTests