GH-16 Implement mempool #240
Conversation
Using iterator for not creating the list of all txs in memory from storage using `gb_trees:iterator/1` was initially [drafted by Artur](f4319ba#diff-2e95a69d7723aebad303814cb3f38e7eR92), though passing the iterator to the calling process (hence moving it across process heaps). Sorting integers in decreasing order by using opposite of fee was [drafted by Artur](f4319ba#diff-2e95a69d7723aebad303814cb3f38e7eR99). Wrt key, apart from fee in key for sorting, the rest of the key can be made smaller. E.g. [Artur had drafted](c375b04#diff-2e95a69d7723aebad303814cb3f38e7eR100) using a key resulting from concatenation of opposite of fee and some hash of the transaction: ``` Hash = aec_tx:hash(SignedTx), Key = <<MinusFee:64,Hash/binary>>, ```
| ?assertEqual({ok, [STx4]}, aec_tx_pool:peek(10)), | ||
|
|
||
| %% A tx already in chain now received from peers. | ||
| ?assertEqual(ok, aec_tx_pool:push(STx2)), |
There was a problem hiding this comment.
If STx2 is already in a chain and we re-add it to the pool, such tx will be removed from the pool in mining attempt? Mining shall recognize it as duplicate then?
There was a problem hiding this comment.
If STx2 is already in a chain and we re-add it to the pool, such tx will be removed from the pool in mining attempt?
Txs are removed from pool when added in chain - see GH-236. Mining itself is not meant to remove txs from pool. After successful mining, if mined block added to chain then txs in block shall be then removed.
Mining shall recognize it as duplicate then?
Yes, thanks to nonce. Mining attempts to apply txs. Each tx is meant to contain initiating account and its nonce, and each tx is meant to ensure nonce in account is strictly less than nonce in txs. So duplicated tx is detected by mining, and mining shall delete such tx from pool.
Closes GH-16.
Complies to GH-236.
Includes API for updating the mempool when receiving new transactions (GH-72).
Supersedes PR #238.