Detail Whitepaper GitHub Comment Analysis

WebSite	https://chain.link/
GitHub	smartcontractkit/chainlink
Update Date	2018 Sep 03 08:09:36

Circulating Supply	350,000,000
Total Supply	1,000,000,000
Max Supply	0
Price	$0.3185947
Volume 24h	$2,768,995
Market Cap	$111,508,144
Change 24h	-6.23%
Update Date	September 26th 2018, 2:13:35 am

v1

Smart contracts are applications that execute on decentralized infrastructure, such as a blockchain. They are tamperproof, in the sense that no party (even their creator) can alter their code or interfere with their execution. Historically, contracts embodied in code have run in a centralized manner that leaves them subject to alteration, termination, and even deletion by a privileged party. In contrast, smart contracts’ execution 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 in any one party. Because they are self-verifying and self-executing (i.e., tamperproof as explained above), smart contracts thus oﬀer a superior vehicle for realizing and administering digital agreements. The powerful new trust model that smart contracts embody, though, introduces a new technical challenge: connectivity. The vast majority of interesting[27]1 smart contractapplicationsrelyondataabouttherealworldthatcomesfromkeyresources, speciﬁcally data feeds and APIs, that are external to the blockchain. Because of the mechanics of the consensus mechanisms underpinning blockchains, a blockchain cannot directly fetch such critical data. We propose a solution to the smart contract connectivity problem in the form of ChainLink, a secure oracle network. What diﬀerentiates ChainLink from other oracle solutions is its ability to operate as a fully decentralized network. This decentralized approach limits the trust in any single party, enabling the tamperproof quality valued insmartcontractstobeextendedtotheend-to-endoperationbetweensmartcontracts andtheAPIstheyrelyon. Makingsmartcontractsexternallyaware,meaningcapable of interacting with oﬀ-chain resources, is necessary if they are going to replace the digital agreements in use today. Today, the lion’s share of traditional contractual agreements that have been digitally automated use external data to prove contractual performance, and require data outputs to be pushed to external systems. When smart contracts replace these older contractual mechanisms, they will require high-assurance versions of the same types of data inputs and outputs. Examples of potential next-generation smart contracts and their data requirements include:

• Securities smart contracts such as bonds, interest rate derivatives, and many others will require access to APIs reporting market prices and market reference data, e.g. interest rates.

•Insurance smart contracts will need data feeds about IoT data related to the insurable event in question, e.g.: was the warehouse’s magnetic door locked at the time of breach, was the company’s ﬁrewall online, or did the ﬂight you had insurance for arrive on time. •

•Trade ﬁnance smart contracts will need GPS data about shipments, data from supply chain ERP systems, and customs data about the goods being shipped in order to conﬁrm fulﬁllment of contractual obligations.

Another problem common to these examples is the inability for smart contracts to output data into oﬀ-chain systems. Such output often takes the form of a payment message routed to traditional centralized infrastructure in which users already have accounts, e.g., for bank payments, PayPal, and other payment networks. ChainLink’s ability to securely push data to APIs and various legacy systems on behalf of a smart contract permits the creation of externally-aware tamperproof contracts.

able to identify eligible payees directly among participating oracles. Consequently, PROVIDER must obtain evidence of misbehavior from the oracles themselves, some of which may be untrustworthy. We propose the use of consensus-like mechanisms in our solution for ChainLink to ensure that PROVIDER does not pay freeloading oracles. The oﬀ-chain aggregation system we propose for ChainLink, with accompanying security proof sketches, may be found in Appendix A. It makes use of a distributed protocol based on threshold signatures that provides resistance to freeloading by f < n/3 oracles. We believe resistance to freeloading is an interesting new technical problem.

As an oracle service, ChainLink nodes return replies to data requests or queries made by or on behalf of a user contract, which we refer to as requesting contracts and denote by USER-SC. ChainLink’s on-chain interface to requesting contracts is itself an on-chain contract that we denote by CHAINLINK-SC. Behind CHAINLINK-SC, ChainLink has an on-chain component consisting of three main contracts: a reputation contract, an order-matching contract, and an aggregating contract. The reputation contract keeps track of oracle-service-provider performance metrics. The order-matching smart contract takes a proposed service level agreement, logs the SLA parameters, and collects bids from oracle providers. It then selects bids using the reputation contract and ﬁnalizes the oracle SLA. The aggregating contract collects the oracle providers’ responses and calculates the ﬁnal collective result of the ChainLink query. It also feeds oracle provider metrics back into the reputation contract. ChainLink contracts are designed in a modular manner, allowing for them to be conﬁgured or replaced by users as needed. The on-chain work ﬂow has three steps: 1) oracle selection, 2) data reporting, 3) result aggregation.
Oracle Selection An oracle services purchaser speciﬁes requirements that make up a service level agreement (SLA) proposal. The SLA proposal includes details such as query parameters and the number of oracles needed by the purchaser. Additionally, the purchaser speciﬁes the reputation and aggregating contracts to be used for the rest of the agreement. Using the reputation maintained on-chain, along with a more robust set of data gathered from logs of past contracts, purchasers can manually sort, ﬁlter, and select oracles via oﬀ-chain listing services. Our intention is for ChainLink to maintain one such listing service, collecting all ChainLink-related logs and verifying the binaries of listed oracle contracts. We further detail the listing service and reputation systems in 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 submit SLA proposals to oracles oﬀ-chain, and come to agreement before ﬁnalizing the SLA on-chain. Manual matching is not possible for all situations. For example, a contract may need to request oracle services dynamically in response to its load. Automated solutions solve this problem and enhance usability. For these reasons, automated oracle matching is also being proposed by ChainLink through the use of order-matching contracts. Once the purchaser has speciﬁed their SLA proposal, instead of contacting the oracles directly, they will submit the SLA to anorder-matching contract. The submission of the proposal to the order-matching contract triggers a log that oracle providers can monitor and ﬁlter based on their capabilities and service objectives. ChainLink nodes then choose whether to bid on the proposal or not, with the contract only accepting bids from nodes that meet the SLA’s requirements. When an oracle service provider bids on a contract, they commit to it, speciﬁcally by attaching the penalty amount that would be lost due to their misbehavior, as deﬁned in the SLA. Bids are accepted for the entirety of the bidding window. Once the SLA has received enough qualiﬁed bids and the bidding window has ended, the requested number of oracles is selected from the pool of bids. Penalty payments that were oﬀered during the bidding process are returned to oracles who were not selected, and a ﬁnalized SLA record is created. When the ﬁnalized SLA is recorded it triggers a log notifying the selected oracles. The oracles then perform the assignment detailed by the SLA.

Data Reporting Once the new oracle record has been created, the oﬀ-chain oracles execute the agreement and report back on-chain. For more detail about oﬀ-chain interactions, see Sections 2.2 and 4.
Result Aggregation Once the oracles have revealed their results to the oracle contract, their results will be fed to the aggregating contract. The aggregating contract tallies the collective results and calculates a weighted answer. The validity of each oracle response is then reported to the reputation contract. Finally, the weighted answer is returned to the speciﬁed contract function in USER-SC. Detecting outlying or incorrect values is a problem that is speciﬁc to each type of data feed and application. For instance, detecting and rejecting outlying answers before averaging may be necessary for numeric data but not boolean. For this reason, there will not be a speciﬁc aggregating contract, but a conﬁgurable contract address which is speciﬁed by the purchaser. ChainLink will include a standard set of aggregating contracts, but customized contracts may also be speciﬁed, provided they conform to the standard calculation interface.

High-reputation services are strongly incentivized in any market to behave correctly and ensure high availability and performance. Negative user feedback will pose a signiﬁcant risk to brand value, as do the penalties associated with misbehavior. Consequently, we anticipate a virtuous circle in which well-functioning oracles develop good reputations and good reputations give rise to incentives for continued high performance.

The Certiﬁcation Service supports endorsements based on several features of oracle deployment and behavior. It would monitor the Validation System statistics on oracles and perform post-hoc spot-checking of on-chain answers—particularly for high-value transactions—comparing them with answers obtained directly from reputable data sources. With suﬃcient demand for an oracle provider’s data, we expect there to be enough economic incentive to justify oﬀ-chain audits of oracle providers, conﬁrming compliance with relevant security standards, such as relevant controls in the Cloud Security Alliance (CSA) Cloud Controls Matrix [26], as well as providing useful security information that they conduct proper audits of oracles’ source and bytecode for their smart contracts.