Reconsidering Oracle Decentralization

  • Commentary
  • May 31, 2020

Last October, the Smith + Crown research team published a report on blockchain oracles and the merit of pseudonymizing decentralized oracle networks. Building on recent commentary from OracleSwap’s Eric Falkenstein, this dispatch revisits issues of oracle obfuscation and decentralization with a new emphasis on efficiency and necessity thereof.

Decentralization drives both the sentiment and technical architecture supporting blockchain networks. From a desire to redistribute the otherwise unilateral power of central banks over their respective currencies came the first cryptonetworks, governed by individual nodes’ collective decisions regarding which software updates to adopt. In the years since, decentralization, enabling actions such as hard forks and chain-orphaning, has proved adept in securing these early networks. Perhaps for reason of this success, there remains a widespread outlook that, as networks and dApps evolve, new innovations in distributed networks must rely on decentralization themselves. This notion that a DLT-system’s characteristics must be mirrored by all components thereof is perhaps most readily apparent in blockchain oracle technology, widely employed by and often existential attack vectors for decentralized financial applications.

Hence, oracle systems such as those of Chainlink and Augur have attempted to emulate the robustness of the networks on which they operate through similar decentralization. However, as Falkenstein argues in a piece entitled “Decentralized Networks Need Centralized Oracles,” decentralization does not inherently add significant value to oracles serving decentralization financial applications and is, in certain cases, a hindrance thereto. In Chainlink, for example, nodes addressing a given query may total in the low-double digits; while more robust than a single oracle, perhaps, it’s disproportionately more feasible to corrupt a dozen nodes than it would be to corrupt Bitcoin’s roughly five thousand nodes. Further, oracle networks do not enjoy protection provided by the threat of a hard fork, nor are attacks against oracle networks self-defeating like those against PoW blockchains. Echoing assertions made in last year’s “The Oracle Problem and Mixicles” report, Smith + Crown maintains that some degree of node pseudonymity and/or obfuscation may limit the potential for corruption in networks or sub-networks unable to achieve meaningful decentralization.

Alternatively, there exist cases in which decentralization establishes an unnecessarily excessive level of security at the expense of efficiency. Take the first instantiation of the Augur protocol, for example. To resolve a given prediction market, all REP holders may participate in reporting outcomes as decentralized oracles, a process which may take upwards of a week to complete. While thus far uncorrupted—by way of oracle fraud, at least—this level of robustness secures only a small number of prediction markets often with trading volumes of less than five ETH. Further inefficient is the cost structure of such systems; that is, an oracle networks whose efficacy—a function of the resources contributed thereto—depends on the value of its native cryptoasset often imposes costs outweighing demonstrable benefits.

Thus, Falkenstein argues that pseudonymous, centralized oracles are more appropriately applied to projects in the DeFi space. Such unilateral mechanisms are undoubtedly more efficient than their decentralized counterparts described above, both in terms of cost and time. Pseudonymization, he posits, will achieve a minimum threshold of security required by most DeFi applications without expending resources beyond the point of diminishing returns.

While Smith + Crown agrees that decentralization is not a mandate for oracles in a larger decentralized system, the team feels individual cryptosystems pose unique challenges and offer unique value, such that a too rigid mandate for use of pseudonymous, centralized oracles proves inappropriate to particular use cases. For example, a pseudonymizing a single oracle reporting weather conditions for insurance contracts will limit its susceptibility to external corruption but leave open the possibility of the employed oracle acting maliciously and, thus, would not be a viable component in systems in which an oracle’s potential to profit from corruption is high; instead, small-scale decentralization alongside pseudonymity would necessarily place internal checks on the oracles themselves while maintaining an acceptable level of inefficiency. In other DeFi applications, pseudonymity may not be legally or logically possible where auditing is required. Ultimately, oracle design, including matters of decentralization and obfuscation, must be performed on an network-by-network basis, as the technological merits of any mechanism are only efficacious to the extent that its strategic placement within a larger system allows.