Enigma enables data privacy for Ethereum contracts. This means the inputs and outputs to contracts can be kept secret from the network throughout a computation. However, Enigma can also be used to enable transactional privacy: the ability to hide the transaction history of addresses. The need for transactional privacy on Ethereum is well-documented, with recent efforts to produce solutions such as Tornado.Cash and Semaphore emerging after a call-to-action from Vitalik Buterin and others.
Salad is a prototype of a coin-mixer built using Enigma’s data privacy and randomness generation. We think Salad is notable for a few reasons, particularly usability and cost.
In this blog post, we’ll first take a close look at what exactly coin mixing is, how it works, and why it is beneficial for users. Then we’ll describe a coin-mixer built with Enigma — a layer-2 network for computational privacy — and compare it to alternative solutions that are built using zero-knowledge proofs.
An Introduction to Coin Mixing
As you probably know, transactions on Ethereum are public, and this creates public links between addresses. For example, if you use an address to play an on-chain game, to provide collateral for a collateralized debt position (CDP), and to pay your friend for drinks, all these transactions are visible to anyone observing the network. This can de-anonymize you, reveal sensitive information, and make you a target for hackers. While Ethereum addresses are pseudonymous, it is very easy to accidentally compromise your identity. However, it is possible to obfuscate the history of your tokens in Ethereum using coin mixing.
In a coin-mix, a group of people combine their coins into one pot (deposit contract). Then, the pot pays out these coins to ‘fresh’ recipient addresses — addresses that have never been used before. This cuts the linkage between past and future transactions, improving transactional privacy.
There are several concepts you should be familiar with to get up to speed with coin mixing:
- Anonymity set: This is how many people participate in a “mix”. The higher the number, the more difficult for an observer to link a receiver address with a deposit address.
- Fixed-amount deposits: most mixers require you to deposit a fixed amount — i.e, 1 eth, or 0.1 eth. Otherwise, you could be traced more easily (for example, a deposit of 6.434343 goes in, and the same goes to a recipient address — that’s likely the same user).
- Intersection attack: This is the use of timing information, information about deposit size, or other metadata around a mix to de-anonymize the users. It is a primary concern when designing a safe mixer, and is the motivation behind constraints on deposit size, anonymity sets, and deposit timing.
- Sybil attack: A counter-party takes up all or most of the available “spots” in the pool. That way, they know that any address they don’t control belongs to other users, thus effectively reducing the anonymity set. This is why some mixers keep the anonymity set secret, or introduce time thresholds.
- Proofs / Deposit Notes: in mixers that use zero-knowledge proofs, such as implementations of Semaphore or Tornado.cash, users must submit a “proof” when they initiate a deposit. This is a feature of how zk-proofs work.
- Relayer: a relayer receives signed messages and executes transactions on behalf of users. In our network, the relayer abstracts some user interactions and streamlines the mix process. In other solutions, the relayer is responsible for paying gas fees for the withdrawal.
Salad is composed of three main components:
- A deposit contract on Ethereum which holds funds to be mixed.
- A secret contract on Enigma, which randomizes receipt addresses.
- A relayer/operator who is responsible for coordinating deposits and batching transactions.
1. Starting the Salad Contract
- On deployment, the secret contract generates a static keypair created by the constructor.
- To accomplish this, we included a cryptographic library within the secret contract. This keypair generation is executed inside the enclave, and the private key is known only to the contract.
- Users need to access the encryption public key for the contract in order to encrypt their recipient addresses. The relayer calls the secret contract, gets the key, stores this in the cache and sends it to the user. The key is verified by the signature of the worker who generated it.
2. Users Submit Transactions
- Users specify their recipient address
- Users select the amount of tokens they want to mix (currently fixed at 0.1 ETH) and send this amount to the deposit contract on Ethereum.
- Users locally encrypt their recipient address using the encryption public key.
- Users send their encrypted recipient address and deal metadata to the relayer.
3. Relayer Submits Deal to Enigma
- The relayer receives signed messages from the users.
- The relayer checks the user’s deposit amount against the amount they have in the Ethereum deposit contract.
- When a quorum of participants has been reached and enough time has elapsed, the relayer creates and submits a new deal (containing encrypted recipient addresses and other metadata) to the secret contract on Enigma.
4. Enigma Secret Contract Shuffles and Returns Recipient Addresses
- The Enigma secret contract receives and decrypts all the recipient addresses.
- The secret contract uses the Enigma randomness service to shuffle all the recipient addresses.
- The Ethereum deposit contract “disbursement” function is called with a list of shuffled, plaintext recipient addresses.
| Salad is open-source. Check out the code or run the demo locally.
Salad vs. ZKP: Usability and Cost
We’re excited to see all the work being done on Zero-Knowledge Proof (ZKP) mixers, such as Tornado.cash and Semaphore. We want to emphasize that we support the work these projects are doing to bring privacy to Ethereum, and their open research and discussion has greatly aided us in the process of developing an Enigma-based mixing solution. We think there’s room for a variety of implementations, with each having relative advantages. Salad has a few essential differences to ZKP solutions, primarily that there is no need for a “withdrawal” interaction, and that our mix takes advantage of private compute on the Enigma network as opposed to zero-knowledge cryptography.
While we don’t have final numbers on this yet, we do know that ZK-proofs are expensive. Currently, we anticipate a mix on Enigma to cost significantly less than other ZKP-based solutions in production (which cost about 900,000–2 million gas). The lowest we’ve seen in testing is 1.1 million gas. That said, we know an upcoming hard fork on Ethereum stands to reduce this gas cost (possibly to as low as 300,000). We anticipate a 10-participant mix on Enigma to cost ~250,000 gas (for scale, this is about the same as a Kyber Swap transaction).
The primary usability advantage of Salad is that it is non-interactive, requiring only one interaction per user. Usability is extremely important for mixers, where privacy guarantees grow stronger when there are more participants and participation is more frequent. It’s also important for Ethereum — if mixers are expensive, cumbersome, or put a large burden for security on the user, it will hinder adoption of this privacy-enhancing technique.
Other solutions we’ve analyzed, such as MicroMix (a Semaphore implementation) currently ask users to leave a browser window open while the deal executes. The reason for this design choice is to make it more difficult for an observer to perform an intersection attack, where they identify connections between deposit and recipient accounts based on timing information. While our implementation does not yet have time limits or time thresholds, because all deal information is submitted up-front, users can easily specify deal metadata (such as being included in x-number of deals from the current deal) without any further interactions or data stored in the browser.
Tornado.Cash, another Ethereum mixer, requires users to securely store a secret note which they will be required to submit when they wish to withdraw their funds.
ZK-Proof based solutions will always require a withdrawal transaction, while Enigma mixer transactions can be set in motion without requiring a second withdrawal transaction from the user.
As mentioned previously, while we don’t have features like a time-threshold currently implemented, this architectural difference (no user-initiated withdrawal transaction) can enable us to make more complex deal parameters around anonymity sets and deposit pooling all part of the task metadata submitted up-front with the deal.
Because of this, we expect third-party integrations with Salad to be straightforward, as deal information is submitted in a standardized task format. This means individual apps have more latitude to create an interface that works easily in their application, such as an exchange specifying standard mix practices for every withdrawal. Our goal will be to make it very easy to integrate this type of mixer-based anonymity into a wallet, voting, or other application where transactional privacy is desired.
We want to make several improvements, as mentioned above in the article, such as how users access the public key from the secret contract, and deal parameters that mitigate intersection attacks.
We also want to bring this prototype to market, and are excited about working on an integration. If you’d like to work with us on this, learn more about the prototype, or think it could be a good integration for your application, please reach out!
This article was originally posted here: https://blog.enigma.co/salad-coin-mixing-with-enigma