Stoolbox doesn’t only change the way we register tickets, its working also improves the value proposition of GET. To read more about what drove us to redesign our blockchain approach from the ground up please check out the blog below.
Stoolbox & ticket transparency
The idea behind Stoolbox is to provide data for the ticket explorer. This will be a consumer-facing application that allows ticket holders to explore the history of their smart tickets by only using the blockchain as a data source. Feature-wise the ticket explorer will be similar to what Etherscan is for transactions on Ethereum, with the important caveat that the ticket explorer will be very easy to understand for anybody!
In this diagram, you find a high-level view on how data flows from the ticketing company to a series of queues to eventually end up on the blockchain.
Situation: Alice buys a ticket. After a while, she decides to resell the ticket on the merged primary and secondary market. Bob buys the ticket. Let’s explore how Stoolbox handles such a situation…
A. When a ticket changes state or owner, the ticketing company sends a message (in a standardized message format) to a queue. This queue is essentially a ‘to do’ list for Stoolbox to read.
B. Stoolbox continuously reads messages from the queue and interprets them. Then it compiles the instruction into a format that is readable for the Statebox smart contract (a Petri-net).
Important! For this instruction to be accepted by the API, a proof of burn of GET is required. If this proof isn’t provided the execution will not be accepted. This principle is comparable with the ‘out of gas’ situation known from Ethereum. In the GET Protocol the mutation will never be processed, meaning the ticket will not change state.
C. If the mutation is accepted, a receipt of the transaction (called a stateHash) is returned to Stoolbox. This stateHash is then forwarded to another queue.
D. Periodically Stoolbox will read all the messages from this queue. From all these mutation-receipts, a batch is created and consequently stored on IPFS for eternity, where anybody with an internet connection is able to download and analyze it.
Important! The publication of all ticket mutations to IPFS by Stoolbox also requires a proof-of-burn. Without this proof, nothing will be stored and no transparency is provided.
E. The file location of IPFS is then pushed to a smart contract on the blockchain. This smart contract is public and will contain an immutable ordered list of all mutation files.
The ticket explorer
If Bob wants to know the history is of a ticket because he wants to buy it, he can use tools that will feed from the smart contract storing all the IPFS files. With all the IPFS files it is possible to reconstruct the complete history of all the tickets issued and traded for any event.
This setup uses the same trustless principle as known from Bitcoin. If you run a Bitcoin node you are required to download all previous blocks. Only with the complete history, you will be able to verify if a certain statement or transaction is correct.
Other explanatory material
- State change receipts further unpacked
- Wirings further explaineed
- State changes batches explored
- GET burns and their role in sustaining security and actor coordination
- A dive into nodes and consensus
How we store ticket histories(IPFS)
IPFS is like Google drive for the popular kids. Never heard of it? Bad news, you are probably a nerd.
Stoolbox stores the ticket mutation data it collects periodically on IPFS. This is essentially a distributed Google-drive (admittedly cutting some important corners here). After having stored a file, this file is publicly available. This is how such a file on IPFS looks like:
While this collection of hashes might not make too much sense now, this will change soon. In the upcoming months, we will release more detailed and technical information on how the community can play around and contribute to these features. Exciting times ahead.
Stoolbox was created in close collaboration with Statebox. We want to thank the Statebox team for all the help :).
More about the GET Protocol
Any questions or want to know more about what we do? Join our active Telegram community for any questions you might have, read our whitepaper, visit the website, join the discussion on the GET Protocol Reddit. Or get yourself a smart event ticket in our sandbox environment. Download the GUTS Tickets app on iOS or Android.