Summary
In the x/name module, for the name records, use a hashed version of the full name as the key instead of a hashed version of the segments.
Problem Definition
In the x/name module, when storing a name record, we use a key that's the result of extracting all the name segments and hashing them. This has two problems: 1) It's a lot of extra work for nothing. 2) It can cause collisions in the keys for different names.
Proposal
Since this is changing the keys used to read/write some records, it'll require a migration.
Update getNamePrefixByType (in x/name/types/keys.go) to just get a hash of the full name (rather than splitting it and using the segments. You'll need a copy of the original function for the migration, though.
Then, create a migration that looks up all the old keys, deletes the entry, and re-writes it using the new key. This migration should be done as a module migration (i.e. bump the module's consensus version etc.).
For Admin Use
Summary
In the
x/namemodule, for the name records, use a hashed version of the full name as the key instead of a hashed version of the segments.Problem Definition
In the
x/namemodule, when storing a name record, we use a key that's the result of extracting all the name segments and hashing them. This has two problems: 1) It's a lot of extra work for nothing. 2) It can cause collisions in the keys for different names.Proposal
Since this is changing the keys used to read/write some records, it'll require a migration.
Update
getNamePrefixByType(inx/name/types/keys.go) to just get a hash of the full name (rather than splitting it and using the segments. You'll need a copy of the original function for the migration, though.Then, create a migration that looks up all the old keys, deletes the entry, and re-writes it using the new key. This migration should be done as a module migration (i.e. bump the module's consensus version etc.).
For Admin Use