Whitepapers Deconstructed: Chainlink
I’ve written this article with the aim of providing a concise summary of both Chainlink whitepapers, bridging the gap between introductory articles and the intimidating original papers. While being fairly comprehensive, I’d strongly encourage anyone wanting a more detailed understanding to check out the original whitepapers and smart contract research forum.
Introduction
Chainlink is a Decentralised Oracle Network (DON), a service that allows smart contracts on a blockchain to access external, real-world data. Smart contracts on a decentralised blockchains such as Ethereum are unable to access this data because a decentralised blockchain must be an isolated, deterministic system in order to reach consensus.
The vision of Chainlinks founder Sergey Nazarov, was to redefine the blockchain industry, by allowing the creation of Hybrid Smart Contracts (HSCs). HSCs are smart contracts with a hybrid infrastructure, having transaction settlement on-chain and contract computation done off-chain. The HSC framework will maintain the security and reliability of a blockchain, while having performance benefits of off-chain computation while removing the external data limitations. This has already allowed decentralised financial products to be built (DeFi applications).
Background On Smart Contracts
A smart contract is a program that is deployed on a decentralised blockchain network such as Ethereum. It can hold and release value in the form of tokens based on the conditions programmed into it when it is created. The utility of a smart contract ground-in in the properties that come from being on a decentralised network;
Security: Existing on a distributed network, the smart contract is immutable and has no single point of failure that is vulnerable to an attack.
Reliability: Once deployed, the smart contracts automatically executes commands under the conditions programmed.
Transparency: The conditions of the agreement are transparent and cannot be altered, removing a requirement of trust between two parties.
Oracles
As mentioned, smart contracts cannot access external data, severely limiting the potential use cases. This limitation is known as The Oracle Problem. This is where a service called an oracle comes in. An oracle is an entity that delivers data from an external data source to the smart contract. The oracle does this by monitoring the blockchain for requests by a smart contract, then retrieving the data from external source(s), and formatting it before returning it to the smart contract through an on-chain transaction
However, this solution introduces a second issue. Using a single oracle to gather data from a single source nullifies the decentralised property that comes from a decentralised blockchain. There are single points of failure at the oracle and data source levels, which is the second piece of the oracle problem. An oracle must maintain the key security and reliability properties, Chainlinks solution is a Decentralised Oracle network (DON).
Chainlink
Chainlink is a Decentralised Oracle Network (DON), which is a protocol in which sub-networks of oracle nodes collectively deliver data to smart contracts (In a DON context “oracle” and “node” will be used interchangeably). Each DON is designed for its specific use case. When a smart contract makes a request for data, a collection of node operators will independently retrieve data from different sources, where the protocol aggregates data entries, and returns a single value. Chainlink service are primarily used on the dominant Ethereum network, however is designed to be compatible with smart contracts on any decentralised blockchain.
Chainlink Architecture
There are three components that make up the Chainlink network;
On-chain: The first on-chain component is USER-SC, the smart contract made by the user which broadcasts requests for data and stores the returned value. The second is CHAINLINK-SC, which is the smart contract that acts as the interface between USER-SC and the Chainlink DON. CHAINLINK-SC calls three further smart contracts; The order-matching contract contains the data and reputation requirements set by the user, and orders a network of suitable oracles to fulfill the task. The aggregating contract collects data provided from the oracles and returns the median value to USER-SC. The reputation contract updates a reputation metric to track performance of an oracles, based on data accuracy and response time. It is extremely important for the Chainlink ecosystem to have a record of oracle behaviour.
Chainlink: The off-chain component are the the individual oracles run by operators that make up Chainlink DONs. They accept suitable data requests on-chain, obtain data through an API call from their external data source(s) off-chain, then submit it on-chain through a transaction.
External: These are the external data sources that oracles gather their data from. Oracles pay for data licenses in order to access these, ensuring the original data is of high quality.
Off-Chain Reporting (OCR)
The Off-Chain Reporting (OCR) protocol was introduced in early 2021 as a way to scale Chainlink by making price feed reports cheaper by reducing on-chain transaction fees. This is done by aggregating gathered data off-chain instead of on-chain. The previous aggregation method involved each node individually sending their data on-chain, each incurring a transaction fee. The data is then aggregated into a single list where the median is taken and submitted by the smart contract on the Ethereum blockchain. The new OCR protocol differs by having the network of oracles communicate to aggregate data off-chain, where the combined list is sent on-chain in a single transaction, reducing gas fees by up to 90%.
As discussed in the oracle problem section, an off-chain aspect to the Chainlink DON introduces a vulnerable point of failure. The OCR protocol is designed to be Byzantine Fault Tolerant (BFT), meaning it can continue to function correctly with a proportion of up to 1/3 of nodes potentially becoming either faulty or malicious. There are three subprotocols in the OCR design;
Pacemaker: The pacemaker is the underlying protocol that drives the report generation process. It continuously runs and acts as a timer that initiates new epochs of the report generation protocol, with each epoch having a random node act as the leader. If insufficient progress is made in the specified timeframe, it will be aborted with a new report generation instance and leader.
Report Generation: The report generation protocol is the process of nodes in the network communicating to arrive at a signed report of data values to be sent to the blockchain. It is a BFT consensus algorithm, meaning the protocol can continue to function correctly even if up to 1/3 of nodes are faulty or act maliciously. These nodes are known as Byzantine Nodes.
The process starts with the leader node making a request for follower nodes to gather data, and compiles responses into a report. There are several rounds that progress when the protocol gathers sufficient signed observations from nodes, ultimately guaranteeing at least one honest node confirms to the validity of the final report (assuming <1/3 are byzantine nodes).
Transmission: The transmission protocol is the algorithm responsible for transmitting the final report from the oracle to the smart contract on the Ethereum blockchain. To avoid excessive transactions, the reports are only submitted if a specified amount of time has passed, or if the price value has changed beyond a threshold since the last report. The selection of oracle(s) to submit on-chain is randomly chosen from the network of nodes.
Chainlink Services
In addition to data feeds, Chainlink also provides a number of additional services for smart contract applications;
Verifiable Randomness Function (VRF): Decentralised applications (DApps) that utilise smart contracts may require a source of randomness to ensure fair operation. Chainlink VRF service generates a random number which can be verified by users through a corresponding cryptographic proof, allowing for transparent randomness. Use cases include blockchain games such as lotteries and NFTs generation.
Keepers: A limitation of smart contracts is that functions can only be triggered when on-chain conditions are met, requiring an external call to trigger at an arbitrary time or condition. Chainlink keepers provides a decentralised, high-uptime, low-cost option for contract authors to outsource smart contract upkeep, instead of creating their own off-chain infrastructure to do so. Use cases include executing limit orders from a decentralised exchange and liquidating undercollateralized loans. A practical example could be; “If account balance is below $50 USD in ETH, then top it up with ETH from this other account.”
Fair Sequencing Services (FSS): In permissionless blockchains miners have control over which transactions go in a block and how they’re ordered. A miner can exploit this through Miner Extractable Value (MEV). MEV occurs when a miner creates a profit through reordering and censoring transactions, coming at the cost of the user. This comes in the form of front-running, back-running and sandwich attacks. Chainlink FSS aims to create order fairness by approximating a first-come first-serve system by decentralising transaction order, resulting in a more equitable financial system.
Security
DON Operator Corruption (Cryptoeconomics)
It is essential for to have a mechanism to enforce correct behaviour among oracle node operators, ensuring there is no opportunity for node corruption through means of bribery. This is achieved through cryptoeconomic incentives for node operators;
Staking: Staking is an explicit incentive, where node operators must deposit locked assets in the form of LINK tokens, which can be confiscated for misbehaviour. Chainlink staking is founded in game-theory and hinges on an idea called watchdog priority.
Each oracle gets the opportunity to act as a watchdog and raise an alert if they believe an aggregate report to be incorrect. When an alert occurs the reporting decision is escalated to a second maximally-reliable oracle network, consisting of nodes with only the highest reputation scores. Escalation should be a rare event and therefore the second-tier network can be highly compensated. A correct alert will result in the highest priority watchdog receiving the sum of staked LINK of corrupt nodes that delivered false data, however will forfeit their own stake if it was proven to be a faulty alert. This results in a super-linear staking effect:
Future Fee Opportunity (FFO): FFO is an implicit incentive. Misbehaviour by an oracle node also jeopardises the future share of fees earned by providing their services, penalising the node with an opportunity cost in terms of potential lost revenue from network participation.
Systemic Failures
The second security risk in the Chainlink ecosystem is systemic failure that occurs from vulnerabilities in the protocol software. This can affect the liveness (availability) or the safety (integrity) of the network.
External Data Source Trust Minimisation:
Even among high-quality (subscription model) data sources, few digitally sign the data they provide. Chainlink aims to accelerate the use of digital signatures by creating a capability for Chainlink nodes to function as an authenticated API front end for external data sources. This capability is referred to as Authenticated Data Origination (ADO), and will help strengthen the end-to-end integrity of oracle reports.
DON Trust Minimisation
Software monoculture occurs when all systems run identical software (such as Chainlink nodes), meaning a vulnerability subjects the network to a catastrophic failure in the event of a successful attack. Chainlink has two main contingency options if such an event were to occur:
Failover clients: Failover clients acts as a second line of defence as a form of software diversification. Nodes are able to switch to a secondary client in the face of an emergency, reducing the dependence on the primary client. For example, nodes running OCR as the primary client also support the previous FluxMonitor client, which has had field testing over a longer period of time.
Minority reports: In the event that honest nodes make up a minority of the network, a minority report is an option to flag the smart contract on-chain. The smart contract has its own polices as to how it responds to these, such as a circuit breaker.
Guard Rails
Guard rails are on-chain failsafe mechanisms that protect the smart contract against failures in the off-chain components of Chainlink. Smart contract owners specify the conditions under which they trigger. For example, a Circuit Breaker can pause updates to the smart contract. In an emergency an Escape Hatch can temporarily shut down the smart contract in some manner and/or temporarily terminate pending transactions.
Chainlink Events
Chainlink is playing a vital role in the rapid growth of the broader blockchain ecosystem, having already partnered with 650 blockchain projects. Coming up on August 5–7, the Smart Contract Summit #1 will have keynotes, panels, workshops and AMAs from the Chainlink team and their partnered projects, and will be a great opportunity to delve deeper into all things Chainlink.
Finally, a quick shout out to Patrick Collins for having awesome content, definitely helped me during my research, check him out:
