Research Summary - Mixicles: Simple Private Decentralized Finance

TL;DR

  • 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.

Citation

  • 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

Link

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?

Background

  • 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.

Summary

  • 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.

Method

  • 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.

Results

  • 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.

Applicability

  • 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.
3 Likes

Zach, thanks for such a thorough and thoughtful summary of this paper. I expect I’ll continue referring to it in the future.

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.

I expect a near term usecase in something like the Baseline Protocol makes a lot of sense, but I’m having a failure of imagination to picture other near term uses.

What are some platforms you see could immediately benefit from the capabilities provided by Mixicles? @Larry_Bates, @tjd233 or @tina1998612 what do you think?

3 Likes

It may be a little off-topic, but after I saw the Tornado cash platform, I think a novel way to trace the linkage between ethereum addresses is to monitor and cluster the newly created addresses. XD

1 Like

@Eric can you elaborate on how the baseline protocol can make use of this?

1 Like

Its my understanding that the Baseline Protocol allows for secure messaging, storage of contracts, inventory syncing, etc. Mixicles could potentially be plugged in to this solution as a method of making private payments between parties that depend on external data.

1 Like

So in terms of specific platform examples, I don’t necessarily have one. However, at an industry level application, I think the insurance industry could be another avenue of implementation. This paper focuses mainly on DeFi applications, which sounds great, but a lot of similarities can be found between the traditional insurance industry and the theorized benefits this would have to DeFi. For example, the privacy of payments, confidential contract terms, the monetary value of goods insured, etc, are all things that would be very similar to the examples given in the paper regarding DeFi.

Furthermore, the ability to enact private/confidential smart contracts while still being relatively audit-friendly has the potential to bring more transparency to the insurance industry without putting clients’ information at risk. This, to me, is a big takeaway. In the US the public generally has very low approval ratings of the insurance industry. The possibility of increasing transparency within the industry without risking the private info of customers by using smart contracts utilizing Mixicles is something I could potentially see happening.

3 Likes

I think insurance would be a great use case for Mixicles, especially with the ability to ‘roll over’ into new rounds to enable perpetual cover. I think insurance is really a subset of DeFi, but an ideal product market fit here regarding the need for privacy regarding what is being insured. An Insurance Mixicle can even be set up in a way where the terms of the insurance agreement is kept private upon creation to prevent manipulation keeping the conditions of payout private, and only reveal the terms if and when a payout occurs. The entire process can be kept private as well of course, which is ideal for most users, but the ability to only reveal publicly what the terms were retroactively is a powerful financial primitive in my opinion. This would provide privacy during the contract’s lifetime and transparency after the fact.

3 Likes

@Zach, that was my thinking as well. How I see it being used would something like the following:

Insurance company Z deposits money (M) into a fund connected to a general smart contract (SC). SC is then connected through a Mixicile to a series of other insurance smart contracts (ISCs) held by clients. Company Z can make public the general equations and terms they use to price both payout (Y) and insuring cost (X), however, due to the privacy company Z is implementing using Mixicles and smart contracts no individual ISC is ever made public. If a triggering event occurs, say a flood and all of the ISCs cover flood insurance, then the SC triggers the individual payouts (Ys) of the ISCs using the deposited money M.

In this way, all payments are made quickly, automatically, and privately, but are also more transparent as the insuring company Z has shown how their payments work without jeopardizing personal information. Also, this allows for the tracking of payments and ensuring they are paid properly and fairly due to the ability to retroactively look at details in contracts if needed. Finally, this could remove one of the most contentious issues between the public and insurers: the timeliness of payments.

2 Likes

Thanks for your response @Eric. Another application that benefits from private payment is a decentralized credit card system. Both merchants and customers would like the payment information to be confidential but also verifiable. Currently this is achieved by centralized means, but certainly possible with Mixicles.

2 Likes