Hello,
I’m just trying to make sure my understanding is correct on a few points.
In the whitepaper, no mention is made of any “network private key”, but it appears in a few places in the documentation, along with the mention that the threshold version is “in the works” (cf Decryption and reencryption - fhEVM).
As I see it, the owner of the private key is able to decrypt the entire state. In this case, this would mean any validator is able to read the entire encrypted state. Switching to a threshold model on the other hand would mean all operations need to be ran by a quorum of validators, proceding independently until they need to “sync up” when a decryption, or a reencryption is required. I also imagine it has some consequences on the (homomorphic) bootstrapping process.
What’s the timeline for the threshold mechanism?
The sync points for validators would in turn mean read calls can be very expensive to execute, and, unlike “normal” ethereum networks, clients cannot exactly alleviate this by running their own nodes. How do you plan on preventing resource exhaustion that can be triggered “for free” in a permissionless system?
Hi @DarkLink1697 , Tore from Zama here.
You post a lot of great questions! Let us try to answer them one at the time.
Regarding the “network private key”. You are absolutely right that the “network private key” can be used to decrypt any cipher text. This is of course a big security problem and hence we don’t want anyone to actually know this key. For this reason we will use maliciously secure MPC and threshold protocols both to generate it but also to proactively secret share it between multiple parties. This means the key will never exist on any single machine and that even if an adversary manages to corrupt and capture key-shares from a couple of parties, the key does not get compromised. In fact, we can execute a protocol to refresh all key shares, thus making whatever existing shares the adversary has learned, useless.
In relation to the threshold timeline, we are working on this implementation very actively and will release a working version this summer.
In relation to the potential for resource exhaustion we want to highlight that decryption will function as a separate service, and not be part of the validator’s responsibilities. Hence decryption is equivalent to doing an oracle call of sorts. Someone will have to pay for it (probably the app developer) but it will be relatively cheap.
Threshold is planned for this summer already? That’s good to hear.
I’m still a bit confused about the compensation for read calls, validators need to be able to decrypt the data when executing calls, which means that they should have (a threshold version) of the key.
If the app developer needs to answer read calls, they also need to have the key.
Is the plan to have one key per contract? Does the contract developer need to run validators and make the nodes available?
The plan is to have decryptions and reencryptions executed asynchronously once we move to the threshold network (hence the comparison to an oracle service).
That is, the validators request decryptions from the threshold network. Hence the validators won’t hold the key shares, but be able to request decryptions (which will of course only be allowed, and validated against, the smart contract logic).
In relation to your question on keys, the plan is to have one key per blockchain (i.e. per fhEVM instance). While it it technically possible to have a key for each contract, this would limit interoperability between contracts on the same fhEVM.
Ah right, and since both networks are fully separate, the economics of the decryption network can be also made fully separate, which would help mitigate issues down the line.