This document explains how to compile Fully Homomorphic Encryption (FHE) modules containing multiple functions using Concrete.
Deploying a server that contains many compatible functions is important for some use cases. With Concrete, you can compile FHE modules containing as many functions as needed.
These modules support the composition of different functions, meaning that the encrypted result of one function can be used as the input for another function without needing to decrypt it first. Additionally, a module is deployed in a single artifact, making it as simple to use as a single-function project.
Single inputs / outputs
The following example demonstrates how to create an FHE module:
from concrete import fhe@fhe.module()classCounter:@fhe.function({"x": "encrypted"})definc(x):return x +1%20@fhe.function({"x": "encrypted"})defdec(x):return x -1%20
Then, to compile the Counter module, use the compile method with a dictionary of input-sets for each function:
Modules support iteration with cleartext iterands to some extent, particularly for loops structured like this:
for i in some_cleartext_constant_range:# Do something in FHE in the loop body, implemented as an FHE function.
Unbounded loops or complex dynamic conditions are also supported, as long as these conditions are computed in pure cleartext in Python. The following example computes the Collatz sequence:
from concrete import fhe@fhe.module()classCollatz:@fhe.function({"x": "encrypted"})defcollatz(x): y = x //2 z =3* x +1 is_x_odd = fhe.bits(x)[0]# In a fast way, compute ans = is_x_odd * (z - y) + y ans = fhe.multivariate(lambdab, x: b * x)(is_x_odd, z - y)+ y is_one = ans ==1return ans, is_oneprint("Compiling `Collatz` module ...")inputset = [i for i inrange(63)]CollatzFhe = Collatz.compile({"collatz": inputset})print("Generating keyset ...")CollatzFhe.keygen()print("Encrypting initial value")x =19x_enc = CollatzFhe.collatz.encrypt(x)is_one_enc =Noneprint(f"| decrypted | cleartext |")while is_one_enc isNoneornot CollatzFhe.collatz.decrypt(is_one_enc): x_enc, is_one_enc = CollatzFhe.collatz.run(x_enc) x, is_one = Collatz.collatz(x)# For demo purpose; no decryption is needed. x_dec = CollatzFhe.collatz.decrypt(x_enc)print(f"| {x_dec:<9} | {x:<9} |")
In this example, a while loop iterates until the decrypted value equals 1. The loop body is implemented in FHE, but the iteration control must be in cleartext.
Runtime optimization
By default, when using modules, all inputs and outputs of every function are compatible, sharing the same precision and crypto-parameters. This approach applies the crypto-parameters of the most costly code path to all code paths. This simplicity may be costly and unnecessary for some use cases.
To optimize runtime, we provide finer-grained control over the composition policy via the composition module attribute. Here is an example:
from concrete import fhe@fhe.module()classCollatz:@fhe.function({"x": "encrypted"})defcollatz(x): y = x //2 z =3* x +1 is_x_odd = fhe.bits(x)[0] ans = fhe.multivariate(lambdab, x: b * x)(is_x_odd, z - y)+ y is_one = ans ==1return ans, is_one composition = fhe.AllComposable()
You have 3 options for the composition attribute:
fhe.AllComposable (default): This policy ensures that all ciphertexts used in the module are compatible. It is the least restrictive policy but the most costly in terms of performance.
fhe.NotComposable: This policy is the most restrictive but the least costly. It is suitable when you do not need any composition and only want to pack multiple functions in a single artifact.
fhe.Wired: This policy allows you to define custom composition rules. You can specify which outputs of a function can be forwarded to which inputs of another function.
Note that, in case of complex composition logic another option is to rely on [[composing_functions_with_modules#Automatic module tracing]] to automatically derive the composition from examples.
Here is an example:
from concrete import fhefrom fhe import Wired, Wire, Output, Input@fhe.module()classCollatz:@fhe.function({"x": "encrypted"})defcollatz(x): y = x //2 z =3* x +1 is_x_odd = fhe.bits(x)[0] ans = fhe.multivariate(lambdab, x: b * x)(is_x_odd, z - y)+ y is_one = ans ==1return ans, is_one composition =Wired( {Wire(Output(collatz, 0), Input(collatz, 0) } )
In this case, the policy states that the first output of the collatz function can be forwarded to the first input of collatz, but not the second output (which is decrypted every time, and used for control flow).
You can use the fhe.Wire between any two functions. It is also possible to define wires with fhe.AllInputs and fhe.AllOutputs ends. For instance, in the previous example:
This policy would be equivalent to using the fhe.AllComposable policy.
Automatic module tracing
When a module's composition logic is static and straightforward, declaratively defining a Wired policy is usually the simplest approach. However, in cases where modules have more complex or dynamic composition logic, deriving an accurate list of Wire components to be used in the policy can become challenging.
Another related problem is defining different function input-sets. When the composition logic is simple, these can be provided manually. But as the composition gets more convoluted, computing a consistent ensemble of inputsets for a module may become intractable.
For those advanced cases, you can derive the composition rules and the input-sets automatically from user-provided examples. Consider the following module:
You can use the wire_pipeline context manager to activate the module tracing functionality:
# A single inputset used during tracing is definedinputset = [np.random.randint(1, 100, size=())for _ inrange(100)]# The inputset is passed to the `wire_pipeline` method, which itself returns an iterator over the inputset samples.with MyModule.wire_pipeline(inputset)as samples_iter:# The inputset is iterated overfor s in samples_iter:# Here we provide an example of how we expect the module functions to be used at runtime in fhe. MyModule.increment(MyModule.decimate(MyModule.decrement(s)))# It is not needed to provide any inputsets to the `compile` method after tracing the wires, since those were already computed automatically during the module tracing.
module = MyModule.compile( p_error=0.01,)
Note that any dynamic branching is possible during module tracing. However, for complex runtime logic, ensure that the input set provides sufficient examples to cover all potential code paths.
Current Limitations
Depending on the functions, composition may add a significant overhead compared to a non-composable version.
To be composable, a function must meet the following condition: every output that can be forwarded as input (according to the composition policy) must contain a noise-refreshing operation. Since adding a noise refresh has a noticeable impact on performance, Concrete does not automatically include it.
For instance, to implement a function that doubles an encrypted value, you might write:
This function is valid with the fhe.NotComposable policy. However, if compiled with the fhe.AllComposable policy, it will raise a RuntimeError: Program cannot be composed: ..., indicating that an extra Programmable Bootstrapping (PBS) step must be added.
To resolve this and make the circuit valid, add a PBS at the end of the circuit: