Signed Metadata

[Slesarew]

Currently the Signer needs trusted authority to verify correctness of metadata used. We could make this trustless if we require allow (edit 1: Signer should not be allowed to sign transactions with trivial blank metadata hash then) every transaction to include metadata hash into signed payload - this way the chain will be constantly verifying metadata validity instead of a trusted party.

This bears very little additional costs, deprecates lots of complex and confusing logic in Signer and makes automated generation of updates possible. Metadata portal might be reduced to a simple untrusted page with generator script since any attack on it will lead to Signer's DoS which is desired behavior.

[bkchr]

This is about creating a signed extension that passes the metadata hash as additional signed data to the signature creation.

The signed extension should be fairly simple to implement, the problem for now is how to get the metadata hash in an efficient way.

[kirushik]

In general I like the idea; this would also probably superseed the transaction_version field.

What worries me, though, is how is it going to work "at margins" for transactions around the runtime upgrade enacted: will we invalidate the whole transaction pool immediately on each minor runtime upgrade?
Will we have a grace period around this, accepting both?
Would we allow issuing transactions for not-yet-accepted runtime in the pool (probably waiting for the relevant upgrade to be enacted)?

[Slesarew]

We could match metadata to block mentioned in mortality for mortal transactions. Not for immortal ones though. Are immortal ones important?

[bkchr]

In general I like the idea; this would also probably superseed the transaction_version field.

Not really, a runtime upgrade, aka changing metadata doesn't mean the transaction version changed.

What worries me, though, is how is it going to work "at margins" for transactions around the runtime upgrade enacted: will we invalidate the whole transaction pool immediately on each minor runtime upgrade? Will we have a grace period around this, accepting both? Would we allow issuing transactions for not-yet-accepted runtime in the pool (probably waiting for the relevant upgrade to be enacted)?

We are already rejecting all transaction from a previous runtime version. CheckSpecVersion is doing that.

[xlc]

The real question is how to have the signer verify the metadata hash trustlessly? It needs to run a light client? But I am not sure if it is possible for air gapped wallet?

We also needs to commit metadata hash to onchain state, which sounds like a complicated task to me. You will want to do it with on_runtime_upgrade instead of a separate tx, so you will need to build a runtime, get metadata hash, and embed it into the runtime.

[bkchr]

The real question is how to have the signer verify the metadata hash trustlessly? It needs to run a light client? But I am not sure if it is possible for air gapped wallet?

The point of this being that the signer doesn't need to be able to verify the metadata at all. It will build the tx, based on the metadata that the user provided. The signature will then include the metadata hash, similar as we do it for spec_version. The runtime will then also add the metadata hash and if that uses a different hash, the signature verification will fail.

We also needs to commit metadata hash to onchain state, which sounds like a complicated task to me. You will want to do it with on_runtime_upgrade instead of a separate tx, so you will need to build a runtime, get metadata hash, and embed it into the runtime.

We could just include the metadata hash as part of the build process. Build the runtime once, get the metadata, generate the hash, build the runtime again and include the hash.

[kianenigma]

I'm kinda inclined to make this happen on the runtime and give a push to the ecosystem (Polkadot and Kusama included) to catch up. I think this will instigate more novel ways to distribute the metadata as well. Seems like a solvable problem, just stuck in a stalemate.

[jak-pan]

Is there any progress on this?

It looks like this will greatly enhance UX for everybody including developers and users. I'm currently working on implementation for HydraDX and Basilsik and we would love to see more widespread use of Parity signer so users can seamlessly use it between the parachains.