As described in the academic paper “Mixicles: Simple Private Decentralized Finance”, Mixicles “use oracles to build simple, privacy-preserving decentralized finance (DeFi) instruments.” Given the complexity of the research paper, we broke down core Mixicles concepts so that the wider DLT community can grasp the underlying mechanisms at play, as well as the profound applications Mixicles open up for enterprise adoption of Decentralized Finance (DeFi).
An Overview of DeFi and its Current Limitations
DeFi has become one of the fastest-growing fields for smart contracts running on public blockchains. According to DeFi Pulse, there are currently around $500M locked up in DeFi protocols running on the Ethereum blockchain in popular Dapps such as MakerDAO, Compound, and Synthetix. DeFi products are built using decentralized infrastructure (blockchains and smart contracts) and allow users from all over the world to lend, borrow, make bets, and generate interest on their assets without a central party facilitator.
While the public nature of blockchains like Ethereum may be acceptable to retail investors, their lack of transaction privacy severely limits their usability for enterprise applications. Enterprises not only require concealment of their internal trading strategies and positions, but they also in many cases are mandated by the law to keep that data private. For example, one of the primary reasons for legally-mandated privacy in financial contracts is to prevent frontrunning — the prohibited practice of entering into a financial trade (option, futures contract, derivative, swap, etc.) to capitalize on the advance, nonpublic knowledge of a large pending transaction. Since public blockchains currently lack the necessary privacy features required for enterprise usage, private/permissioned blockchains have emerged to fill the void with privacy as their central selling point.
Through the use of oracles, Mixicles bring privacy at scale to DeFi instruments on public blockchains. By introducing privacy, public blockchains like Ethereum become substantially more attractive to enterprises because the legal hurdles surrounding data privacy are eliminated in both a cost-effective and scalable manner. Mixicles provide Ethereum with the critical privacy feature it needs to compete with private blockchains and inevitably win over enterprise clients.
Introducing Oracles and Mixers
An oracle is a digital agent employed by a smart contract to retrieve and/or connect it to data and systems outside its native blockchain (off-chain). Oracles enable this off-chain connectivity for the smart contract by reformatting external connection points (APIs) so that two different software applications are compatible for data exchange. The oracles can then pull data into the smart contract and/or push data out based on predefined instructions and endpoints outlined in the Service Level Agreement (SLA).
Chainlink is a decentralized oracle network that gives smart contracts secure and reliable access to data providers, web APIs, enterprise systems, cloud providers, IoT devices, payment systems, other blockchains and much more. It has the following features:
- A robust market of independent oracles providing a range of data and connections
- Flexibility to customize an oracle connection including the number of oracles, types and number of data sources, aggregation strategies, staking deposits, trusted execution environments, Mixicles and more
- A reputation framework for evaluating oracles based on on-chain metrics
It’s an all-in-one network for users to customize how their contract communicates with anything off-chain using varying levels of decentralization, data aggregation, and oracle selection.
A mixer (also referred to as a tumbler) is software that “takes payments from one set of users as input, and makes payments to another (possibly overlapping) set of users as output.” The basic premise is that all users of the tumbler send their payment inputs (their stake in the bet) to the same address, which represents a pool of all inputs. The tumbler then draws on this pool of assets to make payment outputs to users.
In most mixer models, users provide new, never-before-used addresses to the tumbler which then randomizes payments to these addresses. By using a shared address for payment inputs, randomizing payment amounts/timing, and deploying new output addresses unattached to input identities, outside observers of the blockchain have no way of correlating the origin of a transaction on the network (input) with the current location post-tumbler (output).
Combining the Two into a Mixicle
All oracle-enabled smart contracts use data inputs to trigger contract execution (state change) that produces settlement outputs. For example, a derivatives contract takes in market data (input) about the price of an asset and pays out (output) the winners based on the terms (coded logic) of the contract. Chainlink offers a marketplace of oracles that mine inputs and outputs for smart contracts.
Most smart contracts today produce state changes on-chain, which makes it easy for public observers to see and correlate the input and output of a contract. However, Mixicles redefine smart contracts by splitting them into two parts where the state change is separated from the payment output. These two components are divided into off-chain and on-chain components and are not connected in any way the public can correlate together. The interlinking components that brings the two together, while maintaining privacy, are the oracles.
- Off-chain component - a smart contract that represents a service level agreement outlining payment to the oracles for retrieving specific data and using it to compute the correct state change
- On-chain component - a separate smart contract that specifies how the tumbler will pay out parties based on an input from the oracles
The querying smart contract requests an oracle or set of oracles to obtain some piece of data (most likely market data) that will be used to determine the outcome of a DeFi contract. The details of the query are agreed to off-chain and therefore not publicly viewable to on-chain observers. Instead of returning a raw piece of data, such as the actual price of the asset, the oracle(s) returns a report (oracle report) that becomes the basis of a true (1) or false (0) determination of the data. Below are various examples of binary contracts that can return 1 or 0 answers.
The oracle report (x) in a Mixicle determines the payment switch (state change), which is a separate smart contract containing terms that outline how payments are to be distributed to participants based on the oracle report. In the example of a binary option below, there are two possible outcomes of the switch (0 or 1), which represent two different payment routes (payout slates) to settle the contract. Please note that more complex switches that go beyond simple binary options are possible.
In the example above, P0 and P1 represent new, secret addresses owned by Alice and Bob; only they know who owns which address. As we can see, both outcomes of the switch represent different payout slates, but for the exact same payment amount.
Let’s introduce another example that shows how payments can be concealed even more by deploying more addresses and using partial payments.
Finally, let’s look at one last example of how we can obfuscate the timing of payments by conducting many rounds of input payments. With this technique, it becomes even more difficult to know how much a particular contract is worth and the amount of the payout.
As noted in the three examples above, Mixicles offer higher levels of privacy depending on the selection of tools used to obscure inputs and outputs. Users can use a simpler tumbler, employ numerous anonymous addresses, make partial payments, and obfuscate the timing through multiple rounds. Something important to note is that the number of payouts is the exact same for both outcomes of the switch, making it hard for an outside observer to differentiate.
To recap, the two parties deploy a smart contract that pays an oracle to retrieve a piece of web data and make a True/False determination of it (1 or 0). The oracle(s) then relays its report as an input to a separate smart contract that triggers the payment switch. The payout schedule, which was outlined and agreed to beforehand by both parties, is executed based on the switch input it receives. The oracle(s) receives payment for its services pending successful and on-time completion of its defined service. The contract becomes void if the oracle goes offline or fails to respond in time, allowing all parties to withdraw their initial funding from the Mixicle.
The more users involved in a Mixicle, the easier it is to conceal the inputs and outputs of contracts, given there is more money flowing in and out of the pool of assets. This is especially enticing for an extremely large market such as derivatives, where the notional value is estimated to be between $500 trillion to $1.2 quadrillion.
Mixicles are also regulatory compliant because they give users the option to make the oracle report auditable by third parties, which can be compared with the switch provided by the audited entities participating in the smart contract. Constructing DeFi applications that work within the current legal framework is an essential feature for enterprises that operate in highly regulated environments.
Opening Up DeFi to Enterprises Adoption
By separating state changes from payment outcomes and using oracles to pass data confidentially between them, DeFi instruments on public blockchains become far more attractive to highly regulated enterprises with large capital allocations. In fact, DeFi instruments are a drop in the bucket compared to the potential capital sitting in traditional financial vehicles. With many scalability solutions in the pipeline, Chainlink is using oracles to solve the other two major problems inhibiting the development of enterprise smart contracts in finance on public blockchains: connectivity and privacy with audibility.