search

AntoineRondelet / snark-mixer

A PoC for a zkSnark-based mixer on Ethereum (adapted from Miximus)
28 stars 3 forks source link

Add Broadcast event in the Mixer #5

Open AntoineRondelet opened 6 years ago

AntoineRondelet commented 6 years ago

See: Design described here: https://github.com/AntoineRondelet/blockchain-privacy

When Alice and Bob want to exchange the secret that is used to recompute a commitment (and used as input to generate a proof) one contract is used to break the link between both parties. In fact, in order to protect her relationship with Bob, Alice wants to share the secret with him, but she does not want to be "seen" by the other peers in the network.

One way to do this is to exchange the secret off-chain. Another way to do this, is to do it on-chain, and communicate through a "Broadcaster" contract. Alice encrypts the secret with Bob's public key, and sends a Tx containing the ciphertext to the Broadcaster contract. The broadcaster contract can't access the data (doesn't have the corresponding private key), and emits an even containing the ciphertext. All peers of the network listen to this even, and try to decrypt the ciphertext. Only Bob can access the plaintext --> Alice and Bob shared a secret through encrypted broadcast on-chain, without leaking their relationship.

The above approach works with a separate contract "Broadcaster/TransactionRelay", but can also work if we add the ciphertext of the secret as another argument of the deposit function, and if we broadcast this ciphertext via an event at the end of the deposit function. This simplifies the design by deleting one contract, diminishes the number of transactions a party needs to trigger on the network.

AntoineRondelet commented 6 years ago

Current implementation for the Transaction Relay contract: https://github.com/AntoineRondelet/blockchain-privacy/blob/master/contracts/TransactionRelay.sol

AntoineRondelet commented 6 years ago

When the event is added to the Mixer contract, it can be useful to implement a python script in charge of listening of all the Broadcast events.

We can imagine something like, a script listening to broadcast events and trying to decrypt their content in a separate thread, and updating a store of "unspent/unrevealed secrets"

barryWhiteHat commented 6 years ago

Hmmm I need to think more about this. One problem is where does Alice get the gas to pay for the broadcast. This reveals that Alice made a payment but not to who. Bob knows that it was alice who made the payment which is fine.

I assumed that this would happen out of bound with whisper or something similar. What is your use case for doing it on chain?

AntoineRondelet commented 6 years ago

Yeah doing it off-chain is probably the best way to do, as we limit the amount of encrypted data we store on-chain... I thought about using the Broadcast event directly at the end of the "deposit" function, so that Alice does not need to do another call when she deposits, or in a separate contract (but then another call is required...) There might probably be a use case for auditability measures to do it on-chain, although I'll need to put more thoughts into all of this. I'll implement it when I have time and play with it to see how the flow goes ;p

barryWhiteHat commented 6 years ago

For me there seems no reason for user 1 to send a payment to user 2 and then not tell them that they did it. Its like just throwing away.

But you do have a point about auditiing. I would like to do that with a zksnark but i want to do everything with a zksnark :-P

HarryR commented 6 years ago

For me there seems no reason for user 1 to send a payment to user 2 and then not tell them that they did it. Its like just throwing away.

Say you tell user 2, then their computer dies, but it's OK because they have their keys backed up somewhere - then they just re-scan all of the broadcast events to discover which coins are theirs.

(e.g. current design of Monero, ZCash - view key, spend key, re-scanning)