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

core/txpool: remove locals-tracking from pools (part 2) #30559

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

holiman
Copy link
Contributor

@holiman holiman commented Oct 8, 2024

Replaces #29297, descendant from #27535


This PR removes locals as a concept from transaction pools. Therefore, the pool now acts as very a good simulation/approximation of how our peers' pools behave. What this PR does instead, is implement a locals-tracker, which basically is a little thing which, from time to time, asks the pool "did you forget this transaction?". If it did, the tracker resubmits it.

If the txpool had forgotten it, chances are that the peers had also forgotten it. It will be propagated again.

Doing this change means that we can simplify the pool internals, quite a lot.

The semantics of local

Historically, there has been two features, or usecases, that has been combined into the concept of locals.

  1. "I want my local node to remember this transaction indefinitely, and resubmit to the network occasionally"
  2. "I want this (valid) transaction included to be top-prio for my miner"

This PR splits these features up, let's call it 1: local and 2: prio. The prio is not actually individual transaction, but rather a set of addresses to prioritize.
The attribute local means it will be tracked, and prio means it will be prioritized by miner.

For local: anything transaction received via the RPC is marked as local, and tracked by the tracker.
For prio: any transactions from this sender is included first, when building a block. The existing commandline-flag --txpool.locals sets the set of prio addresses.

@holiman holiman force-pushed the local_pool_pt2 branch 2 times, most recently from cffa982 to 165e892 Compare October 11, 2024 07:19
@holiman holiman marked this pull request as ready for review October 11, 2024 07:58
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.

// Package legacypool implements the normal EVM execution transaction pool.
package tracking
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe rename it to tracker or txtracker?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea

core/txpool/tracking/tx_tracker.go Outdated Show resolved Hide resolved
)
for sender, txs := range tracker.byAddr {
stales := txs.Forward(tracker.pool.Nonce(sender))
// Wipe the stales
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stales refers to the transactions with nonce lower than tracker.pool.Nonce(sender).
However, tracker.pool.Nonce(sender) is the current pending nonce of the pool, including the executable txs applied.

Shouldn't we use statedb(latest_chain_head).Nonce(sender) instead?

Furthermore, do we care about the reorg here? should we care about the reorg here?

  • If we don't care, some local transactions might be dropped first and reorg occurs later, they won't be able to be resubmitted;
  • If we care, the "stale" local transactions should somehow be kept for a few (maybe a few blocks) and try to resubmit them if reorg occurs;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we use statedb(latest_chain_head).Nonce(sender) instead?

Yes, good observation!

Furthermore, do we care about the reorg here? should we care about the reorg here?

* If we don't care, some local transactions might be dropped first and reorg occurs later, they won't be able to be resubmitted;

* If we care, the "stale" local transactions should somehow be kept for a few (maybe a few blocks) and try to resubmit them if reorg occurs;

Once it's been included in a block, I think it can be untracked. It will most likely be picked up again if it's reorged. 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we use statedb(latest_chain_head).Nonce(sender) instead?

Yes, good observation!

No wait. Our job here is to make the pool accept the tx. If the pool already has nonce=5 from this sender, then we can consider nonce=5 as stale, and not worry about it anymore. I guess the caveat here is that it might be a replacement... :/

core/txpool/tracking/tx_tracker.go Outdated Show resolved Hide resolved
core/txpool/tracking/tx_tracker.go Outdated Show resolved Hide resolved
eth/backend.go Outdated Show resolved Hide resolved
core/txpool/blobpool/blobpool.go Show resolved Hide resolved
core/txpool/tracking/tx_tracker.go Outdated Show resolved Hide resolved
if isLocal {
localGauge.Inc(1)
}
pool.journalTx(from, tx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, the journal was not only for tracking local transactions, but also for non-local transactions before?

type lookup struct {
slots int
lock sync.RWMutex
locals map[common.Hash]*types.Transaction
remotes map[common.Hash]*types.Transaction
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can do rename in a following pr, just want to mention here

@rjl493456442
Copy link
Member

I think the general idea is good and it's a good direction to "distribute the complexity" of txpool graduately.

@holiman holiman force-pushed the local_pool_pt2 branch 2 times, most recently from e61a7cf to 82c9789 Compare November 4, 2024 08:59
@holiman
Copy link
Contributor Author

holiman commented Nov 4, 2024

TestUnderpricing is flaky in this PR. Not sure why

…ocal txs

core/txpool/legacypool: handle the case when journalling is disabled
core/txpool: store txs to journal on insert
…ing of recheck

core/txpool/tracking: add ability to trigger recheck externally
core/txpool: remove local param from api
eth/catalyst: update tests for new API
miner, eth: update tests for changed txpool api
eth/catalyst: remove trace-log-output from tests
core/txpool: fix nits, also store on insert
@holiman
Copy link
Contributor Author

holiman commented Dec 12, 2024

TestUnderpricing is flaky in this PR. Not sure why

Fixed (crosses fingers)

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

Successfully merging this pull request may close these issues.

2 participants