NFT ticketing system verification

[giorgionocera]

In your Web3 scouting journey, you probably encountered an exciting number of services using NFTs to provide new ticketing systems. Such systems enable an event organizer to verify if a user owns a valid ticket (which usually, on these systems, is an NFT stored on a Blockchain) and provide access to the experience.

During my analysis, I figured out mainly two approaches.

First implementation

First, I reasoned about a system that could mimic "human behavior" at an event.
Let's consider a user, Gianni, who wants to access an experience, bought his paper ticket, and got in line waiting for his turn.
Once his turn comes, he gives the ticket to the Security Officer, who cut it on the dashed line, keeps the receipt, and gives back the copy to Gianni. He can now access the experience.

Similarly, in the following implementation, the user owns an NFT before the event starts, and he/her redeem the NFT through a smart contract once he is in front of the Security Officer.

sequenceDiagram
    participant user as User (Mobile Wallet)
    participant verifier as Security Officer (Permissionless PWA)
    participant server as Backend Services
    participant bc as Blockchain

    Note over user,bc: The User must have a not redeemed NFT ticket to interact with the Security Officer
    user->>+verifier: Open the connection to<br/> the DApp (QR-Code)
    verifier->>+server: Check if User has<br/>a valid NFT ticket
    server->>+bc: Query User's balances
    bc->>-server: Respond with query<br/> result (User's NFT tickets)
    server->>-verifier: Respond with check<br/>result (NFT validity ticket)
    Note over user,bc: If the Ticket is not valid, the Security Officer stops the experience
    verifier->>user: Propose to sign a tx to send the<br/>NFT to the smart contract to<br/>start the redeem process
    user->>+bc: User signs and broadcasts the transaction contacting the smart contract 
    bc->>-user: The Blockchain includes the transaction in a new block and attaches the results from the smart contract
    user->>verifier: Trigger the DApp after<br/>transaction registration
    verifier->>-user: Close the connection to<br/> the application
    Note over user,bc: The Security Officer let the user access the experience

Loading

Second implementation

It is reasonable to consider that the previous solution is time consuming.
Let's again consider our user, Gianni. He wants to join at the concert of his favorite band. Again, he bought his ticket, got in line and waits for his turn. This time, he has the ticket framed at the turnstile and want to access asap to get to the best place from which to watch the show.

With these reasoning in mind, the user has an NFT before the start of the event and uses it in front of the security officer/turnstile to access the experience.

sequenceDiagram
    participant user as User (Mobile Wallet)
    participant verifier as Security Officer (Permissionless PWA)
    participant server as Backend Services
    participant bc as Blockchain

    Note over user,bc: The User must have an NFT ticket to interact with the Security Officer
    verifier->>+user: Scan the signed address<br/>of the user (QR-Code)
    verifier->>+server: Check if User has<br/>a valid NFT ticket
    server->>+bc: Query User's balances
    bc->>-server: Respond with query<br/> result (User's NFT tickets)
    server->>-verifier: Respond with check<br/>result (NFT validity ticket)
    Note over user,bc: If the Ticket is not valid, the Security Officer stops the experience,<br/>otherwise he let the User access the event

Loading

Thoughts

As always, it is possible to outline that also in such a context, there is a trade-off between user experience (which, this time, is directly proportional to the time spent in the verifying operation) and security/usage of fully web3 implementation (no centralization of information).

The first solution, is slower, but only uses NFTs to check the ability for a user to access an event. It is also resistant to "double spending" problem.

On the other hand, by mixing Web3 and Web2 technologies it is possible to provide the second solution, which could be faster at the expense of "distribution" (more than decentralization). In this solution, the check done to avoid double spending is provided by a database (which can be implemented through lightly decentralized services) system.

What do you think?
As always, any contribution is welcome! 😄

[DavideSegullo]

Before giving a full assessment, I have some questions:

1. In the scheme of the first implementation "Those User's balances" means the nft tokens, right?
2. When validating the ticket, by the Security Officer, we will have to check that the ticket not only exists but that it belongs to the event you are in (perhaps there may be several in different places).
3. In the first diagram we expect the smart contract to redeem the ticket, but we have to check if the user remains pending or if to carry out this check it is necessary to listen to two successive blocks and not just the current in which the tx is located. (Research)
4. Can you better explain the last point of the second scheme: "trigger the User wallet to prevent the access to the ticket (QR-Code)", what exactly do you mean?

Thank you

[giorgionocera]

Yeah, I'm going to answer you by points:

1. Yup, it means users' NFTs balance;
2. It is a process included in the validity check of the NFT ticket. This check can be provided on the Backend Service before contacting the blockchain. This will speed up the flow in some cases;
3. Yeah, it could happen that the "Blockchain includes the transaction in a new block and attaches the results from the smart contract" operation can last longer. We need to work out a description for such a process;
4. You are right, I did not express myself well. I want to indicate that the app at that point should no longer be able to show the QR-Code. But for clarity, I will edit the diagram to remove that statement.

Let me know if it is clear enough.
Thank you!

[DavideSegullo]

Yes, It's clear now, thank you

[DavideSegullo]

After the various clarifications, I suggest evaluating the first solution, trying to calculate how slow it actually is as a solution and if the times are acceptable.

What do you think @giorgionocera ?

[giorgionocera]

I really like the first approach. The problem is that it may not be suitable for some scenarios (like concerts).
I agree with you that for sure we need to perform some tests 🤓