The Oracle Problem and Mixicles
As the evolution of distributed ledger technology continues, there remain key obstacles preventing its adoption and application to numerous fields. Among these is the difficulty of blockchains incorporating external data on-chain, given potentially conflicting or corrupt reporting from external sources. This so-called ‘oracle problem’ is especially prohibitive for certain enterprise and decentralized finance uses of blockchain, as external information is typically required to determine transaction parameters. The Mixicles protocol, developed by the team behind Chainlink, presents a privacy-based approach to the oracle problem intended for application to these sectors. The following report examines the so-called ‘oracle problem’ and evaluates Mixicles’ potential contributions to its solution. Overall, Mixicles appear to make oracles more applicable to certain user needs and likely more secure, though the use of private decentralized oracles raises additional questions about auditability tradeoffs.
The Use of Oracles Today
Oracles, in the context of blockchain technology, are information feeds by which off-chain data is incorporated into on-chain transactions. Blockchain oracles may provide a wide variety of information, such as market price feeds, football game scores or daily rainfall in a given city. Regardless, Oracles are necessary because distributed ledgers are deterministic, single data systems, inherently incapable of recording or considering any information other than transactions themselves: a concept referred to as the ‘oracle problem.’ Thus, smart contracts whose outcomes are contingent on the occurrence of real-world events must employ oracles as ‘triggers’ for the distribution of funds. Essentially, an oracle in this context acts as the final signee of a multi-signature smart contract, wherein the other parties sign the contract initially, and the oracle does so once all predefined conditions are met, finalizing the transaction. Because the smart contracts have no way of verifying whether oracle-provided data is actually accurate or not, it is critical that oracles are secure and reliable. At present, there exist three main approaches to the oracle problem:
- Centralized Services: Centralized oracle services are single entities trusted to deliver reliable data to smart contracts. Such entities do not include individual humans lacking clearly defined reporting procedures and often reliant on likely subjective ‘general knowledge,’ but rather standardized, native or application-based oracle services, such as Provable Things. Provable Things provides clients with algorithmically-governed information feeds along with a ‘Proof-of-Authenticity’ cryptographically ensuring the data has not been tampered with in-transit. Such services, even presuming honorable conduct, represent a central point of failure and feasible target for extortion.
- Whitelist Protocols: A hybrid of centralized and decentralized oracle services, these protocols rely on a preapproved set of ‘whitelisted’ algorithmic reporters to deliver data feeds. In MakerDAO’s oracle protocol, for example, a number of pseudonymous nodes and presumed-reputable organizations report pricing data, which is then aggregated through a ‘medianizer’ smart contract to produce a ‘trusted reference price.’
- Decentralized Networks: Decentralized oracle networks distribute crypto assets to incentivize reporters to participate in crowdsourced information feeds used by smart contracts. Many protocols, such as Augur, have such a process as a native feature, while other projects provide decentralized oracle reporting as a service; perhaps the most notable instantiation of the latter is Chainlink. At a high-level, a portion of nodes, acting as oracles, on the Chainlink network bid on and are matched with requests—accompanied by specific parameters—for data; their answers, based on predetermined sources of information, are then compiled via an ‘aggregating contract,’ which ultimately returns values for consideration by the requester’s smart contract.
The following graphic shows the usage of various oracle types by Smith + Crown’s ‘Signal’ projects. Platforms that host dApps utilizing oracles but have no direct involvement with oracles, such as Ethereum, are not considered to be using oracles; however, smart contract platforms that have, themselves, taken steps to integrate oracle systems into their protocols for the facilitation oracle use by dApps are included.
Figure 1. Oracle Use in S+C Signal Projects
How Do Mixicles Work
Mixicles are oracle-enabled, privacy-focused smart contracts designed for use as financial instruments in enterprise and decentralized financial endeavors. Like their name, Mixicles’ core functionality is derived from the concepts of ‘mixers’ and ‘oracles.’ At a high level, in the context of distributed ledger technology, ‘mixing’ is a transaction obfuscation process in which inputted funds are pooled and outputs are drawn from the pool, thus making private the correspondence between senders and receivers. Mixicles smart contracts embody and innovate upon the concept of mixers by:
- Adopting Payment Confidentiality: Borrowing from traditional mixers, payment-destination confidentiality features in Mixicles smart contracts pool funds and conceal receiver identities using pseudonymous bits to denote on-chain addresses. Through the generalization of pseudonymous payments and use of ‘dummy payments’ to ‘pad’ mixicles contracts, payment-amount confidentiality, obscuring the value of transactions, may also be achieved by Mixicles.
- Creating Query Confidentiality: Unlike traditional mixers, which rely on randomization to trigger outputs, Mixicle smart contracts distribute funds from the pool in a manner conditioned on oracle reports, sourced from the Chainlink network, better suiting them for use as traditional financial instruments. Mixicles primary innovation is its obfuscation of the external event on which the distribution of funds is predicated; the destination and timing of the oracles’ report will also be inaccessible to both internal and external parties. In publicly decorrelating oracles’ identities from their operations, this protocol effectively makes them unidentifiable based on the smart contract they are supporting.
Consider, for example, a Mixicle smart contract assuming the role of a standard binary option contract predicated on the price of gold exceeding $1,500 on November 31st. In this scenario, two traders will taking opposing positions and send the specified funds to the smart contract. On December 1st, a set of Chainlink oracles, unidentifiable and uncontactable by both internal and external players, will generate a price feed for gold and report it to the smart contract while concealing its contents from all other parties. At this point, funds held in the contract will be released to the winning trader’s address via a pseudonymous bit such that external observers may only see generally that the funds have left the pool but not know their destination or reason for distribution.
Such functionality intends to make Mixicles ideal for enterprise-based transactions, in which the concealment of crucial business intelligence and actions may be necessary. The exposure of details such as monetary values, contractual parameters and participating counterparties have the potential to elicit malicious and opportunistic actions from external parties. For instance, knowledge of the sector in which a given firm is investing may spur adversarial trading or inspire unexpected competition. Further, publicizing a significant position for or against an asset could result in undesirable market consequences, affecting asset prices and causing the trader to incur losses.
Perhaps most importantly, however, is that such a protocol has the potential to inhibit the corruption of oracles. Indeed, the true potential of Mixicles’ innovations lies in its application of a privacy-based approach to the blockchain oracle problem. While Chainlink has made substantial strides in achieving oracle robustness through decentralization, its oracles nonetheless remain susceptible to manipulation and extortion. Dispersion of dependency amongst numerous nodes has successfully prevented 51% attacks against vast networks such as Bitcoin and Ethereum, yet the same fortitude does not lend itself to scenarios in which a significantly smaller number of nodes are active, as is often the case with a given Chainlink query. That is to say, it is relatively feasible, should oracles’ identities be discoverable, to corrupt the majority of a set of a dozen nodes responding to one query, for example. Thus, as Mixicles’ de facto obfuscation of oracles’ identities hinders malicious actors from identifying and manipulating them at all, another layer of protection is added to the reporting protocol.
Moreover, concealment of payout amounts and destinations prevents malicious actors, potentially including the oracles, from even determining which contracts are profitable enough to even warrant exploitation or with which internal party collusion would be beneficial. Such reinforcements are unquestionably advantageous in enterprise and decentralized financial scenarios in which the potential profit from bribing or colluding with oracles may far exceed the presumptive cost of doing so.
Finally, another issue contributing to the oracle problem and addressed by Mixicles is that of ‘oracle freeloading.’ This refers to the reuse by oracles of existing data feeds already placed on-chain by previous oracles. Such a cycle creates a web of complex dependencies that becomes exponentially less reliable with each instance of reproduction. Obfuscating queries theoretically renders the data they elicit irreproducible; while this does not contribute to the security of individual Mixicles contract, themselves, the proliferation of query confidentiality may ultimately limit the feasibility of oracle freeloading in general.
Real Benefits from Mixicles, Yet Tradeoffs in Auditability
This report finds that there are broadly three ways Mixicles could contribute to solving issues in smart-contract oracle integration:
- Information about business strategy and trade intentions, revealed through smart contract parameters, can expose users, especially enterprises, to risks. By obfuscating the external event precipitating contract distribution, as well as oracle reporting timing, Mixicles can mitigate these risks, making oracle-integrated smart contracts more attractive to those affected.
- Mixicles reduce available vectors for oracle corruption by obscuring oracle identities and payment amounts. A general practice of Mixicle use could improves Chainlink’s oracle network’s overall security.
- To the extent that Mixicles obfuscation of queries renders their data irreproducible, use of Mixicles make oracle freeloading less feasible. Since freeloading can render data unreliable and undermines the economic incentives in providing oracle services, it should be discouraged.
Despite these advantages, it should be acknowledged that Mixicles approach to improving smart contract oracle integration makes important trade-offs on a blockchain’s auditability. Knowing where oracle data is coming from and going to would be essential, for example, to understand and autopsy an oracle failure. Moreover, many finance applications would likely require by law some degree of oversight and transparency. Though unlikely to completely satisfy regulators, Mixicles attempts to address these concerns by allowing authorities to audit transactions, when deemed appropriate, through permissioned decryption of its smart contracts, though this introduces further potential questions about the role of ChainLink in preserving the privacy of Mixicles. Further, the complexities of the transaction obfuscation process all but promises to hinder ease of use to some extent—after all, launching a privacy-securing variant of a smart contract used to facilitate a decentralized market for oracles is not simple. However, in many emerging technology sectors, functionality precedes ease of use. In these regards, Mixicles brings a seemingly thoughtful, albeit imperfect, approach to complex and conflicting demands.