The point: ZK, MPC, FHE, TEE are complementary. You will eventually want TEE plus {ZK, MPC, FHE} in your dApp if you want a privacy preserving smart contract system .
The god protocol: smart contracts with privacy
-
“Imagine the ideal protocol. It would have the most trustworthy third party imaginable – a diety who is on everybody's side. All the parties would send their inputs to God. God would reliably determine the results and return the outputs. God being the ultimate in confessional discretion, no party would learn anything more about the other parties' inputs than they could learn from their own inputs and the output.”
Motivating example: batch auction
-
Comment: I am actually a bit confused about the slides on this one. The first slide says "Can we do this without revealing residual bids?” but then proceeds to talk about “To make a private auction, need to start with private assets”. Isn’t private asset necessary only when you want to keep the winning bid private as well? It is not needed if you just want to keep the residual bids private right?
- Response: Well the point is you shouldn't be able to bid unless you actually lock up the necessary assets, and you don't want to reveal your entire account balance just to bid. So it still seems to require interacting with private digital assets
-
ZKP is sufficient for transfers of digital assets, thus achieving private assets.
- Shielded Pool
- Zcash paper
-
Shortcoming with running the system with just ZKP is that the manager/sequencer have to decrypt the private inputs to carry out the computation on the inputs.
-
Hawk as a concrete example
- Private smart contract. Transactional privacy and programmability.
- Participants:
- commit-reveal scheme and ZKP on blockchain for independent privacy.
- Participants first make a commitments together in the freeze phase.
- Then they send inputs encrypted using the manager’s key and ZKP to prove that the encrypted inputs are indeed what are committed without revealing the actual inputs publicly.
- Comment: does participant ZKP also impose some kind of validity constrain like they are not double spending?
- Reesponse: Yes definitely, they use a nullifier to prevent double spending
- Manager (now often known as sequencer)
- Decrypt the encrypted inputs.
- Run the computation.
- Generate ZKP to prove to blockchain that it performed the computation correctly, without revealing the private inputs or the details of the computation.
- Send the proof that the result actually follows from the computation on the inputs
- Participants:
- Private smart contract. Transactional privacy and programmability.
MPC
-
“They have developed protocols which create virtual machines between two or more parties. Multiparty secure computation allows any number of parties to share a computation, each learning only what can be inferred from their own inputs and the output of the computation. These virtual machines have the exciting property that each party's input is strongly confidential from the other parties. The program and the output are shared by the parties.” from “the God protocol”
-
Mental model
- input is broken into different secret shares, each part on its own looks like random noise that does not reveal any information about the actual input, and only when enough parts are combined together can you recover the actual input.
- MPC allows you to compute arbitrary functions over the encoded data and just decrypt the final result.
- However, nodes can still collude and recover the private information by combining the secret shares.
-
Limitations of using MPC to simulate a mutually trusted virtual computer
- Performance limitation. MPC is slow.
- Maybe to illustrate the point that MPC is heavily I/O bound, we can present it as a virtual computer with clock speed equal to the time it takes to complete multiple rounds of networking needed to complete one operation? maybe illustrating how one single operation are completed under some protocol simple enough to be suitable for pedagogical purpose, like additive secret sharing? The issue with this analogy is of course different operations might take different rounds of communication, so different “clock speed” for different operations, but overall very helpful analogy
- Comment: Maybe a good place to bring up some general theoretical results like Yao’s Garbled Circuit and Fairplay? Like show how theoretically any computation can be translated to perform on top of a MPC protocol. Seeing how exactly it is done and the heavy reliance on networking might help with illustrating the previous point as well.
- Response: These are good points, I'm not sure which are best to go in detail. Maybe we could look at what Nillion or Renegade do as contemporary examples?
- Fundamental tradeoff between privacy and fault tolerance
- I will use threshold based MPC scheme to illustrate the point.
- Threshold MPC protocols rely on secret sharing schemes, where the private inputs are divided into shares and distributed among the participating parties. The protocol ensures that the privacy of the inputs is maintained as long as less than certain threshold of parties collude and combine the secret shares
- The key parameter to set here is the threshold needed to recover the private info from the secret shares
- If the threshold is very low, then only a small fraction of the nodes are needed to keep the system running. It is very fault tolerant. However, it also means that only a small fraction of the nodes need to collude to compromise the privacy of the system, meaning that its privacy is not very good.
- If the threshold is very high, then a large majority of the nodes are needed to keep the system running or to recover the private input. It has good privacy but then it only takes a small fraction of the nodes to go down to take down the system. So it is not very fault tolerant.
- Performance limitation. MPC is slow.
-
The privacy an fault tolerance tradeoff makes it undesirable to have actual users to run as parties running MPC.
- Small threshold would make it easy for users to collude. Large threshold would also be a problem as normal users are probably not very reliable.
- So what often happens is MPC as a service. Rely on institutional operators who supposedly have better liveliness guarantees than regular users. This way we can set a high threshold, keeping a good privacy guarantee of the system while relying on the liveliness guarantee of the operators for fault tolerance.
- Comment: Not sure if that is what you are trying to convey. Maybe the logics also works for low threshold case, as it is harder for even a small minority of institutional operators to collude (or is it?)
- Response: This seemed reasonable.i don't think people really go through these in so much detail, but yes you have to pick thresholds and it's sort of a unpleasant dilemma and this explanation of the trade-offs seems accurate and clear
- Comment: Not sure if that is what you are trying to convey. Maybe the logics also works for low threshold case, as it is harder for even a small minority of institutional operators to collude (or is it?)
- MPC improves the security model. Instead of single node of auctioneer/manager seeing the private inputs, distribute the trust across n nodes where k/n is needed to recover the private info.
- Ratel as a Concrete implementation as MPC extended smart contract system.
- Performance is an issue
- big enough group (k out of the k/n threshold) of key holder colluding could decrypt private info and leave behind no trace, which makes it hard to disincentivize
