Software Design: Introduce nonce caching

[haerdib]

Currently, every compose_extrinsic! call, calls the substrate storage. There's already a workaround for this by using ccompose_extrinsic_offline!, but it sure would be nice, to have a nonce cache that caches the nonce, and updates it with a storage request in case of a failure (e.g. mark it as dirty or something).

Complexity: When to revert nonce? What about future?

[Niederb]

Maybe in a first version we can introduce a NonceProvider trait that abstracts over getting the nonce and provide two simple implementations:

• LocalNonceProvider: Fetches the nonce only once and increases it automatically, but does not implement additional logic (fetching nonce again on error, ...). This one could also be useful for no_std where I don't have an Api instance.
• OnlineNonceProvider: The approach currently used that always fetches the nonce from the node

This will already be some work to think about how the trait should look, how to configure this and how to pass the NonceProvider around. We could then implement fancier nonce caching later on.

[haerdib]

I agree in general, but before doing all this work, we should probably make sure that a local nonce cache does make sense. At least theoretically. E.g. find out if such a cache could ever be robust enough to be applied in the field. What do you think?

[Niederb]

Yes, I agree and I think even this "simple" approach is more involved that it seems at first glance.

[haerdib]

Yes. I was just thinking about the separation of creating and sending extriniscs. The creation is done without the api, while the sending is done with it. For a cache, those two elements would need to be combined somehow. Otherwise, the cache could never be reverted / updated in case something goes wrong during sending.