“Indeed, given truly trustworthy and confidential oracles...the boundary between oracles and smart contracts may become fluid.”

-Chainlink Whitepaper

Pushing Trustlessness Into the Oracle Layer

In the decentralized systems space the word decentralized is synonymous with secure, all else being equal. Security for these systems, protocols, or platforms comes from their tamper-resistant and transparent nature. While much of this industry has focused on the decentralization of lower-level blockchains to run autonomous programs, that security is negated if tamper-resistance or transparency fail at higher levels in the stack.

As oracles begin to pull data, parse information, store credentials and perform off-chain calculations on behalf of smart contracts, the boundaries between classically-defined smart contracts and the oracles that feed them will dissolve. This fluidity will reframe narratives surrounding smart contracts, pushing expectations of trustlessness from base layer blockchains to the oracles that service them. In turn, the industry will shift its focus from base layer chains to the middleware services that provide security for data feeds, payment outputs, off-chain computation and developer experience.

Chainlink has released a promising initial mainnet implementation (v1) and is executing against a roadmap that has the potential to fulfill this vision of a robust, decentralized oracle network. Their initial mainnet implementation, an achievement in and of itself, is an audited oracle software library, a set of team-verified node operators, and a variety of data feeds for developers to choose from. In future iterations, aggregation contracts will allow programmatic selection of nodes and data feeds for each specific need (defined as Service Agreements, or “SAs”, in the Chainlink protocol), node operators will build meaningful reputation based on historical SAs, and Town Crier will provide secure off-chain computation. As Chainlink transitions from a software library to a stateful network, marquee customers will begin to outsource oracle architecture, and Chainlink will slowly become a piece of middleware utilized by most smart contracts of sufficient value and complexity.

If this concept seems entirely foreign, we’ve written previously about the fundamentals of the Chainlink project and need for a decentralized oracle network, see: Our Investment In Chainlink

Maker and the Impact of Oracles

A thought experiment is helpful to illustrate the current state of oracle solutions for externally-connected smart contracts.

In this thought experiment, you are Rune, founder and de-facto leader of Maker. Your company, which operates a collateralized stablecoin built on top of Ethereum, just crossed $300M in assets locked in the protocol. Growth is humming along as you add high-quality assets and other teams build new products on top of your protocol.

Other than regulation, what keeps you up at night?

Security. Security of the underlying blockchain which you are built on top of, the smart contracts you’ve deployed, and the oracles that trigger your smart contracts. Looking at each of them:

The Ethereum blockchain: Though slow and expensive, ETH has the cryptographic guarantees, miner diversity, per-ETH price and per-block rewards ($2.9bn/year) necessary to sustain an honest chain. All things considered, the Ethereum blockchain is not a huge risk for Maker.

Maker’s smart contracts: The Maker team spent months writing them using state of the art methodologies, tested them rigorously on testnets, and had them audited by top security firms. Once deployed Maker will continuously monitor them, but the best smart contract teams in the world built, tested, and audited the logic held in these programs. The main risk event for Maker’s contracts is shortly after launch; as time goes on, and users interact with the smart contracts, the risk of a contract failing actually goes down.

Maker’s price feeds: When Maker launched, decentralized oracle providers had not yet gone live. To pull data on-chain, the Maker team decided to geographically disperse 24 different (now 14) oracles to members of the community, mostly developers on the project. There was, is and probably never will be a direct incentive model from Maker for these node operators to provide reliable data, other than the indirect incentive of the node operators being stakeholders from the community. In February, two of these oracle providers went down for an extended amount of time for unknown reasons. As a safeguard, each of these Oracles pulls a different price feed from an exchange and feeds them into a medianizer contract. There is also a 1 hour delay as well as an emergency settlement switch in case something bad happens. Currently the oracles only provide pricing for ETH, but will need to be expanded as Maker launches Multi-Collateral Dai.

Its obvious that the current implementation of Maker’s oracles represents the largest ongoing security risk to the platform itself. As Maker adds new assets, as the assets locked in the contracts increase, as new data sources need to be incorporated, as old data sources need to be deprecated, and as data feeds need to be re-weighted, the risk of oracles being compromised increases. At $300m in assets locked by crypto users with one collateral asset, the market has said the current level of oracle security/centralization is fine. In a scenario with $1bn in assets locked, with multiple types of asset collateral, or when Maker tries to bring institutions on to the platform, this level of centralization will likely be deemed unacceptable, hindering adoption. Ultimately, Maker’s oracles need to be secure and flexible enough to provide reliable data over the lifetime of the platform, and are the only security threat that increases in risk as the platform scales. Whether or not an approach like Chainlink is the solution, it is obvious that the current architecture cannot scale.

To Rune’s credit, he has acknowledged that Maker’s oracles will need to be upgraded as the platform scales. This problem also isn’t unique; all current DeFi platforms are currently relying on a similar centralized oracle schema. Some, like Synthetix, have already paid the price; 37 million sETH were exposed when a KRW oracle malfunctioned and was exploited on the platform.

What is a better oracle model?

What is a better oracle model than something built in-house by the team?

A better oracle model provides the following things:

Service Agreements (SAs)

• Template that smart contracts can fill out with their data requirements   (number of data sources, number of nodes, reputation of nodes, types of infrastructure they run on) and proposed payment for a given data response
• Template that nodes can then use to bid on jobs

Incentive Compatibility

• Rules enforcing payment for a fulfilled agreement
• Rules enforcing collateral requirements for a fulfilled agreement
• Rules enforcing the slashing of collateral for unfulfilled agreement

Node Reputation

• Reputation as a primitive to assess node operator reliability, uptime and access to  data feeds

Dynamic Node Markets

• Node and data feed competition to drive SA pricing
• Multiple nodes able to bid on contracts for data redundancies

Aggregation Contracts

• Secure contracts that can be used to aggregate nodes responses to a given SA

Composable Inputs

• Secure mechanism through which a smart contract developer can reliably change the inputs, payment or aggregation of a given data source over time

While centralized entities can make headway on aggregation contracts and composability, it does not seem possible for a centralized entity to come up with a solution that is fundamentally incentive compatible.

However, decentralized protocol approaches to oracle models, like Chainlink, can implement all of the above requirements. Just like how Ethereum used game-theory, decentralization and cryptographic guarantees to present a trust-reduced alternative to cloud providers, Chainlink uses the same to present an alternative to centralized oracle providers. Where Ethereum provides binary trustlessness guarantees, Chainlink provides a range of trustlessness guarantees through optional levels of decentralization (a developer can pay for multiple nodes, data feeds, architectures, or have mandatory collateral requirements) when deciding on oracle inputs for a Service Agreement.

On cost and security

This raises two important questions for Rune and developers at large:

• How much oracle decentralization do I need to secure my dApp?
• How much is this oracle decentralization going to cost?

The answer to the first question is that it is context dependent. If you are a tinkerer, a hobbyist, or someone dealing with relatively low amounts of value, then probably not a lot. If you are a company like Maker, with hundreds of millions of dollars in your contracts, you need a much higher degree of decentralization. There is generally a decreasing marginal return for security as it relates to decentralization (and cost), but we get into that later.

The answer to the second question is more nuanced, as the cost for decentralization depends on developments in the Chainlink protocol (Protocol Developments) and those in the Ecosystem as a whole (Ecosystem Developments). Today, however, it is expensive. To make a call from five different price feeds once, it would cost ~0.014 ETH (~$2.65 at today’s prices) worth of gas in transaction fees to use Chainlink’s oracles. For Maker’s architecture, this could cost around $10-50K a year (depending on the number of times the price feed is called), a security budget that far outstrips Maker’s resources. In the future, this gas cost will drastically decrease due to ecosystem developments, while the variety of security guarantees at varying levels of cost will increase as the protocol gains in maturity.  

Ecosystem Developments

Ecosystem developments, as we refer to them here, are advancements unrelated to the core Chainlink protocol itself that have a material impact on the per-oracle call cost and/or the overall security of an externally connected smart contract.

In the near term, ecosystem developments, mainly the node incentive program coupled with a robust node marketplace like Linkpool, will largely neutralize the gas costs that make using Chainlink prohibitively expensive for developers. Nodes will be programmatically subsidized to pull information from a data source or reference contract, and smart contract developers will be able to charge a negligible fee for off-chain data retrieval. Over the longer term, as Ethereum scales and TEEs enable off-chain computation, gas costs will likely be so small that using Chainlink will be economically viable without a node subsidy. Its possible the node incentive program then shifts towards subsidizing bringing on data originators to the platform.

With most of the gas and overhead cost of using Chainlink is reduced via the ecosystem alone, and as smart contracts inevitably increase in value/complexity, nodes will then begin to compete  for smart contract SAs on varying levels of decentralization, data feed access, infrastructure quality, reputation and insurance. While the overhead cost to use Chainlink will be likely be reduced immediately via the node incentive program, this competition between nodes will only emerge once aggregation contracts are released. We explore this, and other protocol developments, below.

Protocol Developments

Protocol developments, as we refer to them here, are advancements related to the core Chainlink protocol that have a material impact on the per-oracle call cost and/or the overall security of an externally connected smart contract.

Right now, we are at 1. Chainlink, as it currently stands, is operating in “single player” mode. Developers can select on-chain reference contracts for a certain piece of off-chain data, but are then responsible for aggregating and parsing the data themselves. It isn’t currently possible to put Service Agreements up for bid to a variety of nodes, as no aggregation contract exists to combine these answers into a meaningful data input. But these initiatives are on the roadmap and some are already under development by the Chainlink team and developer community.

As aggregation contracts are developed, the ability to use multiple nodes/data sources will become viable in practice and Chainlink will transition to #2 - “multi-player” mode. If developers have the need to use a more decentralized architecture, they can then submit an SA to do so, garnering better oracle security at a higher cost. Eventually, as Town Crier is implemented in earnest and off-chain computation becomes viable, the cost of using on-chain contracts to parse, manipulate or even aggregate data can be replaced as aggregation functions are executed within a TEE. For those that don’t want to trust hardware and instead want an on-chain infrastructure, Threshold Signatures will also reduce the cost of aggregating some types of data on-chain. Finally, as standardized reputation metrics become embedded into the protocol, collateralization will become important, introducing additional elements of security and cost.

The broad takeaway on Chainlink protocol developments is that it will transition from a model where there isn’t a lot of functionality at a relatively low cost and level of security, to one where there is a variety of functionality providing different levels of security at varying levels of cost.  

Varying Levels of Cost for Varying Levels of Security

Ecosystem Developments will drive the overhead costs of utilizing any iteration of Chainlink down. Protocol Developments will transition Chainlink from single-player to multi-player mode, enabling developers to auction off their oracle needs at varying levels of security and cost. Nodes will compete on their access to data feeds, infrastructure architecture, collateral availability and insurance.

The result will be a heterogenous market for oracle security, where smart contract developers can buy as much security as they deem necessary. While we believe there will be decreasing marginal returns to decentralization to a certain point, the curve will likely flatten out as the most high value/complexity contracts need ever-increasing guarantees in the form of insurance and collateral for their data feeds.

Where Does This Go Over The Next 18 Months?

While we’ve seen a plethora of application categories from many different industries already building blockchain products, we believe enterprises from different industries will care more about different Protocol or Ecosystem features. To represent this spectrum we think about it using the following matrix:

As the ecosystem continues to mature - base layer scaling happens and professional validators become the norm - we believe we’ll see more decentralized finance (DeFi), games and entertainment applications start using Chainlink as their oracle solution.

As the Chainlink team continues to hit the milestones on their roadmap - aggregation, TEE integration, collateral management - but without the ecosystem moving at the same pace, we believe Chainlink + Ethereum could be viewed as the trusted transaction layer for business process applications. As John Wolpert calls the next paradigm of business applications needing the “5 C's:  Confidence in data Consistency and business logic Continuity across any number of independent state machines without the loss of data Compartmentalization or contract”. It’s clear to him that Chainlink could help provide part of this crucial architecture.

Once both Chainlink and the ecosystem reach their final goals, the largest industries will be able to start building decentralized technology into the core services and product offerings. These industries transact trillions of dollars a year and operate some of the most complex business applications which require the most robust features.