My inspiration came from buying concert tickets through TicketMaster and being charged a 14% fee on top of the price of the ticket. I wondered why TicketMaster could take such a large fee for a simple online transaction. It led me to do some research into the ticketing market, from which I believed that a smart contract is a perfect solution to fix the problems that exist.
What it does
Ticketbooth is designed to make the event ticketing market transparent and enable market competition for primary sales, making it fair for the customer. It allows a venue, performer, events management or events promotion company, to sell tickets to their events. Tickets cannot be brokered for profit and the contract owner can set up a transparent refund policy.
How I built it
The methods on the contract were created to serve the purpose in the design. For every method on the contract, I built unit tests to go with it. When I'd commited the initial contract I started work on designing a web application to demonstrate the contract.
I wanted the application to demonstrate how it might handle a real-world transaction, so I decided to build a ticket buying application that included an integrated payment gateway. The prototype is designed to be demonstrated to an audience with knowledge of blockchain, though is intended to be simple enough so that someone without knowledge of blockchain can use it. The application is built using .NET Core 3.0 using Blazor.
Challenges I ran into
The limitations for using language features in contracts make them far more tedious to write. Being unable to use properties or methods on structs is rather awkward as all the logic has to be written into the contract and relational operators cannot be used for structs.
One feature I added to the contract was validation in the constructor, to ensure that all seats were unique. This caused problems however, due to the massive amount of gas that was used up doing this, which was roughly 1425(n)(n-1) where n is the number of seats passed in. Therefore I opted to rid of validation and would instead create a tool in the future that validates the data before passing it into the contract.
Developing services to interact with a contract is not as smooth a process as it could be. Documentation of the full node could be better and it would be great to have proper documentation and a clear versioning strategy for the full node web API. In its current state, there is a huge barrier to get started with development, as many things need to be explained to developers by the Stratis team. For example, a lot of my understanding of the different smart contract endpoints in the API came from searching through responses to questions in Discord. So the ways in which I see significant and rapid improvement:
- Explicit versioning of endpoints, reflected in the Swagger documentation
- Descriptions in the API documentation for each endpoint
- Response code documentation
Accomplishments that I'm proud of
Having not been involved in much blockchain development in the past, I am proud of developing a working smart contract with a real use case. Additionally I am proud that that contract has the potential to benefit a massive amount of people and change an industry with a bad reputation, for the better.
I've put a fair amount of work into developing this contract and preparing all the material for the submission to this hackathon. I enjoyed writing up a case study and it has somewhat helped broaden my analytic skills. This project is definitely one which I will add to my portfolio. It helped me learn a lot about blockchain and believe strongly in Stratis platform, as a blockchain product, which I'd paid some attention to in the past.
What I learned
A lot of what I learned was regarding how the ticketing industry works and the huge problems that it has. I've written a case study to present these findings and solutions which smart contracts could provide.
What's next for Ticketbooth
Additional features in the proposal are to be added to the contract. I want to approach organisers of events relating to the concert, sports, theatre and ticketing industries, and attend these events, to be able to gather the interest and find out the complexities of introducing Ticketbooth.
Ideally I would like to be able to develop a production-ready ticket sales application that integrates with Ticketbooth, as I believe there to be a huge potential in these contracts. In addition to this, I'd develop an application which can be used by the venue to verify the validity of tickets.