ChainLinkA Decentralized Oracle NetworkSteve Ellis, Ari Juelsy, and Sergey Nazarov4 September 2017 v1.0AbstractSmart contracts are poised to revolutionize many industries by replacingthe need for both traditional legal agreements and centrally automated digitalagreements. Bothperanceverificationandcutionrelyonmanualactionsfrom one of the contracting parties, or an automated system that programmat-ically retrieves and updates relevant changes. Unfortunately, because of theirunderlying consensus protocols, the blockchains on which smart contracts runcannot support native communication with external systems.Today, thesolutiontothisproblemistointroduceanewfunctionality, calledan oracle, that provides connectivity to the outside world. Existing oracles arecentralized services. Any smart contract using such services has a single pointof failure, making it no more secure than a traditional, centrally run digitalagreement.In this paper we present ChainLink, a decentralized oracle network. We de-scribe the on-chain components that ChainLink provides for contracts to gainexternal connectivity, and the software powering the nodes of the network. Wepresent both a simple on-chain contract data aggregation system, and a moreefficient off-chain consensus mechanism. We also describe supportingreputationand security monitoring services for ChainLink that help users make inedprovider selections and achieve robust service even under aggressively adver-sarial conditions. Finally, we characterize the properties of an ideal oracle asguidance for our security strategy, and lay out possible future improvements,including richly featured oracle programming, data-source infrastructure modi-fications, and confidential smart-contract cution.1Contents1 Introduction 32 Architectural Overview 42.1 On-Chain Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Off-Chain Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Oracle Security 74 ChainLink Decentralization Approach 114.1 Distributing sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Distributing oracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 ChainLink Security Services 165.1 Validation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Reputation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Certification Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 Contract-Upgrade Service . . . . . . . . . . . . . . . . . . . . . . . . 205.5 LINK token usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Long-Term Technical Strategy 216.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 Infrastructure changes . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3 Off-chain computation . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Existing Oracle Solutions 268 Conclusion 27A Off-Chain Aggregation 33A.1 OCA protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.2 Proof sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37B SGX Trust Assumptions 3821 IntroductionSmart contracts are applications that cute on decentralized infrastructure, suchas a blockchain. They are tamperproof, in the sense that no party even their cre-ator can alter their code or interfere with their cution. Historically, contractsembodied in code have run in a centralized manner that leaves them subject to al-teration, termination, and even deletion by a privileged party. In contrast, smartcontracts’ cution guarantees, which bind all parties to an agreement as written,create a new and powerful type of trust relationship that does not rely on trust inany one party. Because they are self-verifying and self-cuting i.e., tamperproofas explained above, smart contracts thus offer a superior vehicle for realizing andadministering digital agreements.The powerful new trust model that smart contracts embody, though, introducesa new technical challenge connectivity. The vast majority of interesting[27]1 smartcontract applications rely on data about the real world that comes from key resources,specifically data feeds and APIs, that are external to the blockchain. Because ofthe mechanics of the consensus mechanisms underpinning blockchains, a blockchaincannot directly fetch such critical data.We propose a solution to the smart contract connectivity problem in the ofChainLink, a secure oracle network. What differentiates ChainLink from other oraclesolutions is its ability to operate as a fully decentralized network. This decentralizedapproach limits the trust in any single party, enabling the tamperproof quality valuedinsmartcontractstobeextendedtotheend-to-endoperationbetweensmartcontractsandtheAPIstheyrelyon. Makingsmartcontractsexternallyaware, meaningcapableof interacting with off-chain resources, is necessary if they are going to replace thedigital agreements in use today.Today, the lion’s share of traditional contractual agreements that have been digi-tally automated use external data to prove contractual perance, and require dataoutputs to be pushed to external systems. When smart contracts replace these oldercontractual mechanisms, they will require high-assurance versions of the same typesof data s and outputs. Examples of potential next-generation smart contractsand their data requirements includeSecurities smart contracts such as bonds, interest rate derivatives, and manyothers will require access to APIs reporting market prices and market referencedata, e.g. interest rates.1The main use of smart contracts in Ethereum today is management of tokens, which are acommon functionality in most smart contract networks. We believe that the current focus on tokensto the exclusion of many other possible applications is due to a lack of adequate oracle services, asituation ChainLink specifically aims to remedy.3 Insurance smart contracts will need data feeds about IoT data related to theinsurable event in question, e.g. was the warehouse’s magnetic door locked atthe time of breach, was the company’s firewall online, or did the flight you hadinsurance for arrive on time.Trade finance smart contracts will need GPS data about shipments, data fromsupply chain ERP systems, and customs data about the goods being shippedin order to confirm fulfillment of contractual obligations.Another problem common to these examples is the inability for smart contractsto output data into off-chain systems. Such output often takes the of a paymentmessage routed to traditional centralized infrastructure in which users already haveaccounts, e.g., for bank payments, PayPal, and other payment networks. ChainLink’sability to securely push data to APIs and various legacy systems on behalf of a smartcontract permits the creation of externally-aware tamperproof contracts.Whitepaper roadmapIn this whitepaper*, we review the ChainLink architecture Section 2. We thenexplain how we define security for oracles Section 3. We describe the ChainLinkapproach to decentralization / distribution of oracles and data sources Section 4,and follow with a discussion of the four security services proposed by ChainLink,as well as the role played by LINK tokens Section 5. We then describe a proposedlong-term development strategy, which includes better confidentiality protections, theuse of trusted hardware, infrastructure changes, and general oracle programmabilitySection 6. We briefly review alternative oracle designs Section 7, and concludewith a short discussion of the design principles and philosophy guiding ChainLinkdevelopment Section 8.2 Architectural OverviewChainLink’s core functional objective is to bridge two environments on-chain and off-chain. We describe the architecture of each ChainLink component below. ChainLinkwill initially be built on Ethereum [16], [35], but we intend for it to support all leadingsmart contract networks for both off-chain and cross-chain interactions. In both itson and off-chain versions, ChainLink has been designed with modularity in mind.Every piece of the ChainLink system is upgradable, so that different components canbe replaced as better techniques and competing implementations arise.42.1 On-Chain ArchitectureAs an oracle service, ChainLink nodes return replies to data requests or queries madeby or on behalf of a user contract, which we refer to as requesting contracts anddenote by USER-SC. ChainLink’s on-chain interface to requesting contracts is itselfan on-chain contract that we denote by CHAINLINK-SC.Behind CHAINLINK-SC, ChainLink has an on-chain component consisting of threemain contracts a reputation contract, an order-matching contract, and an aggregatingcontract. The reputation contract keeps track of oracle-service-provider perancemetrics. The order-matching smart contract takes a proposed service level agreement,logs the SLA parameters, and collects bids from oracle providers. It then selects bidsusing the reputation contract and finalizes the oracle SLA. The aggregating contractcollects the oracle providers’ responses and calculates the final collective result ofthe ChainLink query. It also feeds oracle provider metrics back into the reputationcontract. ChainLink contracts are designed in a modular manner, allowing for themto be configured or replaced by users as needed. The on-chain work flow has threesteps 1 oracle selection, 2 data reporting, 3 result aggregation.Oracle Selection An oracle services purchaser specifies requirements that make upa service level agreement SLA proposal. The SLA proposal includes details such asquery parameters and the number of oracles needed by the purchaser. Additionally,the purchaser specifies the reputation and aggregating contracts to be used for therest of the agreement.Using the reputation maintained on-chain, along with a more robust set of datagathered from logs of past contracts, purchasers can manually sort, filter, and selectoracles via off-chain listing services. Our intention is for ChainLink to maintain onesuch listing service, collecting all ChainLink-related logs and verifying the binaries oflisted oracle contracts. We further detail the listing service and reputation systemsin Section 5. The data used to generate listings will be pulled from the blockchain,allowing for alternative oracle-listing services to be built. Purchasers will SLA proposals to oracles off-chain, and come to agreement before finalizing the SLAon-chain.Manual matching is not possible for all situations. For example, a contract mayneed to request oracle services dynamically in response to its load. Automated solu-tions solve this problem and enhance usability. For these reasons, automated oraclematching is also being proposed by ChainLink through the use of order-matchingcontracts.OncethepurchaserhasspecifiedtheirSLAproposal, insteadofcontactingtheora-clesdirectly, theywilltheSLAtoanorder-matchingcontract. Thesubmissionof the proposal to the order-matching contract triggers a log that oracle providers can5monitor and filter based on their capabilities and service objectives. ChainLink nodesthen choose whether to bid on the proposal or not, with the contract only acceptingbids from nodes that meet the SLA’s requirements. When an oracle service providerbids on a contract, they commit to it, specifically by attaching the penalty amountthat would be lost due to their misbehavior, as defined in the SLA.Bids are accepted for the entirety of the bidding window. Once the SLA hasreceived enough qualified bids and the bidding window has ended, the requestednumber of oracles is selected from the pool of bids. Penalty payments that wereoffered during the bidding process are returned to oracles who were not selected, anda finalized SLA record is created. When the finalized SLA is recorded it triggers alog notifying the selected oracles. The oracles then per the assignment detailedby the SLA.DataReporting Oncethe neworaclerecord hasbeen created, theoff-chainoraclescute the agreement and report back on-chain. For more detail about off-chaininteractions, see Sections 2.2 and 4.Result Aggregation Once the oracles have revealed their results to the oracle con-tract, their results will be fed to the aggregating contract. The aggregating contracttallies the collective results and calculates a weighted answer. The validity of eachoracle response is then reported to the reputation contract. Finally, the weightedanswer is returned to the specified contract function in USER-SC.Detecting outlying or incorrect values is a problem that is specific to each typeof data feed and application. For instance, detecting and rejecting outlying answersbefore averaging may be necessary for numeric data but not boolean. For this reason,there will not be a specific aggregating contract, but a configurable contract addresswhich is specified by the purchaser. ChainLink will include a standard set of ag-gregating contracts, but customized contracts may also be specified, provided theycon to the standard calculation interface.2.2 Off-Chain ArchitectureOff-chain, ChainLink initially consists of a network of oracle nodes connected to theEthereum network, and we intend for it to support all leading smart contract net-works. These nodes independently harvest responses to off-chain requests. As weexplain below, their individual responses are aggregated via one of several possibleconsensus mechanisms into a global response that is returned to a requesting con-tract USER-SC. The ChainLink nodes are powered by the standard open source coreimplementation which handles standard blockchain interactions, scheduling, and con-necting with common external resources. Node operators may choose to add software6extensions, known as external adapters, that allow the operators to offer additionalspecialized off-chain services. ChainLink nodes have already been deployed along-side both public blockchains and private networks in enterprise settings; enabling thenodes to run in a decentralized manner is the motivation for the ChainLink network.ChainLink Core. The core node software is responsible for interfacing with theblockchain, scheduling, and balancing work across its various external services. Workdone by ChainLink nodes is atted as assignments. Each assignment is a set ofsmaller job specifcations, known as subtasks, which are processed as a pipeline. Eachsubtask has a specific operation it pers, before passing its result onto the nextsubtask, and ultimately reaching a final result. ChainLink’s node software comes witha few subtasks built in, including HTTP requests, JSON parsing, and conversion tovarious blockchain ats.External Adapters. Beyond the built-in subtask types, custom subtasks can bedefined by creating adapters. A