The Seven Requirements for a Viable Decentralized Oracle Network

14 min readNov 20, 2019

The main value propositions for computing a business process using a blockchain-based smart contract are its high reliability and tamperproof security. However, similar to a computer without the Internet, one of the main limitations of current smart contract designs is their inability to extend their functionality outside the blockchain (off-chain). The main reason for this roadblock is the lack of security guarantees awarded to developers when they connect with data and systems off-chain. Taking into account their underlying value, yet need for increased functionality, there is an increasing demand for a technical solution that allows smart contracts to extend their value off-chain while maintaining their valuable security properties.

A graphic from the Chainlink website showcasing the potential connectivity of the network.

Oracles are gateways for blockchains to connect to the external world. They greatly extend the functionality of a smart contract by allowing it off-chain connection to data providers, web APIs, IoT, payment systems, enterprise backends, and other blockchains. However, an oracle is just a piece of middleware that connects two systems for data exchange, which by itself is subject to the same forms of centralization that blockchains aim to avoid. To solve this, many projects have started decentralized oracle networks to bring blockchain-level security to the oracle layer. With seemingly such importance to the evolution of smart contracts, it’s interesting to ponder why we haven’t seen an expansive decentralized oracle system up until this point?

It should become clear in the analysis below that building a decentralized oracle network is something that requires careful step-by-step planning and calculated design of its features. Analogous to the phrase “Learning how to run before you can walk,” if the network is rushed or its features are poorly designed and released at random, it’s likely that a strong enough foundation can never be established from which to expand the network. To construct a solid base, users will require high levels of trust in the network’s ability to secure value before they will realistically adopt it. In this regard, the early days must be nurtured under trusted stewardship as initial partnerships are built, so that while features are rolled out, they support one another through proper incentive-driven dynamics, yet give leeway to make adjustments and fix security flaws.

This article is designed to showcase, via seven key features, why Chainlink is the market leader in decentralized oracle networks thanks to its meticulous planning when it comes to establishing network trust and designing network features. These features include:

- Distinct asset
- Staking/penalties
- Network of nodes
- Pluggable reputation
- Pluggable aggregation and threshold signatures
- Blockchain agnostic
- Coordination

It’s important to note that many of these features are still in development and not completely finalized, so they may be subject to changes. However, all the information described is derived from public material and listed within the sources below. It’s also worth mentioning that many optional features, such as trusted execution environments, Mixicles, and more, are not included at this time, but offer their own unique value propositions that only further improve the functionality and user experience of the Chainlink network.

Without further ado, let’s break down each of these requirements in greater detail.

Distinct Asset

An oracle network needs its own distinct asset in order to represent the security of the network. Now you may ask, “Why not just allow users to pay in another token, like ETH or DAI?” There are a few answers to this, many of which overlap into the other requirements of a viable decentralized oracle system.

First, if nodes were to take payment in a stablecoin, then the security of the network, which is the value of that oracle network’s asset staked in service agreements, could be severely compromised or fail if that stablecoin project were to fail or experience some type of catastrophic issue. The problem here is the disconnect between the stablecoin project and the oracle project. The oracle project could fail as a result of a stablecoin project, but the stablecoin project wouldn’t fail as a result of a failure in the oracle project. It’s important that the only way in which the oracle network can fail is due to an internal problem in the oracle network itself, as opposed to externally-induced failures.

What about paying in the blockchain’s native token, like ETH? This is actually a significantly more complex protocol to implement when you consider a network of blockchain agnostic nodes. A single client (node) would need to stake and accept payment in the native asset of each network it is set up on, rather than requiring a single payment medium for its work across any chain. This entails establishing wallet setups for each network it supports and maintaining complex account/staking balances for fluctuating assets in different crypto-economic systems, all at the same time. The complexity demonstrated gets into the network of nodes discussion, but in short, the more active a node operator has to be, the more likely it is that they will not stick around long term, thus reducing the security of the network. With a single asset associated with compensating node operators across any blockchain, network cost and security can remain synchronized across any supported blockchain.

This becomes more apparent when you account for threshold signatures and off-chain aggregation, which will ultimately allow Chainlink to scale at cost against centralized oracle systems. Consider the following scenario: a user, Alice, wishes to have the result from 1000+ nodes trigger her contract. It is only with a distinct asset, which serves as the common form of payment for all node operators, that Alice would be able to find a network large enough to service her contract. If there are different assets for different networks than the security of the entire oracle network becomes fragmented amongst different chains, which lowers the overall security for each individual chain.

But, why can’t she just pay them in ETH if her smart contract is on the powerful Ethereum network? This is based on the assumption that Ethereum will be a viable project long term, which is not a bad assumption, however, if Alice is a billion-dollar customer, it’s likely not good enough. If Ethereum were to fail during her service agreement with these nodes and the staked payment was only in ETH, the security of her contract would be completely compromised. However, if using a distinct asset for the oracle network and the Ethereum network fails during the service agreement, the contract’s inputs are still secure and Alice could easily migrate the service agreement along with the same quorum of staking-backed nodes to another blockchain without sacrificing her contract’s security.

Staking/Penalties

A penalty system, often referred to as staking, is a necessary element to prevent unreliable or malicious behavior. At a minimum, there needs to be some way to prevent a user from having to pay for non-responsive nodes. At the same time, unresponsive nodes decrease the security of the inputs to the smart contract they’re servicing, therefore there is a further need to disincentivize non-responsiveness, such as incurring penalties. It’s from these basic properties that a reputation system can be built, by monitoring which nodes have incurred penalties, which have the most at stake, and so on.

A penalty system also provides defense against a Sybil attack at scale. It’s much harder to convince 51% of 1000 nodes to feed a contract bad data than it is to convince 51% of 10 nodes. A majority of nodes will likely want to participate in future service agreements and will not want to start their node’s reputation over from scratch if the attack fails. It is likely that a node receiving consistent requests will bring in more profits from their existing and future service agreements than risk their entire stake for one payout. It’s clear that even without a reputation service in place, a penalty system is sufficient in thwarting most malicious activity (though of course not perfectly, which is the reason why reputation systems are still critical).

An amount of stake is also a signal to users that the node is here for the purpose of servicing requests and have put in their own capital to prove that they have a long-term interest in doing so. It shows they are confident enough in their ability to service requests that they are willing to bet on their own reliability. Without such a signal, users have only one factor, past performance, to determine long-term reliability. While that is an important factor, without staking and penalties the node cannot provide any guarantee that they will continue servicing requests long-term.

Network of Nodes

An oracle network needs both a strong network of nodes and a network of strong nodes. Currently, we’re seeing the latter being built out, with vetted node operators participating in the Chainlink team’s aggregator contracts. However, once Coordination is streamlined, then that paves the way for users being able to take advantage of a strong network of nodes. What’s the difference between the two and why is it important to have both?

In order to kickstart a network, get early users onboard, and initial usage, you need to prove that the oracle network will not fail on its users in its early stages. The Chainlink team has foreseen this with their aggregation contracts and require each node operator to be reviewed before being added. This would allow them to reach out to potential customers with a list of vetted nodes to provide data for their projects rather than a list of random, potentially insecure node operators. With complete control over the initial quorum of node operators, the Chainlink team has the flexibility to change out nodes if quality drops in order to retain security of the network before staking is live. With Coordination, Reputation, and Staking, users can get higher assurances that the quorum of nodes will be available and reliable for the duration of the service agreement without having to validate the identity of each individual node operator.

For a strong network of nodes, you need an oracle client that is easy to run and maintain long-term. The Chainlink node itself is both lightweight (easy on resources) and simple to run. Node operators only need to keep their node funded with enough ETH to fulfill requests (this requirement could be significantly less in the future with threshold signatures) and ensure that their node is online and up-to-date. With an easy to use node client and good incentives to run one, an oracle network can easily grow into what would be considered a strong network of nodes. The Coordinator contract, combined with penalties and reputation, will allow users to take advantage of a strong network of nodes with the same, if not better, level of security than the existing network of strong nodes.

Pluggable Reputation

Reputation is recognized as a hard crypto-economic problem to solve. Any single solution could have its potential problems, trade-offs, and even security concerns. A decentralized oracle network needs to support many different implementations of reputation in order to allow the users of the network to define the criteria that best suits their needs. With pluggable reputation, the user isn’t locked into a single, centralized reputation system. Instead, they are able to choose from different reputation providers, which may rate individual node operators based on different factors. If a reputation provider fails or has some sort of critical issue associated with it, users can simply use a different reputation provider in their place, and the oracle system as a whole continues on without any drop in security.

Reputation providers are also a gateway to prevent Sybil attacks. Reputation providers may opt to perform KYC on nodes before listing them to give users assurances that each node operator listed is a unique entity. High-value contracts will likely have strict requirements of past performance, overall reliability, and security.

A reputation system is only as secure as its slowest update frequency. For example, if a node has been malicious, it can continue to participate in separate service agreements with the same reputation score until an update from that provider has taken place. However, if a reputation provider immediately updates nodes’ reputation upon malicious or any sort of negative activity, then other service agreements can also immediately take action. This means a non-responsive or malicious node can be ejected from multiple (or potentially all) of the service agreements they are a part of for a single action.

This makes it harder to convince 51% of the nodes for any service agreement to feed a contract bad data, given that one incident could affect all of the node’s service agreements and stake, rather than incurring an isolated punishment. This might sound scary, but consider that with pluggable reputation the user can also define a threshold of reputation weight for each participating node in order to be part of the service agreement. In that regard, the node operator doesn’t have to instantly lose everything from a single non-response, but a single non-response could slightly reduce that node operator’s reputation score, which could still be high enough for the service agreements they’re participating in.

Pluggable Aggregation and Threshold Signatures

Users need the ability to select how the answer provided to their smart contract will be calculated. Incorporating pluggable aggregation, users can define their own aggregation models such as common averages or unique algorithms that apply different weights to different data sources. With pluggable aggregation, you also get fine-grained payments based on performance, where nodes that respond first can receive more payment than nodes that respond last, which could potentially receive no payment at all (as defined by the user).

Off-chain aggregation, especially with threshold signatures, is significantly more powerful since computationally intensive operations can be performed much more cost-effectively than on-chain at scale. Again, consider the previous scenario of Alice wanting to use 1000+ nodes to trigger her smart contract. The only way it’s possible to use that many nodes in a cost-efficient manner is through off-chain aggregation and threshold signatures. As demonstrated in the audit of Chainlink (see the Aggregator contract in the Chainlink repository), on-chain aggregation can only scale to around 45 nodes.

Threshold signatures are necessary for Alice to be able to pay 1000+ nodes per request without having to spend millions of dollars per year. They enable the maximum degree of cost efficiency by only requiring a single on-chain response for any number of nodes in the service agreement. This means it’s not required for every node to write back on-chain, incurring network fees to pay for gas, which significantly raises the cost to add nodes to a service agreement. Only a single node would need to respond on-chain with a valid signature, and simple monetary incentive mechanics can ensure that that happens for each request. Ultimately, this allows a decentralized oracle network to scale in a cost-effective way that competes directly with centralized oracles, while adding greater security using the same properties that make smart contracts secure: maximum decentralization.

Blockchain Agnostic

It doesn’t take long to think about the problems that individual blockchains may have which prevents it from becoming a global standard. Ethereum is currently the leading blockchain for smart contract usage, but as previously discussed in the distinct asset category, it is unwise to rely on an external project’s viability for your own success. However, that is not the only reason that a decentralized oracle network would need to support multiple blockchains.

Chainlink’s modularity allows for any blockchain to be supported immediately, with very little ramp-up time required. External adapters allow for a wallet of another blockchain to be used to write to smart contracts of that chain. External initiators, while less frequently talked about, may be even more powerful in that they allow requests created on another blockchain to trigger a Chainlink node. This modularity allows for node operators to rapidly support blockchains other than Ethereum without the significant up-front development cost of changing core features of nodes until it becomes an absolute necessity.

Another point relevant to this topic is the distinct asset (LINK token) and how it would be represented on another blockchain. This is important because users need the LINK token to secure each and every network, as previously discussed. Chainlink’s own token and network functions can be represented and utilized natively on another blockchain without being dependent on the network capacity of Ethereum. To enable this, a specific “TokenReceiverSender” smart contract is created on Ethereum for each blockchain you want to enable this functionality on. Additionally, each externally supported blockchain has a correlating TokenReceiverSender contract for Ethereum, which contains 1 Billion wrapped LINK tokens (wLINK) to represent its total supply.

For example, Ethereum will contain many separate TokenReceiverSender contracts for chains like Tron, Neo, and EOS, each filled with 1B wLINK tokens, while each of those blockchains has a correlating TokenReceiverSender contract for Ethereum only. Essentially, Ethereum would act as a hub that would contain contracts for every other supported chain, spokes. Those other chains would only contain the contracts necessary to return funds back to Ethereum. If another smart contract blockchain were to rise in popularity and usage, then it would make sense to effectively promote it from being a spoke to a hub.

When users want to use wLINK natively on a separate chain, they send their LINK tokens to the TokenReceiverSender contract on Ethereum that represents their desired chain. Users specify what address they want their wLINK tokens sent to when they deposit LINK on Ethereum. This creates a Chainlink request where an oracle confirms the LINK token is locked on Ethereum; once confirmed, it unlocks an equal amount of those wLINK tokens on the other chain so they can then be used natively on the network. Similarly, if a user wants to send funds back, the same process would occur in the opposite direction.

Yet another property within this category is if you consider threshold signatures, not every node needs to have a funded wallet for the target blockchain in order to participate in a service agreement on it, they only need to be able to validate that the request actually occurred. Since only one node needs to respond to the target chain to execute the smart contract and unlock payment in the threshold signature scheme (which would additionally unlock payment for every node in the agreement), this makes the process of supporting other blockchains easy. Nodes would still be incentivized to obtain access to the target blockchain so that they can receive higher payments for responding on-chain.

Coordination

Coordination is arguably the most important piece of a viable decentralized oracle network since it’s ultimately what allows users to actually use the network. Without a means of coordination, users like Alice wanting 1000+ nodes to trigger her contract would have to find and contact each node operator individually. However, with a listing service, such as the Chainlink Market by LinkPool, the process of finding reliable nodes is handled for her. Chainlink not only allows for but encourages multiple listing services to exist because it makes for a strong ecosystem.

Listing services essentially compete to get users (smart contract creators) by trying to get the highest number and most reliable nodes listed on their service. A listing service could also differentiate themselves by offering additional services, such as assisting users with building service agreements, ensure compatibility between different data sources, and hooking into reputation providers to give users the best experience possible.

There’s also a factor of coordination between the nodes themselves since nodes within the same service agreement need to know about each other in order to create a threshold signature. This is where an off-chain p2p networking layer must exist that the nodes use for communicating with one another. A service agreement is basically a coordinated effort between a user, multiple nodes, a specification of work, and on-chain verifiable parameters that ensure nodes that do work get paid.

Building Sustained Success from a Foundation of Trust

After reviewing each requirement of a viable decentralized oracle network, it’s evident that Chainlink is taking the necessary, yet calculated steps required to cultivate continually compounding trust within their oracle network. While competitors have and will continue to emerge, which only validates the importance of the use case, it appears that none of them are on par with the technical design and network effects currently accelerating on Chainlink.

By properly aligning network incentives and onboarding the necessary functionalities, Chainlink is building a very strong foundation for a decentralized oracle network that’s trusted by startups and enterprises alike, something already evident by their 70+ integrations in less than a year on mainnet. This groundwork is not something that a competitor can simply recreate via a new technical achievement, but, instead, requires years of building, networking, and establishing market-wide trust across a variety of disciplines and industries. It’s from this carefully crafted trust dynamic that Chainlink is set up to succeed both in the current moment and long into the future.

Follow me on Twitter: @Crypto___Oracle