GET & Statebox — Scalable blockchain tickets for the masses
The GET Protocol is all about making the ticketing industry more transparent and accountable. By for example by making data points about the ticket trade on the primary and secondary market accountable for the public. Together with our partner Statebox we developed a process that accomplishes just that. In this blog, I will explain what this first of its category, scalable blockchain ticketing approach exactly entails.
On Friday the 7th of June at 10:00 sharp the largest blockchain powered ticket sale to date will embark. The tickets for 2 shows in the Philps Stadium Eindhoven(capacity 30 000+) will go up for sale. Over the course of a full year, we expect to sell and resell all the tickets for these 2 events via the GET Protocol and Statebox API.
For more information and details about this specific sale itself, check out the organizer’s official channels or those of the ticketing company servicing the ticket sale: GUTS Tickets. In the remainder of this blog, the role of the GET Protocol in this ticket sale will have center stage.
What makes the ticketing of this event different?
With the help of the GET Protocol, GUTS Tickets makes a stance against resale and ticket fraud in the ticketing market. In a nutshell, this means that every step in the lifecycle of a ticket is made publically accountable and traceable via a technology called blockchain.
For those interested in the nuts and bolts of the implementation, rest assured. The Statebox powered ticket explorer will be the first repository of the GET Protocol that will be fully open sourced. Following this, the repositories of other components of the GET ticketing system will be made public. Until we created a fully open, inclusive and transparent ticketing system fueled by its native token GET.
Why is transparency needed in ticketing?
If you are more interested in the ‘why’ question I recommend the blog linked below.
Without a doubt a great blog Kasper. But, as anybody with basic knowledge about blockchain will be able to tell you, is that blockchain technology isn’t really known for its ability to get a lot of stuff done. Processing large amounts of data in a secure and most of all in a cost-efficient manner is a challenge. Fully agreed! I personally agree and actually believe on-chain scaling will remain a problem in the future. The inherent added complexity of on an immutable ledger and trustless consensus conflict with processing efficiency on a fundamental level. A point this blog drives home.
This is all a nerdy way of saying that it is generally easier to make to a decision alone as opposed to making this decision with a group of possibly malicious and anonymous people on the interwebz. YouTube explainer video about Blockchain technology.
The experience-driven conclusion, that using blockchain ‘out of the box’ is unpractical, we learned ‘the hard way’ during a real-world ticket sale in the tail end of 2017. Read more about this experience in this blog:
Note: Of course it was not only this experience that made us decide to make our blockchain registration ‘smarter’. Execution cost and the limited capability to store any sort of event/ticket meta-data on-chain also posed big motivators to seek a more fitting technology to provide tickets and events with the much needed accountability.
After improving the Ethereum runner ability to register tickets in pulses we used this improved ‘real-time’ blockchain registration of all ticket trades on the GET Protocol during the majority of 2018. See one of the transaction runners here: ETHERSCAN LINK TO 122 000 tx registrations.
Partnering with Statebox
For the blockchain-side of the GET Protocol the majority year of 2018 was focused on finding, researching and testing a new scaling solution. Eventually, we decided to partner up with Statebox. Since mid-2018 we have been in intensive cooperation with Jelle Herold and his team. The basis of our choice for Statebox is expanded upon in more detail in the blog linked below.
Great, having covered why blockchain is needed, reasons why we can’t use blockchain technology ‘out of the box’ and how Statebox fits in all this we can finally move on to the subject we set about to cover. Good riddance. So here we go, what we came here to find about is:
How are we going to use Statebox to make the upcoming sale of several Guus Meeuwis showing the Philips Stadium more accountable!?
In a nutshell, Statebox allows us to map a process, like a ticket sale, in a manner that allows for secure and swift execution. The manner ticket changes are executed to allow us to provide transparency in selected areas of the lifecycle of a ticket. What this is all entails and how it is accomplished is explained in depth in the material available on the Statebox website.
Does Statebox use smart contracts?
Statebox looks at smart contracts as Petri-nets. This is a mathematical way of describing a process. The concept of Petri-nets is explained in the video of Statebox below:
Some ‘Statebox’ definitions
- Petri-net -> The Statebox ‘equivalent’ of a smart contract. It is a description of a process (like an event sale). In a manner that is deterministic. Which means that there is a limited amount of scenarios a ticket can ‘go through’ and eventually end up in. More in-depth descriptions see Wikipedia / YouTube.
- token/execution -> The object of a ticket within the Petri-net. It’s ‘location’ inside the Petri-net describes the current state of that particular ticket in the event. Example: Is a ticket valid? for sale? for resale?
- firing event/transition -> When a ticket changes state. Example: A ticket is scanned at the entrance would constitute a change of state and thus a firing of the token linked to the ticket in the Petri net. Note that not all firings are valid, if there is no edge to a certain state the token cannot move there. Statebox acts as a filter and mathematically enforces certain agreed-upon rules about what a ticket can and cannot do.
- hash/‘statehash’ -> Similar to the general definition of a hash (Wikipedia / YouTube). With the addition that the way Statebox utilizes hashes allows signaling certain characteristics of the pre-hash input data. This is extremely helpful for conducting zero-knowledge proofs.
Please note that all definitions provided here by me are extremely simplified/flattened to optimize for novice understanding. If what I say seems contradictory or impossible this is due to the simplification. Always refer to the Statebox material for the nuts and bolts of this technology.
So how does Statebox work?
“Statebox produces a hash for each firing event. Hashes all link to the previous one, so a hash referring to the ticket sale at a given time witnesses the whole ticket sale history up to that point. This is analogous to what happens with blockchains, where each block refers to the previous one and so a hash of a given block can be seen as a witness for the whole chain history up to that block. This property allows to publish only the “final” hash of a sale as on chain reference: This hash corresponds to the whole history and altering the history would require to break the hash, which is considered as not being possible with current computational resources.”
“Putting the two things together, property two guarantees that a hash corresponds to the whole history of a ticket sale, while property one ensures that the only “acceptable” histories are the ones where no illegal operations where performed. Again a “parallel history” with illegal operations cannot be disguised as a legit one because of the cryptographic hash property.”
“Finally, compositionality guarantees that the system is scalable: E.g. If you need to design a new kind of ticket with new properties you don’t have to start from scratch. In this case, compositionality ensures that the properties of the new tickets will be easily verifiable starting from the properties of the old one.” Fabrizio Romano Genovese, Head of research @ Statebox
What about the blockchain?
At this point, we haven’t discussed the role of blockchain yet. In this first implementation, we are using IPFS. The location of the stored file is registered in a smart contract on a public blockchain. The diagram shown below does a solid job at showing the time series of this process:
Isn’t this all far too complicated?
Not at all. Buying a ticket with the GET Protocol is just as easy as a traditional ticket. Just try out our demo environment and get yourself a free smart ticket!
The end user is not confronted with crypto, hashes or Petri-nets al all. At least not when buying a ticket via the GET Protocol. Maths in your free time is fine in our book! An area where we have a less ‘laissez-faire’ approach is when on the subject of ticket scalping and overall event related malpractice. How exactly this is done in practice, is explained, in a step by step manner.
Step by step — The story of Alice, a few tickets and a Petri-net
- Friday | 14:00:00 — Alice creates an account on GUTS Tickets (a company that works with the GET Protocol back-end). This user account is locked to her smartphone and comes with a newly created Ethereum wallet account. Alice proceeds to purchase 2 tickets via the ticket shop. Note all she needs is her smartphone and debit/credit card(so no crypto), on average someone like Alice takes about 62 seconds to do all of this. Neat. The GET required to execute this transaction is already included in the ticket fee and travels along with the smart-ticket to the fresh crypto wallet of Alice. 2x neat! No-coiners 0 — Smart people 1.
- Friday | 14:02:00 — After completing the ticket order the updated state of the tickets is pushed, via the GET Protocol, to the Statebox API. From the order details, a transaction is compiled and sent to the Statebox Petri net/smart contract. The Statebox API verifies if this transaction is valid and when this is the case returns a transaction receipt(called a statehash) back to the GET Protocol.
- Friday | 14:02:15 — The statehash from this order is stored by the GET Protocol. The GET Protocol doesn’t immediately push all transactions to IPFS/blockchain, as this would be too expensive and slow. The batching criteria and frequency can vary per event.
- Friday:14:30:00 — A batch of 10 000 transaction receipts, including those of the tickets of Alice, is stored to a publically assessable file storage system called IPFS. The file is stored publically and the location of the file is appended in a smart contract that is publically visible and for anybody to interact with. This means that the batched hashes of an event can be downloaded by anybody, anywhere, always.
- 2019/2020 — This process of firing to Statebox, transaction verification, batching of the transaction receipts and finally the publication of the ticket-mutations to IPFS happens continuously. The storage location of each transaction-receipt batch is publically visible and downloadable by navigating to the events smart contract on a blockchain. Anybody anywhere in the world can check the validity of the published transaction receipts by using the open source tools of Statebox.
The result: An immutable ticket history
So what does this step-by-step process bring us? Well, by navigating the IPFS hashes as stored in the immutable blockchain ledger, the history of every ticket is documented. The documented event data is structured in a manner that allows to the public to keep ticketing companies accountable and honest.
Summary — Executing the final transition
The end result of this process is a ticketing system that allows anybody to check the relevant characteristics of the ticket they hold. Meaning its validity, the resale rules, added fee margins, the previous owner(s). The usage of Statebox allows us to this in scale and with maximum data efficiency.
1. Fast and F̶u̶r̶i̶o̶u̶s̶ Frugal-> A side chain for every ticket
Each tickets current statehash points to its previous statehash, allowing easy verification if a new proposed transition is valid. This not only allows for concurrency, as each ticket is stand-alone & deterministic but also for using economically efficient (centralized) computation resources. By timestamping the batches on the immutable Ethereum blockchain, no entity can rewrite the history of a ticket.
2. Maximum data efficiency -> Privacy is a human right
We care about the privacy of our users. Due to the manner, transactions are hashed, it will be possible to prove very specific characteristics about the transactions initial input, without spilling the beans about all the inputs. For example, Statebox tooling would allow checking if the user-provided birth-date for a certain transaction computed to age above 18.
The result of this ‘inquiry’ from Statebox would then be binary(yes/no). Meaning that the question, if a user is above a certain age, can be assessed without exposing the birth data to the entity asking the question(note that a person date of birth is a quite identifying data point in the context of a single event). There are of course far more possibilities for this zero-knowledge-proof ability of Statebox.
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.
