As we explored in a previous post about smart contracts, a smart contract is an autonomously executable digital agreement that can revolutionize major industries such as insurance, derivatives, and trade finance. However, if smart contracts can provide such immense value, why are they not widely adopted already?

What’s Causing the Delay?

The primary reason smart contracts have not built industry adopted use cases outside of tokens is that smart contracts are not connected to off-chain data (data not stored on the blockchain). Blockchains cannot interact with off-chain data without interfering with the consensus protocol (the process by which a distributed system forms a single state of truth). Interacting with off-chain data can lead to multiple states of the blockchain ledger.

Today, the main use of smart contracts is tokenization, the process of issuing ownership rights to real-world assets or utility in the form of a token. Tokenization exploded from 2017-2018, raising an estimated 20 billion dollars. One of the primary reasons for the growth of tokenization is that it doesn’t require off-chain data. All the token information for an Initial Coin Offering (ICO) is already known and stored on-chain, in the blockchain smart contract. On the contrary, most smart contracts for industries such as derivatives, insurance, and trade finance need external off-chain data such as IoT data, market data, and events data to trigger execution.

This trigger data is not stored on the same blockchain as the initial smart contract, because it is simply neither realistic nor practical to do so. Most of the world’s data exists off-chain. The current lack of connectivity between off-chain and on-chain systems means the new and existing worlds cannot interact with each other.

The second challenge facing today’s smart contracts is that smart contracts cannot push outputs onto external systems. For example, smart contracts cannot execute payments in fiat currencies on traditional payment systems. Cryptocurrencies are simply too risky at present for traditional companies to use and hold on their balance sheet. While that could change in the future, most businesses are not willing to adopt smart contracts that are limited to cryptocurrency-only transactions.

The truth is that smart contracts that are unaware of what is happening in the off-chain world and unable to communicate with existing legacy systems are neither smart nor functional enough for real-world adoption. These two limiting factors are inhibiting the entire smart contract ecosystem from progressing to the next level.

The Current State of Oracles

An oracle is a blockchain middleware that creates a secure connection between smart contracts and various off-chain resources that they need to function. It acts as the middle layer between a blockchain and an API that translates information for the blockchain to read. An API is a defined way to communicate with a particular system and varies in design from system to system. Companies develop their own APIs to enable other systems to leverage their services and data in their applications. For example, Uber uses a GPS API, an SMS API, and a Payments API for its services rather than building each of those applications itself.

There are three oracle models: oracles coded from scratch by and for a particular entity, centralized oracles, and decentralized oracles.

The first of these options is to code an oracle from scratch for each use case. This method introduces vulnerabilities and is also inefficient. Since APIs come in a variety of forms, it is time-consuming and costly to have to research and code every oracle from scratch. It’s not practical for companies that need access to a variety of data, potentially on short notice.

In a centralized oracle service, a third party private company fetches and feeds data into the smart contract. While this service can be useful, the smart contract needs to trust that this single company will not be compromised (by leaking sensitive information, getting hacked, experiencing downed servers, etc.). Oracles trigger smart contracts, and there must be significant faith invested in one private company to determine the outcome of valuable, time-sensitive contracts. Furthermore, when a centralized infrastructure is used for oracles, smart contracts lose their key features of being deterministic, tamper-proof, and reliable in their end-to-end execution.

Chainlink, a Decentralized Oracle Network

There is a third solution to the oracle challenge. At Chainlink, we are creating a decentralized oracle network. We offer an all-in-one platform that has all the tools and data developers need to build any type of oracle design pattern for their smart contracts. Chainlink acts as both an oracle and a flexible framework for matching smart contract developers with secure, reliable oracle solutions.

Each oracle represents a node in the network. All nodes run the Chainlink Core software using different types of hardware to power the processing. All services performed by nodes are paid for in the LINK token, which insulates the economics of the network from outside forces.

Chainlink uses external adaptors called “chainlinks” to connect blockchains and APIs. Each API has its own premade chainlink. We offer a robust set of premade chainlinks, so any developer can easily connect their smart contract to an API, in order to obtain external data or connect to an off-chain system.

Ultimately, Chainlink offers the ability to decentralize both the oracle and the data sources.

Decentralizing the oracle gives developers the ability to use any number of oracle (nodes) they want to service their smart contracts. Having multiple oracles not only protects against a single oracle going offline; it protects against an oracle being a single point of attack for hacks or bribes.

Decentralizing the data sources enables oracles to gather data from multiple sources and then aggregate that data into a single deterministic data point to trigger the smart contract. With multiple data sources, the smart contract can protect against having a single faulty data source. Chainlink offers various aggregation modalities, such as using an average and/or removing the outliers.

Another key feature of Chainlink is its reputation system. Similar to how Amazon and Uber have a built-in reputation system for sellers and drivers, Chainlink offers a reputation system for oracles. Reputation can be based on a variety of metrics, such as uptime, response time, and successful jobs completed. A smart contract requester can choose specific oracles to work with based off of ratings or use a random selection based on a certain reputation threshold. This reputation system not only gives developers reliable metrics when choosing oracles; it also holds nodes accountable for their services.

Furthermore, Chainlink offers various levels of security depending on the needs of the smart contracts. One of the main options being offered outside of standardized oracles is oracles that run in a trusted execution environment (TEE) using some type of trusted hardware, such as Intel SGX. The major advantage of an oracle running in a TEE is that the node operator cannot see the details of the query: inputs, outputs, and requestors. TEEs are appealing because closed private information, such as passwords, private keys and closed source APIs, can be handled by a TEE without revealing any of the information to the node operator or the public. Essentially, a TEE oracle could be programmed to access a private account to get data or trigger an action if sent the login details. They also enable off-chain computation for smart contracts that can lower gas costs and improve scalability.

Finally, Chainlink incentivizes nodes to act in an honest manner using a deposit penalty system. In a centralized oracle model, users can hold the private company accountable. Being able to hold the nodes accountable brings the same insurance to the process. To solve a query, a node must deposit a pre-agreed amount of LINK in order to get the opportunity to service that request. If the node feeds outlier data or goes offline, it loses that deposit and the amount is returned to the requestor. In a certain sense, this node accountability is guaranteed protocol-level insurance for uptime and quality services on the contract. Combined with the reputation system, Chainlink uses game theory to incentivize nodes to perform their jobs correctly or risk financial punishment.

Marching Towards Adoption

In order for smart contracts to gain mass adoption, they need the ability to connect securely and reliably to external off-chain data and systems. This is why we at Chainlink are building an open-source decentralized protocol that gives smart contract developers access and control over the amount of decentralization and confidentiality they need. The decentralized oracle network offered by Chainlink enables smart contracts to connect to off-chain systems in order to keep smart contracts deterministic, tamper-proof, and reliable throughout their entire life cycle.

Join the Community and Start Building with Chainlink Today

If you want to start building with Chainlink today, visit the developer documentation, join the technical discussion on Discord, and/or reach out to us about securely launching your data-enabled application or Chainlink Price Reference Data Contract on mainnet today.

If you want to get involved in the Chainlink community, visit our events page to join future meetups like this in your local area. If you want to become a Chainlink Ambassador and host a meetup, sign up today! For more information, check out the Chainlink website or follow us on Twitter or Reddit.