ChainLink-A Decentralized Blockchain Oracle network-Part 2

ChainLink-A Decentralized Blockchain Oracle network-Part 2

By Ruma | Blockchains Projects | 22 Jul 2020


Chainlink is currently one of the most famous blockchain oracle projects which aims to support blockchain networks i.e smart contracts to accept/transmit external data through the use of APIs. It operates as a fully decentralized network.

The framework connects smart contracts to off-chain inputs which then feeds and triggers the smart contract and will produce off-chain outputs like payments, transfer of data, etc.

Chainlink can be used to connect to data providers, web APIs, enterprise systems, cloud service providers, IoT devices, payment systems, other blockchains, and much more.

In this article, we will discuss the underlying architecture of Chainlink and its various components supporting it to achieve decentralization.

Architectural Overview

The Chainlink project is built on the Ethereum platform. The main objective of the project is to act as a bridge between the on-chain and off-chain data systems. Apart from supporting decentralization the project also supports modularity i.e different system components can be separated and recombined to embed any latest techniques.

A Chainlink network is made up of a collection of Chainlink nodes that handle jobs, tasks, scheduling, and consists of several core adapters that supports data flow from an external system to the blockchain. Chainlink nodes who carry out job execution coordinated by the on-chain Oracle contracts use LINK tokens as an incentive for the Chainlink node operators.

4c5b1ef42a8f541fc50d84a8e67326b4802c3905f18296d6b74001a624b85b52.png

                                    Source- Google cloud

On-Chain Architecture

In an oracle service, A User contract is referred to as requesting contracts (denoted by USER-SC) and Chainlink on-chain interface to requesting contract is termed as CHAINLINK-SC

ChainLink on-chain component consists of three main contracts:

  • Reputation contract-Keeps track of oracle-service-provider performance metrics.
  1. An oracle services purchaser specifies requirements like query parameters, the number of oracles needed, the reputation, and aggregating contracts to make up a service level agreement (SLA) proposal.
  2. The on-chain reputation along with logs of past contracts helps the purchasers to manually sort, filter, and select oracles.
  3. Rather than contacting the oracles directly, the SLA is submitted to an order-matching contract when the purchaser is done with their SLA proposal.

 

  • Order-matching contract- This contract takes a proposed SLA, logs the SLA parameters, and collects bids from oracle providers. The reputation contract helps in finalizing the oracle out of the bid pool.
  1. A log gets triggered when a proposal is submitted to the order-matching contract. The proposal can be monitored and filtered by oracle providers depending upon their capabilities and service offerings.
  2. The contract accepts bids from nodes that satisfy the SLA’s requirements. To bid on a contract, the oracle service provider attach the penalty amount and then commits it.
  3. Requested number of oracles is selected from the qualified bids pool. Penalty payments that were received during the bidding process are returned to oracles who were not selected.
  4. The final SLA record is created by triggering a log notifying the selected oracles. The oracles then perform the assignment mentioned in the SLA.
  5. Once the new oracle record has been created, the off-chain oracles execute the agreement and report back on-chain.

 

  • Aggregating contract- This contract collects responses from the oracle providers and calculates the final unified result of the ChainLink query. The response validity of each oracle is reported and maintained in the reputation contract. It also feeds oracle provider metrics back into the specified contract function in USER-SC.

ChainLink workflow:

7fc05b3bcc6a1d60dc7d704a23c7c83d0c06659a81634bac5070671c9d7b01b8.png

  • USER-SC makes an on-chain request
  • CHAINLINK-SC logs an event for the oracles
  • ChainLink core picks up the event and routes the assignment to an adapter
  • ChainLink adapter performs a request to an external API
  • ChainLink adapter processes the response and passes it back to the core
  • ChainLink core reports the data to CHAINLINK-SC
  • CHAINLINK-SC aggregates responses and passes them back as a single response to USER-SC.

Off-Chain Architecture

In off-chain architecture, different oracle nodes are connected to the Ethereum network. Individual responses are aggregated by following one of the existing consensus mechanisms into a global response that is returned to a requesting contract USER-SC

 The ChainLink nodes are powered by the standard open-source core implementation which handles standard blockchain interactions, scheduling, and connecting with common external resources. External adapters can be used to provide additional specialized off-chain services.

ChainLink Decentralization Approach

To idealize the concept of decentralization three approaches will be used.

  1. Distribution of data sources

To overcome the dependency into a single source, the system is designed to obtain data from multiple sources. The responses from the different systems are aggregate to find the outcome.

  1. Distribution of oracles

The system supports different oracle nodes with each oracle contracts has its own distinct set of data sources which may or may not overlap with other oracles.

f99175dfaa89f2c5476bf924e3dc1ebd0f5e70dcbec6ccaf4bd870051b8b5402.png

  1. Use of trusted hardware.

ChainLink Security Services

Chainlink consists of four key security services. These services might be run by one company or a group launching the ChainLink network, but are strictly operate according to ChainLink’s decentralized design.

  • Validation System- This system provides users a performance metric to select oracles. It checks for the following two things while selection:
    • Availability: Response failure to time-bound queries should be captured by the system.
    • Correctness: Incorrect responses or deviations from responses provided by peers should be captured by the system.
  • Reputation System Following are the different metrics that determine oracle performance which chainlink records and publish as user ratings.
    • Total number of assigned requests
    • Total number of completed requests
    • Total number of accepted requests
    • Average time to respond
    • Amount of penalty payments

Incentives are given to high-reputation services whereas any erroneous activity leads to penalty along with demeaned brand reputation.

  • Certification Service- The goal of the Certification Service is to prevent and/or remediate rare but catastrophic events, specifically en bloc cheating in the form of Sybil and mirroring attacks.

 

  • Contract-Upgrade Service- The Contract-Upgrade Service enables the Chainlink network to support a new set of oracle contracts. This service is optional and is in user control.

 

  • LINK token usage- The ChainLink network utilizes the LINK token to pay ChainLink Node operators. The LINK token is an ERC20 token, with the additional ERC223 “transfer and call” functionality of transfer (address, uint256, bytes), allowing tokens to be received and processed by contracts within a single transaction.

References:  Chainlink Whitepaper  

 

Read More: Understanding Blockchain Oracle- Part I

 

How do you rate this article?


7

0

Ruma
Ruma

Blockchain researcher and content writer | Voice| altcoinbuzz.io| writer.io | tulip311bit@gmail.com | Twitter: @rumadas123 | Telegram: @RumaDas


Blockchains Projects
Blockchains Projects

My reviews on various blockchain projects.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.