Introduction

At first I have to say that I have realized that my few previous articles have probably been a bit too long. My desire of giving a full overview on a topic, in some cases, have brought me to write papers which require between 30 and 40 minutes to be read (and more to be well digested). I have decided to take another approach. I will write consistent papers which allow to focus on self contained sub topics and as a last job I will provide a wrap up long paper which I will probably publish in my blog or on steemit.

Analyzing Chainlink is different from assessing a blockchain implementation (like I did to give an example with stellar: stellar blockchain), a task which requires to research two hours per day for at least two or three weeks and experimenting a bit before starting with the wrap up, or from assessing a token (I did it with oxt: orchid vpn and bat: BAT equilibrium price), a task simpler but still quite long. Analyzing chainlink requires to dig very deep in the rationale behind it, and to understand some implementation cases and their monetization. Once clarified the current ecosystem and the possible evolution with some scenarios the attention can be brought to the LINK token too (the token itself plays quite a special role in the case of chainlink and this add complexity to the topic). The work will be, at the end, comparable, if not bigger, to the one I did to assess stellar as blockchain implementation.

On the first part of my articles about chainlink I will focus on two main topics:

What is the motivation behind the development of chainlink

The chainlink on chain architecture: Chainlink smart contract Handling of the oracles



These topics will be developed having as references the website and the whitepaper. Every analysis should always start from these two mandatory pillars as an ICO could have never been performed without providing this fundamental information.

Why chainlink

To understand why we need chainlink let’s take a normal scenario in developing a smart contract in ethereum:

A smart contract is coded

The smart contract will be audited and it will be certified as properly written and exploits from hacker cannot be excluded.

The smart contract will be deployed on ethereum and then run in a decentralized environment.

Now let’s take a look to the smart contract. Is it just performing stateless operations which don’t require information from the off – chain world? The case is very unlikely. Normally information is needed. It is a so common case that there is a name for the code which access off chain data by calling ad hoc API: oracle.

The scenario then is the following:

We are happy to go to production with the 3 points above fullfilled. We have oracle calls.

The second part is clearly the weak point in the chain. It breaks the full idea of decentralization creating a single point of failure and it is enough to have a centralized part in the application to say with confidence that it cannot any more be considered fully decentralized.

[picture from the official website https://chain.link/]

Chainlink is the solution to the single point of failure problem.

Visually this is achieved visually the following way:

[picture from the official website https://chain.link/]

The picture below shows the data aggregation of 21 oracles made by chainlink getting rid of the single point of failure.

[picture from the website: https://eth-usd-aggregator.chain.link/]

To make it more readable I propose the picture in two (I recommend to follow the link anyway and read the site).

The calculated price showed above for ETH in USD is the result of the aggregation of the result provided by 21 oracles which, singularly, would be single points of failure. They are assigned a reputation based on given metrics and out of it, with an aggregation algorithm the result is provided. The selection of the oracles is also not random: depending on the client contract goal there is a sophisticated matching triggered.

I will explain in the next section the meaning of the pictures with greater detail.

On chain architecture

Goal: answer to a user smart contract with the most ‘suitable’ service pool.

I have prepared a picture of a chainlink smart contract which describes the onchain architecture:

Definitions:

Metric: a set of metrics are defined (predefined or custom written)

SLA: it is the Service Level Agreement that a user contract (client of chainlink can define and upgrade).

The three components of a chainlink smart contract are:

Reputation: each oracle service provider has associated a reputation which is calculated based on a given metric

Order matching: is the procedure which allows to select a pool of oracle service providers among all the available which fulfill the user smart contract SLA.

Aggregation : it is the procedure by which the responses of the N selected oracle service providers are assigned a weight and aggregated in the result returned to the user smart contract..

We can distinguish two procedures depending on how the matching happens:

Manual matching

Automatic matching (dynamic case)

Manual matching

For each oracle service provider are performed the steps to define a reputation

An oracle service providers expects some inputs and reply with some outputs: in general it is fulfilling a certain SLA

An user smart contract upload a certain SLA (the expected one) and is presented with a curated list of potential oracle service providers.

The user smart contract select the desired oracle service providers, in a number sufficient to satisfy the desired pool size.

The oracle service providers constitute the chainlink smart contract which, when triggered, by some user inputs, aggregates the response of each single oracle service provider to provide the end response.

This is the most simple procedure, but it is not always possible. Sometime a contract has a dynamic nature so that the pool of oracle service providers has to be matched automatically.It is the:

Automatic matching

For each oracle service provider are performed the steps to define a reputation

A oracle service providers expects some inputs and reply with some outputs: in general it is fullfilling a certain SLA

A user smart contract upload a certain SLA (the expected one). The contract in this case is automatic and the user smart contract CANNOT select the desired oracle service providers from a list, in a number sufficient to satisfy the desired pool size.

An automatical order matching is triggered by matching the logged SLA of each potential service providers and the SLA uploaded by the user contract

Each service providers bids (basically post its cost ) and pay a caution fee to be eligible to enter the pool

The pool is created by order matching

The oracle service providers constitute the chainlink smart contract which, when triggered, by some user inputs, aggregate the response of each single oracle service provider to provide the end response.

A common step is that the single responses of the oracle service providers are processed to identify eventual outliers and punish misbehaviour desincentivizing them. In the case of automatic matching this consist in not returning the caution fee paid to join the pool during the bid process.

Lets interpret, considering the description above the following figure (already provided)

In the figure we see all the described concepts.

The 24 external dots disposed on a circle are a set of oracle service provided that we can imagine have been selected manually by a user smart contract. The SLA actually is very simple and clear: provide the ETH USD exchange rate. Among the potential candidates using the reputation associated with each of them the user smart contract creates the pool of 24 that we see. Finally the single outputs are aggregated by the aggregation function of the chainlink smart contract in the result in the inner circle as a result of an algorithm.

It should now be clear how a chainlink smart contract operates eliminating the single point of failure and centralization factor naturally arising when on chain code wants to access off chain data.

What’s next

In the next article e will go through the off – chain component of the contract describing how chainlink deals with it. On top of it we will present the concept of oracles security