Release v444: remove miner-burn scaling from subnet emission shares - #3058
Conversation
…lude issue 2445 notes.
…n evm maintainer skill
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
VotingPower::<T>::iter() performs an unbounded synchronous scan from on_runtime_upgrade. The returned weight is calculated only after all entries have already been read, so it cannot prevent upgrade execution from exceeding the block limit as this map grows. Convert this to a bounded, resumable migration with a persisted cursor and explicit per-block budget.
|
🔄 AI review updated — Skeptic: VULNERABLE |
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
VotingPower::<T>::iter() performs an unbounded synchronous scan during on_runtime_upgrade, while also accumulating every subnet total in memory. Existing state size therefore controls both execution weight and memory use, potentially preventing the runtime upgrade from completing. Convert this to a bounded, resumable migration with persistent progress, and mark it complete only after the final batch.
|
🔄 AI review updated — Skeptic: VULNERABLE |
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
This iterates every VotingPower entry synchronously during on_runtime_upgrade, with no bound or resumable cursor. The returned database weight is calculated only after completing the scan, so a sufficiently large map can make the upgrade block exceed its execution budget and jeopardize chain liveness. Implement this as a bounded, resumable migration with persistent progress.
|
🔄 AI review updated — Skeptic: VULNERABLE |
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
VotingPower::<T>::iter() performs an unbounded synchronous scan during on_runtime_upgrade. As voting-power state grows, this can exceed the runtime-upgrade execution budget and prevent the release from completing. Convert this to a bounded, resumable migration with persistent cursor/progress state.
|
🔄 AI review updated — Skeptic: VULNERABLE |
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
on_runtime_upgrade invokes this migration synchronously, and VotingPower::<T>::iter() has no upper bound. Its storage reads and BTreeMap memory consumption therefore grow with all historical voting-power entries, potentially exceeding the upgrade block's execution or memory limits. Weight returned after execution does not constrain the work. Backfill this state through a bounded, resumable cursor before marking the migration complete.
|
🔄 AI review updated — Skeptic: VULNERABLE |
| } | ||
|
|
||
| let mut totals = BTreeMap::<NetUid, u64>::new(); | ||
| for (netuid, _, voting_power) in VotingPower::<T>::iter() { |
There was a problem hiding this comment.
[HIGH] Runtime upgrade scans the complete voting-power map
VotingPower is unbounded, but this synchronous runtime-upgrade migration iterates every entry before returning its weight. A sufficiently large live map can exceed upgrade-block execution capacity and stall the chain. Move this backfill to a bounded, resumable migration with a persisted cursor and per-block weight budget; mark it complete only after the final page.
|
🔄 AI review updated — Skeptic: VULNERABLE |
5 participants
Summary
Release v444 bundles runtime, EVM, SDK/CLI, transaction-fee, storage, proxy, commitments, limit-order, and GRANDPA fixes.
Changes
Emission shares: remove miner-burn scaling
(1 - MinerBurned)weighting from subnet emission shares.MinerBurnedbookkeeping remain unchanged.Recycle transaction fees instead of rewarding block authors (#3053)
Complete EVM precompile implementation (#3018)
0x80f), Drand (0x810), Timestamp (0x811), RuntimeConfiguration (0x812), and PrecompileRegistry (0x813), with 31 functions across the five new addresses.EVM precompile documentation and maintenance tooling (#2998)
btcli v11, SDK compatibility, and alpha-fee fixes (#3052)
--dry-run --jsonplans, secret hygiene, call-name resolution, and multisig funding preflight.CheckNonceso alpha-only coldkeys can use the alpha fee fallback.bittensor 11.1.0alongside the runtime upgrade for the new v444 SDK/CLI features, and rebuild offline signing payloads prepared before spec 444.GRANDPA finality fixes and polkadot-sdk pin (#3055)
cacb4310.Reject deterministic commitment failures before block inclusion (#3040)
set_commitmentsubnet existence and registration.Remove empty and obsolete storage entries (#3061)
on_idle.Purge commitments when neurons are trimmed (#3062)
max_uids.Refund unused weight for proxied calls (#3063)
proxyandproxy_announced.LastCallResultandProxyExecutedbehavior.Human-readable Ledger limit orders (#3002)
Release plumbing
spec_version:443→444.11.1.0.bittensor-core:0.1.3.Release