Chainlink: An Encyclopedic Study | Xord
1 Introduction
In today’s world, Blockchain is enabling decentralization in the world. But, on analyzing the applications of Blockchain technology you’ll see that most of the time cryptocurrencies or decentralized finance applications are involved. Now, wherever cryptocurrencies go, their prices have to follow. And so an extensive number of decentralized applications need real-world data. This real-world data comes from resources that reside outside of the Blockchain. So, oracles were very much needed.
Chainlink is a fully decentralized oracle network that enables access to real-world data to smart contracts in Blockchain.
Also, read about Flash Ecosystem.
2 Chainlink’s Architecture
This section focuses on Chainlink’s architecture. When transactions in Blockchain(on-chain) take place, the transaction requester has to pay a fee. The more the transactions, the greater will be the over cost. Off-chain transactions don’t have a transaction fee as they are not part of Blockchain.
2.1 Onchain architecture
2.1.1 User Contract
Users who want to request queries for data, create a UserContract to do so.
This UserContract then interacts with the ChainlinkClient contract.
2.1.2 Chainlink Contracts
The requests made via UserContract are sent to the ChainlinkClient contract. UserContract inherits this contract to create requests to the Chainlink network. The ChainlinkClient contract implements the ChainlinkRequestInterface. With every variable being private and every function being internal, users cannot make changes in the ChainlinkClient contract.
The Chainlink contracts are designed in a modular way. And so users may configure and change the contracts as needed.
Chainlink has three components; DeviationFlaggingValidator, PreCoordinator, and aggregator contracts.
The Reputation / DeviationFlaggingValidator is for tracking the performance of oracle, the order-matching / PreCoordinator matches user’s requests with oracles, and lastly, the aggregator aggregates the responses of oracles.
* DeviationFlaggingValidator Contract
This contract, also known as the reputation contract, keeps track of the oracle’s performance metric. This contract checks the current value against the previous value and makes sure that it does not deviate outside of some relative range. If the deviation threshold is passed then the validator raises a flag on the designated flag contract.
The validate function verifies that the current answers submitted by oracles don’t deviate 100% from the previous value.
Chainlink uses the CheckedMath library which is adapted from Openzepplin’s SignedSafeMath library. This library reverts the transaction in case of overflow.
On every flagging of an oracle, an event is emitted. However, only owner and owner-approved addresses can flag an oracle. Also, only the owner can remove the flag of any flagged oracle. When the oracles are flagged the raiseFlag function is called which checks whether the address is allowed to raise the flag. This function then calls the private function of tryToRaiseFlags.
The tryToRaiseFlag function flags the oracle named as the subject.
The reputation of every oracle on Chainlink can be viewed at Chainlink Block Explorer.
Chainlink security services also make use of oracles reputation, see section 4
* PreCoordinator Contract
contract also referred to as order-matching contract essentially deals with the order-matching mechanism in Chainlink. This contract creates on-chain service level agreements.
Users submit their SLA to this contract with oracleRequest function.
Then work-flows as:
- User calls createServiceAgreement function.
- createServiceAgreement function returns saId or service agreement id.
- Then the user creates oracleRequest which calls the private function createRequest function. The createRequest function creates requests to each oracle in the service level agreement with the requester’s data payload as arguments.
- The oracle contract in the request function receives the callback function selector, ‘chainlinkCallback.selector’.
- When oracle executes the request it finally calls the callback and submits the response to order matching contract.
The CreateRequest function in turn calls the sendChainlinkRequestTo function which is part of the ChainlinkClient contract.
This function creates a Chainlink request to a specified oracle address and returns the requester’s ID.
* Aggregating Contract
Aggregating contracts collect the results and finds an aggregate of all the responses from all the oracles. The aggregated result is also stored on-chain so the users can obtain the latest price feed.
By implementing the AggregtorV3Interface, the periodic price updates can be accessed.
ChainLink provides its own contracts which can be used (as they are or modified). However, in v0.6 the contract functions are deprecated and as of writing, this publication v0.7 is under development.
Also read about Uniswap v2 Protocol.
2.1.3 On-chain Workflow
Now that we have an overview of all involved contracts, grasping the workflow would be less complicated.
The on-chain architecture workflow has three steps which are as follows
* Oracle Selection
An oracle service purchaser specifies the requirements that make up the service level agreement and submits it to the order-matching contract along with the reputation and aggregating contract to use for the rest of the agreement. The SLA proposals contain query parameters and the number of oracles needed by the purchaser.
However, in the above createServiceAgreementfunction the number of oracles i.e. _oracles parameter, cannot exceed the limit of 45 oracles.
The globalNounce contributes to creating a unique service agreement ID. In case the globalNounce overflows, its value will start all over again. Oracles then commit to the proposal by attaching the penalty amount to be paid in case of misbehavior. Furthermore, the contract only accepts requests from those oracles who fit the service level agreement requirements. Bids are accepted by the contract till the bid window is open. The requested number of oracles is filtered out from this pool of bids. The oracles which aren’t selected get the possible penalty fee that they paid at the time of bidding is refunded.
The selected oracles then carry out the assignment as per the service level agreement.
* Data Reporting
The off-chain oracles execute the assignment and report back the result on-chain. All the oracle’s responses are saved in the response array against the requester’s ID. The median of all responses is calculated to cater to the doubt of faulty responses.
See section 2.2 for details of off-chain architecture.
* Result Aggregation
The result of oracles is then fed to an aggregator contract which then calculated a weighted answer.
Then, all the oracles responses are checked for validity and their reputation is updated accordingly.
Finally, the weighted answer is sent to UserContract.
Chainlink has a standard set of aggregating contracts, but customized contracts can also be specified, provided they conform to the standard calculation interface.
2.2 Off-chain Architecture
The oracle nodes on Chainlink gather responses to off-chain requests. These responses are sent to Chainlink contracts.
How these responses are sent to Chainlink contracts is discussed in section 2.3.
2.2.1 Core Node:
The core node is responsible for interfacing with the Blockchain. It is also responsible for scheduling and balancing work across various services.
Assignments i.e. the work done by the Chainlink node consists of subtasks. Assignments are the core of the system, they are composed of one or more sequential subtasks, a schedule, a fee specification, and an optional name and description. Subtasks are the smaller job specification of the assignment, as they are work specifications for distinct job types.
Once an oracle receives an assignment, they sign the hash of the assignments. Upon receiving affirmative confirmation the user pays the oracle.
Assignments can essentially be triggered in two ways.
* Scheduled Updates
Scheduled updates are set when assignments are created. As each assignment has a set deadline, the number of updates can be determined upfront, and the cost of all scheduled updates is paid with the creation of the assignment. Additionally, any upfront costs of the assignment can be covered at the time the assignment is created.
* On-Demand Updates
The word on-demand is quite self-explanatory but if payment is required it must be paid with the request, not upfront. Any adapter may trigger an update on the entire assignment. However, the update triggers at the start of the earliest subtask and follows the full progression through all subtasks. To accommodate this, adapters often need to be stateful i.e. they store the data that triggered their snapshot and use it when they are next in the pipeline.
Also, oracles may choose to charge a service availability fee similar to an SLA. The baseline of this agreement is that the requester deposits the total fee amount into a contract where the oracle retrieves it in a prorated fashion. If the oracle fails to respond to requests, the requester gets the deposit back.
Chainlink’s software node comes with built-in subtasks which include HTTP requests, JSON parsing, and conversion to various Blockchain formats.
2.2.2 External Adapters:
Adapters are services an oracle runs to expand the functionality they offer. Programs, irrespective of the programming language, can easily be implemented simply by adding an intermediate API. Oracle providers can specify their offered services and requirements by following the adaptor specification and protocol.
Several external adaptors are available on https://chainlinkadapters.com. The node operators can easily access and use these tools and services.
2.2.3 Subtask Schemas:
The oracles specify the adapter’s subtask requirements using the adapter schema.
Want to build and use external adaptors?
2.3 Off-Chain Reporting
Chainlink initially used the flux aggregator model. While this method is quite straight-forward, it comes with increased cost. As every single node is submitting the response on-chain, they all have to pay the gas fee. Off-chain reporting enables nodes to aggregate their observation in a single report. This is done using a secure P2P network. Then a quorum of nodes sign the aggregated reports and then a single node submits the report on-chain.
All nodes watch the final on-chain result on Blockchain for any single point of failure. In case the submitter node fails to get transmission confirmation with-in the specified time, a round-robin algorithm comes into action. In this scenario, other nodes also submit their final result report until one of them is confirmed.
3 Chainlink’s Decentralization Approach
Chainlink comprises three ways to decentralize the network.
3.1 Distributing Sources
To ensure that the result of a query is obtained from multiple resources is valid, distributed sources are used. When oracles work on an assignment, they may retrieve data from multiple sources and aggregate them. However, one data provider may obtain and release information obtained by another data provider. Faulty data may get forwarded by multiple data providers.
The high degree of tamper-resistance and reliability is ensured by Chainlink as it exclusively pulls data from premium data aggregators. Volume-adjusted aggregated price point from all centralized and decentralized exchanges represented by each data source. This makes it inherently resistant to numerous attack vectors like flash loans or abnormal deviations.
To avoid unsolicited correlations, Chainlink pursues research on mapping and reporting the independence of data sources.
3.2 Distributing Oracles
Just as the sources can be distributed, the same can happen for oracle nodes. These distributed oracles may get data from multiple sources. Some of these sources may overlap but will return a single answer.
3.2.1 In-Chain Aggregation
The first solution provided for the aggregation to get that single answer is in-chain aggregation. The aggregated answer of each node goes through a contract and then a refined answer is returned. However, the problem of freeloading persists.
To deal with freeloading a commit / reveal scheme is used.
Commit / Reveal Scheme
In this approach, oracles commit their cryptographic responses to Chainlink thus hiding their responses from other nodes. After enough responses are submitted, the nodes reveal their answer.
3.2.2 Off-Chain Aggregation
This solution deals with the problem of the transaction cost. As more and more oracles are used the transaction costs increase. The off-chain aggregation approach allows Chainlink to send a single aggregated answer to the smart contracts. The consensus is accomplished by allowing each oracle to generate a partial signature of its answer which together would create a verifiable signed answer from the collection of answers provided by all participating oracles. For this, Schnorr signatures are implemented. This enables the receiver to verify the sender.
To prevent freeloading in off-chain aggregation, it is required that each oracle obtain their data from the data provider instead of from one another.
A PROVIDER waits until enough nodes have committed their answers and de-commitment messages are received. Then, it sends the reward to oracles included in the accepted de-commitment set. Hence, incentivizing them for being honest.
4 Chainlink Security Services
Chainlink security services subsume of four key services.
4.1 Validation System
The on-chain behavior of oracle nodes is monitored by the Chainlink network for availability and correctness. Thus, a performance metric is formed. This performance metric is available on-chain that will help users in the selection of oracles.
4.2 Reputation System
The reputation system will publicly reference the on-chain history maintained by it. The factors on which individual nodes are rated other than availability and correctness are:
the node’s total number of assigned, completed, accepted requests, the average time to respond, and the number of penalty payments.
The overall purpose of the reputation system is to provide incentives for nodes to produce honest data in a timely manner.
4.3 Certification Service
The certification system deals with Sybil and mirror attacks. The long-term solution is to use trusted hardware. However, certification service design’s short-medium solution issues endorsements of high-quality oracle providers. These endorsements are based on the stats in the validation system and would perform post-hoc spot-checking of data with reputable sources. In case oracles submit false responses, the answers will be visible in post-hoc review.
4.4 Contract Upgrade Service
The use of contract upgrade service is optional. When vulnerabilities are discovered, users can choose to use this service.
Contract upgrade service will essentially make a new smart contract based on the existing one and migrate all of its assignments to the upgraded contract. The use of a flag MIGFLAG would act as an indicator to use the new upgraded contract and not the existing one. If the flag is missing, automatic forward i.e. FALSE default value, would be used by the contract. The changes made by the contract upgrade service will be available on-chain.
4.5 LINK Tokens
LINK tokes are the native tokens of the Chainlink network used to pay for services of the network. These services include retrieving off-chain data, formatting data into Blockchain readable data, off-chain computation, and but not limited to uptime guarantee as operators.
LINK token is an ERC667 token that inherits from the ERC20 standard. This allows token transfers to contain a payload.
Glossary
- Freeloading: Freeloading is when an oracle instead of working to get the answer to a query, takes and submits the answer of another honest oracle.
- Availability: It is the ability of an oracle to respond to queries in a timely way.
- Correctness: It is the ability of oracles to provide correct responses and not erroneous ones.
- Sybil Attacks: Sybil attack refers to when one entity takes over the majority of the network.
- Mirror Attacks: Mirror attacks cause oracles to send individual responses based on data obtained from a single data-source query.
- Flux Aggregator Model: In this model, every oracle node must submit its price value individually. Once all responses are received on-chain, the contract aggregates them and confirms the price.
- Post-hoc: Analyses that were specified after the data were seen.
References:
Learn about Categories Of Decentralized Finance.
Originally published at https://xord.com on March 15, 2021.
