Мempool

[joelreymont]

Tracking ticket for all the things mempool.

• Implement the mempool Implement the mempool #16.
• Update mempool when receiving transactions Update mempool when receiving new transactions #72.
• Add new transactions to block while mining Add new transactions to block while mining #68.
• Delete transactions from the mempool when adding a block to our chain Delete transactions from the mempool when adding a block to our chain #232.
• Return transactions to the mempool when discarding a block Return transactions to the mempool when discarding a block #233.
• Syncing and the mempool Syncing and the mempool #186.
• Transactions are not to be added to the mempool if they already exist Transactions are not to be added to the mempool if they already exist #230.

[sennui]

moving the note here:

Add ticket to improve mempool (batch API for delete) Consult with Luca. I commented and accepted the first PR #240)

[sennui]

where do we want to catch duplicated transaction. Current solution will not catch two same txs with different fees

[sennui]

cc: @lucafavatella ^^

[lucafavatella]

@zp-sd I added in backlog of “Core” project a note “Optimize mempool”.

Currently in master the mempool process is only responsible for (1) initializing the txs in-memory storage and (2) proxying peek/put/delete operations. Wrt potential future changes to mempool for limiting transfer of data between heaps of mempool process and its client (that we briefly mentioned yesterday), responsibility (2) may be removed from mempool process by choosing an in-memory sorted ETS table (and catch a few error cases when attempting to peek multiple txs) - hence removing the mempool process from peek/put/delete operations. Though I suggest deferring optimizations like this to after the usage of the mempool is more firmly established e.g. nature of key, potential secondary indexes, and guarantee of additional constraints needing the serializing process.

[joelreymont]

https://www.pivotaltracker.com/epic/show/3784794