Fix uid_lookup gas consumption

[l0r1s]

Summary

• Add per-subnet AssociatedEvmAddressCount storage and maintain it on association insert/remove/clear paths.
• Backfill the new count map from existing AssociatedEvmAddress entries during runtime upgrade.
• Use min(limit, associated_count) to precharge uidLookup iteration and bound the lookup to the charged read count.
• Expose associatedEvmAddressCount(uint16) on the UID lookup precompile for smart contracts.
• Account for the new association-count storage access in the associate_evm_key weight.

[github-actions]

🚨🚨🚨 HOTFIX DETECTED 🚨🚨🚨

It looks like you are trying to merge a hotfix PR into main. If this isn't what you wanted to do, and you just wanted to make a regular PR, please close this PR, base your changes off the devnet-ready branch and open a new PR into devnet ready.

If you are trying to merge a hotfix PR, please complete the following essential steps:

1. go ahead and get this PR into main merged, so we can get the change in as quickly as possible!
2. merge main into testnet, bumping spec_version
3. deploy testnet
4. merge testnet into devnet, bumping spec_version
5. deploy devnet
6. merge devnet into devnet-ready

If you do not complete these steps, your hotfix may be inadvertently removed in the future when branches are promoted to main, so it is essential that you do so.

[github-actions]

🛡️ AI Review — Skeptic (security review)

VERDICT: VULNERABLE

LOW scrutiny: established contributor with write permission; hotfix branch hotfix-uid-lookup targets main and is labeled/described as a hotfix.

No .github review-instruction changes, dependency changes, build-script changes, or supply-chain surface were introduced. Static review focused on the runtime storage/precompile changes and migration paths.

Findings

Sev	File	Finding
CRITICAL	pallets/subtensor/src/lib.rs:2603	Runtime storage change lacks spec_version bump	inline

Conclusion

The diff appears legitimate, but it changes runtime behavior and storage without a corresponding spec_version bump. That is a chain-safety issue that should block merge until the runtime version is updated.

---

🔍 AI Review — Auditor (domain review)

VERDICT: 👍

Gittensor: LIKELY by recent subtensor-heavy contribution pattern; author has write permission and substantial prior repo activity.

PR body is substantive and matches the implementation. Static audit found the hotfix narrowly scoped: it adds and backfills per-subnet EVM association counts, maintains the count on insert/remove/clear paths, uses that count to cap UID lookup gas precharging, exposes the count through the precompile, and adds focused tests for migration, cleanup, and precompile cost behavior.

Spec version is bumped to 426 for the main-targeted runtime change. I did not run tests or formatting scripts because no finding required runtime confirmation, and the workspace is clean.

Findings

No findings.

Conclusion

Approved. The count map is initialized by migration, updated on the relevant association lifecycle paths, and the precompile now meters only the bounded actual-read count while preserving the caller's lookup semantics up to that bound.

[github-actions]

🔄 AI review updated — Skeptic: SAFE Auditor: 👍

[github-actions]

🔄 AI review updated — Skeptic: SAFE Auditor: 👍

[github-actions]

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

[github-actions]

[CRITICAL] Runtime storage change lacks spec_version bump

This PR adds runtime storage and migration/precompile behavior, but the diff does not bump runtime/src/lib.rs spec_version (it remains 425). Runtime-affecting changes must advance spec_version; otherwise nodes with an old native runtime at the same spec can treat old native code as equivalent to the upgraded Wasm, risking divergent execution or silently missing this hotfix. Add the runtime version bump in this PR before merging to main.

[github-actions]

🔄 AI review updated — Skeptic: VULNERABLE