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.
I’m not sure I understand the use case, but from my understanding
You’re requiring a single Update → the submitter will necessarily see all contracts which are part of the update
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
step1 <- ...
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…
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:
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.
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.
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.
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.