- Chainlink Mixicles enable the creation of privacy-preserving financial smart contract instruments by separating payment inputs from payment outputs using a mixer design with conditioned reports from blockchain oracles. Mixicles provide privacy of both the terms and outcomes of the agreement by keeping information off-chain, while also minimizing expensive cryptographic computation.
- Juels, A., Breidenbach, L., Coventry, A., Nazarov, S., Ellis, S., & Magauran, B. (2019, September 3). Mixicles: Simple Private Decentralized Finance. Retrieved from https://chain.link/mixicles.pdf
Core Research Question
- How can blockchain oracles enable the creation of privacy-preserving financial smart contracts on blockchain networks such as Ethereum without relying on expensive cryptography or complicated contract structures?
- Smart contracts are pieces of programmatic logic created by users that are hosted on a blockchain network. Every state change is initiated by a private key holder and is both executed and verified across every node in the blockchain network.
- Blockchain oracles are off-chain mechanisms that connect on-chain smart contracts to external resources such as data APIs that operate outside of the blockchain network. Such data (conditioned reports) is often required in the execution of automated smart contract applications.
- Decentralized Finance (DeFi) is an ecosystem of smart contract-based financial applications that seeks to increase transparency, facilitate fair economic access, and reduce counterparty risks through the use of decentralized blockchain networks and on-chain coded logic.
- Mixers (also known as tumblers) are tools used for improving the anonymity of cryptocurrencies by disconnecting payment inputs from payment outputs by “mixing” user deposited funds together, obscuring the originating address from which funds were sent.
- There is a large amount of value in the traditional economy waiting to migrate on-chain. However, there are currently two problems in the blockchain space preventing more sophisticated classes of financial agreements from being brought on-chain.
- The first problem is access to secure and reliable blockchain oracles required for smart contracts to access external resources like data feeds. Chainlink aims to solve this problem through its decentralized oracle network, providing data feeds such as the price of a specific stock which can be used to settle an options contract at expiry.
- The second problem is smart contract confidentiality as currently, smart contracts can leak critical business intelligence such as monetary amounts, instrument terms, and participating counterparties. Contract privacy is both a business and legal requirement for most traditional financial institutions in order to prevent front-running and/or undesired market movements.
- To overcome these issues, this paper introduces the concept of a “mixicle”, an oracle-enabled smart contract providing confidentiality for on-chain DeFi instruments. Mixicles operate similarly to traditional mixers, but they provide a few key differences.
- Mixicles are designed for the purpose of preserving privacy for financial instruments, not the concealment of cryptocurrency movements.
- Mixicles rely on oracle reports to determine payouts, rather than random shuffling.
- Mixicles are also amenable to audit and regulation, providing an opt-in compliance attribute.
- The design goals of Mixicles are simplicity and efficiency, in addition to compatibility with the existing Chainlink Network and its accountability features (ability to monitor and enforce correct oracle behavior). For this reason of simplicity, Mixicles avoids the usage of zero-knowledge proofs (ZKPs) and Trusted Execution Environments, opting for a conceptually simpler design.
- The paper focuses on the implementation of Mixicles for the Ethereum blockchain, but similar constructions work for both permissionless and permissioned blockchains such as Hyperledger Fabric, Tezos, NEO, Libra (Diem), etc. Additionally, the focus is on two-player mixicles, although the construct can be expanded to a larger number of contract participants.
- The traditional solution to smart contract privacy involves mixing, taking cryptocurrency payments from one set of users as input, and making payments to another (possibly overlapping) set of users as output. The key benefit of mixing is that it makes the correspondence between inputs and outputs private. Observers outside of the mixing process cannot tell who’s paid whom. The larger the amount of participants in this mixing process, the larger the anonymity set.
- In a generalized view, mixers (also known as tumblers) can be seen as a “payment switch whose internal operation is private.” In a tumbler, the switch is randomized, but in a mixicle the switch instead takes input from an oracle. This expands the functionality of a traditional mixer to support financial use cases such as bets (representing most financial agreements).
- As an example, a Mixicle can pay all funds it receives to one player, choosing this player based on the outcome of some predefined event x as reported by an oracle. In Figure 2, Alice and Bob are the two players, while P0 and P1 represent pseudonymous addresses with one owned by Alice and the other Bob. While these addresses are publicly known, which belongs to Alice and which belongs to Bob is unknown to outside parties.
- The switch, which determines if P0 or P1 receives the payment, is set by a blockchain oracle reporting on event x and can take the form of a Boolean value (concealing what the event was), where for example switch(x) = 0 pays all funds to P0 and switch(x) = 1 pays all funds to P1.
- If the event used was based on the price of a specific stock, then this binary Mixicle would be a financial instrument known as a binary option. This binary Mixicle not only provides confidentiality for the receiver’s identity but also makes private the nature and outcome of the underlying bet. The switch does not need to be binary but can support arbitrary switch logic.
- The paper covers the adversarial model and security requirements of Mixicles including the oracles, internal players, external players, as well as the overarching goals of a Mixicle including Confidentiality, Auditability, and Robustness.
- Confidentiality is provided through two primary components. The first is payment confidentiality which ensures privacy for the identities of the players to which payments are routed and privacy for the amounts involved in the underlying financial instrument. The second is query confidentiality which makes the switch and event x private for external players and even the oracle if additional trusted hardware like Town Crier or cryptography like DECO is used. Additionally, there is timing confidentiality by delaying results to prevent side-channel attacks which can reveal information about which event the switch was based upon.
- Auditability is provided through an immutable transaction record where a third party can verify claims about the terms, execution, and payouts of the Mixicle using on-chain ciphertexts that can be decrypted by a specific key holder such as an auditor, regulator, or law enforcement.
- Robustness is provided through three interrelated components provided by the Chainlink oracle network and its network of trusted, publicly known oracle nodes. The first is accountability where if an oracle behaves incorrectly, then any internal player can prove this non-compliance to an auditor. The second is collusion-resistance where no coalition including the oracle or any actor can defraud an internal player except by means of an auditable oracle failure. The third is denial of service resistance where if the oracle fails to provide timely Mixicle inputs, then players can still withdraw their funds.
- The first Mixicle construction is the “SIMI: Simple Mixicle” which is a basic but practical construction for a two player, binary option. The players each generate pseudonymous addresses and an associated bit for each, and then commit to the specification of the switch used, the time it is run, the payment amount that each will pay in, and a deadline for which the oracle must report. These terms are signed by all parties and sent to the oracle off-chain to be signed and returned. After these terms are on-chain and the off-chain event occurs, the oracle delivers the result to the contract in the form of a single bit, signifying who wins payment, where the true meaning of the bit is only known to the internal players. The smart contract then pays out the combination of both user deposits to the address associated with the oracle’s reported bit.
- While SIMI has desirable properties, it leaks the pay-in and pay-out amounts to external viewers. This leaks monetary amounts and the relative risk each player is taking on by comparing the difference in deposits. Another Mixicle construction to overcome this involves “SIMI-PS: Simple Mixicle with Payout Slates”. This is proved through the use of a payout slate, a sequence of pseudonymous addresses and payment amounts. Through using payout slates in combination with dummy payments, players in a mixicle can provide partial privacy for input amounts. Payout slates can be used to create granularity in payments where a single party has multiple pseudonymous addresses in their control.
- While SIMI-PS provides ideal privacy for a single financial contract, there may be situations where privacy is desired over a multitude of rounds, such as the same bet with the same parties taken multiple times in a row without leaking the results of any intermediary round. This is where “SIMI-PPS: Simple Mixicle with Private Payout Slates” are described. Players are able to engage in a sequence of financial-instrument executions, where funds are only withdrawn during the last round, enabling full private payouts in all non-terminal rounds.
- Robustness is added to SIMI-PPS through an oracle timeout where players can withdraw their funds if the oracle does not report within a given timeframe. Additionally, similar to state channels, Mixicles aims to move logic off-chain wherever possible, however to support oracle auditability, SIMI-PPS oracle reports are posted on-chain and hence unlike state channels can autonomously identify and arbitrate current state using on-chain data.
- The paper introduces Mixicles as a simple template for enabling privacy-preserving smart contracts through the use of blockchain oracles and provides a framework for the creation of a wide range of DeFi instruments that achieve confidentiality. By concealing the terms of a financial agreement, the data used to trigger its outcome, the monetary amounts involved, the per-user risks taken, the resulting movement of funds, and the identity of the receiver, smart contracts are able to keep sensitive contract properties hidden and expand the category of financial agreements that can be brought on-chain.
Discussion and Key Takeaways
- The primary takeaway from the construction of Chainlink Mixicles is that they provide an avenue for traditional institutions to adopt smart contract-based decentralized financial applications due to their ability to enable confidentiality of a contract’s terms, monetary amounts, and outcomes required for business and legal reasons, as well as support selective auditability for regulatory compliance. Together with DECO for TLS web session proofs, institutions are able to drastically reduce counterparty risks through non-custodial smart contracts, while retaining the privacy benefits provided by the centralized agreement structures of today.
Implications and Follow-ups
- Additional considerations in the construction of Mixicles include the importance of withdrawal confidentiality on Ethereum. Consider a Mixicle that generates a payout of ERC20 based stablecoins to a newly created Ethereum address. When the owner of that address wants to withdraw or interact with their stablecoins, they require Ether to pay for transaction fees. However, the challenge is sending Ether to this address without leaking any contextual information as to who owns that address. Various potential solutions for this include having the oracle’s transaction trigger a transfer of funds to a different output address/contract, utilizing meta-transactions to pay transaction fees in tokens to a relayer, prefunding an output account using another transaction-specific privacy mixer like Tornado.cash, or utilizing the PAYGAS opcode once implemented into Ethereum. More research can be pursued around this topic, particularly in the case of institutions engaging with multiple Mixicle based financial contracts.
- Next steps suggested in the paper include the creation of security proofs, integration with complementary technologies, harmonization with ISDA guidelines and documents, enhanced mixing, and the creation of even more DeFi instruments.
- Mixicles are particularly applicable in the Decentralized Finance ecosystem where the privacy of increasingly larger financial transactions becomes more important as institutions begin to utilize smart contracts within business processes with data confidentiality requirements. In particular, Mixicles are a practical solution for preventing transaction front-running by adversarial actors and other forms of Miner Extractable Value (MEV). Mixicles can provide confidentiality around the terms of the agreement and what conditions the contract executes upon to prevent adversarial trading.
- Mixicles can also be used in the creation of advanced derivatives contracts such as a futures contract on the closing price of TSLA at the end of day/week/month or an options contract on the volatility of a cryptocurrency such as Bitcoin given a specific timeframe. As a framework for financial privacy, Mixicles are purposefully generalizable to support the creation of any type of on-chain financial contract with confidentiality.