core/txpool: remove locals-tracking from pools (part 2) #30559
Conversation
holiman
force-pushed
the
local_pool_pt2
branch
2 times, most recently
from
cffa982
to
165e892
Compare
holiman
requested review from
gballet,
lightclient,
karalabe and
rjl493456442
as code owners
core/txpool/tracking/tx_tracker.go
Outdated
| // 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 |
There was a problem hiding this comment.
maybe rename it to tracker or txtracker?
core/txpool/tracking/tx_tracker.go
Outdated
| ) | ||
| for sender, txs := range tracker.byAddr { | ||
| stales := txs.Forward(tracker.pool.Nonce(sender)) | ||
| // Wipe the stales |
There was a problem hiding this comment.
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;
There was a problem hiding this comment.
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. 🤷
There was a problem hiding this comment.
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... :/
| if isLocal { | ||
| localGauge.Inc(1) | ||
| } | ||
| pool.journalTx(from, tx) |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
we can do rename in a following pr, just want to mention here
|
I think the general idea is good and it's a good direction to "distribute the complexity" of txpool graduately. |
…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
force-pushed
the
local_pool_pt2
branch
from
165e892
to
165f71b
Compare
holiman
force-pushed
the
local_pool_pt2
branch
from
e61a7cf
to
82c9789
Compare
|
|
Replaces #29297, descendant from #27535
This PR removes
localsas 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
localHistorically, there has been two features, or usecases, that has been combined into the concept of
locals.This PR splits these features up, let's call it
1: localand2: prio. Thepriois not actually individual transaction, but rather a set ofaddresses to prioritize.The attribute
localmeans it will be tracked, andpriomeans it will be prioritized by miner.For
local: anything transaction received via the RPC is marked aslocal, and tracked by the tracker.For
prio: any transactions from this sender is included first, when building a block. The existing commandline-flag--txpool.localssets the set ofprioaddresses.