Vision: Easily verifiable key-less accounts

[emostov]

Some use cases require creating a key-less account that can be easily verified by a DApp.

Currently, the only way to do this with a substrate FRAME pallet is to spawn an anonymous proxy account and then remove all keys from the account. To prove that an account is key-less, one would need to verify both 1) that the account was created with a proxy::Call::anonymous extrinsic and 2) that the account has no proxies in the proxy::Proxies map.

Assuming a DApp wants to exclusively rely on node RPCs (and not any indexing services), looking up historical extrinsics just to check if accounts might be keyless is unreasonably expensive. Instead, it would be helpful if a DApp could perform perform just a few lookups to prove an account is keyless.

Some possible ideas:

• Create a map in the proxy or system pallet that stores if an account if it does not allow_signatures, which could be set for an account at any time to make it key-less. This could also be added to the AccountInfo storage item. A signed extension would then need to be added in order to check if the origin is allowed to sign
• Create a map of anonymous proxy account -> spawner (or just a bool if we don't think its necessary to store the spawner)

In either of the aforementioned ideas we should consider cleaning up key less account metadata once they are dusted. This can be done with the OnAccountDeleted hook. However one might argue that if an account is set to not have a signature, it should forever not be able to have one, and thus should not be cleaned up

[xlc]

2) that the account has no proxies in the proxy::Proxies map.

What's the reason of this? It will be inaccessible. There are easier way to generate an inaccessible accounts.

[emostov]

2. that the account has no proxies in the proxy::Proxies map.

What's the reason of this? It will be inaccessible. There are easier way to generate an inaccessible accounts.

Yeah, the goal is to have a provably inaccessible account. What are easier ways to generate one?

[xlc]

Just like how all the system accounts are generated. You concatenate bunch of known bytes together.

e.g. modlpy/cfund:2000 or 13UVJyLnbVp77Z2t6rXwoAfLPiGe6FVeKuTYPC4T8zWZ8vTS https://polkadot.subscan.io/account/13UVJyLnbVp77Z2t6rXwoAfLPiGe6FVeKuTYPC4T8zWZ8vTS

If the pub key is ^modlpy\/cfund:\d{4}\0+$ then it must be a Crowdloan funding account without private key.

[emostov]

Ah thanks, I see what you mean. To clarify, the use cases I am targeting would be allowing an accessible account to converted to an inaccessible account. For example, if some pallet requires an admin role, one could use an account as the admin to do setup and then make the admin inaccessible.

[xlc]

In that case, can you just allow the admin role to be replaced? And then you can replace it with a known inaccessible account.

[emostov]

In that case, can you just allow the admin role to be replaced? And then you can replace it with a known inaccessible account.

Good point, not sure if I can think of a use case then.

There should still be some set of standardized ways for UIs to determine if a pub key is inaccessible. For example if we can determine system pub keys because they start with modlpy/, could we establish some other standardized prefix for user generated keys? Then any UI that detects one of these prefixes can be fairly confident an account is inaccessible.

[xlc]

I don't have context, but can't it just be always the same one? Why do you need to generate multiple those inaccessible accounts? I would suggest to use the all zero address for that but it is not the a good idea anymore. But I guess we can use the all one address?

[bkchr]

For example, if some pallet requires an admin role, one could use an account as the admin to do setup and then make the admin inaccessible.

What is the point of this? This would mean the admin role would never be usable again? If that is the case, you could also just use a admin: Option<AccountId> and if that is a None, then the admin is inaccessible.

[emostov]

Yeah, I agree. I don't think I have a concrete use case then for making an accessible account inaccessible