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

Unclear presentation of the new release #6031

Closed
RogerHKW opened this issue Oct 15, 2023 · 2 comments
Closed

Unclear presentation of the new release #6031

RogerHKW opened this issue Oct 15, 2023 · 2 comments
Assignees
Labels

Comments

@RogerHKW
Copy link

RogerHKW commented Oct 15, 2023

There are 3 things that I don't understand in the text of your new release. I can't update because of that.

  1. You cite several times "# 5772" but clicking the tag doesn't work in this text when I want to learn more about this change.

tx-pool-retention-hours: simply remove it, since it is not applicable in the Layered txpool, old transactions will eventually expire when the memory cache is full.

Isn't there a vulnerability here? By mistake (or with the goal to disturb all Besu nodes of the network), it can happen that accounts send transactions with nonces far enough in the future (up to +199) and, if the gas price is reasonable, these transactions will slowly start to clog our 2nd and 3rd layers, potentially squatting our pools forever if these accounts get abandoned before they reach such nonces.

--Xlayered-tx-pool-layer-max-capacity, --Xlayered-tx-pool-max-prioritized and --Xlayered-tx-pool-max-future-by-sender just drop the X and keep the same behavior

It contradicts what is written before. In the text above this paragraph, what seems to be dropped is Xlayered-. So, what should I drop to make sure that Besu understands my settings?

@non-fungible-nelson
Copy link
Contributor

@fab-10 will address questions 2 and 3 , thanks for these. I have fixed question number 1.

@fab-10
Copy link
Contributor

fab-10 commented Oct 17, 2023

tx-pool-retention-hours: simply remove it, since it is not applicable in the Layered txpool, old transactions will eventually expire when the memory cache is full.

Isn't there a vulnerability here? By mistake (or with the goal to disturb all Besu nodes of the network), it can happen that accounts send transactions with nonces far enough in the future (up to +199) and, if the gas price is reasonable, these transactions will slowly start to clog our 2nd and 3rd layers, potentially squatting our pools forever if these accounts get abandoned before
they reach such nonces.

Let's call these txs nonce-gapped, since they are not candidate for selection, due to the fact that for the same sender, preceding tx is missing, and thus introduces a nonce gap.
Actually, one of the goals of this implementation is to avoid that those nonce-gapped txs will clog the txpool, and prevent other new txs to be added.
Let me describe how we achieve this property with the new implementation, detailing the lifecycle of a nonce-gapped tx:

  • when we try to add it to the txpool we detected the nonce gap, and this means that it skips both the prioritized and the ready layers (since these layers only accept txs that are sequential with no gaps), so it directly goes to the sparse layer.
  • the sparse layer keeps track of all the gaps, and it will only promote a tx if has no more a gap
  • when the sparse layer if full, it starts evicting txs from the oldest
  • thus a nonce-gapped tx will always live in the sparse layer, until there is no more space and eventually it gets evicted, or the gap is filled and can be promoted, think of it like a purgatory for those kind of txs.
  • at the same time the prioritized and the ready layers are always free of these non-executable txs
  • even in the case the txpool is full, when a new sequential executable tx arrives in the pool, it will gets added even if the price is lower that all nonce-gapped txs, because we prefer executable txs and the space for it is recovered evicting the older sparse tx
  • so instead of regularly evict old txs, we evict them when the txpool is full, actually trying to fully utilize the space reserved for it

Test performed have confirmed that the layered implementation is much more robust than the legacy in preventing nonce-gapped txs from harming the txpool, if there is space they could be there for a long time, but will never prevent new good txs from being added and confirmed.

Hope this helps, the description in the release was necessarily high level, but I am happy to describe the details of the implementation, and hear about possible issues. See also #5290

--Xlayered-tx-pool-layer-max-capacity, --Xlayered-tx-pool-max-prioritized and --Xlayered-tx-pool-max-future-by-sender just drop the X and keep the same behavior

It contradicts what is written before. In the text above this paragraph, what seems to be dropped is Xlayered-. So, what should I drop to make sure that Besu understands my settings?

You are right, indeed there is an error in this section, and the right options are the ones above, will update the changelog, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants