First-Party vs Third-Party Oracles
This is a replacement entry for the third part in the API3 series, “Getting APIs on the Blockchain”. The previous pieces introduced the definition and context of contemporary APIs.
Thousands of years ago, oracles were seen as agents that bridged the divine and mortal realms. Then in 1938, Alan Turing used the term in his dissertation to describe something that bridged the digital and physical realms. It’s in this context that Web3 has taken ‘oracle’ to describe software that brings outside information into a blockchain.
We’ll see that these oracle bridges have varying degrees of security depending on how their designers view the Oracle Problem and API Connectivity Problem.
The Oracle Problem
The problem of getting off-chain data on-chain is seen abstractly as two general systems that need to be compatible through technical interfaces. Because of this lack of specificity in the definition of the problem, a completely flexible structure becomes a requirement of the solution that can only be acheived by third party oracles.
When a problem is underspecified, any solution will be sub-optimal since in practice, the problem will have clear bounds. This is the case with oracles now — rather than starting the design process viewing all possible ways to decentralize access to traditional API services, the solution was pre-selected by the blockchain-native consensus mechanism.
There are several issues from that come from middle-manning data into blockchains with third-party oracle networks.
Attack vectors
Using a network of third party actors to relay information introduces a new attack surface as compared to data that’s provided directly from the source. Malicious oracles acting together can shape results. Even outside of a cabal, a single actor can impersonate a large portion of the network by spooling up a number of oracle node operator identities, building a reputation of honest operation, and then carry out a Sybil attack when desired.
Middleman tax
In order to incentivize reliable service provision from third party oracles, honest acts must provide consistent and greater potential profits than could be gained from malicious ones. The game theory surrounding this argument is detailed in Section 3.2 of the API3 whitepaper. The “middleman tax” is an additional cost not present in first-party oracle models.
Additional costs
To protect against the additional attack vectors, datafeeds presented by third-party oracles require an excess of redundancy at the oracle level — there must be enough oracles employed in retrieving any point of data that it becomes unlikely that there is a Sybill attack in progress. These measures do not add to security at the data source level. In fact, they only minimize vulnerabilities introduced by third-party oracles rather than rectify or improve the security of the system. Additionally, these redundancies multiply the middleman tax and increase costs of operations.
Bottlenecked decentralization
As previously covered by The API Connectivity Problem, x oracles are rarely drawing from x sources when aggregated into a datafeed. Considering this, increasing the number of oracles used to provide data does not necessarily mean that the aggregate data is of higher quality or more trustworthy than data provided by a single, reputable source.
Unfortunately, because the community is familiar with validator node decentralization equating to the same at the blockchain level, it’s easy to confuse oracle decentralization with data decentralization.
These factors and assumptions conceal that the real bottleneck to decentralization of data on blockchains is at the source level.
Reliable sources
While some API data providers use simple methods, others are aggregating multiple sources after applying advanced filters to ensure the highest quality data to their customers. CoinMarketCap’s volume inflation detection algorithm comes to mind as highlighting how data quality can affect the decisions of investors.
With third-party oracles obscuring their data sources in the face of incentives to gather the cheapest, most easily accessible data available, it becomes important for developers to question the quality of the datafeeds they are using.
This is especially true at a time when oracle exploits on price feeds have been making headlines with jaw dropping losses.
Proof-of-Reputation
First-party oracles have skin in the game, requiring the API provider to put their reputation at stake to play in the Web3 space. The game theory is that the success of their business in the real world is tied to their trustworthiness in Web3, and their trustworthiness in Web3 is tied to the success of their business in the real world.
Though they do not have tokens allocated to their oracle node to be slashed in the event of erroneous or malicious behavior, first-party oracles are putting their businesses’ reputation on the line in every point of data they provide. This reputation underpins first-party oracle’s on and off-chain revenue, and the chance of tarnishing it acts as a massive deterrent to malicious behavior.
The Coinbase oracle is a great example of a business leveraging their trustworthiness, especially as a company in the blockchain space where the health of the ecosystem is a further incentive against malicious behavior.
It’s worth pointing out that third party oracle solutions often implicitly trust their data sources. Using job specifications and adapters on the Chainlink network, users can select where their oracles will gather data from (though verifying that user selections are indeed the sources is another issue). This type of construction either assumes the trustworthiness of the data source, or that the responsibility of vetting sources falls to the developer.
First-party oracles on the other hand transparently allow developers to assess source reliability, and leverage the trust and reputation of API providers to ensure quality data.
Final thoughts and the next blog post
It’s the point of this post that if there is an API provider that is serving their data onto the blockchain by operating a first-party oracle, that third party oracles have no benefit.
This is not saying that first-party oracles are completely trustworthy, just that third-party solutions only abstract the issue and add new attack vectors. Additionally, we will address problems such as downtime and the quality of data provided by first-party oracles later in the series.
Next up, however, we’re going to look at what’s in the way of first-party oracle integration, why we don’t see more API providers doing it on their own, and how API3 is facilitating the changes needed to get more API providers into the blockchain space.
[Read on to part 4 in our series]
Note: some of the substance of this piece may be attributed to “First Party vs Third Party Oracles” as initially written by Sasa Milic for the API3 DAO in the API3 Medium publication directory (see this link).
