CPS-0026? | Approaches to Fully Homomorphic Encryption

[kozross]

This CPS discusses what benefits having full homomorphic encryption (specifically TFHE) on Cardano would have, and what problems would have to be addressed to deal with it.

Rendered

[rphair]

@kozross this is on agenda for Triage at next CIP meeting (https://hackmd.io/@cip-editors/127) where I hope we can confirm some title which is specific enough to cover Fully Homomorphic Encryption but general enough to accommodate any of the approaches under consideration here.

• Ideally a CPS should be stated as a problem rather than a solution. I've given it a "working title" and please feel free to refine it further & we'll also visit that issue at the meeting.

[rphair]

... as indicated above: great title for a CIP but likely too specific & not "open" enough for a CPS.

[kozross]

I understand where you're coming from with this. I'm used to writing CIPs, rather than CPSes, which is the probable cause. Programmable bootstrapping is a rather key component of why I believe TFHE specifically to be so worthwhile: the question is less 'which scheme should we use', but 'how should we use it', and I'd like the title to reflect that.

Definitely open to suggestions!

[rphair]

Suggested change

	Title: Fully homomorphic encryption with programmable bootstrapping
	Title: Approaches to Fully Homomorphic Encryption

OK, I will put in a vote for what is currently the PR title... pending any stronger suggestions that might come in.

[kozross]

@rphair - I renamed CPS.md to README.md to match your request on my other CPS draft.

Edit: I've also reworded the open questions section to hopefully be less wordy and better organized.

[perturbing]

Just a quick review: nice proposal! I see the value, I do wonder if these operations will fit inside the Plutus budget. 🤔 Having a benchmark as an indication is paramount. (see for example the bls12-381 msm cip here)

[kozross]

@perturbing - 'fitting inside the budget' is a problem, but I feel the bigger issue is that programmable bootstrapping is like higher-order builtins on steroids. Consider something like this kind of builtin and its intended signature (in Plinth):

MapList :: forall a b . (a -> b) -> BuiltinList a -> BuiltinList b

Nothing semantically prohibits us from defining such a builtin. However, how on earth do you cost this? The only assurances we have are that the function argument would get called a number of times proportional to the length of the list argument, as the function argument could do more-or-less arbitrary amounts of work, which we wouldn't be able to figure out. Programmable bootstrapping is this, but even worse: Boolean circuits are a very general model of computation, which gives even less to go on. And that's before we consider that they can be encrypted!

@kwxm explained the problem of higher-order builtin costing to me at length - I would love to hear his opinion on the problem of costing something like programmable bootstrapping and what possible solutions could exist.

In terms of having a benchmark, I believe this is a concern for a CIP, not a CSP. Indeed, I see this as a call to action towards getting us to the point where we know what we need to even do such a measurement.

[perturbing]

However, how on earth do you cost this?

I see your point, and I do not have the answer (unfortunately). I know that costing is complex and the devil is in the details, and clearly your function MapList is too unconstrained to be costed (as the f that gets mapped can be arbitrarily complex). But is this also the case for FHE? Is the space of arguments of such a function not bound? If so, we just need to find the measure 🤔

I do not know yet how the interface of your linked library works, but if it is indeed similar to MapList, I wonder if it can be done.

[kozross]

@perturbing - that is exactly my point. Hopefully @kwxm might be able to chime in and clarify the situation a bit better, as I'm not a costing expert.

Edit: Also @perturbing - addressed your comment regarding Rust FFI.

[rphair]

@kozross this was considered a well researched production at the CIP meeting today and a good starting point for discussing how to include this in Cardano. There were some views that maybe homomorphic encryption would be better provided from elsewhere: and then there was a counter-argument of "why pass that business off to other chains & L2's when we might not have to?".

As already pointed out the main question is cost and we noted that @kwxm was already tagged - although if this is coming from/through Mlabs we also noted that the primary responsibility of providing a refined costing model & estimate should be from the proposer.

@kozross please continue to tag others who may be interested in the general features of this - I am no subject matter expert myself but think @effectfully @michaelpj could be interested & insightful about this.

Please in any case change the containing directory to CPS-0026 and update the "rendered" link in your original comment 🎉

[rphair]

(continued)

[kozross]

@rphair - thanks for that! The 'L2 or not L2' question is precisely the difference between the 'non-native' approach and the other two, so I believe the CPS provides for both possibilities. I happen to agree that 'owning' the capability is better for a lot of reasons, but we expect the necessary research phase before any implementation choices to consider this more thoroughly.

In terms of costing models and estimates - the standard process MLabs have experienced with all of the CIPs proposing builtins was that we specify the overall scaling (for example, 'linear in the first argument'), while the exact model is defined based on work once a PR of the new builtin(s) has been sent to Plutus Core. Obviously, if costing such a builtin is outright impossible, no amount of work on the proposer's part will help. This is one reason I want to hear what Kenneth has to say.

Edit: Updated as per your request.