WIP: core/txpool/localpool: sketch up idea of the localpool

[MariusVanDerWijden]

PoC of a standalone subpool for local transactions, this would allow us to remove handling of locals in the main txpool

My main ideas:

• Most important thing about local transactions is the persistency
• If you need more than x local transactions, you should build your own thing on top
• Reorging should not take much time and can be done on the main thread
• Because local transactions are trusted, we can get along with way fewer safeguards in place imo

I added a (very preliminary) benchmark which shows that the reorg routine can be executed in < 2ms for 1 million transactions that are dropped (as long as no transactions are resurrected)

[MariusVanDerWijden]

The data structure itself is basically the same idea as @holiman's local limbo locals-tracker, but implemented as a subpool instead . The more I think about it, the better I like the idea of the local limbo locals-tracker
I'm going to close this for now, but I think we should really move the local handling out of the main transaction pool in order to reduce its complexity

[holiman]

Wait. Just want to clear up any misconceptions...

The 'limbo' idea is a to remove the notion of queued. The non-executable txs would land in "limbo", and a short time later either graduate as executable or removed entirely (#27004) .

The 'locals-tracker' idea is to NOT use a txpool/subpool for handling locals, at all, but instead just use a little standalone tracker. Said tracker does, from time to time, check if geth "remembers" a transaction, and if not, submits it again (#27535). The idea being that the actual txpool is a good simulation of the peer txpools, so if the local txpool accepts it (and broadcasts it), then the peers might also accept it (again).

[MariusVanDerWijden]

No misconceptions, I just didn't know that you called it locals-tracker (I thought local-limbo kinda describes it well, but I think your nomenclature is easier to distinguish)