You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
The various map pallets mostly use blake2_256 hashers and sometimes linked_maps and empty double maps. All linked maps should be removed. Double maps where the initial item is expected to be constant (e.g. pallet-session's NextKeys) should be altered to a simple map now. Hashers should be switched to either:
blake2_128_concat in the case that the user is able to place map items whose keys are entirely at their discretion.
twox64_concat in the case that the user cannot.
An example of the former would be the frame_system's Account storage item, since any address (even one without a known corresponding private key!) may be sent an existential deposit and therefore be created.
An example of the latter would be frame_system's BlockHash storage item, since its keys are limited to the block number integers. Users cannot populate it directly, nor can they influence the data.
A second example of the latter would be pallet-staking's Bonded item. Though this has a corresponding key type/value to frame_system's Account storage item, it has different semantics; no entry can be placed except through a valid signed transaction coming from the account of the key. As such its value is heavily constrained and cannot be selected at will (in general a public key would need to be known for the account and the distribution/correlation between public and secret keys are not such that a trie-imbalancing global griefing attack would be practical to execute).
Tasks
Remove all the superfluous double-maps from Session & migrate.
Replace all hasher(blake2_256)s with _concat hashers & provide either static or dynamic migration.
The text was updated successfully, but these errors were encountered:
shawntabrizi
changed the title
Account storage in Balances Pallet needs to be migrated
Storage in Balances Pallet needs to be migrated to use twox64concat
Feb 13, 2020
gavofyork
changed the title
Storage in Balances Pallet needs to be migrated to use twox64concat
Migrate storage maps to use twox64_concat or blake2_128_concat
Feb 18, 2020
The various map pallets mostly use
blake2_256
hashers and sometimeslinked_map
s and empty double maps. All linked maps should be removed. Double maps where the initial item is expected to be constant (e.g.pallet-session
'sNextKeys
) should be altered to a simple map now. Hashers should be switched to either:blake2_128_concat
in the case that the user is able to place map items whose keys are entirely at their discretion.twox64_concat
in the case that the user cannot.An example of the former would be the
frame_system
'sAccount
storage item, since any address (even one without a known corresponding private key!) may be sent an existential deposit and therefore be created.An example of the latter would be
frame_system
'sBlockHash
storage item, since its keys are limited to the block number integers. Users cannot populate it directly, nor can they influence the data.A second example of the latter would be
pallet-staking
'sBonded
item. Though this has a corresponding key type/value toframe_system
'sAccount
storage item, it has different semantics; no entry can be placed except through a valid signed transaction coming from the account of the key. As such its value is heavily constrained and cannot be selected at will (in general a public key would need to be known for the account and the distribution/correlation between public and secret keys are not such that a trie-imbalancing global griefing attack would be practical to execute).Tasks
hasher(blake2_256)
s with_concat
hashers & provide either static or dynamic migration.The text was updated successfully, but these errors were encountered: