Home / Coin Guide / What is ChainLink? An In-depth review on the project

What is ChainLink? An In-depth review on the project

The ChainLink network provides reliable tamper-proof inputs and outputs for complex smart contracts on any blockchain.

Coming up with a really valuable smart contract necessitates the implementation of multiple inputs to prove contractual performance, as well as multiple outputs to affect outside systems and/or send payment to finish the smart contract. Chainlink provides smart contracts with the inputs and outputs they need to realize their full potential.

Smart contracts require secure middleware to connect them to real world data. This external data will execute the contract, bringing about the need for its high authenticity.

ChainLink’s decentralized oracle network provides similar guarantees of security as smart contracts themselves. By capacitating multiple chainlinks to assess the same data before it becomes a trigger, any one point of failure is gotten rid of, and the overall value of a smart contract that is vastly secure, reliable, and transparent maintained.


Architectural Overview

ChainLink’s core functional objective entails bridging two blockchain environments, that is on-chain and off-chain. Chainlink will initially be developed atop the Ethereum blockchain network, nonetheless, the team intends for it to support all leading smart contract networks for both off-chain and cross-chain interactions. In both its on-chain and off-chain versions, ChainLink has been designed with modularity in mind. Every piece of the ChainLink system is upgradable in such a manner that various components can be replaced as better techniques and competing implementations arise.

Figure 1: ChainLink workflow:

1) USER-SC makes an on-chain request;

2) CHAINLINK-SC logs an event for the oracles;

3) ChainLink core picks up the event and routes the assignment to an adapter;

4) ChainLink adapter performs a request to an external API;

5) ChainLink adapter processes the response and passes it back to the core;

6) ChainLink core reports the data to CHAINLINK-SC;

7) CHAINLINK-SC aggregates responses and passes them back as a single response to USER-SC.

On-Chain Architecture

As an oracle service, Chainlink nodes return replies to data requests or queries made by or on behalf of a user contract, which the project’s developer team terms as requesting contracts and denote by USER-SC. ChainLink’s on-chain interface to requesting contracts is itself an on-chain contract which the Chainlink team denotes by CHAINLINK-SC.

Behind CHAINLINK-SC, Chainlink has an on-chain component consisting of three main contracts namely:

  1. reputation contract,
  2. an order-matching contract,
  3. And an aggregating contract.

The reputation contract keeps track of the metrics as regards oracle-service-provider performance. 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 implementing the reputation contract and finalizes the oracle SLA. The aggregating contract collects the responses from oracle providers and calculates the final aggregate result of the Chainlink query. It as well feeds oracle provider metrics back into the reputation contract. ChainLink contracts are designed in a modular manner, giving room for them to be configured or replaced by users as required.

The on-chain work flow comprises of three major steps, as highlighted below:

  1. Oracle Selection: 

An oracle services purchaser particularizes the requirements that make up a Service Level Agreement (SLA) proposal. The Service Level Agreement proposal consists of such details as query parameters as well as the number of oracles required by the purchaser. In addition, the purchaser specifies the reputation and aggregating contracts to be used for the rest of the agreement.

Using the reputation maintained on-chain, alongside a more robust set of data collected from logs of past contracts, purchasers are in a position to manually sort, filter, and select oracles via off-chain listing services. The team’s strife is for Chainlink to maintain one such listing service, collecting all Chainlink-related logs and validating the binaries of listed oracle contracts. The data used to generate listings will be pulled from the blockchain, giving room for alternative oracle-listing services to be built. Purchasers will submit SLA proposals to oracles off-chain, and reach consensus prior to finalizing the SLA on-chain.

Manual matching is not possible for all situations. For instance, a contract may need to request oracle services dynamically in response to its load. Significantly, automated solutions resolve this issue and enhance usability. For the above-mentioned reasons, automated oracle matching is also being proposed by Chainlink through the implementation of order-matching contracts.

Once the purchaser has specified their Service Level Agreement proposal, rather than directly contacting the oracles, they will submit the SLA proposal to an order-matching contract. The submission of the proposal to the order-matching contract activates a log that oracle providers are able to monitor and filter on the basis of their capabilities and service objectives. Chainlink nodes as a result decide on whether or not to bid on the proposal, with the contract only accepting bids from nodes that meet the SLA’s requirements. On the off chance an oracle service provider bids on a contract, they commit to it, specifically by attaching the penalty amount that would be lost due to their misbehavior, as stipulated in the SLA.

Bids are accepted for the entirety of the bidding window. The instant the SLA has received a sufficient amount of qualified bids and the bidding window has ended, the requested number of oracles is selected from the pool of bids. Penalty payments that were offered amid the bidding process are returned to oracles who were not selected, and a finalized SLA record is created. When the finalized SLA is recorded it triggers a log notifying the selected oracles. The oracles as a result carry out the assignment detailed by the SLA.

  1. Data Reporting:

Once the new oracle record has been created, the off-chain oracles execute the agreement and report back on-chain.

  1. Result Aggregation:

As soon as the oracles have disclosed their results to the oracle contract, their results will be fed to the aggregating contract. The aggregating contract computes 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 taken back to the specified contract function in USER-SC.

Discerning outlying or incorrect values is an issue that is particular to each type of data feed and application. For example, discerning and rejecting outlying answers prior to computing the average may be imperative for numeric data but not Boolean. As such, there will not be a specific aggregating contract. Instead, there will be a configurable contract address which is specified by the purchaser. Chainlink will include a standard set of aggregating contracts, nonetheless, tailored or rather customized contracts may also be specified, for as long as they conform to the standard calculation interface.

Off-Chain Architecture

Off-chain, ChainLink initially comprises of a network of oracle nodes connected to the Ethereum network, and the team behind the projects intends for it to support all leading smart contract networks. These nodes independently gather responses to off-chain requests. Their individual responses are aggregated via one among a variety of possible consensus mechanisms into a global response that is returned to a requesting contract USER-SC.

The Chainlink nodes are powered by the standard open source core implementation which takes care of standard blockchain interactions, scheduling, and connecting with common external resources. Node operators may choose to add software extensions, referred to as external adapters, which capacitate the operators to offer additional specialized off-chain services. Chainlink nodes have thus far been deployed alongside both public blockchains and private networks in enterprise settings; capacitating the nodes to run in a decentralized manner is the motivation for the Chainlink network.

ChainLink Core

The core node software is responsible for interfacing with the blockchain, scheduling, and balancing work across its various external services. Work done by ChainLink nodes is formatted as assignments. Each assignment is a set of tinier job specifications, referred to as subtasks, which are processed as a pipeline. Each subtask has a specific operation it carries out, prior to passing its result onto the next subtask, and eventually reaching a final result. Chainlink’s node software comes bundled with a number of in-built subtasks, being inclusive of HTTP requests, JSON parsing, and conversion to a variety of blockchain formats.

External Adapters

Beyond the built-in subtask types, custom subtasks can be defined by creating adapters. Adapters are basically external services with a minimal REST API. By designing adapters in a service-oriented manner, programs written in whichever programming language are able to be easily implemented simply by including a small intermediate API in front of the program. Similarly, interaction with complicated multi-step APIs can be simplified to individual subtasks with parameters.

Subtask Schemas

It is the team’s anticipation that several adapters will be open-sourced, so that services can be audited and run by various community members. With various types of adapters being developed by various developers, ensuring compatibility between adapters is key.

Chainlink at the moment operates with a schema system based on JSON Schema, to particularize what inputs each adapter needs as well as the manner by which they should be formatted. Similarly, adapters specify an output schema to describe the format of each subtask’s output.

Oracle Security

To best explain Chainlink’s security architecture, it is fundamental to first explain the reason as to why security is important, and what the implications are.

Why is it necessary for oracles to be secure? 

In the event a smart contract security is fed with false data, it is bound to pay out the inappropriate party. If smart contract insurance data feeds can be tampered with by the insured party there may be insurance fraud, and if GPS data given to a trade finance contract can be modified after it leaves the data provider, payment can be released for goods that are yet to arrive.

Generally, an appropriately functioning blockchain, with its ledger or bulletin-board abstraction, offers extremely strong security properties. Users depend on the blockchain as a functionality that correctly gratifies transactions and averts data from being altered. They treat it in effect like a trusted third party. A supporting oracle service must offer a level of security corresponding to that of the blockchain it supports. An oracle too must as such serve users as an efficient trusted third party, providing correct and timely responses with very high probability. A system’s security is only as strong as its weakest link. As such a highly trustworthy oracle is required to preserve the trustworthiness of a well-engineered blockchain.

Defining oracle security: An ideal view

In order to reason about oracle security, we must first define it. An instructive, principled way to reason about oracle security stems from the following thought experiment. Imagine that a trusted third party (TTP) – an ideal entity or functionality that always carries out instructions faithfully to the letter – were tasked with running an oracle. We’ll denote this oracle by ORACLE (using all caps in general to denote an entity fully trusted by users), and suppose that the TTP obtains data from a perfectly trustworthy data source src. Given this magical service ORACLE, what instructions would we ask it to carry out?

As illustrated in figure 2 above, the behavior of an ideal oracle ORACLE is defined by steps below:

  1. Accept request;
  2. Obtain data;
  3. Return data.

In addition, to protect the confidentiality of a request, upon decrypting it, ORACLE never uses or discloses the data it contains, except to query src.

To realize the integrity property, also referred to as the authenticity property, it should simply be required that ORACLE undertakes the following steps:

  1. Accept request: Ingest from a smart contract USER-SCa request Req = (srcτ, q) that specifies a target data source, src, a time or range of times τ, and a query q;
  2. Obtain data: Send query q to src at time τ;
  3. Return data: Upon receiving answera, return a to the smart contract.

These simple instructions, correctly carried out, define a strong, meaningful, yet simple notion of security. Intuitively, they dictate that ORACLE acts as a trustworthy bridge between src and USER-SC. For instance, if src is https://www.FountOfKnowledge.com, τ is 4 p.m., and q = “price for ticker INTC”, the integrity of ORACLE guarantees that it will provide USER-SC with exactly the price of INTC as queried at 4 p.m. at https://www.FountOfKnowledge.com.

Confidentiality is yet another desirable property for oracles. As USER-SC sends Req to ORACLE in the clear on the blockchain, Req is public. There are many situations in which Req is sensitive and its publication could be harmful. If USER-SC is a flight insurance contract, for instance, and sends ORACLE a query Req regarding a particular user’s flight (q = “Ether Air Flight 338”), the result would be that a user’s flight plans are revealed to the whole world. If USER-SC is a contract for financial trading, Req could leak information about a user’s trades and portfolio. There are various other examples, of course.

To protect the confidentiality of Req, it can be required that data in Req was encrypted under a (public key) belonging to ORACLE. Continuing to leverage the TTP nature of ORACLE, the information-flow constraint could then simply be given to ORACLE:

Note: Upon decrypting Req, never reveal or use data in Req except to query Src.

There are other crucial oracle properties, for example, availability, the last of the classical CIA (Confidentiality-Integrity-Availability) triad. A truly ideal service ORACLE, of course, would never go down. Availability as well entails more subtle properties such as censorship resistance: An honest ORACLE will not single out particular smart contracts and deny their requests.

The concept of a trusted third party is similar to the notion of an ideal functionality used to prove the security of cryptographic protocols in certain models. We can also model a blockchain in similar terms, conceptualizing it in terms of a TTP that maintains an ideal bulletin board. Its instructions are to accept transactions, validate them, serialize them, and maintain them permanently on the bulletin board, an append-only data structure.

Why the ideal oracle (ORACLE) is hard to achieve

There is, without doubt, no perfectly trustworthy data source Src. Data may be benignly or maliciously corrupted due to faulty web sites, cheating service providers, or honest mistakes.

On the assumption Src isn’t trustworthy, then even if ORACLE does operate exactly like a TTP as instructed above, it still doesn’t completely meet the notion of security the Chainlink team wants. Given a faulty source Src, the integrity property defined above no longer means that an oracle’s answer a is correct. If the true price of Intel is $40 and https://www.FountOfKnowledge.com misreports it as $50, for example, then ORACLE will send the incorrect value a = $50 to USER-SC. This problem is unavoidable when using a single source SrcORACLE simply has no way to know whether the answers Src provides to its queries are correct.

A bigger issue, of course, is the fact that ChainLink’s TTP for ORACLE is just an abstraction. No service provider is unconditionally trustworthy. Even the best-intentioned may be buggy or hacked. So there is no way to for a user or smart contract to have absolute assurance that a service ORACLE will carry out its instructions faithfully.

ChainLink reasons about its security protocols in terms of this ideal functionality ORACLE. The goal in ChainLink is to achieve a real world system with properties as close as possible to those of ORACLE under realistic trust assumptions.

For simplicity in what follows, the complete set of ChainLink contracts, i.e., its full on-chain functionality (not just its interface 10 to requesting contracts) is now denoted by CHAINLINK-SC. The multiple individual contracts actually used in the system architecture are thereby abstracted away.

ChainLink Decentralization Approach

3 basic complementary approaches to ensuring against faulty nodes proposed are:

  1. Distribution of data sources;
  2. Distribution of oracles;
  3. and Use of trusted hardware.

As some media platforms do not support subscripts later in the text, they will be replaced by a symbol “-”, where it is appropriate

Example: equals A-1

Distributing sources

A simple way to deal with a faulty single source Src is to obtain data from multiple sources, i.e., distribute the data source. A trustworthy ORACLE can query a collection of sources Src-1, Src-2, . . . , Src-k, obtain responses a-1, a-2, . . . , a-k, and aggregate them into a single answer A = agg(a-1, a-2, . . . , a-k)ORACLE might do this in any of a number of ways. One, for example, is majority voting. If a majority of sources return the identical value a, the function agg returns a; otherwise it returns an error. In this case, provided that a majority (> k/2) sources are functioning correctly, ORACLE will always return a correct value A.

Many alternative functions agg can ensure robustness against erroneous data or handle fluctuations in data values over time (e.g, stock prices). For example, agg might discard outliers (e.g., the largest and smallest values ai) and output the mean of the remaining ones.

Of course, faults may be correlated across data sources in a way that weakens the assurances provided by aggregation. If site Src-1 = EchoEcho.com obtains its data from Src-2 = TheHorsesMouth.com, an error at Src-2 will always imply an error at Src-1. More subtle correlations between data sources can also occur. ChainLink also proposes to pursue research into mapping and reporting the independence of data sources in an easily digestible way so that oracles and users can avoid undesired correlations.

Distributing oracles

Just as sources can be distributed, ChainLink’s ideal service ORACLE itself can be approximated as a distributed system. This is to say that instead of a single monolithic oracle node O, we can instead have a collection of n different oracle nodes {O-1, O-2, . . . , O-n}. Each oracle O-i contacts its own distinct set of data sources which may or may not overlap with those of other oracles. O-i aggregates responses from its data sources and outputs its own distinct answer A-i to a query Req.

Some of these oracles may be faulty. So clearly the set of all oracles’ answers A-1, A-2, . . . , A-n will need to be aggregated in a trustworthy way into a single, authoritative value A. But given the possibility of faulty oracles, where and how will this aggregation happen in ChainLink?

Initial solution: In-contract aggregation. The initial proposed solution in ChainLink will be a simple one called in-contract aggregationCHAINLINK-SC — which, again, denotes the on-chain part of ChainLink — will itself aggregate oracle responses. (Alternatively, CHAINLINK-SC may call another aggregation contract, but for conceptual simplicity we assume that the two components form a single contract.) In other words, CHAINLINK-SC will compute A = Agg(A1, A2, . . . , An) for some function Agg (similar to agg, as described above), and send the result A to USER-SC.

This approach is practical for small n, and has several distinct benefits:

  • Conceptual simplicity: Despite the fact that the oracle is distributed, a single entity, CHAINLINK-SC, performs aggregation by executing Agg.
  • Trustworthiness: As CHAINLINK-SC’s code can be publicly inspected, its correct behavior can be verified. (CHAINLINK-SCwill be a relatively small, simple piece of code.) Additionally, CHAINLINK-SC’s execution is fully visible on chain. Thus users, i.e., creators of USER-SC, can achieve a high degree of trust in CHAINLINK-SC.
  • Flexibility:CHAINLINK-SC can implement most desired aggregation functions Agg — the majority function, averaging, etc.

Simple as it is, this approach presents a novel and interesting technical challenge, namely the problem of freeloading. A cheating oracle O-z can observe the response A-i of another oracle O-i and copy it. In this way, oracle O-z avoids the expense of querying data sources, which may charge per-query fees. Freeloading weakens security by undermining the diversity of data source queries and also disincentivizes oracles from responding quickly: Responding slowly and freeloading is a cheaper strategy.

The team suggests a well-known solution to this problem, namely the use of a commit / reveal scheme. In a first round, oracles send CHAINLINK-SC cryptographic commitments to their responses. After CHAINLINK-SC has received a quorum of responses, it initiates a second round in which oracles reveal their responses.

Algorithm 1 shows a simple sequential protocol that guarantees availability given 3f+1 nodes. It uses a commit / reveal scheme to prevent freeloading. Oracle responses are decommitted, and thus exposed to a potential freeloader only after all commitments have been made, thereby excluding the freeloader from copying other oracles’ responses.

On-chain protocols can leverage block times to support synchronous protocol designs. In ChainLink, however, oracle nodes obtain data from sources that may have highly variable response times, and decommitment times by nodes can vary due to, e.g., use of different gas prices in Ethereum. To ensure the fastest possible protocol responsiveness, therefore, Alg. 1 is designed as an asynchronous protocol.

Here, Commit-r(A) denotes a commitment of value A with witness r, while SID denotes the set of valid session ids. The protocol assumes authenticated channels among all players.

It is easy to see that Alg. 1 will terminate successfully. Given 3f + 1 nodes in total, at most f are faulty, so at least 2f + 1 will send commitments in Step 4. Of those commitments, at most f come from faulty nodes, so at least f + 1 come from honest nodes. All such commitments will eventually be decommitted.

Additionally, it is easy to see that A will be correct in Alg.1. Of the f + 1 decommitments on the single value A, at least one has to come from an honest node.

In-contract aggregation via Alg. 1 will be the main approach supported by ChainLink in the short term. The proposed initial implementation will involve a more sophisticated, concurrent variant of the algorithm. ChainLink’s longer-term proposal is reflected in the rather more complicated protocol OCA (Off-Chain Aggregation) specified in Algorithms 2 and 3 in Appendix A. OCA is an off-chain aggregation protocol that minimizes on-chain transaction costs. That protocol also includes payment to oracle nodes and ensures against payments to freeloaders.

Algorithm 1 InChainAgg(

) (code for CHAINLINK-SC)

1: Wait until Req is received from USER-SC.

2: sid ←$ SID

3: Broadcast (requestsid).

4: Wait until set C of 2f + 1 messages (commit, sid) from distinct O-i are received.

5: Broadcast (committedsid).

6: Wait until set D of f + 1 distinct valid decommitments (decommit,(r-i , A-i),sid) are received where, for some A, all A-i = A.

7: Send (AnswerAsid) to USER-SC.

Medium-term strategy: Off-chain aggregation. In-contract aggregation has a key disadvantage: Cost. It incurs the cost of transmitting and processing onchain O(n) oracle messages (commits and reveals for A-1, A-2, . . . , A-n). In permissioned blockchains, this overhead may be acceptable. In permissionless blockchains with onchain transaction fees such as Ethereum, if n is large, the costs can be prohibitive. A more cost-effective approach is to aggregate oracle responses off-chain and transmit a single message to CHAINLINK-SC A. ChainLink’s team proposes deployment of this approach, called off-chain aggregation, in the medium-to-long term.

The problem of achieving a consensus value A in the face of potentially faulty nodes is much like the problem of consensus that underpins blockchains themselves. Given a predetermined set of oracles, one might consider using a classical Byzantine Fault Tolerant (BFT) consensus algorithm to compute A. Classical BFT protocols, however, aim to ensure that at the end of a protocol invocation, all honest nodes store the same value, e.g., in a blockchain, that all nodes store the same fresh block. In ChainLink’s oracle setting, the goal is slightly different. ChainLink’s team wants to ensure that CHAINLINK-SC (and then USER-SC) obtains aggregate answer A = Agg(A-1, A-2, . . . , A-n) without participating in the consensus protocol and without needing to receive answers from multiple oracles. The problem of freeloading, moreover, still needs to be addressed.

The ChainLink system proposes the use of a simple protocol involving threshold signatures. Such signatures can be realized using any of a number of signature schemes, but are especially simple to implement using Schnorr signatures. In this approach, oracles have a collective public key pk and a corresponding private key sk that is shared among O-1, O-2, . . . , O-n in a (t, n)-threshold manner. Such a sharing means that every node O-i has a distinct private / public keypair (sk-i , pk-i ). O-i can generate a partial signature

that can be verified with respect to pk-i.

Figure 4: Sig-sk[A] can be achieved by any n/2+1 of the oracles.

The key feature of this setup is that partial signatures on the same value A can be aggregated across any set of t oracles to yield a single valid collective signature Σ = Sig-sk[A] on an answer A. No set of t − 1 oracles, however, can produce a valid signature on any value. The single signature Σ thus implicitly embodies the partial signatures of at least oracles.

Threshold signatures can be realized naïvely by letting Σ consist explicitly of a set of t valid, independent signatures from individual nodes. Threshold signatures have similar security properties to this naïve approach. But they provide a significant onchain performance improvement: They reduce the size and cost of verifying Σ by a factor of t.

With this setup, it would seem that oracles can just generate and broadcast partial signatures until t such partial signatures enable the computation of Σ. Again, though, the problem of freeloading arises. It must therefore be ensured that oracles genuinely obtain data from their designated sources, rather than cheating and copying A-i from another oracle. Chinlink’s solution involves a financial mechanism: An entity PROVIDER (realizable as a smart contract) rewards only oracles that have sourced original data for their partial signatures.

In a distributed setting, determining which oracles qualify for payment turns out to be tricky. Oracles may intercommunicate off-chain and there is no longer a single authoritative entity (CHAINLINK-SC) receiving responses and are therefore unable 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. ChainLink’s team proposes the use of consensus-like mechanisms in the solution for ChainLink to ensure that PROVIDER does not pay freeloading oracles.

The off-chain aggregation system the team proposes for ChainLink, with accompanying security proof sketches. It makes use of a distributed protocol based on threshold signatures that provides resistance to freeloading by f<n/3 oracles. ChainLink’s team believes resistance to freeloading is an interesting new technical problem.

Chainlink Security Services

Thanks to the protocols that were just described, ChainLink proposes to ensure availability and correctness in the face of up to f faulty oracles. Additionally, trusted hardware is being actively considered as a secure approach toward protecting against corrupted oracles providing incorrect responses. Trusted hardware, however, may not provide definitive protection for three reasons. First, it will not be deployed in initial versions of the ChainLink network. Second, some users may not trust trusted hardware. Finally, trusted hardware cannot protect against node downtime, only against node misbehavior. Users will therefore wish to to ensure that they can choose the most reliable oracles and minimize the probability of USER-SC relying on > f faulty oracles.

To this end, ChainLink’s team proposes the use of four key security services: a Validation System, a Reputation System, a Certification Service, and a Contract-Upgrade Service. All of these services may initially be run by one company or group interested in launching the ChainLink network, but are designed to operate strictly accordingly to ChainLink’s philosophy of decentralized design. ChainLink’s proposed security services cannot block oracle node participation or alter oracle responses. The first three services only provide ratings or guidance to users, while the Contract-Upgrade Service is entirely optional for users. Additionally, these services are designed to support independent providers, whose participation should be encouraged so that users will eventually have multiple security services among which to choose.

Validation System

The ChainLink Validation System monitors on-chain oracle behavior, providing an objective performance metric that can guide user selection of oracles. It will seek to monitor oracles for:

  • Availability: The Validation System should record failures by an oracle to respond in a timely way to queries. It will compile ongoing uptime statistics.
  • Correctness: The Validation System should record apparent erroneous responses by an oracle as measured by deviations from responses provided by peers.

In the initial, on-chain aggregation system in ChainLink, such monitoring is straightforward, as all oracle activity is visible to CHAINLINK-SC.

Recall, however, that in the off-chain aggregation system envisaged for ChainLink, it’s the oracles themselves that perform aggregation. Consequently, CHAINLINK-SC does not have direct visibility into oracle responses and cannot itself monitor availability and correctness.

Fortunately, oracles digitally sign their responses, and thus, as a side effect, generate non-repudiable evidence of their answers. Chinlink’s proposed approach will therefore be to realize the validation service as a smart contract that would reward oracles for submitting evidence of deviating responses. In other words, oracles would be incentivized to report apparently erroneous behavior.

Availability is somewhat trickier to monitor, as oracles of course don’t sign their failures to respond. Instead, a proposed protocol enhancement would require oracles to digitally sign attestations to the set of responses they have received from other oracles. The validation contract would then accept (and again reward) submission of sets of attestations that demonstrate consistent non-responsiveness by an underperforming oracle to its peers.

In both the on-chain and off-chain cases, availability and correctness statistics for oracles will be visible on-chain. Users / developers will thus be able to view them in real time through an appropriate front end, such as a dApp in Ethereum or an equivalent application for a permissioned blockchain.

Reputation System

The Reputation System proposed for ChainLink would record and publish user ratings of oracle providers and nodes, offering a means for users to evaluate oracle performance holistically. Validator System reports are likely to be a major factor in determining oracle reputations and placing these reputations on a firm footing of trust. Factors beyond on-chain history, though, can provide essential information about oracle node security profiles. These may include users’ familiarity with oracles’ brands, operating entities, and architectures. The team envisions the ChainLink Reputation System to include a basic on-chain component where users’ ratings would be available for other smart contracts to reference. Additionally, reputation metrics should be easily accessible off-chain where larger amounts of data can be efficiently processed and more flexibly weighted.

For a given oracle operator, the Reputation System is initially proposed as supporting the following metrics, both at the granularity of specific assignment types, and also in general for all types supported by a node:

  • Total number of assigned requests: The total number of past requests that an oracle has agreed to, both fulfilled and unfulfilled.
  • Total number of completed requests: The total number of past requests that an oracle has fulfilled. This can be averaged over number of requests assigned to calculate completion rate.
  • Total number of accepted requests: The total number of requests that have been deemed acceptable by calculating contracts when compared with peer responses. This can be averaged over total assigned or total completed requests to get insight into accuracy rates.
  • Average time to respond: While it may be necessary to give oracle responses time for confirmation, the timeliness of their responses will be helpful in determining future timeliness. Average response time is calculated based on completed requests.
  • Amount of penalty payments: If penalty payments were locked in to assure a node operator’s performance, the result would be a financial metric of an oracle provider’s commitment not to engage in an “exit scam” attack, where the provider takes users’ money and doesn’t provide services. This metric would involve both a temporal and a financial dimension.

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

Certification Service

While ChainLink’s Validation and Reputation Systems are intended to address a broad range of faulty behaviors by oracles and is proposed as a way to ensure system integrity in the vast majority of cases, ChainLink may also include an additional mechanism called a Certification Service. Its goal is to prevent and/or remediate rare but catastrophic events, specifically en bloc cheating in the form of Sybil and mirroring attacks.

Sybil and mirroring attacks. Both ChainLink’s simple and in-contract aggregation protocols seek to prevent freeloading in the sense of dishonest nodes copying honest nodes’ answers. But neither protects against Sybil attacks. Such attacks involve an adversary that controls multiple, ostensibly independent oracles. This adversary can attempt to dominate the oracle pool, causing more than f oracles to participate in the aggregation protocol and provide false data at strategic times, e.g., in order to influence large transactions in high-value contracts. Quorums of cheating oracles can also arise not just under the control of a single adversary, but also through collusion among multiple adversaries. Attacks or faults involving > f oracles are especially pernicious in that they are undetectable from on-chain behavior alone.

Additionally, to reduce operational costs, a Sybil attacker can adopt a behavior called mirroring, in which it causes oracles to send individual responses based on data obtained from a single data-source query. In other words, misbehaving oracles may share data off-chain but pretend to source data independently. Mirroring benefits an adversary whether or not it chooses to send false data. It poses a much less serious security threat than data falsification, but does slightly degrade security in that it eliminates the error correction resulting from diversified queries against a given source Src. For example, if https://www.datasource.com emits erroneous data due to, say, a sporadically triggered bug, multiple queries may still obtain a correct majority result.

Sybil attacks resulting in false data, mirroring, and collusion in general may be eliminated by the use of trusted hardware in ChainLink’s long-term strategy.

Certification Service design. The ChainLink Certification Service would seek to provide general integrity and availability assurance, detecting and helping prevent mirroring and colluding oracle quorums in the short-to-medium term. The Certification Service would issue endorsements of high-quality oracle providers. ChainLink’s team emphasizes again, as noted above, that the service will only rate providers for the benefit of users. It is not meant to dictate oracle node participation or non-participation in the system.

The Certification 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 sufficient demand for an oracle provider’s data, ChainLink’s team expects there to be enough economic incentive to justify off-chain audits of oracle providers, confirming compliance with relevant security standards, such as relevant controls in the Cloud Security Alliance (CSA) Cloud Controls Matrix, as well as providing useful security information that they conduct proper audits of oracles’ source and bytecode for their smart contracts.

In addition to the reputation metrics, automated on-chain and automated offchain systems for fraud detection, the Certification Service is planned as a means to identify Sybil attacks and other malfeasance that automated on-chain systems cannot. For example, if all nodes agree that the moon is made of green cheese, they can cause USER-SC to ingest this false fact. MOON COMPONENTS = {GREEN CHEESE} will be recorded on the blockchain, however, and visible in a post-hoc review.

Contract-Upgrade Service

As recent smart contract hacks have shown, coding bulletproof smart contracts is an extremely challenging exercise. And even if a smart contract has been correctly programmed, environmental changes or bugs can still result in vulnerabilities.

For this reason, ChainLink’s team proposes a Contract-Upgrade Service. The team emphasizes that use of this service is entirely optional and in control of users.

In the short term, if vulnerabilities are discovered, the Contract-Upgrade Service would simply make a new set of supporting oracle contracts available in ChainLink. Newly created requesting smart contracts will then be able to migrate to the new set of oracle contracts.

Unfortunately, though, existing ones would be stuck with the old, potentially vulnerable set. In the longer term, therefore, CHAINLINK-SC would support a flag (MIGFLAG) in oracle calls from requesting contracts indicating whether or not a call should be forwarded to a new CHAINLINK-SC should one become available. Set by default (i.e., if the flag is missing) to falseMIGFLAG would enable requesting contracts to benefit from automatic forwarding and thus migration to the new version of CHAINLINK-SC. In order to activate forwarding, a user will cause her requesting contract to issue ChainLink requests with MIGFLAG = true. (Users can engineer their smart contracts so that they change this flag upon receiving an instruction to do so on-chain from an authorized contract administrator.)

Migration of users to new oracle contracts functions as a kind of “escape hatch,” something long advocated for by blockchain researchers as a mechanism to fix bugs and remediate hacks without resorting to such cumbersome approaches as whitehat hacking or hard forks. Migration to the updated contracts will be visible on the blockchain, and available to audit for users to review before upgrading.

ChainLink’s team recognizes nonetheless that some users will not feel comfortable with any one group controlling an escape hatch in the form of migration / forwarding. Forced migration could empower the migrating contract’s controller, or a hacker who compromises relevant credentials, to undertake malicious activity, such as changing oracle responses. It is for this reason that requesting contracts have full control of the forwarding feature and can thus opt out of escape-hatch activation. Additionally, in accordance with ChainLink’s focus on decentralization, ChainLink’s team expects that providers will be able to support multiple versions of CHAINLINK-SC developed by the community.

Design Principles

As team continues their work on ChainLink, the team will seek to prioritize the following core values:

  • Decentralization for secure and open systems. Decentralization is not only the foundation of the tamperproof properties of blockchains, but the basis of their permissionless nature. By continuing to build decentralized systems, ChainLink’s team aims to further enable permissionless development within the ecosystem. ChainLink’s team believes that decentralization is a crucial component for a globally thriving ecosystem with long-term sustainability.
  • Modularity for simple, flexible system design. ChainLink’s team appreciates the philosophy of building small tools which do one thing well. Simple components can be easily reasoned about and thus securely combined into larger systems. ChainLink’s team believes that modularity not only enables upgradable systems, but facilitates decentralization. Wherever key pieces of ChainLink depend on or are managed by too few parties, ChainLink’s team will seek to design an ecosystem which allows for competing implementations to be used.
  • Open source for secure, extensible systems. ChainLink is made possible by standing on the shoulders of many open source projects. ChainLink’s team values the community and will continue to contribute by developing ChainLink in an open source manner. ChainLink’s team plans to engage continually with developers, academics, and security experts for peer review. ChainLink’s team encourages testing, audits, and formal proofs of security, all with the aim of creating a platform whose robustness and security can support future innovations

The ChainLink Team

Source: ChainLink website.

Starting his career at FirstMark Capital, Sergey Nazarov left to join the cryptocurrency revolution in 2011. He spiritedly believes blockchain technology has the capacity to revolutionize the manner in which societies distribute wealth, enforce contracts, and share crucial information.

Steve Ellis is a former a Software Engineer and team lead at Pivotal Labs, where he worked on securing sensitive HIPAA compliant data and building scalable payments automation software. He is a big fan of Ethereum, Bitcoin and the decentralized future.

Dimitri was previously a Software Engineer at Pivotal Labs and McKinsey. He has led engineering teams at such notable organizations as Infogroup. He’s excited about the positive societal impact of smart contracts, owing to the fairness and transparency they bring about.

Mark began his career at Gunderson Dettmer, helping manage the growth of leading global hedge funds. He built Valcu, a technical leader in contracts automation software, where Mark saw the vast potential of externally connected smart contracts.

Alex is an experienced software engineer. He formerly worked at Pivotal Labs and Northpass, developing secure and highly scalable enterprise software. He is enthusiastic about the revolutionary impact that well-made smart contracts will have on the world’s global financial system.

After an academic career studying the security of the Tor network, John went on to lead software development teams that have built some of the largest big data processing systems, while as well making open-source contributions to such leading projects as the Rust programming language.

  • Dan Kochis – Global Head of BD & Partnerships.

Dan Kochis has a long history of closing deals that help organizations reach their next stage of growth world-wide. He was integral to Alibaba’s first United States’ acquisition, a number of worldwide strategic partnerships worth over $120 million USD in annual revenue, and corporate exits totaling over $4 billion USD.

Adelyn is an experienced growth marketer, whose senior roles at her previous organizations have led them to be acquired by such major playmakers as Amazon. Adelyn is additionally an expert in Applied Artificial Intelligence, and believes smart contracts have a large contribution to make in that field.

Thomas is a vastly experienced Integration Engineer, whose role majorly entails helping in the planning and management of large software deployments for enterprise clients. He is as well a big fan of ChainLink, and the decentralized future.

Rory is an experienced community manager, with a genuine passion for seeing worthwhile technologies like ChainLink achieve mainstream adoption by the larger smart contracts and cryptocurrency communities.


Source: ChainLink website.

Ari is a professor of computer science in the Jacobs Institute at Cornell Tech and a co-director of IC3 (Initiative for Cryptocurrencies and Contracts). He is a former Chief Scientist of RSA.

Andrew is a renowned leader in decentralized consensus research and secure blockchain infrastructure. He is an Associate Professor of Computer Science at the University of Illinois and an advisor to both Zcash and Tezos.

Evan is one of the creators of LLVM which generates the low level machine code running every Apple device, as well as much of Google, Nvidia, and Intel. He is at the moment the Director of Engineering at Facebook.

Tom is the founder of DocuSign, the leading e-signature company that revolutionized digital contracts. He is a seasoned entrepreneur, executive and board member who is renowned for creating billions of dollars in enterprise value.

Hudson is the Ethereum community manager, a renowned authority on smart contracts, and the Ethereum development roadmap. Significantly, he has written about why he’s supporting our work.

Jake was previously the Chief Technology Officer at Triton Research, going on to launch CoinFund, one of the leading research groups focused on web 3.0 and blockchain-based infrastructure.

Brian is the Chief Executive Officer of Smith+Crown, a vastly renowned playmaker in blockchain research space as regards providing in-depth analysis of both ongoing token sales and the larger evolution of decentralized technology over the past 2 years.

Chainlink Partnerships

Product & Traction

Oracles, ideally, provide a trustless (or at least near-trustless) way of getting extrinsic (i.e., “real-world” or off-chain) information, such as the results of football games, the price of gold, or truly random numbers, onto the Ethereum platform for smart contracts to use. They can also be used to relay data securely to DApp frontends directly. Oracles can therefore be thought of as a mechanism for bridging the gap between the off-chain world and smart contracts. Allowing smart contracts to enforce contractual relationships based on real-world events and data broadens their scope dramatically.

Some more examples of data that might be provided by oracles include:

  • Random numbers/entropy from physical sources such as quantum/thermal processes: e.g., to fairly select a winner in a lottery smart contract
  • Parametric triggers indexed to natural hazards: e.g., triggering of catastrophe bond smart contracts, such as Richter scale measurements for an earthquake bond
  • Exchange rate data: e.g., for accurate pegging of cryptocurrencies to fiat currency
  • Capital markets data: e.g., pricing baskets of tokenized assets/securities
  • Benchmark reference data: e.g., incorporating interest rates into smart financial derivatives
  • Static/pseudostatic data: security identifiers, country codes, currency codes, etc.
  • Time and interval data: for event triggers grounded in precise time measurements
  • Weather data: e.g., insurance premium calculations based on weather forecasts
  • Political events: for prediction market resolution
  • Sporting events: for prediction market resolution and fantasy sports contracts
  • Geolocation data: e.g., as used in supply chain tracking
  • Damage verification: for insurance contracts
  • Events occurring on other blockchains: interoperability functions
  • Ether market price: e.g., for fiat gas price oracles
  • Flight statistics: e.g., as used by groups and clubs for flight ticket pooling

Markets and volume

Information from Coinmarketcap.com:

Information from Etherscan.io:

Information from Coinlib.io:

ChainLink form a bullish pennant pattern which is most commonly breaks to the upside.


Confidential Consortium Blockchain Framework is an open-source system that capacitates high-scale, confidential blockchain networks that meet all significant enterprise requirements —offering a means to accelerate production enterprise adoption of blockchain technology.

Microsoft, through the Coco project, realizes the latter by designing specifically for confidential consortiums, in which case nodes and actors are explicitly declared and controlled. On the basis of these requirements, the framework presents an alternative approach to ledger construction, granting enterprises the scalability, distributed governance as well as the facilitated confidentiality they are in need of without sacrificing the inherent security and immutability they expect.

Leveraging the power of extant blockchain protocols, Trusted Execution Environments (TEEs) such as Intel SGX and Windows Virtual Secure Mode (VSM), distributed systems and cryptography, the Confidential Consortium Blockchain Framework enables enterprise-ready blockchain networks that deliver:

  • Throughput and latency approaching database speeds.
  • Richer, more flexible, business-specific confidentiality models.
  • Network policy management through distributed governance.
  • Support for non-deterministic transactions.

By providing these capabilities, the framework offers a trusted foundation with which extant blockchain protocols can be incorporated to deliver complete, enterprise-ready ledger solutions, opening up broad, high scale scenarios throughout the expanse of industries, and furthering blockchain’s capability to digitally revolutionize businesses.

Oraclize is the leading oracle service for smart contracts and blockchain applications, serving thousands of requests on a daily basis on such platforms as Ethereum, Rootstock, R3 Corda, HyperLedger Fabric and EOS.

The solution developed by Oraclize is to demonstrate that the data fetched from the original data-source is genuine and untampered. This is accomplished by accompanying the returned data together with a document called authenticity proof. The authenticity proofs can build upon different technologies such as auditable virtual machines and Trusted Execution Environments.

This solution elegantly solves the Oracle Problem:

  • Blockchain Application’s developers and the users of such applications don’t have to trust Oraclize; the security model is maintained.
  • Data providers don’t have to modify their services in order to be compatible with blockchain protocols. Smart contracts can directly access data from Web sites or APIs.
  • Oraclize engine can be easily integrated with both private and public instances of different blockchain protocols.
  • Hivemind

Hivemind is a Peer-to-Peer Oracle Protocol which absorbs accurate data into a blockchain so that Bitcoin-users can speculate in Prediction Markets. These markets have the potential to revolutionize the emergence and diffusion of knowledge in society.

An “oracle corporation” model attempts to guarantee that a group of self-selected, anonymous, greedy users will always resolve contract-outcomes honestly. Outcomes are established by weighted-vote, according to users’ ownership of a second type of “VoteCoin”, of which there are a constant amount (granting Sybil-immunity). Ownership of the VoteCoins is redistributed according to a Schelling Coordination Game, which destabilizes malicious cartels only. Large individual malicious-votes are discouraged through collapse in the market value of Votecoins and threat of (rare, Sybil-resistant) Miner Vetoes and Overrides. Like equities, VoteCoins are tradable and pay dividends over time, removing the incentive for an “exit scam”.

In very simple terms, æternity is a new blockchain platform, but it is also a vision for the future. This vision is being realized by a global community of believers, convinced in the disruptive potential of scalable, public blockchain technology. It is a movement that aims to propose decentralized, trustless alternatives to the existing governance, economic and financial intermediaries.

From a technological point of view, arternity is a public, open-source, blockchain-based distributed computing and digital-asset platform that builds upon decentralized cryptographic P2P technology. The platform is open to anyone, anywhere in the world to use.

A crucial feature for most contracts, whether encoded as text or as code, is the ability to refer to values from the environment. The æternity Oracle Machine provides real-world data to the blockchain. Each user can ask questions about the environment and the oracle provides the answer. The consensus mechanism comes into play in case of disagreement.

Mobius integrates the old internet with the new decentralized internet of value. Just as Stripe integrates payment processing into apps, Mobius (MOBI) integrates the blockchain ecosystem into apps.

The simple public APIs abstract away the underlying complexity of blockchain integration and development; so any developer is in a position to build modular constructs on the blockchain without particular domain prowess. Resultantly, Mobius simplifies the process of connecting any application, gadget, or data stream to the blockchain ecosystem.

The live dApp (decentralized application) Store capacitates every developer to securely distribute and scale cross-blockchain apps for widespread adoption. The MVP use-case is the live dApp Store that makes it trivial for developers to accept in-app digital currency (cryptocurrency) payments. The Mobius protocol encompasses standards as regards interoperable blockchain login, payment, smart contracts, governance, and oracles.

Witnet is a decentralized oracle network (DON) that connects smart contracts to the

outer world. Generally speaking, it allows any piece of software to retrieve the contents published at any web address at a certain point in time, with complete and verifiable proof of its integrity and without blindly trusting any third party.

Witnet runs on a blockchain with a native protocol token (called Wit), which miners called witnesses earn by retrieving, attesting and delivering web contents for clients. On the other hand, clients spend Wit to pay witnesses for their Retrieve-Attest-Deliver (RAD) work. Witnesses also compete to mine blocks with considerable rewards, but Witnet mining power is proportional to their previous performance in terms of honesty and trustworthiness — this is, their reputation as witnesses. This creates a powerful incentive for witnesses to do their work honestly, protect their reputation and not to deceive the network.

Token Mechanics & Economics

The ChainLink network utilizes the LINK token to pay ChainLink Node operators for the retrieval of data from off-chain data feeds, formatting of data into blockchain readable formats, off-chain computation, and uptime guarantees they provide as operators. In order for a smart contract on networks like Ethereum to use a ChainLink node, they will need to pay their chosen ChainLink Node Operator using LINK tokens, with prices being set by the node operator based on demand for the off-chain resource their ChainLink provides, and the supply of other similar resources. The LINK token is an ERC20 token, with the additional ERC223 “transfer and call” functionality of transfer(address,uint256,bytes), allowing tokens to be received and processed by contracts within a single transaction.

When a user creates a smart contract, they’ll be able to put a price (in LINK) on how much they’re willing to pay for the data retrieval. Nodes will bid on those smart contracts by paying the penalty fee (in LINK) if the smart contract creator has decided to set an amount for the penalty fee. Nodes not selected will be able to withdraw their LINK that they spent on bidding. Nodes that were selected will be able to withdraw their penalty fee and rewards for data retrieval after they have submitted data which was accepted by the smart contract.

As the node returns acceptable data to the smart contract, it will be paid (in LINK) for both partial and whole (whichever is relevant) completion. For example, if an assignment is to retrieve a data point from a data provider once, then upon completion, the node would be paid for 100% of the assignment. Another example, if an assignment is to retrieve a data point from a provider every day for 30 days, then each time the node returns acceptable data to the smart contract, it will be paid as a percentage of the total assignment.

Payment for assignment completion and penalty withdrawals accumulate over time, instead of automatically being released back to the node’s Ethereum address. The node operator will need to pay the gas fee in order to withdraw the accumulated LINK.

Token Metrics

ICO Token Price: 1 LINK = 0.11 USD (0.00038462 ETH)


Team: Team with early involvement in crypto, and good prior experience
Idea: Crucial for the market, working and easily implemented oracles will be a great adoption driver for crypto market
Whitepaper: Whitepaper is good in technical part, but lacks important information like token metrics and token mechanics, some additional info can be found on GitHub

This project has been around for quite some time, but it was mostly under radar until 2017, when it got a moment to shine when a lot of hype was generated in 4chan. ChainLink is well known for its weak involvement with community, though in the last few months this trend is changing — tweets are more frequent and a lot of partnerships are announced and confirmed.

ChainLink is quite ambitious, it tries to create blockchain agnostic middle layer which will make smart contracts reach higher places with its oracles. Working decentralized oracles are a game changer on this market, with right partnerships it is hard to imagine just how big ChainLink’s capitalization will be. ChainLink already has some working oracles, and even show-cased some for SWIFT, securing a place on Sibos. This created a lot of speculations and does so even now, especially since it is stated on ChainLink’s website that “We work with Banking Technology Leaders like SWIFT, helping connect banks to smart contracts with Enterprise Grade Oracles”. Unfortunately no additional nor further info or confirmation is given so this remains as a highly speculated topic. Not too long ago there were some speculations about NASDAQ partnering with ChainLink, well, it was because of Brave New Coin (BNC), BNC is working with Chainlink as their data provider. Nasdaq is working with BNC to release Bitcoin Liquid Index (BLX) and the Ethereum Liquid Index (ELX) indexes so people are assuming ChainLink will be used in order to get that price data.

ChainLink got a lot of partners which plan to use its oracles and that is very good for this project, since for some time it had literally 0 marketing and this will at least increase awareness about this project as well as build stronger ecosystem.

ChainLink has a number of competitors from both traditional and crypto companies, most of the crypto-competitors are quite new, or only partly overlap with ChainLink (like Aeternity, which is more of a EOS-ETH competitor) while competitors like Microsoft COCO or Provable (which became ChainLink’s partner recently) have a drawback of being a centralized oracle service.

On the downside ChainLink is lacking economical papers with incentives for node operators, it would be nice to see use of proceeds, as well as distribution of 35% of the tokens which were reserved for incentivizing the ecosystem and well, despite the fact that high activity can be seen on GitHub and Pivot, it would still be nice to see a roadmap. All these point are associated with ChainLink’s weak interaction with community, but since testnet is active for quite a long time and mainnet is somewhere soon to be launched, it would be nice to see more transparent company.

To sum it up, ChainLink is a promising project with some working features (on testnet), a number of strong partnerships and a lot of speculations.

Chainlink Rating

Tech - 8.5
Economics - 8.8
Team - 8.9
Market Opportunities - 8.7
Product - 8.4


User Rating: 4.55 ( 2 votes)

About TheCryptoToday

Check Also

Libra – an analysis of Facebook’s new cryptocurrency

Use Cases, Technology and User Experience What is the use case of the token? According …

Leave a Reply

Your email address will not be published. Required fields are marked *