mirror of
https://github.com/zama-ai/concrete.git
synced 2026-04-17 03:00:54 -04:00
docs(common): documentation edits
This commit is contained in:
@@ -47,7 +47,7 @@ circuit = f.compile(inputset, configuration=configuration, loop_parallelize=True
|
||||
```
|
||||
|
||||
{% hint style="info" %}
|
||||
Additional kwarg to `compile` functions take higher precedence. So if you set the option in both `configuration` and `compile` methods, the value in the `compile` method will be used.
|
||||
Additional kwargs to `compile` functions take higher precedence. So if you set the option in both `configuration` and `compile` methods, the value in the `compile` method will be used.
|
||||
{% endhint %}
|
||||
|
||||
## Options
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Debug
|
||||
|
||||
In this section, you will learn how to debug the compilation process easily and get help in case you cannot resolve your issue.
|
||||
In this section, you will learn how to debug the compilation process easily and find help in the case that you cannot resolve your issue.
|
||||
|
||||
## Debug artifacts
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Deploy
|
||||
|
||||
After developing your circuit, you may want to deploy it. However, sharing the details of your circuit with every client might not be desirable. You might want to perform the computation in dedicated servers, as well. In this case, you can use the `Client` and `Server` features of **Concrete**.
|
||||
After developing your circuit, you may want to deploy it. However, sharing the details of your circuit with every client might not be desirable. As well as this, you might want to perform the computation on dedicated servers. In this case, you can use the `Client` and `Server` features of **Concrete**.
|
||||
|
||||
## Development of the circuit
|
||||
|
||||
You can develop your circuit like we've discussed in the previous chapters. Here is a simple example:
|
||||
You can develop your circuit using the techniques discussed in previous chapters. Here is a simple example:
|
||||
|
||||
<!--pytest-codeblocks:skip-->
|
||||
```python
|
||||
@@ -70,7 +70,7 @@ client.keys.generate()
|
||||
|
||||
This method generates encryption/decryption keys and evaluation keys.
|
||||
|
||||
The server requires evaluation keys linked to the encryption keys that you just generated. You can serialize your evaluation keys as shown:
|
||||
The server needs access to the evaluation keys that were just generated. You can serialize your evaluation keys as shown:
|
||||
|
||||
<!--pytest-codeblocks:skip-->
|
||||
```python
|
||||
@@ -80,12 +80,12 @@ serialized_evaluation_keys: bytes = client.evaluation_keys.serialize()
|
||||
After serialization, send the evaluation keys to the server.
|
||||
|
||||
{% hint style="info" %}
|
||||
Serialized evaluation keys are very big in terms of size, so you may want to cache them on the server instead of sending them with each request.
|
||||
Serialized evaluation keys are very large, so you may want to cache them on the server instead of sending them with each request.
|
||||
{% endhint %}
|
||||
|
||||
## Encrypting inputs (on the client)
|
||||
|
||||
Now encrypt your inputs and request the server to perform the computation. You can do it like so:
|
||||
The next step is to encrypt your inputs and request the server to perform some computation. This can be done in the following way:
|
||||
|
||||
<!--pytest-codeblocks:skip-->
|
||||
```python
|
||||
@@ -93,7 +93,7 @@ arg: fhe.Value = client.encrypt(7)
|
||||
serialized_arg: bytes = arg.serialize()
|
||||
```
|
||||
|
||||
Then, send serialized args to the server.
|
||||
Then, send the serialized arguments to the server.
|
||||
|
||||
## Performing computation (on the server)
|
||||
|
||||
@@ -113,11 +113,11 @@ result: fhe.Value = server.run(deserialized_arg, evaluation_keys=deserialized_ev
|
||||
serialized_result: bytes = result.serialize()
|
||||
```
|
||||
|
||||
Then, send the serialized public result back to the client, so they can decrypt it and get the result of the computation.
|
||||
Then, send the serialized result back to the client. After this, the client can decrypt to receive the result of the computation.
|
||||
|
||||
## Decrypting the result (on the client)
|
||||
|
||||
Once you have received the public result of the computation from the server, you can deserialize it:
|
||||
Once you have received the serialized result of the computation from the server, you can deserialize it:
|
||||
|
||||
<!--pytest-codeblocks:skip-->
|
||||
```python
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Manage Keys
|
||||
|
||||
**Concrete** generates keys for you implicitly when they are needed and if they are not generated already. This is useful for development, but it's not flexible **(or secure!)** for production. Explicit key management API is introduced to be used in such cases to easily generate and re-use keys.
|
||||
**Concrete** generates keys for you implicitly when they are needed and if they have not already been generated. This is useful for development, but it's not flexible **(or secure!)** for production. Explicit key management API is introduced to be used in such cases to easily generate and re-use keys.
|
||||
|
||||
## Definition
|
||||
|
||||
@@ -50,7 +50,7 @@ serialized_keys: bytes = circuit.keys.serialize()
|
||||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
Keys are not serialized encrypted! Please make sure you keep them in a safe environment, or encrypt them manually after serialization.
|
||||
Keys are not serialized in encrypted form! Please make sure you keep them in a safe environment, or encrypt them manually after serialization.
|
||||
{% endhint %}
|
||||
|
||||
## Deserialization
|
||||
@@ -70,7 +70,7 @@ circuit.keys = keys
|
||||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
If assigned keys are generated for a different circuit, an exception would be raised.
|
||||
If assigned keys are generated for a different circuit, an exception will be raised.
|
||||
{% endhint %}
|
||||
|
||||
## Saving
|
||||
@@ -87,7 +87,7 @@ Keys are not saved encrypted! Please make sure you store them in a safe environm
|
||||
|
||||
## Loading
|
||||
|
||||
After keys are saved to disk, you can load them back anytime:
|
||||
After keys are saved to disk, you can load them back via:
|
||||
|
||||
```python
|
||||
circuit.keys.load("/path/to/keys")
|
||||
@@ -95,7 +95,7 @@ circuit.keys.load("/path/to/keys")
|
||||
|
||||
## Automatic Management
|
||||
|
||||
Lastly, if you want to generate keys in the first run and reuse the keys in consecutive runs:
|
||||
If you want to generate keys in the first run and reuse the keys in consecutive runs:
|
||||
|
||||
```python
|
||||
circuit.keys.load_if_exists_generate_and_save_otherwise("/path/to/keys")
|
||||
|
||||
@@ -24,8 +24,8 @@ for sample_x in range(3, 6):
|
||||
assert result == sample_x + sample_y
|
||||
```
|
||||
|
||||
Basically, if you have multiple arguments, `encrypt` method would return a `tuple`, and if you specify `None` as one of the arguments, `None` is placed at the same location in the resulting `tuple` (e.g., `circuit.encrypt(a, None, b, c, None)` would return `(encrypted_a, None, encrypted_b, encrypted_c, None)`). Each value returned by `encrypt` can be stored and reused anytime.
|
||||
If you have multiple arguments, the `encrypt` method would return a `tuple`, and if you specify `None` as one of the arguments, `None` is placed at the same location in the resulting `tuple` (e.g., `circuit.encrypt(a, None, b, c, None)` would return `(encrypted_a, None, encrypted_b, encrypted_c, None)`). Each value returned by `encrypt` can be stored and reused anytime.
|
||||
|
||||
{% hint style="warning" %}
|
||||
Ordering of the arguments must be kept! Encrypting an `x` and using it as a `y` could result in undefined behavior.
|
||||
The ordering of the arguments must be kept consistent! Encrypting an `x` and using it as a `y` could result in undefined behavior.
|
||||
{% endhint %}
|
||||
|
||||
Reference in New Issue
Block a user