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.

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.