Mapping Storage Key – How to Derive the Storage Key of Mapping to an Account

It's not clear if you want to retrieve all the values in a mapping or use the mapping to store structures that contain interesting, multipart things.

No to the first interpretation.

Yes to the second.

Lay out an instance (for one key) in a struct. Map the structs to the keys.

struct MyStruct {
  uint part1;
  bool part2;
  ...
}

mapping(uint => MyStruct) public myStructs;

It's also possible to store arrays and more mappings in a struct. The getters and setters get more interesting than the "free" getter you get with this public mapping of scaler types.

UPDATE

Upon reflection, I realized there is a third interpretation.

• Pass the entire mapping around, without interpretation.

No, to externally.

Yes, to internally.

You can pass a mapping internally by sending only the storage pointer. A storage pointer reduces the object to 1 32-byte word from which all slots in the mapping can be deduced. As such, it is meaningless externally and external opinions about can't be trusted. Therefore, functions that do that must be marked internal or private. If that sounds cryptic, have a look at https://blog.b9lab.com/storage-pointers-in-solidity-7dcfaa536089.

You can pass structs this way, and mappings can reside in structs, so ...

Have a look at:

pragma solidity 0.5.12;

    contract ArrayMapping {

    struct MyStruct {
        uint part1;
        bool part2;
    }

    struct MapStruct {
        mapping(uint => MyStruct) myStructs;   
    }

    MapStruct map;

    function get(uint index) public view returns(uint, bool) {
        return fetch(map, index);
    }

    function fetch(MapStruct storage m, uint index) internal view returns(uint, bool) {
        return (m.myStructs[index].part1, m.myStructs[index].part2);
    }
}

A "storage pointer" to the struct that contains a mapping is passed into fetch. This doesn't help fetch iterate, count or otherwise understand the contents of the mapping but it gives it the raw material to get started.

You can pass structs around to/from libraries and that can help compartmentalize logic that is focused on complex storage structures. See https://github.com/rob-Hitchens/UnorderedKeySet and https://medium.com/hackernoon/binary-search-trees-and-order-statistics-for-ethereum-db47e2dd2c36 for examples.

Hope it helps.

When you declare a mapping like in the following contract :

contract MappingExample {
    mapping(address => uint256) balances;
}

The variable balances is assigned to storage slot 0 (simply because it is the first one). But the mapped elements are elsewhere.

To compute the storage slot or location of the mapped elements, the following is used :

slot = keccak256([key, mappingSlot]) // concatenate key and mapping slot

The thing is that non allocated storage slots default to the value 0. So every key that was not assigned a value points to a non allocated storage slot for which the EVM can return the value 0 directly. There is no need to actually store 2^256 - 1 slots just because a mapping was declared.

If you are curious about that you can see the implementation of the SLOAD OPCODE in go-ethereum here that calls the evm.StateDB.GetState method defined here:

func (s *StateDB) GetState(addr common.Address, hash common.Hash) common.Hash {
    stateObject := s.getStateObject(addr)
    if stateObject != nil {
        return stateObject.GetState(s.db, hash)
    }
    return common.Hash{}
}

As you can see, if stateObject == nil then common.Hash{} is returned. This is a zeroed 32 bytes array. Basically, a zeroed out storage field that doesn't need to be stored in case the address has not state associated to it.

In turn (not directly) it will call GetCommittedState defied here. This method is pretty big so I'm not pasting it here, the same logic follows if the key cannot be recovered from the state trie a default value of 0 will be returned.

So, refining our example a little:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.10;

contract MappingExample {

    mapping(address => uint256) balances;

    constructor() {
        // Setting balance of an arbitrary address.
        balances[address(0x10)] = 100;
    }

}

You can read balances[address(0x10)] with the following Web3 code:

import Web3 from "web3";

const web3 = new Web3("http://localhost:8545");

// ADDRESS OF OUR CONTRACT (CHANGE IT FOR YOUR OWN)
const contractAddress = "0xd4EC28074b7A66F536D9feCf9b2f81B962215e69";

// STORAGE SLOT OF THE MAPPING
const mappingSlot = '0000000000000000000000000000000000000000000000000000000000000000';

// KEY THAT WE WANT TO READ IN THE MAPPING
const key =         '0000000000000000000000000000000000000000000000000000000000000010';

// COMPUTE THE ACTUAL STORAGE SLOT OF THE VALUE ASSOCIATED WITH THE KEY
const balanceSlot = web3.utils.soliditySha3({t: 'bytes', v: key + mappingSlot});

const balance = await web3.eth.getStorageAt(contractAddress, balanceSlot);
console.log(web3.utils.toNumber(balance));
// DISPLAYS : 100

Because the hash (interpreted as a storage index) is stored in the EVM, any unknown value will return a 256 bit 0 value as shown in the GetState function, this 0 value doesn't need to be stored.

In essence, every value in a mapping is mapped to something. But not all values are stored in the contract storage space, only the values that have been set. Making it a quite efficient structure that doesn't require every node to allocate 2^256 - 1 bits for each mapping in existence.