Bringing Schiphol’s Flight Status API to Ethereum Apps with ChainLink
Over the last couple of weeks Chainlink has been generating a lot of buzz, most recently due to partnerships with Google Cloud Platform and Oracle. All of this news sparked my curiosity so I decided do what any self-respecting geek does when learning of a cool new technology — kick the tyres and BUIDL something on it.
Before diving in, some background: in blockchain terminology an oracle is a middleware component which can make off-chain data available to applications running on the blockchain (known as smart contracts). This is not be confused with the company Oracle, although somewhat confusingly Oracle (the company) is building oracles (the middleware) using Chainlink.
In the traditional programming world a wealth of data is only an API call away. In the blockchain world things are a little different. Why is this?
The TL;DR version is that smart contracts are executed on multiple nodes so they must be deterministic — that is, given some code and some inputs, any node executing the code will come up with exactly the same result. If smart contracts could call web APIs they would lose this determinism, as two nodes executing the same code could get different results (indeed, they would definitely get different results once you take into account uncontrollable variables like headers, response times, and so on).
A more detailed overview of oracles, ChainLink, and “the oracle problem” can be found in Blockonomi’s Oracles Guide.
To work around this the concept of external oracles was developed. Instead of the smart contract contacting the API directly, the smart contract asks the oracle to fetch some data, and then waits for the oracle to respond. The oracle is responsible for gathering data and writing the data to the smart contract by executing an Ethereum transaction.
Making off-chain data available to smart contracts is a very vague statement — let’s look at a more concrete example.
Fizzy is a blockchain app created by the insurance company AXA which allows Ethereum users to purchase flight insurance directly from a smart contract. In the event of a delayed or cancelled flight there is no need to make a claim — the payout will be immediately sent to the wallet that purchased the insurance. If you have ever gone through the rigmarole of claiming for a cancelled flight from an evasive airline trying to delay or wriggle out of paying a valid claim you will appreciate how revolutionary this is.
The benefits of on-chain insurance for both the insurer and the insured are immediately clear. For the customer there is no need to jump through the usual set of hoops involved in claiming in flight insurance.
For the insurer the costs of providing the insurance are reduced as there is no need to pay customer service teams to review and manage incoming claims. These reduced margins mean the product can be offered at a lower price, leading to increased competition and efficiency in the insurance market.
But where does the data come from? In this case AXA runs a private oracle which is responsible for sending flight statuses to the smart contract. The contract’s setFlightLandedAndArrivalTime method receives the flightId and actualArrivalTime as input from the oracle and checks to see if anyone has purchased insurance on the given flight. If so, and if the flight is delayed or cancelled, any open policies are automatically paid.
Offering insurance via a smart contract is a great step forwards. There is no need to blindly trust that the contract will pay out — I can read the code myself and confirm that, if the oracle reports my flight has been cancelled, the smart contract will pay out my claim (while some might argue that Solidity is not the most readable programming language I would counter that reading 50 lines of Solidity is vastly preferable to reading 50 pages of legal boilerplate which strips away more of my consumer rights with each increasingly-verbose paragraph).
However, I am still ultimately trusting AXA to pay out as their smart contract will only accept flight status data from their oracle. AXA could terminate the oracle (locking my funds in the contract) or even provide false data to avoid paying out claims.
If AXA wanted to falsify the oracle data they could only do so in a very public fashion, by writing incorrect information to the blockchain. I personally feel that the damage AXA’s reputation would suffer as a result would prevent them from doing this under most circumstances, but the possibility for nefarious action on their part remains.
The idea of the ChainLink network is that a decentralised network of oracles can retrieve data from a variety of sources. Instead of relying on a single source of truth (AXA), what if we could use ChainLink to request the flight status from a neutral third-party?
For this use case I believe airports could reasonably be considered neutral. They have no skin in the game when it comes to insurance contracts so can be relied upon to accurately report the status of a flight to the best of their knowledge. And who knows better than an airport whether a plane has arrived or not?
I decided to use this as a test bed for playing around with ChainLink, and create an oracle which allows a smart contract to consume data from an airport’s public API.
First I needed to get a ChainLink node up and running according to the process described here. Next I followed the Fulfulling Requests tutorial and set up the ChainLink version of hello, world — retrieving the current Ethereum price and writing it to a smart contract. Thanks to the excellent documentation these steps were all plain sailing.
With the node up and running I started to look at how ChainLink can access external data and soon found myself on the External Adaptors page. An External Adaptor is essentially a web service acting as a bridge between a ChainLink node and an external API. While ChainLink itself is written in Go, communication between the node and the adaptor is carried out through a REST API so adaptors can be written in any language.
Next I needed to find a data source. Schiphol Airport provides an API which offers “a wealth of information on current and scheduled flights to and from the airport, carried out by more than 90 different airlines”. This includes an endpoint for retrieving the status of a specific flight. Bingo!
The External Adaptor turned out to be simplicity itself. My adaptor receives some POSTed JSON data which includes a flightId parameter. I just needed to pass this flight ID to Schiphol’s API and parse the returned data to figure out whether or not the flight had been cancelled. Finally a response is returned to the ChainLink node so the data can be handed to the next stage of the job.
As you can see it really is a demonstration implementation with no error checking and a very simplistic algorithm:
- If the flight has arrived the flight status is 1
- If the flight was cancelled the status is 2.
- For all other states the status is 0.
To use an External Adaptor it must be referenced in a ChainLink job spec. The process of setting this up is described here. I ended up with a job spec which executes the following tasks:
- use the Schiphol External Adaptor to get the flight status
- extract the “flight status” from the data returned by the adapter
- convert this value into Ethereum’s integer type
- create an Ethereum transaction which writes the result to a smart contract
Writing this up in ChainLink’s job spec format resulted in the following JSON:
At this point I took off my node operator hat and put on my smart contract developer hat so I could write a function to execute my new job using my previously-deployed oracle. For the sake of simplicity I modified the sample consumer contract and added the following functions:
The first function creates a request to the oracle, asking for the flight status of the given _flightId. Note the req.add call on line 6 — this adds the _flightId parameter to the oracle request, where it is ultimately sent to my External Adaptor. The second function is called once the node has retrieved the flight status and is used to store the status in a contract variable.
With all the pieces in place I could finally test it out. I visited my consumer contract’s page on Etherscan and verified the contract code, which allowed me to execute contract functions from Etherscan’s web interface.
After filling in the oracle address, job ID, and flight ID I submitted the transaction. The terminal window where the node was running showed a flurry of activity as the node received the new job, executed each task in turn, and finally wrote the result back to the smart contract. Checking the node’s web UI showed the status of each of the job’s tasks, along with the resulting data from each step.
The flight ID I used for my test referred to a cancelled flight so when I returned to Etherscan I could see the updated flightStatus variable:
The flight status is now correctly represented in the smart contract.
Now, I have no interest in building a decentralised insurance platform myself so I will not be building on this example any further. However I am fascinated by the potential here: using these components it would be possible for someone to build a truly decentralised peer to peer insurance platform where anyone can buy or sell insurance without trusting anything but the airport APIs.
The need to trust the airports could be further reduced by adding additional airport APIs to the oracle and requiring double confirmation of cancelled flights. For example if a flight from New York to Amsterdam is cancelled, claims will only be paid out if JFK’s API reports a cancelled departure and Schiphol’s API reports a cancelled arrival.
Once the data is available to smart contracts, and a marketplace for offering and buying insurance exists, it would be possible to build an entirely algorithmic insurance company. An enterprising solo developer could train a machine learning model (with historical cancellation data, live weather updates, et cetera) and run a profitable insurance business from their laptop. Of course they would be competing with other AI insurance companies, and over a long enough time period the most efficient business would capture the majority of market — may the most well-trained model win. Perhaps this upcoming revolution in the insurance industry, a long-time favourite of Berkshire Hathaway, will be enough to convince Warren Buffet to take a proper look at blockchain technology (if his upcoming lunch doesn’t put him off the space for life).
As mentioned above Oracle (the company) is using ChainLink to help startups monetise their data and APIs. I can see this being popular with both startups and established companies alike; API monetisation still seems to be an issue for many companies so the ability to introduce a new revenue stream will be compelling for many CFOs. This is particularly true in the case of companies like Schiphol where the API is required to power things like the Arrivals/Departures boards — any revenue produced by selling access to the data can help offset the cost of offering the API, or perhaps even turn the API from a cost center into a profit center.
As Ethereum adoption continues to gain steam amongst businesses large and small I expect we will see more companies opting to add blockchain oracles to their data offerings, and eventually running a ChainLink node will be as commonplace as offering a REST API.
Published at Sat, 29 Jun 2019 13:27:15 +0000
