An introduction to Chainlink: Oracle problem and Hybrid smart contracts
Part 2: In these two posts, we are going to mainly read about the Oracle problem, hybrid smart contracts, and Chainlink.
Part 1
Chainlink
ChainLink is a blockchain project that provides an intriguing decentralized solution to authenticating the data from oracles and the subsequent output data of smart contracts. ChainLink identifies that problem with centralized oracle feeds as a single point of failure and offers a solution through a “middleware” comprised of a decentralized oracle network.
Importantly, ChainLink identifies and authenticates data prior to it becoming a trigger for a smart contract.
With ChainLink, smart contract users can use the network’s oracles to retrieve data from off-chain application program interfaces (APIs), data pools, and other resources and integrate them into the blockchain. Basically, ChainLink takes information that is external to blockchain applications and puts it on-chain.
ChainLink’s on-chain interface consists of oracle nodes that reply to data queries made by contracts. The on-chain interface is comprised of 3 components:
- Reputation Contract
- Order-Matching Contract
- Aggregating Contract
The Reputation Contract uses a proprietary method for storing and tracking oracle service provider metrics.
The Order-Matching Contract takes a service level agreement (SLA) and logs the data parameters of the SLA while simultaneously taking bids from oracle providers.
Service Level Agreement: A set of parameters and requirements for the user requested data search. These may include oracle reputation, data specifications, number of oracles/data resources needed, and so on.
The Aggregating Contract collects the oracle provider’s responses and calculates the final collective result of the initial ChainLink query.
Aggregating the oracle data provided by multiple sources helps ensure a more accurate view of the data supplied, reducing the reliance on a single entity (oracle). Oracle provider metrics are also fed back into the reputation contract for managing oracle accuracy through an incentive-driven reputation system.
The use of the SLA is vital for the oracle selection process. Users requesting oracle data can identify explicitly the parameters and inputs they are looking for as well as how many oracles they would like to use. The reputation of oracle providers can also be added to the SLA proposal.
ChainLink is effectively functioning as an off-chain listing service with an on-chain oracle authenticity/aggregation product. Oracle providers are collectively managed through a participating reputation system, and automated order-matching services facilitate the selection of oracle providers for specific data needs. Providers can also submit bids for SLA’s based on their requirements.
A pool of oracle providers is eventually selected by ChainLink who are notified of the task required. Providers (which are off-chain) subsequently report the requisite data on-chain. The resulting data is fed into the aggregating contract where a weighted answer is calculated. The weighted response is returned to the specific smart contract function as the trigger for the contract’s relative execution. Further, the provided data accuracy from the oracles is fed into the reputation contract as part of the larger reputation system.
ChainLink has a native token that is used for compensating oracle providers that supply accurate information. The architecture of the platform also consists of oof-chain components including external adapters, subtask schemas, and a core node software for interfacing with the blockchain.
Despite ChainLink functioning as a middleware, it is a decentralized oracle intermediary that functions as a tool for accurately interpreting and allocating external data to blockchains. Users ultimately have to trust that the ChainLink model works correctly, but its distributed oracle sourcing and subsequent aggregation of data are profoundly more effective methods of authenticating data than directly trusting external data feeds themselves.
How Does ChainLink Work?
ChainLink’s core objective is to bridge on-chain and off-chain ecosystems, and as such, it has two main architectural components: on-chain infrastructure and off-chain infrastructure.
On-Chain Functions
ChainLink’s first component consists of on-chain contracts deployed on Ethereum’s blockchain. These oracle contracts process the data requests of users looking to take advantage of the network’s oracle services. If a user or entity wants access to off-chain data, they submit a user contract (or requesting contract) to ChainLink’s network, and the blockchain processes these requests into their own contracts.
These contracts are responsible for matching the requesting contract up with the appropriate oracles. The contracts include a reputation contract, an order-matching contract, and an aggregating contract.
The first of these, the reputation contract, is exactly as it sounds: it checks an oracle provider’s track record to verify its integrity. In turn, the order-matching contract logs the user contract’s service level agreement on the network and collects bids from responsible oracle providers. Finally, the aggregating contract accumulates the collective data of the chosen oracles and balances them to find the most accurate result.
With these contracts, ChainLink’s on-chain functions undergo a three-step process.
1. Oracle Selection
When a requesting contract is submitted, the user specifies a set of parameters and requirements for their data search known as a service level agreement (SLA). These may include oracle reputation, data specifications, number of oracles/data resources needed, and so on. Users can then filter and manually search for oracles using ChainLink. At times when a manual search is not optimal, an automated matching engine will be available. For this option, oracles can bid based on a contract’s SLA. Contracts have the option to implement a penalty fee for misbehavior, and once a contract has received enough quality bids, these oracles are selected and the service agreement is initiated.
2. Data Reporting
This one is pretty simple. After they are chosen, off-chain oracles carry out the service agreement and transmit the requested data to the blockchain for on-chain nodes to process.
3. Result Aggregation
In order to ensure data integrity, an aggregating contract collects the data submitted by all oracles associated with a requesting contract. The aggregating contract then averages all the data to provide the requesting contract with an accurate, weighted answer. It should be noted that, under certain circumstances, not all answers can be averaged, but for simplicity’s sake, this article will not explore these possibilities.
Off-Chain Functions
ChainLink’s second component consists of off-chain oracle nodes that are connected to the Ethereum network.
Off-chain nodes are responsible for collecting the data from the off-chain resource as requested by user contracts. After retrieving the relevant data, these nodes process that data through ChainLink Core, the core node software that allows off-chain infrastructure to interact with ChainLink’s blockchain. Once the data is processed, ChainLink Core transmits it to the on-chain oracle contract for result aggregation. In compensation for this work, off-chain oracle operators are paid in LINK, ChainLink’s native token, for harvesting and sending data.
In addition to carrying out this crucial function, off-chain nodes also allow developers to integrate external adapters. While it’s not a perfect parallel, external adapters are for ChainLink what decentralized applications are to the Ethereum network. These adapters are plugins that node operators can use to accommodate a number of additional programs into their base of operations. Additionally, they can perform subtasks that streamline the data collection process.
The Standard for Secure and Reliable Oracles
In order to bring determinism to the oracle layer, A network should tick some checkboxes:
Open-source
Being an open-source technology allows the wider blockchain community to independently verify the security and reliability of Chainlink’s source code and functions, as well as contribute to its improvement.
External Adapters
Allowing nodes to securely store API keys and manage account logins enables smart contracts to retrieve data from any external system and API, including those that are password/credential protected.
Decentralization
Employing decentralization at the node and data source level ensures no one node or data source is a single point of failure, providing users strong guarantees that data will be available, delivered on time, and resistant to manipulation.
Data Signing
Having nodes cryptographically sign the data they provide to smart contracts allows users to identify which nodes sent data and look at their past history to determine their performance quality.
Service Agreements
Using binding on-chain agreements between the requesting smart contract and the oracle provider that outline the terms of the oracle service and penalties/rewards for performance provides users with enforceable guarantees on the quality of their off-chain data requests.
Reputation Systems
Feeding signed on-chain data into reputation systems allows users to make informed decisions about which nodes are good and which nodes are not based on a variety of metrics like successful jobs performed, list of clients served, average response time, etc.
Certification Services
Enabling nodes to increase their security and reliability by obtaining any number of certifications can provide users additional guarantees like KYC, geographic location of the node, security reviews of their infrastructure, and more.
Advanced Cryptography and Hardware
Providing flexibility for more advanced cryptography (like zero-knowledge proofs) and hardware (such as trusted execution environments) enables oracles to perform additional functions like proving the origin of data (e.g. specific data came from a specific server), keeping data confidential, performing off-chain computation, and more.
Distributed Sources and Distributed Oracles
Unlike its centralized counterparts, ChainLink’s program is completely decentralized. The problem with a centralized oracle is, it may give way to fraudulent data. If, for instance, a user contract relied on one oracle to provide a report on a financial audit, this oracle could tamper with this data if it had malicious intent.
To solve these security issues, ChainLink implements what it calls source and oracle distribution. If an oracle wants a trustworthy reputation, it can draw its data from multiple sources. In addition, when a user contract puts in a request with the network, that request is contracted out to multiple off-chain oracle nodes. These oracles may draw from like or different sources.
To illustrate this, let’s say that the Boomer Blockchain Stock Tracker submits a contract request for stock market data. In line with ChainLink’s oracle distribution, this request is then matched up with Oracle A, Oracle B, and Oracle C. Because of the network’s emphasis on source distribution, Oracle A draws its data from Barron’s and CNN Money, Oracle B from MSN Money and Market Watch, and Oracle C from Barron’s and Nasdaq. Thanks to this variety, Boomer Blockchain Stock Tracker isn’t receiving its data from a centralized source and is, instead, receiving a balanced aggregation of information.
