I’m working on an article comparing a smart contracts app vs a blockstack app and stumbled upon a problem.
Imagine a hotel bookings system that connects hotel guests and hotels (like bookings.com just decentralized).
On an Ethereum app hotel inventory would be published on a smart contract and every booking would be saved onto the blockchain – probably in an atomic transaction exchanging tokens for a room in a hotel.
On Blockstack, a hotel guest and a hotel would communicate peer to peer - without a blockchain. Which is great, because you don’t need to pay any transaction fees and it’s fast!
But how do you imagine the process of booking could work on a Blockstrack app? Because if the booking is not saved on blockchain, the hotel guest doesn’t have any proof he actually had a reservation.
For example, you’d want to leave review on some sort of a reputation system for that hotel - how would the reputation system know that you actually had a reservation at that hotel?
Perhaps a hotel could send the guest some kind of a cryptographically signed booking certificate, and if the user makes it public on a reputation system - anyone can verify that it really came from the id belonging to that hotel?
The hotel could give out signed receipts – the receipt would be signed by the hotel and the user for the specific date and room. In addition, the hotel could maintain a set of records (room number, hash(signed-receipt)) for all occupied rooms, and construct a daily Merkle tree out of them and announce the Merkle tree root on a blockchain. Each day’s Merkle tree commits the hotel to the occupancy of each room. Then, any ticket holder could take their day’s Merkle root and query the hotel for a Merkle proof that their room is reserved for them by checking the hotel’s hash of their ticket against their signed ticket (i.e. to prove the existence and uniqueness of (room number, hash(signed-receipt)) in a particular day’s Merkle tree). When the guest arrives at the hotel, she presents the signed receipt and Merkle proof to show that she is the intended guest for the duration of the stay.
BTW, Blockstack apps can be smart contract apps as well.
For the hotel app, verifiable credentials - as you mentioned - should probably the way to go. The hotel issues the registration confirmation, and the user then can assert the claim that she visited the hotel in that year/season together with the review (https://www.w3.org/TR/verifiable-claims-use-cases/#assert-claim).
Verifiable claims are an important component, but they don’t go far enough towards a solution.
What happens if the hotel is malicious and books two people in the same room on the same night? By having the hotel commit a Merkle tree over all (room number, hash(signed-receipt)) pairs, the hotel is forced to commit to one guest or another.
How do you ensure guest anonymity? By having the hotel to commit to hash(signed-receipt) (more generally: a salted hash of the identifier), the hotel can publicly prove room bookings without having to divulge who booked them.
I think here are different problems that can be solved differently.
What happens if the hotel does not have a room with that room number? I don’t see blockchain as solution for these problems.
What problem does this solve?
If there is an exchange for room bookings then it might make sense to use blockchains (at the costs of anonymity), the hotel does not care who books the room, they just issue (non-fungible) reservation tokens that dealers and users can buy on the exchange. Not sure whether that is legal…
The blockchain serves to prevent the hotel from equivocating about the state of its bookings. This follows from the fact that there can only be at most one copy of the Merkle root hash of the booking state at a given point of time. You are right that the blockchain cannot stop the hotel from renting rooms it does not have, but the Merkle root hash combined with the user’s receipt and Merkle proof will serve as non-repudiable evidence of the hotel’s malicious behavior. The facts that (1) the Merkle root cannot be “taken back” once written and (2) there can be at most one Merkle root per day (and only the hotel can write it) both ensure that the malicious behavior can be identified.
The hotel commits to the hash of the signed receipt precisely to guarantee anonymity – only the user (and possibly the hotel) possess a copy of the signed receipt. Only the Merkle root over the booking state needs to be public, since this is required in order to later allow the customer to either (1) prove to the hotel that they booked the room, or (2) prove to a judge and jury (or the general public) that the hotel defrauded them.
A hotel listing and an exchange for “booking tokens” is a separate app altogether from the hotel booking site that @valrepsys asked about.