I refer to this - http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html

pragma solidity ^0.4.0;

contract SimpleStorage {
    uint storedData;

    function set(uint x) public {
        storedData = x;

    function get() public constant returns (uint) {
        return storedData;
    } }

It states:

Of course, anyone could just call set again with a different value and overwrite your number, but the number will still be stored in the history of the blockchain

I understood the state variables are stored in contract storage which is persistent. Are their previous values stored in the blockchain itself?

My question is really what happens if someone is storing db keys, and they have a lot of them in an array - thousands or millions.

How exactly would the array be stored when one element is changed? Does the historical storage hold only the changed array element and an index or is the whole array stored?

If I have say -

Student {
 uint age;
 uint studentId;
 uint studentScore;
 uint studentCourseFee;

Student[] public students;

Then I have 40,000 students so Student[] has 40K elements, and then I change one entry. What happens to the whole array? If I change entry 22,045 in the array (eg delete it), how does the historical storage record that and how does the new array get stored, now it is one entry shorter?

I can foresee scaling problems with am approach under any design here.

1 Answer 1


The blockchain itself doesn't store the state. It stores the block headers, transactions, and transaction receipts. The state is constructed by applying the transactions in the correct order.

Moreover, every contract has a storage consisting of virtual 2^256 256-bit slots. How datatypes are mapped to these slots is language/compiler dependent. Here you can read how it works in Solidity: http://solidity.readthedocs.io/en/latest/miscellaneous.html#layout-of-state-variables-in-storage. You'll see that arrays in Solidity do not follow the layout, which you would expect in C/C++ for instance.

Finally, every storage slot is stored by the node in a data structure called merkle-patricia-tree (trie). When the state changes, only the delta of the change is appended to the trie. See https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/

Changes to the storage are very expensive in Ethereum (20,000 gas / 32-byte slot). Maximum capacity of a block is around 8Mil gas. This means, in theory, you could store some 12-13Kb of data every 15s. Hence, it doesn't make sense to use Ethereum for storing large data. The design goal is: store as less as necessary. move everything else to an off-chain database or a distributed filesystem (swarm/ipfs/...).

  • If I have a bytes32 key on a db (eg hash of IPFS store) which then changes but I store a state in the blockchain, is the change reflected in the transaction history in the blockchain? I saw in the docs it said it was. So I was trying to see how the blockchain history could be examined in geth. Commented Mar 8, 2018 at 5:26
  • Yes it will be reflects in the transaction history. you would have a TX1 with the hash1 at Block B1, and then later TX2 with hash2 at Block B2. Via geth's web3 console you could inspect the transaction inputs or traces to get the data. You could also fetch the stateRootHashes of the contract from Block B1 and B2 and lookup these at the low-level in the trie, which is stored in a LevelDB in geth.
    – ivicaa
    Commented Mar 8, 2018 at 5:30
  • my calculation was wrong. I edited the answer.. it's 20000gas/32-byte slot and not byte.
    – ivicaa
    Commented Mar 8, 2018 at 5:41
  • Have you the command to fetch stateRootHashes? I have been experimenting with getStorageAt. I assume we use that somehow to see what was stored, or do we use getTransactionReceipt? Commented Mar 8, 2018 at 5:47
  • 1
    That article is brilliant. It seems to me that leveldb analysis is needed which means some kind of tool outside of web3. I am really surprised after so many years no one did this in web3. But it seems fundamental to me to examine blockchain storage to confirm it is permanent. It is interesting also that state variables are described as ephemeral in that article. That is an interesting concept especially when contracts are re-deployed and hence new contract storage is defined. Commented Mar 9, 2018 at 5:40

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.