Blockchain in Travel Industry — Part 1: The wider context

Lukas Schack
TUI Blockchain Lab
Published in
7 min readApr 8, 2019

TUI’s Blockchain Lab works on innovative Blockchain applications beyond the Proof-of-Concept level. In this series of blog posts we want to outline some basic thoughts on why we think Blockchain and distributed systems will bring a benefit to the Travel Industry.

About this article series

We will not cover the 101 on Blockchain — there are many great articles here on Medium and other online sources (e.g. https://blockchain.berkeley.edu/decal/fa18/fund/). Instead we will focus on some technical key concepts that we think may fundamentally change the speed of adoption of applied consensus mechanisms. The first is the concept of Zero Knowledge (“Proof that you know a secret without unveiling the secret”) and Layer-2 frameworks (in particular State Channels). Our assessment of specific technologies may change over time — due to the tremendous speed this field is developing in.

This first post is about the general context: Where do we see future use cases of Blockchain in travel space? Since Blockchain is a base layer technology all our findings and assessments should be easily transferable to other industries.

The second post is about the application of ZK-SNARKS: A concrete solution to existing challenges of Blockchain, namely the conflicting poles between public readability of the ledger and privacy required by the business.

The third post is a hands-on tutorial based on the ZoKrates implementation that shows how a concrete use case looks like.

The fourth will be about a concrete implementation of State Channels. A technique to combine the security and immutability of on-chain transactions with the speed and scalability of off-chain transactions.

Blockchain in Travel Industry

The tremendous attention Blockchain gained over the last years was — and still is — mainly caused by the high expectations on cryptocurrencies. Especially Bitcoin became a speculation object that is often compared to the tulip mania in the 17th century in Europe. We rate this hype as a clear indication for the investor’s anticipation of the profound impact this truly decentral type of money has for the financial industry and possibly also society.

Often “Blockchain” is misused as a synonym for “Bitcoin”. In reality Bitcoin is on application of Blockchain. Analogous to “Email” as one application of the “Internet”. In all our past activities we did not consider on-chain payments as a valuable use case for TUI. A very high volatility of nearly all cryptocurrencies forbid this. And all mitigations like pegging the cryptocurrency to fiat money or physical assets are not working reliably on a large scale. Also legal aspects are not fully clear at the moment (as of February 2019). But once those challenges are solved — we think that also payments will play an important role in future since they are an intrinsic element of all public Blockchain infrastructures.

But if it’s not the cryptocurrency — where do we see the benefits that justify spending a lot of time investigating and applying this technology?

This brings us back to the one and only valuable characteristic coming with Blockchain and only with Blockchain: Trust by architecture in a trustless environment. This is a fundamental difference to decentralised systems — that are sometimes misleadingly interchanged with Blockchain.

Comparison of different system architectures.

The table above compares fundamental characteristics of three different system architectures. First the traditional server-client setup where all the data is stored in one central place. This can also be a cloud provider that internally replicates the data. The important point here is that all the data is controlled by one entity. That entity could amend or delete data without the clients noticing it. It requires the trust of clients that the central entity is not misbehaving. A distributed database like Oracle has the advantage of higher availability and failure safety since the data is replicated across multiple entities. Also local autonomy can be granted so that only data owners can control subsets of the overall data. But in terms of possible data operations a distributed database allows for changing written data. Those changes can be logged and tracked by all system users. Blockchain systems on the other hand only allow additions to the shared data. Since all the data is fully replicated to all participating entities, all can verify the validity of a transaction. The foremost application for such a system is a cryptocurrency where each incoming and outgoing value transfer is communicated and validated by all other participants. This concept can easily be widened to value transfers of any kind, like the transfer of the right to use a bed in a hotel for one week from a hotel to a customer.

Both, distributed databases as well as Blockchains have to deal with physical and technical limitations of network latency. This has some impact on the availability and data consistency (see CAP theorem). Blockchains are typically designed to favour data consistency higher than data availability. This results in a rather “slow” system when compared to a centralised system. A distributed database in contrast can be configured to value data availability over consistency which results in much faster writing operations but could lead to inconsistent data states when queried at the same time from different end points.

We want to explicitly outline here that from our perspective Blockchain is not and probably will never be a replacement for a centralised system architecture or a distributed database. It is an additional architecture that works besides the other two classes. Its purpose is to provide a highly secure network where direct value transfers between participating entities without the need of a third party can be conducted. Whenever nothing prohibits to use a trusted third entity it may be more efficient to use a centralised system which typically comes which much higher transaction speed.

But back to the above question that is not answered yet: Why do we think we should use Blockchain?

The answer is: We want to develop a system in which every participant knows exactly what he is owning in what point in time. We believe that the travel industry needs a 1-to-1 link between physical assets like cabins in cruise ships or beds in hotels and the legal entity that has the right to use that specific asset. In other terms it means de-duplication of inventory. A unique view on all physical assets across the whole travel industry. This goes hand in hand with benefits like a gapless audit trail of all owned or contracted assets. On the other side the removal of intermediaries is of central importance. From TUI’s perspective there are multiple intermediaries between the physical assets and the end customers enjoying their holidays. A typical example on the supplier side is a bedbank which gives access to multiple hotels by aggregating and standardizing. Towards the holiday maker there are multiple intermediaries along the distribution chain, like online travel agencies, for instance.

We offer the customer packaged holidays that consists of manifold individual elements.

The above image illustrates how a TUI holiday looks from the customer perspective. The traveller receives a package, conveniently including all the components that belong to a relaxing sun and beach holiday. Such a packages contains all individual parts like a flight, the transfer from the airport to the hotel, the room(s) in the hotel and maybe some excursion or tickets to a soccer match nearby. This sketch is extremely simplified. Sometimes there are 10s of individual components and most are provided by different suppliers. That means that each individual holiday is a set of assets combined in a (nearly) unique permutation.

The real-world complexity of above example is much higher since there are multiple markets TUI is offering its products. The physically identical bed can be on sale in different markets. Hotels cope with this complexity by abstracting from physical beds or rooms to room types describing properties that a room has to fulfil. But the challenge remains: How to cope with this increasing complexity and how to ensure that not more than available beds or rooms get sold? The next article outlines another use case

Why couldn’t we all do it with a third party that acts as the trustworthy central instance? Isn’t TUI itself a trustworthy central entity?

Yes, that would definitely work — as long as all participants follow a common standard of describing their assets and as long as that central entity is in the participant’s confidence. For TUI that is definitely the case in Europe. But whenever we look to South America or Asia, TUI is hardly known. Blockchain can help here to establish this trust. Every participant of an open ecosystem can be sure that no excessive fees are added to its products, for instance. Also double bookings can be prevented.

Another important driver is the removal of intermediaries. Especially in the travel industry a touristic product has multiple stations between the original supplier and the end customer. Removing intermediaries directly could lower the fees along that chain. This may result in lower prices for the customer and potentially higher margins for the suppliers.

In the second post we share our vision on Zero Knowledge Proofs, a solution to one fundamental problem of current Blockchains: the required compatibility of consensus and privacy.

--

--