Inspiration
The project was born out of my love of concerts and clubbing. I develop crypto note based technologies and found a fitting use case for it here. I purchased some tickets for an event a few days before I started development and all it was is payment and I received a QR code that was scanned at the entrance of the venue. This seemed quite an interesting challenge to implement as a decentralized cryptographic protocol so I decided to do it.
What it does
The application is divided into 3 pages.
On the first page you can create an event that you would like to sell tickets to. The event has a name, a price per ticket, available tickets that will be sold and you can add an external handler contract. The handler contract implements an ExternalTicketHandler interface, this allows users to add external contracts that will be called when tickets are scanned. The use-case for this is for example when a person enters a venue and the ticket is scanned, he can receive a POAP to his address. But the use-case is versatile, it can be a real life token airdrop or just access control so only certain wallets can handle tickets. This makes the protocol extendable while I keep the core very simple!
The user is redirected to the second page after he created the event and this is the page that is shared with the final users. The users can purchase tickets here or redirect to the third page where the ticket can be scanned and invalidated. On this page the user can click "Purchase Ticket" and if there are still available tickets he is prompted to sing a transaction with his wallet. The tickets are downloaded as a PDF afterwards! The PDF contains a QR code that can be scanned to validate the ticket, the crypto note is a large string with the secret encoded. This can be found on the bottom of the page also so it's copy-able.
The third page is used for handling the tickets. It opens up a QR code scanner that can be used to easily verify and invalidate the tickets. The recommended use is with the Brave wallet on mobile, this is by far the fastest mobile crypto browser that supports both the native Camera APIs and sending transactions to the fantom network. When the ticket is invalidated the sender of the transaction can airdrop tokens or perform other actions on the ticket. The address of the ticket's buyer and the sender's address available for developers to extend this with functionality.
How we built it
ZKTickets was built using Circom, Solidity, Hardhat, Parcel and Vanilla Typescript, HTML and CSS.
I created the zero-knowledge circuits using the circom languge, it's arithmetic circuit logic that allows me to create the cryptographic notes. The user generates a secret and a nullifier and they are both hashed using Poseidon Hash. The hash of the secret+ nullifier is called a commitment, and the hash of the nullifier by itself is called the nullifierHash. These are the hashes that will be dispatched in the transactions to the blockchain so the secret itself is never revealed to anyone.
The Solidity code handles the tracking of ticket validity, the verification and the sale. The tickets are sold for FTM. When tickets are invalidated the contract can call an external solidity contract that allows somebody to extend the protocol.
Hardhat was used for the development and testing and finally Parcel was used to build the front ends. I used vanilla TS to reduce vulnerabilities that stem from using frameworks like react and it makes development feel fun and fresh.
Challenges we ran into
Some of the challenges I ran into is using the qr code scanner on mobile while sending a transaction. The development of a native mobile version is out of scope for the hackathon, but thankfully brave browser for mobile saves my day. The application could be modified to implement gas abstractions because transactions that use zkSnarks as parameters can be relayed by anyone since they are not modifiable without knowing the secret variables, but this would require that I include fees to pay for gas and build a server side relayer to dispatch the transactions on behalf of users,then any browser without a wallet could be used when scanning tickets, but this would make the application less decentralized and depend on external infrastructure which can induce downtime and the ExternalTicketHandler extensions would not have the required msg.sender variables in relayed transactions. So this influences how the application would work and limit the token minting on ticket scanning on mobile.
But as I wrote earlier it fully supports the Brave browser on mobile. Metamask too however that is slow. These problems did not surface when using a desktop with browser extensions or brave but in a real scenario in a club that does not work well.
Accomplishments that we're proud of
I am proud to have created this in record time, in about 1 week. I have experience in creating similar applications before but I built this fully for this hackathon. I am proud to have created a working implementation that mimics the use of ticketing platforms like Resident Advisor.
What we learned
I learned a lot about about creating the final PDFs with the crypto notes. This has been challenging before, and I'm still learning how to design PDFs
Overall I had a lot of fun developing this application and I hope the judges like it too.
What's next for ZkTickets - An Event Ticketing Protocol using ZKP
The protocol is currently on testnet but will deploy on mainnet after the hackathon. I will create some ExternalTicketHandler contracts that users can deploy from the App so they don't have to know how to code if they want to mint an NFT on ticket scanning, do access control or even an in-person token sale/ airdrop.
Log in or sign up for Devpost to join the conversation.