Remove the caching as long as we are not using it. about anon HOT 3 CLOSED

We will need a simpler form of caching where we save the latest root hash every few blocks, just so the clients can create proof against it and submit it before it changes. #8 (comment)

from anon.

The solution mentioned above will still leave some failing transactions so, in order to provide a smooth experience, a simpler solution can be like:

Just have a linked list of the last n root hashes, keep track of the head and the tail in the list. Every t blocks remove the tail root hash and insert the current one (taken from storage) to the head of the list. This linked list can be implemented with BTreeMap. This is done inside the on_finalize inside mixer pallet, but there will be a standalone function inside the Merkle pallet, so people can call it on demand

Improvements from the current caching strategy:

1. No need to pass the block number to specify where is the root hash that you constructed proof for (for v1 at least)
2. Smaller memory footprint

from anon.

So the feeling I'm getting is that we shouldn't touch the cache at all. It is sufficient for the use case atm and is efficiently implemented in the module's storage. It supports pruning to arbitrary length as specified in the runtime and we can set this to be anything reasonable for now.

As for block number, since we always carry it forward. You can just query latest block - 1 to get the previous root to prove against.

from anon.