Daml Programming Challenge : Privacy-preserving statistics

Here’s a problem I’ve been working on for a while and am interested to see if anyone can implement a working solution:

1. Create a list of integers where each element is private to a single party
2. Extract the biggest integer from the list

Some more requirements:

• When calculating the max value, avoid disclosing the entire list to participants
• The max operation should be atomic i.e. run in a single Update

Caveat emptor: I’ve not been able to do this myself, especially the last point. I’m not convinced it’s even possible!

I should add that the trick here is also to avoid participants becoming aware of other participants. In an ordered list, I don’t think it’s possible to do this without disclosing at least the identity of the adjacent participant.

Luciano:

run in a single Update

Who runs this? A party with access to all the elements?

Leonid_Rozenberg:

A party with access to all the elements?

The way I’ve implemented this is to use the stakeholder of the head of the list. So they don’t have visibility to all the elements necessarily.

I’m not sure I understand the use case, but from my understanding

1. You’re requiring a single Update → the submitter will necessarily see all contracts which are part of the update
2. You’re looking for the max of the whole list → the Update must include the whole list → the submitter will see all integers

So I don’t see a trivial way to do this.

If you’re willing to use things like trusted hardware, I believe @georg has used Intel SGX in the past for something similar. A single party runs the max function on the list in the enclave, but only the trusted enclave sees the entire list, protecting the list’s privacy from any single human.

Yes, in retrospect I don’t think this was very well thought out.

Basically what I was trying to see if it was possible to stage multi-party ‘blind’ transactions atomically. So for instance, an auction (without a central agent) where participants can’t see each other’s identities, or subcustodial structures where settlement occurs atomically across multiple parties, but they only know the identity of their adjacent ‘link’ in the settlement chain.

I think in it’s current form this question isn’t very helpful. Will remove it.

One addition that I’ve thought about before is adding hidden effect (or Action) to Daml. So one could write

do
  step1 <- ...
  hiddden {
    step2 <- f step1
  } 
  step3 <- g step2

And no one who would ordinarily be notified of what happens in f is actually notified. If you have access to the code, one is delegating the truth of f to it and the node that you’re running on. Bernhard will chime in with other concerns, but this is just an idea…

If they’re not notified they also cannot validate it. So you have to make some fairly fundamental changes to Daml’s ledger model to handle something like that.

As @cocreature points out, hidden changes the fundamental trust assumptions in the system. That said, we could implement something like this that delegates trust to an enclave or ZKP proof system, so anything in a hidden block still holds under modified trust assumptions. Example assumptions could be:

1. hidden executes in an enclave on all nodes, protecting data from the node operator. You trust that a malicious party can’t extract data from the enclave.
2. hidden executes in the submitting node’s enclave, and the enclave sends an attestation to all other nodes. You trust that a malicious party can’t forge an attestation.
3. hidden executes in a ZKP prover, sending proof to all other nodes. You trust that a malicious party can’t forge a ZKP proof.

At the moment, I think this puts too much onus on app developers to think about trust properties. Furthermore, there are still too many security vulnerabilities being found regularly with both enclaves and ZKP implementations. Security researchers in recent years have broken the three trust assumptions I wrote above.

So doing some more reading on this, I’ve found that what I’m looking for actually has a name:

Secure multi-party computation | Definition and overview

In an MPC, a given number of participants, p1, p2, ..., pN, each have private data, respectively d1, d2, ..., dN. Participants want to compute the value of a public function on that private data: F(d1, d2, ..., dN) while keeping their own inputs secret. For example, suppose we have three parties Alice, Bob and Charlie, with respective inputs x, y and z denoting their salaries. They want to find out the highest of the three salaries, without revealing to each other how much each of them makes. M...

Is this something that we’ve explored, in the context of daml or Canton?

We haven’t considered adding MPC directly to Daml. It would look very similar to the use of enclaves that I described.
The difference is in the trust model - MPC relies on cryptographic assumptions and enclaves rely on different security assumptions.