Simplemempool's state may blow up if client's request throughput exceeds availability layer's throughput.

[ranchalp]

Client's requests are saved in memory as part of the mempool's state in state.NewTxIDs, memory that is released once a number of requests are provided to the availability layer. If the availability layer requests transactions at a slower rate than clients request are received, eventually state.NewTxIDs will blow up.

[matejpavlovic]

Yes this is true. This can be mitigated by making the mempool aware of client watermarks (expressed through the ClientProgress data structure in the code), where the system would start ignoring transactions from a client if too many are already pending. The number of transactions could technically still explode if too many different clients submitted a few transactions each. Another solution would be to simply limit the size of the mempool and plainly refuse transactinos if the mempool is full. That would require a mechanism for letting the client know about it, so it knows whether to try to resubmit or not.

All that said, this is a low-priority issue for the moment, as the first use of Mir is with Lotus, which uses its own mempool. Currently, the Simplemempool is only used for testing and demos.