I found a lot of example of tokens (like ERC20) using this pattern:

contract MyCoin {
    mapping (address => uint) balanceOf;


Those contracts are deployed once, the "balanceOf" mapping being responsible for holding balances of all users owning some of MyCoin.

Coming from the traditional world of RDBMs this is pretty counter intuitive... A class is commonly implemented with a table, and an instance of the class would be a line in this table. No one would create a table with a single line containing a blob for all data for every users. So my first idea for a coin implementation would rather be:

contract MyCoin {
    address owner;
    uint balance;


One instance of the contract would be deployed for each user holding some of MyCoin.

I understand this pattern raises many security issues (anyone can forge a contract with the same interface but different behavior, or just deploy an instance with a lot of coins coming from nowhere). No doubt those issues can be resolved but it would increase the complexity of my code, increasing the risk of bugs.

What I don't get is how the mapping in the first example could be an efficient way to store millions of accounts? Is there a limit? Are performances of such call affected by the number of items in the mapping? How?

Last question: is there some working / efficient / secure example of the second pattern?

Thanks a lot,

  • I found some clues on how contract's data is stored in Ethereum is this post: ethereum.stackexchange.com/questions/18885/… If I understand well, the number of entries in a mapping will not affect contract performances as state variables are stored appart from the blocks.
    – Phililippe
    May 10 '18 at 11:54

This is a design issue you have to consider in advance. if you know that you’ll be having an unlimited amount of balance holders, which balance could potentially be updated (think of transfers between individuals etc.) then it is recommended to use a mapping, as it allows you to look up the value without looping through everything.

Mappings do have a storage limit (every value in a mapping is computed by keccak256(key.p) p being the storage pointer. The total storage is 2^256 * 32bytes, after reaching this limit you'll basically start overwriting old data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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