Blockchain, a new buzzword on the block? Since cryptocurrencies boosted in 2017, the massive media focused on Bitcoins and alike cryptocurrencies, it is compared with the tulip bubble in the 17th century, new millionaires, Finance’s gurus saying these currencies worth zero, etc. I believe we will see real-valued cryptocurrencies but backed by a regulation, or cryptocurrencies for niche business models and collaborative economy, but not with this nonsense that we are living. In this article we are going to introduce this technology through an experiment, a Passenger Journey Blockchain that tracks and processes all the transactions from the trip’s booking, going through the airport, airlines, flight, public transportation and the final hotel destination. Just for playing with the Passenger Journey Process and the Blockchain technology.
First of all, please, apologize me if you already know Blockchain basics, if so go through the Proof-Of-Concept Passenger Journey example, and also apologize me if you don’t know about blockchain because it is needed to read some lines in this article before the Passenger Journey example.
CHAPTER ONE. BLOCKCHAIN 101
I really want to put the focus on the technology behind cryptocurrencies, Blockchain technology, a new decentralized and distributed platform, that has a lot of interesting features:
- Massive Distributed database (ledger). Holds the data
- Distributed nodes that produce transactions. Records the data under a consensus network agreement.
- Cryptographic foundation. This means, confidentiality, integrity and availability. Safe the data and make it transparent, in some cases this transparency is configurable.
Cryptocurrencies are the main, and original, application for the blockchain technology but a lot of applications, consortiums and business cases are looking at this technology for improving current business models, creating new ones and putting in value complex business processes. A lot of examples there:
- International payments clearance between banks.
- International shipment processes.
- UN World Food Program in non-bankarized refugees camps for payments.
- Local farmers communities with funding needs.
- Tokens for exchanging assets.
- “Smart contracts” needed for controlling transparent or regulated processes. I do not like too much the “Smart contract” term, not too much precise.
- A “classic”, insurance domain. Share, and record, information between all the parties involved in claims.
So, I wanted to introduce myself in this technology developing a POC about the passenger journey process, at least in some points of the process. From the booking to the destination, involving, transports, payments, fees between parties (airlines, ANSP, airports, hotels, etc.), and recording all the steps and transactions in the Blockchain.
BUT WHAT A BLOCKCHAIN IS?
The academic definition is “It s a decentralized database in which the data evolution (transactions), including its status, is recorded in a differential changing way, this delta is represented by a block, and its evolution is like a chain and is safe and immutable.” It is a little bit academic, let’s be more clear approaching the main features we mentioned above:
- It is a database, yes, and it records data held in a block. Just a record.
- It is distributed, yes, the database has several nodes that maintain the same information, and its evolution (traceability), so the same recorded data has a lot of copies. But….are they the same in every node?
- It has the data encrypted, yes, the data is encrypted and has a lot of classic cryptographic measures at its core. These measures are focused on, the data would/should be confidential (depends on the case), the data its immutable and the data is accessible. But who guarantee this?
- Nodes everywhere, that holds the copies of the data and validates that the data is truthful and the network has a consensus about that. If the data is not accepted, the data is not recorded.
- Regarding the database (blockchain) accessibility perspective, there are two types: public (everyone can join and participate) or privates (only pre-approved participants are allowed). And there are two other types for them, permission (only who has certain rights can execute transactions) or not-permissioned (everybody can execute everything).
WHAT PROBLEM DOES THE BLOCKCHAIN RESOLVE?
Simplifying a lot, trustfulness. Not only with third-party you already confide (you don’t need blockchain for that) but with others for sharing data, knowledge and transactions or contracts. It is a win-win for every party involved in the blockchain. Remember, every transaction and record is validated by the network with clear rules and stored in nodes across it.
WHAT ARE THE MAIN ACTORS IN A BLOCKCHAIN?
As mentioned before the blockchain architecture is composed of nodes, in my case, I’ve chosen Hyperledger implementation, it has three main types:
- Client: the client invokes the transaction, the data to be processed and stored. The client can be an App, a Web, etc.
- Endorsing Peers: they are the nodes that confirm/accept the transaction and maintain the transaction/data status and have a blockchain copy.
- Orderer node: very specific of Hyperledger, they are the nodes that offer the communication service, the delivery guarantee service for the data/transactions among nodes.
WHAT ARE THE SMART CONTRACTS?
They are one of the most valuable factors of the Blockchain success, they provide you the way for make transactions, establish the rules and process the data that resides in the blockchain, in the case of Ethereum implementation, the Smart Contract, its functions and data are also a block inside of the Blockchain, so the contract has all the good parts and attributes of the data and its status.
You can imagine a lot of Smart Contracts examples: if some condition met pay someone, insurances policies, data sharing, if you use this copyrighted photo register it and pay a fee, letter of credits between banks and customers, supply chain and delivery tracking and of course, create a cryptocurrency and develop its offering, buy and sell, etc. contracts (the famous Initial Coin Offerings, ICO).
In our case, and this is a little introduction for our example, we will model all the transactions between the passenger, airports, airlines, ANSP, hotels, etc. through Smart Contracts (Chaincode).
CHAPTER TWO. THE PASSENGER JOURNEY BLOCKCHAIN
And finally, we get here, to the example. In this Proof-of-Concept we are aiming the following objectives:
- To track, in the same blockchain, the whole Passenger Journey from its booking to the final destination.
- To process the main journey’s transactions (contracts) among parties and record them in the blockchain.
Why? I could “sell” you the innovation buzzwords, all the hype arguments around Blockchain and the future, but I’m not going to sell you anything. I take this example to model the whole Passenger Journey Process as a Supply Chain Procurement for setting the foundation better services, better transparent travel policies, better passenger experience through seamless processes (as security processes), etc. It is not the technology, it is the problem of all the little drawbacks you can face in a Trip, delays, stressful security processes, baggage claiming, booking problems, etc. A lot of providers having a Passenger in the center of an experience. This is just an example for gathering all the parties in a single platform.
The next graphic shows the case:
The passenger books a trip, take a public transportation (bus, Uber, taxi, train, subway, etc.) to get the airport, checks the baggage, pass through the security check-in, enjoy some meals, VIP lounges, take the flight, cross some countries, arrive to the final airport, pass the immigration control, baggage claim, take public transportation to the city, check-in in the hotel, etc. All these steps have transactions to process, and some of them have payments involved, so let’s model them through a Blockchain!
The parties involved are shown in the next infographics:
Putting the Passenger in the center, the rest of actors involved in the Trip are surrounding him, but not all of them have a direct interaction with the passenger, for example, AirNAV provides navigation services to the airline, commissions between the Booker and Airlines and Hotels, fees between Retail/F&B and Airport, etc. All these transactions and contracts are executed within the Blockchain and the data is stored into it too.
CREATING THE BLOCKCHAIN
Let’s create the Blockchain, in this case for simplicity, quick prototyping and small computer’s resources consuming, Docker came to help, and just download a Hyperledger Fabric Container and execute it on Docker on my Laptop. (See, at the end of this article, another case of Docker running Hyperledger Fabric on a Synology NAS).
The architecture of the solution should be as follows
In this article for developing a quick Proof-of-Concept, I merged in the same Docker container, all the actors, nodes, API, using Composer the tool to rule them all. Let’s see the deployment.
CREATING THE MODEL
The model file (.cto) has the participants, assets, transactions, concepts and types needed for this POC.
Participants are the actors, Passenger, Airport, Hotel, PublicTransport, Airline, etc.
Assets are those artefacts that could be used in some transactions. For example, baggage, the booking, a flight, etc.
Types, they are just the types of the Participant or Asset’s attributes, in Baggage asset, the bagStatus attribute could be CHECKED, BOARDED, UNLOADED, etc. so this part of the model could be as follows:
Concepts, are like an attribute contained within an Asset, Participant or Transaction, and can be used as the abstracts class in Object Oriented Programming. In this case, I modelled as a Concept the fees exchanged in some transactions.
CREATING THE “SMART CONTRACTS”
I do not like too much the Smart Contract (Transactions) name, but it is not bad for explaining “an interface between two parties exchanging data under certain conditions or rules”. The transactions are defined in the model, as follows:
TESTING THE BLOCKCHAIN
Let’s play a bit with the Blockchain, we are going to populate some basic data, the participants, airlines, hotels, airports, transports. In this case, using Composer, but the good way is doing programmatically through a User Interface as a Desktop/Web App or a mobile App. Let’s start adding the Participants.
ADDING THE ACTORS
Creating a participant or an actor, is very simple, remember this must be done through an application, we use the attributes defined in the model and populate them in JSON format. Let’s see some of them:
Once created, you can see them in the registry;
Let’s see some other assets’ creation:
And of course, we need flights:
MAKING OUR FIRST TRANSACTION. BOOKING A TRIP
We just have the minimum for creating our first transaction, booking a trip, with a flight, accommodation and even one public transport. The example is just informative, obviously, we can add more attributes, flight’s legs, transportation, etc. We invoke the makeReservation transaction.
And we have our first block stored in our Passenger Journey’s Blockchain! It has the transactionID (very important for continuing the chain), timestamps and the rest of the data we added in the transaction.
Now, we can run all the steps that follow the booking, going to the airport and store the transaction, going to the airport and check the baggage, security, buying some stuff at the airport, boarding, changing the flight status and communicate to Eurocontrol, store the flight hours (TSAT, TOBT, etc), check-in at the hotel, take an Uber, etc, etc. And of course clearance the fees among parties. All playing with the model and transactions.
You might be wondering how about some privacy in all these transactions, I mean, probably the fees applied by the Navigation Air Service Provider are not useful for the Passenger, or the fee paid by the passenger to Uber is not interesting for the Hotel, or yes, the passenger bought some perfume at the airport, and the airport wanted to know the gross amount in order to get the fee, etc. For this cases, Channels and Access List came to help. You can define the visibility rights and or the transaction rights that the participants have. Let’s see a little example:
WHAT ABOUT PAYMENTS?
Let’s introduce the fee payments among parties, we introduced, in the model above, the concept Pax Fee, we need to make some changes in the model in order to add payments and allow to transfer money (or crypto-coins) among parties. The following example is related to the payment between the airline and the Air Navigation Service Provider.
First of all, we create the Wallets, these are the accounts from/where the money flows.
The User is the owner, but our participants are not identified by Users, we have Airlines users, Passenger users, Booker users, Airport users, etc. We need to abstract a bit the model, first, we create the participant User, and extends it to the other participants.
So, we have the Wallet and Participants defined, now, we have to model the payment transaction. This is very simple one, the payment for the Air Navigation services paid by the airline.
Please remember we defined some concepts fee before, so the attribute AirNavigationFee will contain the amount, the concept and some id.
We are ready to implement it in the code and pay for the service.
Turning into real life. These are the steps for the transaction between an airline and an ANSP.
- Create the Wallets for each participant.
- Execute the transaction.
This the Wallet’s creation for the Air Navigation Service Provider, in this case on behalf of NATS.
And this the Airline’s Wallet:
So after the successful flight, Iberia Airlines must pay to NATS for the Navigation Services.
And the transaction is completed, let’s see what’s happened:
The record is stored in the Blockchain:
The Wallets have new amounts:
And we triggered an event for inform both parties of the transaction’s success:
VISIBILITY AND ACCESS RIGHTS
You might wonder if some transactions should be more private in this blockchain network. Why must the fees paid by the airline be accessible by the airport, the passengers or the bookers? Or how to hide the pax security or passport’s control clearances’ transactions? And, of course, the wallet’s amount. We have two tools for resolving these issues, channels and access control lists.
Channels: they are private networks between two or more parties/members/participants of the blockchain. The transactions are executed and only visible to the members granted to participate in these channels. See the next visual explanation.
Access Control: we can set rules for defining access restrictions to the members to the Blockchain’s assets, which users are permitted to create, read, update or delete elements in the blockchain. For instance, the Wallet should be only viewed and managed by the wallet’s owner (and admin of course), let’s see the example:
BLOCKCHAIN APPLICATIONS. WHAT FOR?
We can establish a lot of business cases for getting the value of a Blockchain, imagine some of them:
- The flight was cancelled or delayed (for more of 5 hours) you have a trip insurance. All the members, Insurance Company too, receive the events of this cancellation or delay, and take the actions for giving the passenger the best customer experience: book a hotel room paid instantly the compensation, notify the booked hotel your late arrival, change UBER reservation, etc.
- Auditing transparently airport operations.
- Government customs and passenger movements, under legal terms, of course.
- Data protection rules for passengers.
- Unique digital ID for passengers, easy customs, easy check-in, etc.
Why I chose Hyperledger Fabric vs Ethereum?
Ethereum exposes total transparency for its transactions, everyone that participates in the Blockchain can see everything. In this Proof-Of-Concept case, you saw it is needed some data/transactions privacy among parties. In Hyperledger Fabric you can set the visibility rights among parties. Ethereum, public or private, shows all the transactions to everyone participating in the Blockchain, but Hyperledger Fabric can handle permission rights, through channels to establish the visibility.
And less important, for my POC, I don’t need currency for the payments (nevertheless the case has payments), Ethereum has ether built-in and Hyperledger has any currency in its foundation, but you can develop one in it. Because its permissionless philosophy, Ethereum needs more processing power, due to its consensus algorithm, nevertheless I need a permissioned blockchain so fortunately, I saved a lot of my laptop CPU.
Hyperledger Fabric on Docker running in a Synology NAS.
As I mentioned before, Hyperledger Fabric on Docker no needs too many resources. In the article, I use Docker in my laptop, but I also ran this on my Synology NAS, it’s pretty simple, let’s me show you just how to do it and see how much resources are needed.
First, install Docker package in the NAS through Package Center
You can download and manage the containers through the Docker App, but in this case, you can open a SSH to the NAS and execute the Docker’s commands for downloading and running the container.
And that’s all, you can access to Composer at the NAS local IP, and play!
As mentioned before, the computing and disk resources are pretty small.
Final disclaimer: There are a lot of technical concepts and architecture topics involved in the Blockchain domain, explaining them and justifying them in this Proof-of-Concept would need at least two or three more articles for covering them. If you are interested in knowing more, I suggest you read the great publications by Hyperledger https://www.hyperledger.org/resources/publications and Ethereum http://www.ethdocs.org/en/latest/
MORE INFO AND CONTACT
- Personal page in LinkedIn
- Twitter. @aeriaablog
- Facebook. aeriaA in Facebook
- LinkedIn. aeriaA page in LinkedIn