[feature] Allow association with an EVM address

[camfairchild]

Add a map for ss58 to EVM address for associations to be on-chain.

Should also be queryable via EVM.

Must include a signature of the EVM key to prove ownership of both keys.
E.g. a signature of the ss58 pubkey.

[ppolewicz]

The EVM key should sign not just the ss58 of the neuron that's setting the association, but also a hash of a relatively recent block (say from no more than 10 blocks ago).

The new function for selective fetching of the metagraph should be able to return info about the EVM address as a column containing h160 of the associated EVM key as well as the block in which it was signed (specifically the block that the hash was signed by the EVM key, not the block number in which the association has been made)

[keithtensor]

There should be a storage map from (netuid, uid) -> (H160 hash of the EVM key, block it was signed) in the substrate side, and the corresponding extrinsics to CRUD the map.

There should also be a function in the EVM precompiles in the reverse direction, i.e. (netuid, H160 hash of the EVM key) -> sorted list of (uid, block it was signed).

One thing to note is that the ss58 should map to only 1 EVM key, whereas the reverse is not true -- an EVM key is allowed to have multiple ss58 keys associated with it, so when we return the data from the EVM precompiles, we'll want to sort the list of ss58 keys by the last block that it was signed on.

We should also allow for an optional parameter for a limit of items that gets returned by the map in the EVM precompiles, so that callers get to decide how many items they want.

[camfairchild]

There should be a storage map from (netuid, uid) -> (H160 hash of the EVM key, block it was signed) in the substrate side, and the corresponding extrinsics to CRUD the map.

This is probably easier to just be (ss58, netuid) -> H160, with no need for per-uid in-case of de-registration, although this may be easier when pulling the neuron info/metagraph.

There should also be a function in the EVM precompiles in the reverse direction, i.e. (netuid, H160 hash of the EVM key) -> sorted list of (uid, block it was signed).

I imagine it should be possible with this requirement, but this mapping should be accessible on the substrate-side also.

[camfairchild]

There should also be a function in the EVM precompiles in the reverse direction, i.e. (netuid, H160 hash of the EVM key) -> sorted list of (uid, block it was signed).

One thing to note is that the ss58 should map to only 1 EVM key, whereas the reverse is not true -- an EVM key is allowed to have multiple ss58 keys associated with it, so when we return the data from the EVM precompiles, we'll want to sort the list of ss58 keys by the last block that it was signed on.

We only require the most recent association per-netuid

[ppolewicz]

final storage map shape:

(netuid, uid) -> (h160, block_at_which_ownership_was_proven)

[mateuszsrebrny-reef]

I was thinking - wouldn't it be neat if the mapping could also be accessible from within the smart contract (ie as a precompile)?
I mean if the smartcontract was to do something like getStake it needs to know the ss58, it would be nice if it didn't have to get it from the caller, wouldn't it?
Not sure if this is the same feature request though?

[keithtensor]

This is done in #1418 and #1518.