Salad in Enigma blockchain

[cankisagun]

• Discuss randomness in the new chain (pros / cons of a master randomness node, can using an oracle be an option)
• Salad architecture
• Understand deposit and message sending to a CosmWasm smart contract (dependency on Issue X)

This issue links to issue #27

[guyz]

Cross-posting from Slack: I thought about the randomness issue again, and it MIGHT be secure for Salad (and might not be - I just can't think of an attack), but I'm fairly convinced it's not secure for things like gaming, auctions, etc..
Here's the reasoning - the issue is generally that the pseudo-randomness is defined as random_number := KDF(random_seed, tx_hash) [KDF is similar to a hash]. So basically, given the same transaction you'd get the same randomness.
The problem is that if I have an enclave and I can manipulate the transaction somehow, I can look for a transaction that would lead to a tx_hash that benefits me. For example, say it's a lottery app where each user sends a tx with a specific number, and one of those numbers is chosen at 'random' and pays out a reward. Obviously, if I'm the last player sending a tx, I would iterate through many numbers (and would simulate the result using my own enclave), until I find a tx that gives me the payout. This is similar to why generating randomness from several users requires a commit-reveal scheme, otherwise the last player can manipulate the beacon to their benefit.
Now to Salad - In Salad, all you get in the output is the permuted list of addresses. There's is no notion of that being beneficial to an attacker, and since they still don't really learn the randomness used, they can't break anonymity. There's also no attack on funds et al. So, I might be wrong, which is still a good reason to use proper randomness, but for Salad specifically this may be fine/secure.

[reuvenpo]

@guyz Wouldn't This allow a user to manipulate the randomness so that recipients[n] == mixed_recipients[n] for some n they care about (as in, that a specific index in the original list of recipients would remain in the same index in the mixed result)? That way they could compromise at least one tx that they care about.

[ainsleys]

Data flow for Salad so we can surface some questions:

1. Users 1-10 send 10 SCRT and an encrypted(recipient_address) to a secret contract.
2. Every 24 hours, the secret contract will "mix" the funds. This requires someone to call the mix() function (a relayer? a user?). How will we measure 24h and prevent mix() from being called prior?
3. The mix() function results in a list of 10 addresses. mix() should call distribute() with these addresses. Are they in plaintext? Who pays for distribute()?
4. distribute() sends 10 SCRT to each address, respectively

[cankisagun]

Capturing conversation on slack:

Background: Salad mixer contract requires a participation quorum and elapsed_time (# of blocks) to execute the mix. Every time t, the contract is expected to try the mix assuming the participation quorum is met. If it's not, at t= 2t the contract will try to mix again.

Currently Salad contract cannot initiate the mix unless it's been triggered by another party external to the contract (can be users or an operator model). The external contract needs to provide a time input. Since we cannot reliably tell the block height inside the secret contract, Salad may be gamed if it's allowed to be called by any network participant.

There are two ways around this issue:

1. Introduce an operator model
2. Introduce crypto economic incentives for network participants

Operator model:
Operator only reports the block height, and no other information (This can be verified by inspecting the contract source and binary), when the information is needed. i.e. when a mix needs to happen anyways. Network participants can see how often the operator calls the mixing contract, which leaves zero attack surface for gaming the mix.
However, the operator is centralized and can be taken down / creates a point of failure.

Crypto-economic incentives:
This model is based on the assumption that there's a fee involved in the mix (0.1%) that is reserved for network participants to trigger the mix when quorum and time requirements are met. There can also be a simple on chain voting which would require a stake (that's lost in the event of malicious behavior) similar to Token Curated Registries
This would require the following steps:

• Introduce a fee model to the mix, where 0.1% of the mix amount is given to the users who are expected to call the mix when enough blocks are validated
• In order to call the mix, Alice need to submit a deposit.
• If Alice is malicious, Bob can challenge Alice. In order to challenge Bob needs to put a deposit as well
• Network participants can vote in case of a challenge for a 10 block window (assuming t = 2 hours, 1 minute challenge period is negligible). The result of the vote determines whether Alice is correct + the mix can be executed or not.
• If Alice wins, she collects the fee from the mix + her deposit. All users who vote for Alice, shares Bob's deposit
• If Bob wins Alice's deposit is shared among Bob and all participants (in some proportion)

The problem with the crypto economic modei is that it's complex and requires participation from the network. We know that TCRs at times failed to achieve expected behavior even though there were economic incentives baked into the model

The advantage of this model is that it can be done in a completely decentralized and censorship free manner.

One option can be to start with the operator model and then see if it creates any problems for Salad before investing in the complexity.

However it's worth noting that there'll be applications that won't be able to use a centralized operator for time measurements such as Dead Man Switch

cc @reuvenpo

[reuvenpo]

I see a few issues with the model as you propose it. I will number them only so it's easier for you to reference them later:

1. I don't think that the current setup is well cross-integrated enough to enable some of the flows here. Namely it's unclear to me how you would integrate a voting mechanism with the contract mechanism, and how they would communicate. If they are separate cosmos modules then that's a problem.
2. Network interaction means this is not really a "single tap" mechanism, and people might not care enough to try and claim the rewards you describe. The voting mechanism itself requires high levels of participation.
3. What happens in cases of high competition over the rewards? You must make sure that players can not filibuster a mix by continually proposing challenges. A vote must happen at most once per mix, and its result must be accepted.
4. Even if the vote is managed in the contract's secret state, how does the contract know that a vote has been completed? It can't trust the current block height, so why should it believe that the timeframe for the vote has really elapsed? (This is a serious design consideration. The design of the vote can not assume knowledge of time because the enclave does not trust time)

[cankisagun]

Based on our discussion today regarding issue #201 , do we have other limitations besides the time for the mix?

If we can't tell how much the user is sending to the mixing contract, then we may want to make sure that secret contract takes only a single mix amount such as 10, 100 or 1000 SCRT etc.

Since the SGX can verify the message_sender, we can make sure that if there are 10 addresses required to trigger a mix, we will be able to accurately verify the number of addresses and make sure that the quorum is achieved without requiring an operator. Is this accurate @reuvenpo

[reuvenpo]

do we have other limitations besides the time for the mix?
then we may want to make sure that secret contract takes only a single mix amount

We still need to verify that the user can afford that constant amount. I'm not sure how we can do that trivially.

[cankisagun]

I was thinking that we can force payment on the contract level and if I have insufficient funds, my transaction is invalid. In this case I shouldn't be able to submit my encrypted recipient address to the mixer contract. Am I missing something?

We can also look to add a deposit contract if that helps

[reuvenpo]

You always gotta look at things from the enclave's perspective. If there's a mix that you want to anonymize, then locally (using a modded host/node) you can replay one participant's transaction, and then forge the rest of the transactions in the mix without spending a penny. We might be able to mitigate this by using the message chaining trick that i mentioned when talking about voting. That way we can rely on the consensus layer outside the enclave to ensure that only the contract owner can lock the mix, preventing malicious replays (by anyone except the contract owner)