A case for a decentralised hotel booking marketplace

Preamble: a few weeks back a friend of mine asked me to talk to his client (the friend’s an accountant) about a project idea they had. The client is a tour operator who is looking to bring some fresh ideas into the space densely populated by dinosaurs. Unsurprisingly, they were looking to employ the blockchain for decentralising some parts of their business and cut some costs by ‘removing the middlemen’. Noble undertaking but I had to disagree with some aspects of their vision, in particular the fact that, it really isn’t that simple to remove the middleman even if you are using smart contracts. Without delving too much into the details of the debate, the following piece is the product of this discussion where I tried to show what it really meant to build a decentralised hotel booking marketplace. I doubt this will be anything new to anyone who’s balls-deep into the web3/crypto space but I figured, there’s enough educational value in this report for me to not want to just leave it to rot in the depths of my google docs archives.

I fixed some grammar and made some (very minor) stylistic changes but other than that, this is the original text, as it was. If something seems a bit off or sounds like outright BS - please let me know, I’ll take your comments on board with gratitude.

Introduction

In this use case we will try and imagine how a decentralised market for hotel bookings could look like. We will sketch out a rough top-level system design, go through a few interaction examples and discuss the utility of peer-to-peer consensus network (“the blockchain”) in such system.

Please note, this is not an architecture design document and is not intended to be a recipe for creating a system of any kind. The point of this document is to discuss the anatomy of a decentralised application, the associated gains, risks and challenges of using peer-to-peer consensus networks. We will use a very simplified model of a decentralised hotel booking market to merely help give the discussion some context.

The platform

Let’s consider a system that caters to the following use cases:

• A hotel can publish and modify listings for their rooms
• A hotel must lock down a deposit for future disputes and refunds
• A customer can find and book rooms published on the platform
• A hotel can take payments directly on the platform
• A customer can dispute any deals with the hotels they booked
• An independent arbiter, for a small fee, can help disputing issues by looking at the evidence presented by the customer and the hotel and settle in either’s favour
• There can (and should!) be more than one arbiter settling any particular dispute
• Arbiters are economically incentivised to act honestly and with due care (e.g. in non-unanimous scenarios, those in the minority get punished)
• Whoever initiates a dispute, pays for it. Whoever wins a dispute, gets rewarded/reimbursed.

The list is nowhere near being comprehensive enough for any sort of real-world application but should do for our exercise.

The UI

Strictly speaking, for a truly decentralised hotel booking protocol, having a graphical user interface is not required. It is not uncommon for a system of this kind to start out as command line interface (CLI) clients and acquire a visual interface at a later stage. We will talk about the possible workings of this further in the text but in the meantime, this is what a UI would look like, whether visual or programmatic: a standalone app.

The app can be web-hosted but should also be allowed to be run locally or copied and hosted anywhere by anyone. This way no single party can exert any significant level of control over the system, acting as a gatekeeper. This implies there can be no traditional back-end to the system. Otherwise, the back-end would require an operator which needs to be trusted with consistency and validity of the server-side data. Decentralised applications aim to minimise the amount of trust required for the system to function — introduction of a trusted operator running the application backend would completely offset any benefits otherwise gained from the trustless nature of the system.

Functionally, the UI should be capable of allowing its users to input data into the system (e.g. creating a listing) and reading the existing state of the system (e.g. finding the currently available listings) for all of the use cases outlined in “The platform”.

It’s reasonable to expect the code of the UI (as well as anything else in this system) to be open source.

A few possible ways of distributing the UI:

• Hosted; easiest for everyone but prone to “single point of failure” issues and introduces an unnecessary element of centralisation
• Downloadable from the web; not as convenient as if hosted but is less censorable
• Downloadable in a decentralised way (e.g. decentralised file storage, DAT, etc.); the most uncensorable and fraud-resistant option but it just might be too early for this

Business logic and persistence layer

In traditional client-server architectures, the former would normally be implemented as a server, receiving requests and sending responses according to a set of rules coded up in some programming language of choice (NodeJS, C#, Ruby etc.) The latter is typically a database of some description (Mongo, MySQL, LevelDB etc.).

In a decentralised application, both functions would have to be performed by a peer-to-peer protocol which

1. Ensures the consistency of data across all connected clients to prevent issues such as double-booking
2. Provides a known set of rules for the users to update the state of the system (e.g. in order to make a booking a customer must first pay)
3. Provides strong guarantees that the rules cannot be broken

Essentially, rule 1 provides persistence while rules 2 and 3 provide a business logic execution environment. All three together provide the means for creating a web application while the peer-to-peer nature of the protocol removes the need for any single party to operate the service.

Such protocols are known as consensus networks and are more commonly known as blockchains (note, blockchains are a subcategory of consensus networks). The main defining feature of consensus networks, as opposed to other types of p2p protocols, is the introduction of strong cryptographic guarantees over the consistency of carried data.

With a blockchain “under the hood”, there are generally two options for where our business logic can reside:

Protocol layer: i.e. make it part of the blockchain itself, similar to how it’s done in “featurecoins” (e.g. Namecoin for DNS; Steem). This can be quite efficient and works well for simple use cases but becomes incrementally less feasible as the complexity of the interactions supported by the system grows. Adding new features would require frequent software updates and blockchains are notoriously bad at that (at least the truly decentralised ones).

Meta-protocol layer: blockchains such as Ethereum are relatively feature-free but instead allow deploying completely arbitrary code onto the network and ensuring that the code will function exactly as defined. An application’s logic can be written in a single logical unit, very similarly to how one would write a class in Java or C++, and such unit is called a “smart contract”. A smart contract can be deployed, or registered on the network and upon that can exist and function completely independently of the creator.

Using smart contracts, one can create a business logic layer for their decentralised application without having to worry about the internals of the blockchain that runs it (which is usually very complex).

Other components

Note that the sort of versatility and security attributable to blockchain tech, come at the expense of efficiency, as compared to more traditional tools like SQL databases. Smart contracts on the Ethereum blockchain are slow and expensive to run so the extent of their use should be as minimal as possible, ideally for sealing agreements and making payments only.

To give an example, the SSTORE opcode which persistently stores a single 8-byte word of data, costs 20,000 units of GAS (see the Ethereum Yellow Paper, page 20, appendix G. Fee Schedule, Gsset). Storing a megabyte of data would incur the computational cost of at least 2,500,000,000 GAS. Leaving aside the fact that the current per-block maximum GAS limit is several orders of magnitude lower than this figure, the cost of this operation, at 10 Gwei per gas unit and assuming $300 per ETH, would be $7,500. You can find a better detailed explanation here.

If storing large amounts of data is indeed required for any of the protocols in our system to function then it is preferable to use an alternative solution such as a decentralised file storage. There are several options for this such as Storj, Madesafe or the more mature IPFS. Integrating a decentralised file storage into the system would pose its own challenges, not least associated with increased complexity and attack surface.

Apart from the content storage requirements, a decentralised protocol might have to depend on frequent non-persistent secure p2p messaging, e.g. for deal negotiations. Apart from inevitably incurring cost on any form of data transfers, the public Ethereum network is also rather slow: the current average block time of the Ethereum network is 14 seconds. While certain permissioned blockchain configurations provide sub-second block times, they also introduce a strong element of centralisation. The new generation of blockchains projects such as Polkadot as well as some off-chain solutions such as Lightning Networks, State Channels or the Whisper protocol will, depending on the circumstances, be able to facilitate high-frequency data exchange at no added centralisation, none is mature enough to rely on. There is no known “silver bullet” solution to the problem — the right tool will depend on the nature of the needs of the project (in other terms, YMMV).

Thought of as a database, blockchains are unbeatable at censorship resistance and maintaining data integrity. They are terrible at most other things.

As a general rule,

A blockchain should only be used in a project if and only if there is absolutely no way to substitute it with a different class of software.

Protocols

Protocol: a set of rules governing the exchange or transmission of data between devices.

App: a computer program designed to perform a group of coordinated functions, tasks, or activities for the benefit of the user

You can read about the benefits of developing decentralised protocols over decentralised applications in this article reviewing the differences between the two. We can also just say that decoupling of system components in software is generally a very good strategy. With that, let’s review the two main underlying protocols supporting our use cases:

Listing and booking protocol

The protocol should allow service providers (hotels) to

• Create new listings
• Update existing listings (created by the listing owner)
• Delete existing listings (created by the listing owner)

The protocol should allow service consumers (customers) to

• Make a booking and pay for it
• With some constraint, amend or cancel bookings

A new listing is created when the provider transacts with the protocol (i.e. calls a function in a smart contract) with

• The information about availability dates
• Cost of accommodation per day
• Link to a document describing the offering (e.g. a URL to a web page) accompanied by hash of the document content to prevent future fraudulent substitution of the content

A new reservation is made when the consumer transacts with the protocol by:

• Requesting the start and end dates for the booking
• Sending the specified in the listing amount of funds

Once complete, a reservation can either result in automatically updating the availability of the listing or simply rely on the listing’s owner to update their records. The latter approach is more error-prone but is somewhat more flexible.

Dispute resolution protocol

The protocol should allow anyone to:

• Submit a security deposit
• Retract the deposit, subject to a time delay or some more complex set of rules
• Indicate whether they want to act as an arbiter or not

The protocol should allow anyone who has submitted a deposit to initiate a dispute by:

• Challenging another address which holds a deposit

A dispute is then resolved by selecting (probably at random) a number of depositors and initiating a vote. The disputing parties are then allowed a period of time to present any evidence to the chosen arbiters — this process can happen off-chain. Following that, on-chain secret ballot voting happens, using some form of commit-reveal scheme. Once the results are revealed:

• The majority (probably stake-based) will have chosen the winner
• The loser’s deposit (or part of) is taken away
• The minority voters’ deposits (or parts of) are taken away
• All the confiscated funds are then shared between the winning party and the arbiters

Note the multi-purpose role of the deposit in this, rather simplistic model of the protocol:

• Service providers can submit a deposit as proof of good intent in any other protocol (but in particular, our listing and booking protocol)
• Arbiters can submit a deposit and flag up their intention to be an arbiter. Minority voters in any dispute lose their stakes
• A dispute initiator has to submit a deposit to prevent anyone from creating new disputes inconsiderately

This protocol depends on a few game-theoretic aspects working in its favour. In particular, the assumption is that arbiters should always be incentivised to act truthfully because the truth is always more common than any particular lie in a reasonably large pool of participants. This game theoretic concept is called Focal point and is also more commonly known in the crypto community as the idea of SchellingCoin.

The nature of this protocol definitely poses the most amount of risk to the system as any possibility of collusion would render it useless. Schelling point has not yet been proven to work at scale in consensus networks. However, several other projects are actively looking into utilising the concept. Most notably, the decentralised prediction market Augur heavily relies on Schelling point voting on event outcomes. Perhaps, something can be learned from the work they have done.

Token

Having designed and implemented the two protocols outlined above, together with some auxiliary software to tie the two together into some form of an API, one can have a working bare-bones proof-of-concept prototype that can be deployed on the live network and tested in the wild.

However, it is still missing a vital economic element. Namely, economic incentive for the development team and the ecosystem to help the system grow. Surely, great projects can exist as donationware thanks to altruism and enthusiasm of their communities but it’s undeniable that to accelerate growth, the project has to give some promise of economic reward.

By introducing a protocol coin (aka a token) necessary for the protocol to function, such economic incentive can be created. The protocol can give the token utility. Utility drives demand up and creates scarcity. Scarcity increases exchange value and makes token holders wealthier (and happier!).

The main requirements for the token are:

• Finite supply
• Reasonably uniform distribution among token holders
• No centralised/authoritative control over any function of the token by any party (strictly speaking, not a requirement but an extremely desired property)

Finally, within our system the token can be required for submitting deposits within the Dispute resolution protocol. That alone, should give it enough utility to drive the value up. Especially so, as by design most of the available supply should be locked down for potentially long periods for time, further reducing available supply.

Comparison to a centralised version of the service

Given a working implementation of some version of the system described in this report, the result would be a set of fully decentralised (i.e. free of control of any single party) protocols, some auxiliary software that ties them up into a single mechanism and gives it context (i.e. makes an App). Let’s say the following is also true:

• The app is downloadable from the internet from multiple sources to download from
• The code for the entire system is open source, developed by the core team and independent contributors
• The core team has no authority to alter any of the protocols, at least not without permission from the token holders according to some governance rules
• The protocols can be interacted with using the API/UI (which can actually be proprietary) developed by the core team, but the users of the system can also develop their own tools if they wish to do so

There is no operator running the service — it exists on its own. No middlemen between any of the participating parties making agreements. The system has no owner; it’s decentralised.

Comparing this to a centralised service providing the same functionality in respect to hotel bookings and resolving disputes, what are the relative advantages and disadvantages of our system over its centralised alternative?

Advantages

• No single point of failure: no matter what happens to the core team, the service can continue to function.
• Guarantee of immutability of agreement: no sudden terms changes; no possibility for the service to “bait and switch”.
• Alignment of stakeholder incentives: token holders benefit from the project’s success and help its development/promotion/etc.
• Virtually eliminated operating costs: no infrastructure, no staff — no fees (except blockchain tx fees).
• Accelerated liquidity: much easier (currently) to float a token than any more traditional financial instrument.

Disadvantages

• Reliant on game theory: many unknowns in the system design to deal with. Attack vectors hard to predict.
• Decentralised systems tend to get complex and bugs can be catastrophic.
• Regulatory push-back on token sales: high legal costs and increased risk liability for the core team.
• Very unstable ecosystem: few well established libraries and tools, a lot of the available software is experimental

Conclusion

Decentralised applications and protocols supported by consensus networks have tremendous potential in that they largely eliminate the human element in facilitating and enforcing agreements. Two parties making a deal on the internet no longer need a third one, imposing its authority, creating a monopoly and charging arbitrary fees. At least that is the idea.

Hopefully, this report serves to show how a decentralised application such as a hotel booking marketplace needs to be structured in order to be considered truly trust-free. It should also make it clear that the peer-to-peer space is scary and should be approached with maximum care.