Tickets on Edo: Simply Explained
What are tickets, how do they work and use cases?
The Edo upgrade is just around the corner, bringing new features to the Tezos protocol such as Sapling, a new “adoption period,” and tickets. While the first two have been extensively discussed and understood, it appears that understanding tickets has left many in the dark, including myself. So I reached out to Aditya Gautam (Twitter @_aditya_gautam), Senior Software Developer at Tezsure, to have a conversation. Aditya was incredibly helpful and answered all of my questions. I put together this article to help the community better understand tickets, and pass along the knowledge he shared with me. A huge thank you to Aditya! Make sure to follow him on twitter and let’s get into it.
So, What is a ticket?
A ticket is a new type, like string or nat, that is essentially a key that unlocks functions. A ticket is used one time to unlock a function in a contract as long as that function is expecting that ticket.
The idea of tickets may be better understood as a one-time use “key” that “unlocks” a function.
In the same way there is a token minting and burning contract, there is a minting and burning contract for tickets. I think of a ticket as a token that takes in two parameters, the amount and the value. The amount is how many tickets will be created, and the value is an identifier for that specific ticket. The ticket also stores the contract address it originated from. If a contract holds a ticket, it can access and “unlock” a function (as long as the function is expecting that ticket).
What problem is this solving?
Every feature of a proposal to the Tezos protocol solves a problem, so what purpose does ticketing bring and what does it solve? Before Edo, to access a restricted entry point, you would need to have a recognized public key or be the originator to access the function. Tickets allow you to access any function as long as you hold the ticket. Now, each function just expects a specific ticket from a specific originator and the user can access the function. The proposal of tickets solves these problems and more, which you’ll see in the use cases below.
Use Cases
Multi-signature
A great use case for tickets is that it replaces the need for a multi-sig. Just reference the ticketer address as a valid multi-sig ticket in the dApp’s contract and if you hold one, it unlocks.
New Account
A great use case is to sign up a specific user for a new account on your platform. Let’s say you are beta testing and you want your friend to check it out and make an account. You don’t want random people to start beta testing, so you can send your friend a ticket in advance to access the Sign-Up function. Now that your friend has accessed the function, he can make an account and his ticket is burned from the original storage.
Smart Contract Permission Structure
Let’s say I’m building a series of smart contracts that interact with one another. The current way I would do this is by writing into the contracts storage, who has permission to use which functions. Some users can access some functions but lower level users may not be allowed to, so how do I change these permissions without going into each contract and changing them? Or, if I add a new contract to this web of contracts, would I need to go into every contract and add this new one? Not anymore. With tickets you can have each function expecting a given ticket, and you can mint and distribute the tickets on your own to those involved in your project. Tickets are a permissioned bridge that connects contracts.
Gaming Platform
As a gaming platform, you could issue tickets to users and hypothetically use them as lives that let the user play again and to keep playing they need to purchase more tickets. This would prevent them from replaying without permission. You can use a ticket to access items in an in-game shop. You can allow users to play bonus rounds with a ticket. A ticket could be used as a let’s say, “Weapon of your choice” bonus prize for a one time bonus event! This ticket will allow any user to choose between a pink gun, rainbow pistol, samurai sword, etc and each of those functions accepts the same ticket.
Voting
If there are 100 members on a board, and you need 51% of your board members to vote in order to pass the budget, you could distribute 100 tickets to your board members and they can cast their vote by ”depositing” their ticket in a Yay or Nay function. Whichever function, either Yay or Nay, reaches 51 votes first wins.
I hope this helped you understand tickets better! Feel free to reach out to me on Twitter with any questions at @AdShinder and go follow Aditya on Twitter @_aditya_gautam. This article couldn’t have been written without his help and guidance.
Additional Ticket Notes for Developers:
- If you use a map or big_map to store the tickets in the originating contract, no other type can be stored within that
- The value parameter can only be type nat.
- You can initiate a simple ticket with the following line:
parameters (ticket %nat)
If you can read Python, here is the scenario testing the fungible asset example
SmartPy Tickets:
