Reject transactions for already spent coins

[xgreenx]

Description

Our e2e tests were flaky, example: https://github.com/FuelLabs/fuel-core/actions/runs/14343235447/job/40207476637

The reason was that during transaction reconciliation(after we fixed that), we included transactions that had already been executed and confirmed in the pending pool. After the timeout on the pending pool we will remove all dependent transactions, and in the case of the test, it was a transaction from another test suite that used Change output(which already was confirmed and existed on the chain) of the transaction from the first test suite.

So basically, the e2e tests revealed that it was possible to submit transactions with already spent inputs, which will be included in the pending pool and later discarded along with all dependent transactions(even if outputs already were stored on the chain as coins).

This change rejects transactions immediately, if they use spent coins. TxPool has a SpentInptus LRU cache, storing all spent coins.

Checklist

• New behavior is reflected in tests

Before requesting review

• I have reviewed the code myself

[AurelienFT]

LGTM. The tx pool start to have a lot of little caches maybe we should try to generalize them etc in the future

[AurelienFT]

nit: I would prefer a naming such a mark_input_as_spent or confirm_input_spent from what I understand it helps to understand the code

[MitchTurner]

Is it possible to move these tests to the service level? I don't think we should have tests on the internal details of the service.

[rymnc]

nice

[rymnc]

something like -

Suggested change

	pub struct SpentInputs {
	/// Use LRU to support automatic clean up of old entries.
	spent_inputs: LruCache<InputKey, ()>,
	/// When it is unclear whether an input has been spent, we want to store which
	/// transaction spent it. Later, this information can be used to unspent
	/// or fully spend the input.
	spender_of_inputs: HashMap<TxId, Vec<InputKey>>,
	}
	pub struct SpentInputs {
	/// Use LRU to support automatic clean up of old entries.
	spent_inputs: LruCache<InputKey, ()>,
	/// Direct-indexed vec for transaction data
	tx_data: Vec<Option<(TxId, Vec<InputKey>)>>,
	/// Number of active entries
	tx_count: usize,
	}

just an idea, given the following assumptions/reasoning -

• TxId already hashed, we don't want to double hash it for insertions
• HashMap has poor cache locality ~ if it is large enough then we might remove other important things from the cpu cache. i'm assuming here that this will be a huge cache with xxx
• i think it is worth it to benchmark with real characteristic of how the txpool calls these functions

[xgreenx]

Vec<Option<(TxId, Vec<InputKey>)>> means that we need to remove from the middle of the vector, plus the search here will be slow. It is possible that complexity will be O(n) instead of O(1)

[rymnc]

search can be O(1) if we use https://www.ietf.org/archive/id/draft-eastlake-fnv-21.html / equivalent to compute an index with a given TxId.

[xgreenx]

Still, removal is O(n)=) Plus this HashMap will be in most cases small or empty

[rymnc]

O(n) only in rare cases though. if you expect the hashmap to be small then there will be no collisions and therefore removal will be O(1) then