LIGO concepts used in this part: with this second entrypoint, we will need to register players and map a raffle ticket to each player. Thus, we will learn how to use collections. It will also be the opportunity for you to review functions and checks
The second entrypoint can be freely called by everyone who wants to buy a ticket. In our use case, each address can only buy one ticket, which costs 1 Tez.
Two additional variables have to be stored:
- who is taking part in the raffle
- who owns a ticket
The storage has to be modified. Collections are going to come in handy for the modification of the storage
Lists are linear collections of elements of the same type. Linear means that in order to reach an element in a list, all the elements before have to be browsed (sequentially accessed). Elements can be repeated as only their order in the collection matters. The first element is called the
head, and the sub-list after the head is called the
Lists are used for returning operations from a smart contract's main function and to store the same values several times in a collection
For more details, see the Ligolang
Sets are unordered collections of values of the same type (as opposed to lists which are ordered collections). Like the mathematical sets and lists, sets can be empty and, if not, elements of sets in LIGO are unique, even though they can be repeated in a list.
For more details, see the Ligolang
A Map is a data structure that associates a value to a key, thus creating a key-value binding. All keys have the same type and all values have the same type. An additional requirement is that the type of the keys must be comparable.
Maps load their entries into the environment, which is fine for small maps, but for maps holding millions of entries, the cost of loading them would be too expensive. For this we use
big_maps. Their syntax is the same as for regular maps, but they are optimized for a huge number of entries.
Thanks to these collections, the second entrypoint of the Raffle smart contract can be implemented. A list of participants must be stored, as well as the ticket/owner pair.
Two new variables will be stored in the contract storage.
What collection should be used for:
- the participants (who can only buy one ticket)?
- the tickets and their owner?
For the first point, two collections could be used: a list and a set. Since the participants can only buy one ticket, a
set is the right choice (since each element cannot appear twice).
For the second point, each ticket should be mapped to its owner. The number of participants is not limited: there might be millions of them, so a
big map seems the right choice.
The set of participants should a have set of addresses, while the big map should map a ticket id (a nat) to an address. The new storage is:
The smart contract needs to expose an entrypoint to buy tickets. The method is the same as the one detailed for the first entrypoint:
- Define the type parameter. This type should be
unitsince the buyer does not get to choose the ticket id:
- Adding the entrypoint in the variant:
- Handling the new entrypoint in the control flow:
The last step is to implement the logic of this entrypoint. Just as for the first entrypoint, this logic will be implemented in a function,
Two variables have to be checked:
- is the buyer sending enough funds?
- has the buyer not already bought a ticket?
For the first point, this is the same check that is done for the first entrypoint. Checking if an address is calling the entrypoint for the first time (= a buyer cannot buy more than one ticket) means checking if the calling address is already in the payers
Once these two checks have been performed, the buyer can receive a ticket. For this, the entrypoint needs to:
- register the address of a participant. The address must be added into the players set from the storage.
- create a raffle ticket id. Since each participant can only buy a single ticket, the size of the participants set gives the new ticket id.
- associate the ticket with its owner. The new ticket id will be a map to the buyer in the
These three steps use the methods described in the collections section.
Our contract now is: