I have looked at a few transactions with some smart contracts and I have found that they store a dump of contract's storage.

For instance:

https://mainnet.tezrpc.me/chains/main/blocks/246869/operations/3/0 https://mainnet.tezrpc.me/chains/main/blocks/328655/operations/3/0

"operation_result": {
    "status": "applied",
    "storage": [
        //...     ??

What is the point of doing that? It takes a lot of memory, especially if the storage of the contract is large.


Actually, it is not the full storage, but only the non-big_map part. Normally, that part should not grow too much, compared to the big_map part.

But indeed, it can still be expensive to repeat that storage in all transaction results, especially partial ones. In the node, transaction_results are stored in the blocks, themselves stored in the store database. With a rolling node, i.e. a node that does not keep all the blocks, this storage will be recovered when the blocks will be forgotten. Putting the storage in the transaction results also increases the bandwidth of the nodes, since it makes the blocks bigger, so longer to transmit.

I think the idea was that it was a small cost to pay compared to the benefit for the developers of Dapps to be able to easily monitor the storage of their smart contracts.

  • What are the benefits for dapps developers? This is more like a debug mode for dapps, which (as I think) should not be in production at all. Could you give some examples when is really needed to have a part of the storage in each operation? – Groxan Mar 5 '19 at 12:11
  • If you don’t provide the storage after each operation, you can only query it by RPC between two blocks. So, you won’t be able to observe intermediate states when several transactions in the same block alter the same storage. I don’t have a particular example of use in mind, but sometimes, a feature that is useless for many people find an interesting and unexpected usage. – lefessan Mar 5 '19 at 14:23
  • seems to me off-chain simulation of the storage and RPC query of the storage are the right thing to do in production in order to maintain node resources. The convenience of tracking the state of a contract can be solved by tooling whereas the price to pay for extra storage in the full node is permanent. – Ezy Mar 6 '19 at 13:27
  • Anyway, as you can see, there are many contracts that use map instead of big_map to store some data about their callers. This is a serious vulnerability, because I can spam all these contracts from many addresses until the storage becomes so large that no one can send a transaction to the contract due to operation size limit. – Groxan Mar 7 '19 at 14:49
  • Moreover, this vulnerability is not obvious to novice developers. I think that everything in the world should be as simple and obvious as possible so that newbies do not lose their money. – Groxan Mar 7 '19 at 14:59

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.