feat: allow vault to store client version on-chain

[sander2]

The main use case of this feature is to be able to notify the vault in the UI if they are running an outdated vault. It will also be interesting for statistics to see how fast vaults upgrade.

It does not currently emit an event - should it?

[gregdhill]

@sander2 did you have a chance to look whether Substrate has any offerings for such functionality (also for the heartbeat mechanism)? I think we could maybe reuse the identity pallet for this.

[sander2]

@sander2 did you have a chance to look whether Substrate has any offerings for such functionality (also for the heartbeat mechanism)? I think we could maybe reuse the identity pallet for this.

It's possible but less efficient and more cumbersome: we would have to call set_identity from the vault client, which has to take IdentityInfo, which is a huge struct. So it'd be a lot more costly in fees, and also more work to read and modify this in the client. Imo it's not worth it.

[nud3l]

I would be OK with adding this feature as proposed by @sander2.

Substrate technically supports off-chain indexing: https://docs.substrate.io/how-to-guides/v3/ocw/indexing/

Pro:

• No tx cost to write to storage

Con:

• Nodes need to opt-in to sync off-chain storage (need to make sure Vaults connect to a node that has it enabled)
• Not sure if this is supported in subxt

My suggestion is to add a low-prio ticket to investigate the iff-chain index option further also in context of a heartbeat.

[sander2]

I didn't know about off-chain storage, interesting. If we're really worried about storage though, another approach could be to only emit an event and then to rely on squid to do storage for us. Although now that I think about it, even an event needs to be stored somewhere, so I guess it would end up using the same amount of disk space as using a storage item

[sander2]

not really a prio, especially now that we have the runner. Could be nice for statistics but that's about it