I have N fundamental data storage variables for each user (AccountId) that must be stored in mappings and are accessed and modified during method calls (#ink[messege]) in a smart contract. Not all of these fundamental data storage variables are used in all methods.

For example:

  • There are N fundamental data storage variables and 2 methods that modify them.
  • 1st method modifies the first M<N of variables.
  • 2nd method modifies all N variables.
  • Both methods are called the same often.

I have few ideas on how to organize data in this case and I don't know which one to choose:

  1. Each variable is stored in a separate Mapping<AccountId, data_type>.
  2. I divide variables into 2 structs (or tuples) and I store these structs (tuples) in
    two mappings.
  3. I divide variables into 2 structs (or tuples). Then I make a super-struct (super- tuple) that contains both of the previous structs (tuples). I have one Mapping<AccoundId, SuperStruct>
  4. All variables are stored in one struct (tuple) and there is only one mapping.

The question is how to organize that data to make accessing and modifying cheap (in gas)? Is it possible to give some general rules, or is it very case-dependent?

1 Answer 1


It is case dependent.

When a variable in a struct needs to be changed, the whole struct needs to be re-written. Therefore, it can be more gas efficient to separate the M variables by storing them in another struct in another Mapping. The re-write operation is now of smaller size.

However, if the M/N ratio is fairly big. Each time all N variables need to be changed a search needs to be done twice for each AcccountId which might exceed the gas usage in the case where all variables are stored in one struct, one mapping.

addtional information (ink! docs): https://use.ink/datastructures/overview

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.