Static metadata validation

[gregdhill]

Splitting this out from #309 for discussion. It is important for us that our clients cannot interact with a chain whose runtime differs from that which it was built with (except in special circumstances). @ascjones @dvdplm how do you think that we can implement this? The simplest solution would be to embed a hash of the metadata source and compare on startup but I'm not sure how to provide more granular permissioning.

[jsdw]

It feels like there is an immediate benefit to being able to hash the runtime-acquired metadata and compare with that used for codegen (and that would be a fairly easy thing to add); is that fair to say, or is it not particularly useful to you without more granular permissioning?

w.r.t more granular permissioning, I wonder what level makes sense to do it on? We could for instance work at the pallet level, hashing pallet information and spitting out errors/warnings when you try interacting with pallets that aren't identical. We could also be even more granular and do some sort of per-call hashing.

Offhand it feels like verifying things at the pallet level feels like a good compromise between granularity and ease of use (we could expose for instance a single function that verifies the pallet codegen against the runtime metadata, and a general config function to prevent any calls to incompatible pallets).

What is your use case @gregdhill, and what sort of granularity makes the most sense for it?

I'd love to gather some thoughts on this! from others too.

[dvdplm]

w.r.t more granular permissioning, I wonder what level makes sense to do it on?

This an interesting one; it really depends on the application. A wallet might only care about a reduced subset of changes to a subset of pallets, and work fine with other metadata changes. A crowdloans-related app a separate subset, etc.

It feels like this could be an almost arbitrarily complex feature, all the way from blocking using single calls, pallets or storage items to just refusing to start on a mismatch of the full metadata.

I'd say we definitely want a way to configure subxt's behaviour on full metadata hash mismatch (panic? error? no error until first call?). And likely a pallet-level configuration as well, but that requires some deeper thought on the design.

[ascjones]

I think full and pallet level metadata validation will be good enough.

Full metadata validation, performed by the ClientBuilder after fetching the metadata:

subxt/subxt/src/client.rs

Line 99 in abd7a41

let metadata = metadata?;

. This validation should provide an explicit opt out e.g. .skip_full_metadata_validation().

And then pallet level validation, performed on the codegen generated pallet method e.g. tx().balances(). Again this could be disabled globally at the ClientBuilder, or even as another method on the pallet api builder to configure it for individual pallets. Not sure that makes sense though.