Stoolbox, a love story of two IT fads
We have been able to couple 2017’s blockchain fad with the serverless hype of 2018. This blog will go into detail on why this makes for such a great couple.
Over the last months, we have been working on scaling the registration of our smart tickets on the blockchain. We are excited to announce that this project(called Stoolbox) is nearing production readiness in the upcoming weeks!
Stoolbox doesn’t only change the way we register tickets, its working also improve 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.
Smart ticket blockchain requirements
Before getting into how Stoolbox works, let’s start by listing the requirements for the blockchain approach we had when we started out. Note these feature requirements were formed in 1.5 years of selling blockchain registered tickets. This experience makes us certain that if implemented correctly, the features of Stoolbox will become a key driver in the protocols value proposition.
- Scalable, reliable & cost-efficient processing of transactions
With the expected sales pipeline ahead of us, it is paramount that the blockchain registration part has to be able to process millions of tickets in a cost-efficient and reliable manner. A feat Ethereum surely didn’t provide out of the box as we learned the hard way.
2. Maximum transparency while respecting consumer & client privacy
Publishing datapoints to the blockchain only make sense if there is any meaning full information in the data that is made public. It should be possible to draw meaningful conclusions from the data, conclusions that expose certain public concerns.
However, the published data points should not compromise the identity of attendees(GDPR) nor the event marketing efforts of the event organizers themselves(implied scarcity can be a big marketing tool for event organizers. Exactly like it is for ICOs #hype #fomo).
3. Implementing the protocol should be non-invasive for any backend
To make it easy and cheap to integrate with the GET Protocol, we need our blockchain solution to easily integrated into the backend of integrating ticketing companies. To do this we have to assume that no ticketing system is built the same. Therefore Stoolbox needs to focus on generalizable concepts that will be compatible for a wide range of architectures.
For example, we want to make it possible for ticketing companies that still use static QR codes to slowly make their tickets a bit smarter/digital. Forcing companies to go full-digital at once is too big of an ask. By making implementation of ‘smartness’ gradual we aim to lower this friction. We have already seen this approach pay off!
4. An indispensable for GET
As the protocol scales and more unknown actors start using its features the economic fundamentals need to remain robust. We need to ensure the native asset won’t be forked out by an actor. Policing everybody doesn’t scale and can become technically hard as we open source. Hence if we want to ensure GET remains the unit of account within the protocol, the token must be made indispensable in its use case.
It might be hard to imagine this indispensibility angle so let’s use a metaphor. Let’s say you are monetizing a network of roads, you could do this with placement of toll-booths at all exits. As paying a toll fee doesn’t benefit drivers in their quest, they will choose not to pay this fee if there is a possibility to do so (like take an illigal route around a toll-booth). Hence you would need to invest in preventing this from happening. A different monetization approach would be to be the only company selling fuel to these cars(including an additional fee on top of the fuel fee). Drivers of cars cannot choose to not use fuel, hence no policing would be required as fuel is indispensible for a car to operate.
Whereas now GET is the only allowed currency to pay for protocol features, it will become the fuel required to get anything done in the GET Protocol. Like fuel, GET should be indispensable for a smart ticket to work in the GET Protocol(think Gas/ETH).
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!
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 an 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.
This process might sound overly complex or convoluted, but with the help of some clever open-sourced tools this whole charade won’t be any harder than reading a Medium blog.
Stoolbox infrastructure
Stoolbox is a punny cross-product of Statebox, our partner and our ticketing backend Entrails. The GUTS Tickets backend is the first to integrate Stoolbox.
Developer collaboration
For a long time, the only developers to have ever gotten their hands dirty with GET Protocols code & tooling have been those working in our offices in Amsterdam. A few weeks back we have opened a Slack channel for all the developers of the ticketing companies that are currently integrating & testing the GET Protocol features. Among these integrators are of course the developers of ITIX, but they are not alone.. Which integrators are keeping them company will be a subject of a different blog.
In this blog, I will describe the high-level features of Stoolbox. A more detailed and technical break-down of the design choices we made will be detailed in the future in our documentation.
For starters, let’s break down one by one the what Stoolbox is. What does IT do?
The data IT feeds on
Ticketing companies integrating with the GET Protocol (GUTS, ITIX and more soon) push ticket mutations to an SQS queue. Integrators format these messages according to pre-defined and public message format.
Due to this modular approach, Stoolbox can be integrated into any back-end with just a few lines of code.
The tasks IT performs
Stoolbox reads messages from this SQS queue. After validating the message format its contents are interpreted. If needed additional values are derived from the message. This is possible by utilizing several mathematical characteristics coming from Statebox (using category theory and other techniques).
From these values, a mutation instruction is formed. This instruction is called a ‘firing’, when executed it will move a token to a different state inside the petri-net of the event. This firing is essentially similar to Ethereums signed transaction. This firing is passed on to the Statebox API who will handle the validation and consensus of the mutation.
Part of the input data needed to process a mutation is a proof-of-burn a certain amount of GET. This is the protocols fee for facilitating the execution of the mutations. Without this GET proof-of-burn, tickets cannot change state. Just like with a car, you need to burn fuel to move forward. Burning fuel isn’t a choice or luxury, it is forced upon you by the first law of thermodynamics.
If this firing is deemed correct, it’s transition receipt called a stateHash is returned by the Statebox API. This stateHash is pushed to another SQS queue where it will be processed for timestamping and eternal storage.
How IT gets work done (hint: AWS Lambda)
Stoolbox is designed as a serverless application. This means that all its functions are performed by AWS Lambda workers. These workers can be deployed on the fly, allowing Stoolbox to scale rapidly. When there are little tasks, the workers can be retired without any overhead costs. This means that while Stoolbox is ready for 10 million transactions in a minute at any time, there are no overhead costs for being ready.
This is a perfect feat, especially for ticketing, as the bulk of the mutations will in bursts(initial sale, ticket scanning etc).
How IT keeps organized
Due to the mathematical characteristics of the petri-net executions (symmetric & deterministic, the compositionality of mutations etc) of the input variables Stoolbox requires no key-value database to operate(these are overrated anyway! #blockchain #SQLQ). As all the necessary data to execute an execution can be inferred from data of an executions current state.
The lack of a database feat fits perfectly in the serverless setup as Lambda’s workers do not need to be aware of each other or the global system state to perform tasks. Allowing Stoolbox to deploy a theoretically infinite amount of workers without the risk of data corruption or loss of state.
How IT stores results (IFPS)
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 publically available. This is how such a file on IPFS looks like:
https://gateway.ipfs.io/ipfs/QmPftBC3XDBJ3xonXawDSdcVPTgsJFrqV5SpS9KW97Pm8S
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.
