Disclosure: Smith + Crown was a compensated advisor to this project.
Many compelling uses of blockchain technology require smart contracts to trigger based on external events — ie, if silver reaches $60/oz on Jan 1st 2032, sell forty ounces on COMEX. However, current blockchain architecture makes this difficult to enforce, because smart contracts cannot reliably reference off-chain data sources. Such data sources may present conflicting information to whoever queries them or be used to manipulate smart contracts. In order to reduce reliance on centralized oracle services that represent a single point of failure, projects such as Chainlink aim to build a decentralized oracle network, designed to allow smart contracts to rely on off-chain data in a trustless manner. Chainlink’s success would mean projects across the industry could more fully utilize smart contracts in what were hitherto hypothetical use cases. At a high level, Chainlink acts as an oracle middleware protocol between smart contracts and external data sources (typically APIs).
Other blockchain-based projects have also attempted to address this so-called ‘Oracle Problem’. Augur, for example, is a prediction market that leverages a nuanced incentive system to induce manual human reporting of real-world events. Chainlink argues that this process, while accurate and decentralized, is too slow and does not scale to the streaming of real-time data that Chainlink envisions as a primary use case. Another related project is Provable, which Chainlink claims relies on a central point of control to notarize queries.
Founded by Sergey Nazarov (CEO) and Steve Ellis (CTO), Chainlink raised $32 million through an ICO and private sale of LINK, the project’s token, in September of 2017. The project has since made several notable partnerships, such as with Google, Oracle, Swift, IC3, and Gartner. The Chainlink mainnet went live on Ethereum as of May 2019.
Chainlink is a decentralized oracle network, whose oracle middleware allows smart contracts on smart contract platforms, like Ethereum, to interoperate with off-chain data providers, APIs, payment gateways, and external chains, enabling on-chain smart contracts to evaluate contract variables using off-chain data.
In a (simplified) use-case, a smart contract would broadcast a ‘request contract’ on-chain, monitored by a blockchain (ie, Ethereum) node. Each request contract has a service level agreement (SLA), which defines the parameters for the data request, such as which external data feeds to use (ie, Nomics), how many Chainlink nodes should make the request, and any uptime guarantees for streaming data. Chainlink nodes monitor the blockchain for these requests and bid on them. Once matched with a request, Chainlink nodes query/return the external data using an External Adapter, which is an external API-specific software module that allows a Chainlink node to interact with it; this data is then aggregated through the Aggregating Contract (see below) to a single value, and reported back to the smart contract that originally requested it. The Chainlink nodes are then compensated in LINK for their work.
A smart contract that requests data from the Chainlink network can select particular oracles (that is, Chainlink nodes) to perform this work. The Chainlink core team operates one marketplace for matching requests and groups of Chainlink nodes, but requestors are free to solicit data requests from third-party marketplaces. For a query response to be considered valid, it only needs to meet the standards of the defined SLA and be accepted by the requesting smart contract; it does not need to be validated by every Chainlink node. The Chainlink network is not forming a global consensus about every API response.
In summary, the Chainlink protocol defines the following contract types, which work in tandem to validate data requests from oracles:
- Reputation Contract - monitors Chainlink nodes, recording the ‘reputation’ of each according to how effectively they follow the SLAs of data oracle requests that they accept from smart contracts. Chainlink nodes who report data that deviates significantly from the final aggregated value lose reputation, and may not be selected for future requests.
- Order Matching Contract - logs an SLA for a data request from a smart contract, collects bids from Chainlink oracle nodes, matches bid with request
- Aggregating Contract - collects the returned data from all oracles who have accepted the data request, aggregates all values into a single ‘source of truth’. The manner in which the data is aggregated (average, median, etc.) is defined by the SLA. This final value is recorded in the requesting smart contract (ie, on Ethereum).
Per the Reputation Contract, nodes are held accountable through a combination of reputation system (based on metrics like uptime, response time, and successful jobs completed), node required LINK staking, and an optional Chainlink node approval process. The Chainlink team can also conduct an optional technology audit and identity verification process, in order to prevent one user from serving as multiple oracle nodes. This overview by Google Cloud provides a helpful summary of the Chainlink query workflow.
Oracle contracts can also use multiple Chainlink nodes, allowing smart contracts to execute only if a majority of nodes return the same value, or from like logics (average, median, etc) decided by the smart contract designer. Additionally, nodes can be run in Trusted Execution Environments (TEE), such as the TownCrier Oracle. TEE can handle private information, such as passwords, private keys and closed source APIs, without revealing such information to the node operator.
Since smart contracts requesting data define their own aggregating function and sources, they have the primary responsibility to ensure their request/SLA returns accurate data. Thus, Chainlink nodes are not principally interested in returning real-world-accurate data, they are incentivized to return data from the specified providers that is not flagged through the Reputation Contract as erroneous. Of course, the fact that such data is deviated does not imply that the Chainlink node has acted maliciously; it could be that the underlying API that it requested from has simply returned bad data.
Ultimately, Chainlink effectively operates as a multisig oracle service, broadly similar to the MakerDAO price feeds, but with a native payment and staking token.
Chainlink’s token, LINK, is an ERC-677 token (a modification of the ERC-20 standard that simplifies token contract calls) used primarily by dApp users to pay Chainlink node operators for providing oracle services as described above. Node operators can be required to stake LINK as collateral to process certain requests. Such deposited Link is forfeited should the node be offline at time of request or submit outlier data (as determined by the Aggregating Contract). Such deposits are optional, however, determined by requesters, so operators can currently participate as nodes without holding tokens: the extent to which LINK is required for the right to work as a node depends on how willing requesters are to utilize depositless nodes.
Chainlink currently simplifies fees to one request per one LINK; at time of writing, details on the live network’s fee structures are forthcoming.