ethereum
feat(txpool): only try demoting txns from accounts that were active
txpool demotes pending txns only if their nonce is now lower than the nonce in the latest state
or the account no longer has enough funds to cover the costs. Unless the account in question
was active since the last txpool reorg, there is no way that it's nonce changed or balance decreased.
for time periods where txpool is heavily congested, demote can take multiple seconds due to all the state access that it needs to do per pending ~~txn~~ account.
From a glance, it appears the IO overhead is per account in the pending set (balance + nonce lookup). not per tx.
I think it might be a reasonable change. Have you ever estimated how much performance gain we can have with this change? Or do you know what's the ratio between the all pending accounts and the active accounts?
I think it might be a reasonable change. Have you ever estimated how much performance gain we can have with this change? Or do you know what's the ratio between the all pending accounts and the active accounts?
I don't have numbers on ETH mainnet, but on Scroll this change brought demoteUnexecutables runtime from ~800msecs to ~15msecs with roughly 28k pending txns. But keep in mind Scroll blocks are significantly smaller (~80Txns)
We've discussed this a bit on triage today, but figured we'll let it marinate a bit more. One one hand we agree that it's a meaningful optimization and it's already something we do in the blobpool. On the other hand, the current code has a bit of self-corrective behavior if some invariant breaks internally, whereas the proposal requires a much higher degree of correctness.
Wondering if it would be a saner approach to move out the unexecutables into a limbo and redesign the pool from scratch. It's something we've always wanted to do but it's not really a quick thing at all. Lets ponder about it a bit more.
I've been assigned on this PR for a while, and I think it would've been a good idea back then. But it looks like we can no longer rely on the core assumption after EIP-7702. Specifically, since any number of delegated accounts can be touched by a transaction, and delegated accounts can also send transactions, we do have to re-check all accounts in the txpool.
