Transaction Pool docs

[tomusdrw]

Additional high-level documentation for the transaciton pool. Includes a problem statement that should be independent from the current implementation and some implementation hints + high level description of the current code.

[tomaka]

Note that my suggestions about English languages are suggestions, I'm not good at language

[tomaka]

The implementation notes don't mention anything about this?

[tomusdrw]

Added an extra paragraph on that.

[tomaka]

I don't understand the "privacy leaking" part. The transactions that are in a block's body are always equal to the one in the pool, no? Even if you're not propagating a transaction, once it's included in a block, the block itself will be propagated.

[tomusdrw]

I expanded the paragraph a bit cause it wasn't phrased very well. The point was mostly about being front runned by someone. Imagine that as a block author you find some solution to an on-chain puzzle and instead of propagating it you only include it in your own block. Or you want to report equivocation (a be rewarded for that) without letting anyone else to simply copy your finding.

[tomaka]

Maybe it should mention that when receiving transactions with the same bytes multiple times, it is only included once in the pool.

[tomusdrw]

Actually this is something that we deduct indirectly from provides tag description. I've added a point to "Implementation suggestions". Let me know if that suffices.

[tomaka]

Actually this is something that we deduct indirectly from provides tag description.

That's an interest take on this, but it implies that we should add the same transaction multiple times in the pool in case the provides tag is empty.

But this raises lots of questions, for example: if you receive the same transaction twice from the network, how do you know whether they're a unique transaction that's been gossiped around, or if it's actually two different people who have submitted the same transaction?
And if we prune transactions from the pool only if a transaction whose provides overlaps has been included in a block, that means we'd never prune transactions where provides is empty?

[tomusdrw]

That's an interest take on this, but it implies that we should add the same transaction multiple times in the pool in case the provides tag is empty.

The provides tag list cannot be empty (I mention that in the document) - such transactions should be considered invalid, we could panic in the runtime call actually if someone tries to do that, but the current pool implementation refuses to import such transaction for sure.

if it's actually two different people who have submitted the same transaction?

If the transaction is signed, it will contain two different signatures, so it's not the exact same payload. If it's unsigned, then well, I'd argue that de-duplication is sensible, cause it's literally nothing that allows us to distinguish one transaction from the other (or identify the sender for instance).

[gilescope]

Fantastic read - thank you so much for documenting this.