Story behind Travel Protocol

T

First of all, congrats to the team to build #travelProtocol under 36hrs in #ETHGlobal Hackathon Brussels, and of course, brought back two awards!

The Most creative use case award from Worldcoin.

The best zk dApp (2nd place) from Polygon.

Amazing job team! In this article, you will find the thought process and how we implement the solution.

Problem and solution

When you make a hotel booking, you fill in your name, gender, nationality, even your home address, and most people think it’s so common that they have been doing that for years! Platform like Booking.com, Airbnb, they have been collecting tremendous data from us for decades. By 2023, Booking.com has over 120 million active mobile users on their platform, and have generated one billion nights booked and 36 million airline tickets purchased in 2023[1].

Can you imagine that the real names, gender and even home address of these 120 million people are known to one company, and is stored “carefully” on their server, and is shared with their partners?

According to Booking.com’s own privacy policy [2], they collect A LOT of user data, because they want to offer better services to their customers. “The main reason we ask for personal details is to help you organize your online Trip Reservations and ensure you get the best possible service.”

Ethereum has been serving over 200 million [3] users globally, without collecting any of their personal information. Why can’t the booking platform offer great services while not collecting unnecessary personal data?

During our interviews with hotel managers, we noticed that the working process they check-in a guest is to manually match guests’ names to the information booking platform shared with them. Normally a name check is fine, but they have much more information like gender, nationality, phone number etc to compare and check.

One important thing we found is that some countries require the hotel to obtain guests’ identity document by law. Therefore, the hotel does have the right to see a person’s passport for instance. However, there is no such law that give the right for booking platform to collect such information.

So the problem we are trying to solve is to let the booking platform passes a Booking Proof information for a user without giving away actual user data. To achieve this goal, we must 1) allow the booking platform to give some information that the hotel can easily verify. 2) The user can verify to the hotel their unique identity. If we combine 1) and 2), the problem is resolved.

Here is the implementation:

We incorporated World ID (from Worldcoin.org) as the unique identity for users. This can be replaced by other wallet technology but Worldcoin has more personal attachment due to the iris scan data. Once user login with their World ID, and successfully book a hotel in our platform (it’s a simulated booking). Our platform will create a Booking Proof using the data like user’s World ID, Booking ID, check-in/out date and hotel information, but without personal sensitive data. This Booking Proof will be stored with the World ID in a table for later use.

• We use circom to compile the circuit.
• Generate the witness and proof using snarkjs.
• Generate the verifier contract (Verifier.sol).
• Write the protocol smart contract travel_protocol.sol
• Deploy the smart contract to Polygon zkEVM.

For more information about circom and snarkjs, please refer to their official repo: https://github.com/iden3/snarkjs

Also thanks to Kartik Jain who posted an article [4] to explain this, which helped us quickly acquire the necessary knowledge.

So far, we know the World ID of the user, we know their booking information. No more.

When user goes to the hotel, the hotel will request the user to scan the World ID QR code on a webapp provided by us. A webapp can be run on any platform (computer or smart phone). Once user verifies their World ID, the App will automatically search for the associated Booking Proof and verify it with the Blockchain. We have created a simple database using pocketdb running along with the Next.js web application, for simplicity. You can deploy it to a more advanced database or even IPFS or file protocol e.g., Filecoin. Data are completely anonymous, thus we don’t need to worry too much of where we store the data, however, data availability is important. A decentralized storage solution might be favorable in the long run.

This is the project page from ETHGlobal: https://ethglobal.com/showcase/travel-protocol-1skiq

Discussion

The team not only wrote the code but also talked to local hotel managers to verify the use case. We got very positive feedback on the solution both from users and hotel managers.

However, the Travel Protocol V 0.01 is a prototype that created under 36 hours, to demonstrate the possibility of booking hotel without revealing user sensitive information. There is still a lot room to improve and we foresee a lot of challenges to actually implement this solution into hotels. Below are a few challenges we think worth solving in the near future.

1. Worldcoin has over 12 million verified user, it’s a good start, but it’s way small number even just compare to booking.com’s 120 million user. There are Expedia, Trip, and many more travel giants. How can we increase adoption of SSI and crypto technologies? How company like Worldcoin, Humanity Protocol continue to thrive and scale up is critical to the success of travel protocol.
2. In Booking.com’s privacy policy, they mention that one use case to share data with other entities is when required by government authorities. We can imagine police are interested to track where are the criminals stay when they move from one city to another. Booking is able to share such information with the police, but if the data is not provided to us, how can we help the police if needed? Can police collect iris data from everyone in the future as one of the bio-metric data? This is another interesting topic to work on.
3. With less data, the booking platform will lose insight of the user and has less capability to run their AI to better serve their customers. How can we resolve this problem, so we can get enough adoption from booking platforms to together build the protocol?

Reference:

[1] https://www.businessofapps.com/data/booking-statistics/

[2] https://www.booking.com/content/privacy.html#personal-data-collected-type

[3]https://ycharts.com/indicators/ethereum_cumulative_unique_addresses#:~:text=Ethereum Cumulative Unique Addresses is,16.01%25 from one year ago.

[4] https://medium.com/@kartikjain42/guide-to-crafting-your-first-zero-knowledge-contract-1815d82be1ea

Follow and talk to us on social medias: linktr.ee/mobifi_official