I have heard in many places that Tezos is making use of a specific kind of container called BigMap in order to store data inside a smart contract.

The object must be relatively complex because so far only one BigMap instance is allowed within a single smart contract.

My questions are the following:

  1. What are BigMap's and how do they differ from the other standard types of containers? (I did not find any info on BigMap in the Tezos documentation)
  2. Why is there a limitation to a single one in a smart contract?
  3. What would be the advantage of having more than one? (as a matter of fact, I see that there is currently WIP to lift this constraint, see this gitlab issue)

1 Answer 1

  1. The BigMap container is a special map (dictionary) whose storage is only read or written per key on demand.

The motivation to have such a container is the following. Suppose that you have a contract containing lots of more or less independent data and you don't want to read / write all of the data at once but only a small part of it. Think of crypto-kitties, collections, STOs (security tokens), etc. It is in general much more efficient resource wise (gas and execution time) to only access the part you need instead of loading everything.

  1. The limitation of only one per contract is really for simplicity purposes in the Michelson implementation.

  2. With today's implementation, having only one BigMap means that if you need two such things map1 and map2, you need to encode the mixing of map1 and map2 by doing something like:

key = Left key1 | Right key2

An example where you would wish to have two such maps can be a contract that represents real estate and owners or collectibles and owners. You may wish to access owners of some goods or goods of some owners.

I personally think that lifting this restriction in Michelson would be nice.

  • 2
    Unfortunately, you can't use sum types as keys to bigmaps because sum types aren't comparable (for no good reason). You would have to use the hash of the sun type, or its packed byte representation.
    – Arthur B
    Commented Mar 19, 2019 at 8:04
  • @ArthurB I missed this limitation when I wrote this answer. Thanks for the precision. It might be reasonable to lift this restriction eventually (and do unit and option as well I guess).
    – FFF
    Commented Mar 19, 2019 at 12:08
  • 1
    ... and Pair. And yes, it's a pretty straightforward patch to make these types comparable
    – Arthur B
    Commented Mar 20, 2019 at 18:08

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.