Social encounters

Event recap of August 19, 2019, Web3 Stack Meetup during Berlin Blockchain Week, with technical presentations from bloXroute, NEAR, Elixxir, and Enigma.

Enigma enables data privacy for Ethereum contracts. This means the inputs and outputs to contracts can be kept the 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. Salad is notable for a few reasons, particularly usability and cost.

In this blog post, the author, Ainsley Sutherland, will first take a close look at what exactly coin mixing is, how it works, and why it is beneficial for users. Then she will 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 combines 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 the network, the relayer abstracts some user interactions and streamlines the mixing process. In other solutions, the relayer is responsible for paying gas fees for the withdrawal.

Salad

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 key pair created by the constructor.

To accomplish this, a cryptographic is included 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 number 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 addresses 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.