fix: map to hotkey not uid

[distributedstatemachine]

Description

This PR improves the user experience and data integrity of EVM address associations by changing the storage from UID-based to hotkey-based. Since UIDs can be recycled when neurons are deregistered and re-registered, the current implementation leads to confusing UX where querying by UID might return EVM associations from previous neuron owners.

Problem

The current implementation stores EVM address associations using the storage map:

StorageDoubleMap<_, _, NetUid, _, u16, (H160, u64)>  // (netuid, uid) -> (evm_address, block)

Additionally, the association logic already requires signing with the hotkey, making it more logical to store the association by hotkey rather than by UID.

This creates a suboptimal user experience:

1. User A registers a neuron, gets UID 5, and associates their EVM address
2. User A deregisters their neuron
3. User B registers a new neuron and gets the recycled UID 5
4. Querying UID 5's EVM association now incorrectly returns User A's EVM address

Solution

This PR changes the storage to use hotkeys instead of UIDs:

StorageDoubleMap<_, _, NetUid, _, T::AccountId, (H160, u64)>  // (netuid, hotkey) -> (evm_address, block)

Hotkeys are permanent and unique to each account, preventing any inheritance issues.

Changes Made

1. Storage Map Update

• File: pallets/subtensor/src/lib.rs
• Changed AssociatedEvmAddress to map from (netuid, uid: u16) to (netuid, hotkey: T::AccountId)

2. Core Function Updates

• File: pallets/subtensor/src/utils/evm.rs
  • Updated do_associate_evm_key to store by hotkey instead of uid
  • Removed unnecessary UID lookup since we're storing directly by hotkey
  • Renamed uid_lookup to hotkey_lookup with updated return type

3. Precompile Updates

• Files: precompiles/src/hotkey_lookup.rs (renamed from uid_lookup.rs), precompiles/src/lib.rs
  • Renamed UidLookupPrecompile to HotkeyLookupPrecompile
  • Updated function signature to return hotkey addresses instead of UIDs
  • Updated precompile registration and enum values

4. Admin Utils Update

• File: pallets/admin-utils/src/lib.rs
  • Updated PrecompileEnum::UidLookup to PrecompileEnum::HotkeyLookup

5. Migration Implementation

• Files: pallets/subtensor/src/migrations/migrate_evm_address_to_hotkey.rs, pallets/subtensor/src/migrations/mod.rs, pallets/subtensor/src/macros/hooks.rs
  • Created migration to convert existing storage entries from uid-based to hotkey-based
  • Added migration to the runtime upgrade hook
  • Handles orphaned entries where neurons have been deregistered

Breaking Changes

This is a breaking change that affects:

1. Storage Migration Required: Existing EVM address associations need to be migrated from UID-based to hotkey-based storage
2. API Changes:
   • The uid_lookup function is now hotkey_lookup and returns hotkeys instead of UIDs
   • Precompile function changed from uidLookup to hotkeyLookup
3. Client Updates: Any clients querying AssociatedEvmAddress storage will need to update their code to use hotkeys instead of UIDs

Testing

• Verify do_associate_evm_key correctly stores by hotkey
• Test hotkey_lookup returns correct hotkeys for given EVM addresses
• Verify precompile works correctly with new signature
• Test that deregistering and re-registering neurons doesn't inherit EVM associations
• Ensure storage migration correctly converts existing data

Migration Plan

A storage migration has been implemented in migrate_evm_address_to_hotkey.rs that:

1. Reads all existing (netuid, uid) -> (evm_address, block) entries
2. Looks up the hotkey for each uid using the Keys storage map
3. Stores the data in the new format (netuid, hotkey) -> (evm_address, block)
4. Handles orphaned entries where the neuron has been deregistered
5. Logs migration statistics including migrated and orphaned counts

The migration is automatically executed during runtime upgrade.

Related Issue(s)

• Closes #[issue number]

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run cargo fmt and cargo clippy to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.