Salad

Salad is composed of three main components:

A deposit contract on Ethereum which holds funds to be mixed.

which holds funds to be mixed. A secret contract on Enigma , which randomizes receipt addresses.

, which randomizes receipt addresses. A relayer/operator who is responsible for coordinating deposits and batching transactions.

High-level data flow for Salad

1. Starting the Salad Contract

On deployment, the secret contract generates a static keypair created by the constructor.

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.

receives signed messages from the users. The relayer checks the user’s deposit amount against the amount they have in the Ethereum deposit contract.

checks the user’s deposit amount against the amount they have in the 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.

receives and decrypts all the recipient addresses. The secret contract uses the Enigma randomness service to shuffle all the recipient addresses.

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.

Cost

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

Usability

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.

MicroMix suggests users leave a browser window open for 9+ hours

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.

The private note (proof) that must be submitted when a user wishes to withdraw (image from Tornado.cash)

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.

Next Steps

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!