Issues with Third-Party Oracles as Middlemen
Last updated
Last updated
Existing solutions envision an abstract problem where an arbitrary system needs to be able to interoperate with another arbitrary system through their technical interfaces in a very general sense. This over-generality necessitates an ever-flexible interface that can only be supported by third-party oracles. However, this solution is not optimal because the practical scope of the problem is far more constrained. In most cases, the decentralized interoperability problem is actually the problem of receiving services from traditional API providers in a decentralized way. This more limited definition of the problem allows for optimal solutions that do not require a third-party intermediate layer on the interface path.
Vulnerability
A decentralized oracle network uses an aggregation function to reduce the oracle reports into a single answer. This function is essentially a consensus algorithm, and as all consensus algorithms, it is susceptible against a certain ratio of dishonest ac- tors. This means that a group of malicious oracles can collude to skew the outcome,and even control it completely. In addition, a single actor can fabricate multiple oracle node operator identities—as well as build a sufficient track record of honest operation—to perform the same types of attacks entirely by themselves, which is known as a Sybil attack. The most critical downside of having an additional layer of parties on the interface path is the formation of entirely new attack surfaces. This means that each added layer of middlemen would be able to execute the collusion and Sybil attacks de- scribed above independently. Then, in terms of security, the ultimate solution is the complete removal of the middlemen.
Middleman tax
An oracle plays a game where they can report honestly or misreport (which includes denying service). Reporting honestly has only an incremental payoff, but allows the oracle to continue playing the game. On the other hand, misreporting has a one-time payoff proportional to the value secured by the contracts depending on the report, yet results in the game ending. Then, the maximum cumulative payoff the oracle can receive starting from transaction ti is
P [i] = max (xi, vi + P [i + 1]).
A rational oracle will eventually misreport if the amount it can gain from an attack outweighs the potential gains it can make if it did not perform the attack. That is, if the following holds for a given rational oracle, it will eventually misreport:
∃i ∈ N, xi > vi + P [i + 1] .
This indicates that the potential benefit an oracle will gain from acting honestly must exceed the amount that can be gained from misreporting at all times to avoid any misreporting. Although one can approximate v with the amount paid to the oracle per-request and x with the amount that is secured by the oracle’s response, this would underestimate the risk because there are additional factors that incline oracles towards misreporting, some of which are given below:
• According to the time preference theory, the oracle node operator will value future rewards less (i.e., vi decays with increasing i).
• In practice, the oracle acting honestly does not guarantee the game to continue and this risk further lessens the value of future rewards.
• There may be additional benefits to performing an attack that are unaccounted for, e.g., opening a short position on an asset that will depreciate with the oracle solution’s failure.
Due to this uncertainty, one needs to overestimate the required vi, i.e., overpay the oracle for it to not attack.
This model can be extended to decentralized oracle networks. Since the oracle reports or their artifacts are recorded on-chain, it is trivial to implement a smart contract that will reward colluding oracles trustlessly. This means that a third-party that is able to profit from an attack can employ oracles with the guarantee that they will be paid a deterministic amount if they collude.
At a high-level, an oracle’s job is essentially:
(1) to listen for on-chain requests,
(2) to make the respective off-chain API calls,
and (3) to write the response back on-chain. Therefore, a third-party oracle is fundamentally a middleman. Although the service provided is as minimal as possible, these middlemen have to be paid proportionally to the amount being secured by the data feed due to the reasons described above, which is especially problematic for high-value use cases such as DeFi. We call this phenomenon the “middleman tax”, which can be eliminated completely by avoiding third-party oracles, resulting in very significant cost savings for users.
Ineffective redundancy
Data feeds depending on third-party oracles require over-redundancy at the oracle level. This is because third-party oracles are far less trustworthy than API providers, the latter having a traditional off-chain business and respective reputation to maintain. Typically, each API provider is served by 2–3 oracles in such a data feed. Note that this decentralization does not provide additional security at the data source level, but only decreases the additional vulnerability caused by using third-party oracles. Unfortunately, this results in the operation costs being multiplied on many levels. For example, the data feed essentially employs all the technical personnel that operate the oracle nodes, and having more of these nodes means supporting more people. Furthermore, using more oracles results in a direct increase in gas costs. Specifically, oracle request–response gas costs increase linearly with the number of oracles, while the gas costs of aggregation functions that do combinational operations (e.g., median) increase superlinearly.
Lack of transparency
Decentralization at the API level and decentralization at the oracle level are in- dependent of one another—the overall system is only as decentralized as the more centralized of the two, i.e., the weakest link. However, the general public and even the users of decentralized oracle networks overlook this fact and confuse decentral- ization at the oracle level with the overall decentralization of the system. This is primarily caused by a lack of transparency regarding the data sources used by the oracles, which disguises the fact that decentralization is severely bottlenecked at the data source (API) level.
Data feeds composed of third-party oracles appear more decentralized than they actually are. In addition, when the data feeds are not transparent in the source of their data, developers cannot appraise data feed integrity and have to trust the governing entity. However, there is no immediate incentive for the governing entity to choose quality over lower prices and convenience if the data sources are not transparent, which may result in the outcome commonly referred to as “garbage in, garbage out”.
Interestingly, what is a favorable tactic for the governing entity—namely, obscur- ing the data source—is very much necessary for the third-party oracle. Most API terms of service prohibit the resale or unauthorized distribution of the API data, which positions an oracle node operator serving such APIs to be in breach of those terms and susceptible to broad sources of legal liability including claims by the API provider. This issue is exacerbated by the API call times, responses, and pay-ments all being recorded on a public blockchain. This not only puts individual node operators at litigation risk, but also creates a systemic risk for the whole oracle network, as coordinated legal action at scale would put existing third-party oracles out of operation immediately and discourage new ones from joining.
Note that although lack of transparency and abstraction of data sources is the norm, it is not at all a necessity. Especially when the API provider and ecosystem incentives are aligned, it is perfectly possible for oracles to serve API data to users with the express consent of the API provider, allowing the oracles to disclose their data sources to their users. It is in the interest of the API providers to do this, as it increases on-chain demand for their data.
