core/txpool/blobpool: delay announcement of low fee txs#33893
Conversation
evictionPriority was used in only one place, where we cap it to 0. Cleaner to do it right in the function. Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
Previously, blobpool eviction priority did not differentiate well transactions that are close to the basefee limit and transactions that are way under the limit. Here we improve this differentiation, giving more priority to transactions that are closer to the current base fee and/or blob fee, thus potentially includable in a shorter time. Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
It is not the role of the blobpool to serve as a storage for limit orders below market: blob transactions with fee caps way below base fee or blob fee. Therefore, the propagation of blob transactions that are far from being includable is suppressed. The pool will only announce blob transactions that are close to being includable (based on the current fees and the transaction's fee caps), and will delay the announcement of blob transactions that are far from being includable until base fee and/or blob fee is reduced. Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
…ties The priority groups for positive fee difference were not used. In these cases we always used the tip as the basis for comparison. Thus, it is useless to do an extra log, just to then throw it away. Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
EIP-7892 (BPO) changed the maximum blobfee decrease in a slot from 1.125 to 1.17 . Since we want priorties to approximate time, we should change our log calculation. Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
cskiraly
requested review from
healthykim,
lightclient and
rjl493456442
and removed request for
rjl493456442
Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
|
As I mentioned previously, there is an alternative approach to "filtering out" low-price blob transactions. If we determine that a transaction's blobFeeCap is too low and that it is very unlikely to be included in the near future, we can explicitly reject the transaction regardless of it was submitted via local RPC or received from the network. In the current approach, we keep low-priced transactions on hold in memory and only propagate them once they are close to being includable. It might be problematic in terms of UX for locally submitted transactions. If a user submits a transaction that is simply held in the local pool without any feedback, it may create confusion. It would be better to explicitly tell user: "The blob fee cap is too low, and the transaction is unlikely to be included in the network". Also, this approach is way easier to implement. Any particular reason to not go with this direction? |
It is way easier, but it is also subpar. You say "near future" but what is that near?
I'm convinced that using a drop threshold would make operation worse and not better from the UX perspective. I don't think the role of the submit RPC is to do dumb fee checks. As a user, check current fee before submitting a transaction, so you submit something reasonable. Once that concept is clear, it should also be clear that withholding is much better than dropping. By passing the transaction over the RPC you pass on the responsibility of making the tx get on chain if possible. And that's what the node and network does with the withholding. With drop, instead, the node would start doing future price predictions, and it's not the role of the node to do that. |
The issue is in this approach, node is already responsible for determining if the transaction is includable or not, if so, propagate it. The determination is very simple, check the gap between the current base fee and the one assigned in the transaction. I am kind of convinced by the withholding approach though, reason is: in the dropping approach, a larger allowance should be permitted; otherwise, the node effectively forces users to submit high-fee transactions. The rejection threshold must be more conservative to avoid being too restrictive. In contrast, for withholding approach, the propagation threshold can be much stricter. Since transactions are not immediately rejected but temporarily held in memory, the node has more flexibility in deciding when to propagate them. |
| // EIP-7892 (BPO) changed the ratio of target to max blobs, and with that | ||
| // also the maximum blob fee decrease in a slot from 1.125 to approx 1.17 . | ||
| // Since we want priorities to approximate time, we should change our log | ||
| // calculation for blob fees. |
There was a problem hiding this comment.
The issue is that the blob configuration will be changed across the forks, it's probably better to make it fork-aware?
There are some complexity around the fork boundary though. If the config is changed, we should in theory re-compute the tx priority accordingly.
There was a problem hiding this comment.
We will address this later. It's not so easy to handle changes to the ratio, as you say, but for now it should be up-to-date with the current fork.
Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
fjl
left a comment
fjl
left a comment
There was a problem hiding this comment.
I haven't tried this, but we're going for it. The idea behind this change is solid. Not accepting transactions with low fee is a bad option because the fees can jump so much.
Delays announcement of blob transactions that are far from being executable. Only blob txs within 1 fee-jump of current market fees (priority >= -1) are announced to peers, saving bandwidth on txs that can't be included yet. When fees change (new block), previously suppressed txs that are now close enough get announced. If fees spike and a previously announced tx falls below threshold, its announced flag resets so it can be re-announced when fees recover. Reference: ethereum/go-ethereum#33893
3 participants
This PR introduces a threshold (relative to current market base fees), below which we suppress the diffusion of low fee transactions. Once base fees go down, and if the transactions were not evicted in the meantime, we release these transactions.
The PR also updates the bucketing logic to be more sensitive, removing the extra logarithm. Blobpool description is also
updated to reflect the new behavior.
EIP-7918 changed the maximim blob fee decrease that can happen in a slot. The PR also updates fee jump calculation to reflect this.