chore: minor fixes

This commit is contained in:
enrico.eth
2024-01-04 12:39:37 +01:00
parent 03e4199f17
commit b75976bfbc
4 changed files with 9 additions and 146 deletions

View File

@@ -12,19 +12,19 @@ This is a research project and is not meant to be used in production. The code i
**Mock Prover**
```bash
cargo run --example bfv -- --name bfv -k 9 --input bfv_test/bfv.in mock
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv.in mock
```
The `MockProver` does not run the cryptographic prover on your circuit, but instead directly checks if constraints are satisfied. This is useful for testing purposes, and runs faster than the actual prover.
- `bfv` is the name of the circuit located in `examples/bfv.rs`
- `bfv_test/bfv.in` is the input file for the circuit located in `data/bfv_test/bfv.in`. A different test vector file can be generated using [bfv-py](https://github.com/yuriko627/bfv-py)
- `bfv/bfv.in` is the input file for the circuit located in `data/bfv/bfv.in`. A different test vector file can be generated using [bfv-py](https://github.com/yuriko627/bfv-py)
- `-k` is the DEGREE of the circuit as you specify to set the circuit to have `2^k` number of rows. The number of rows is determined by the number of constraints in the circuit. Working with larger data inputs will require a larger degree.
**Key Generation**
```bash
cargo run --example bfv -- --name bfv -k 9 --input bfv_test/bfv_empty.in keygen
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv_empty.in keygen
```
To generate a random universal trusted setup (for testing only!) and the proving and verifying keys for your circuit.
@@ -36,7 +36,7 @@ This will generate a proving key `data/bfv.pk` and a verifying key `data/bfv.vk`
**Proof Generation**
```
cargo run --example bfv -- --name bfv -k 9 --input bfv_test/bfv.in prove
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv.in prove
```
Note: during proof generation we must pass an input file containing the actual input data.
@@ -44,36 +44,20 @@ Note: during proof generation we must pass an input file containing the actual i
**Proof Verification**
```
cargo run --example bfv -- --name bfv -k 9 --input bfv_test/bfv_empty.in verify
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv_empty.in verify
```
Note: during proof verification we can pass an empty input file.
## Benchmarks
- **Proving time: 8.5s**
- **Proving time: 10.2s**
- **Verification time: 299ms**
Benches run using `bfv_2` run on M2 Macbook Pro with 12 cores and 32GB of RAM.
Benches run on M2 Macbook Air with 8 cores and 8GB of RAM.
N and Q Parameters of the BFV encryption scheme should be chosen according to TABLES of RECOMMENDED PARAMETERS for 128-bits security level => https://homomorphicencryption.org/wp-content/uploads/2018/11/HomomorphicEncryptionStandardv1.1.pdf.
In order to reproduce the benchmark modify the following parameters in `examples/bfv.rs`:
```rust
const N: usize = 1024;
const Q: u64 = 536870909;
```
Then run the following commands:
```bash
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv.in mock
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv_empty.in keygen
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv.in prove
cargo run --example bfv -- --name bfv -k 13 --input bfv/bfv_empty.in verify
```
## Warning: Overflow
Many polynomial operations performed inside the [circuit](./examples/bfv.rs) involve careful handling of coefficients in order to avoid overflows on the prime field. This [guide](https://zipcpu.com/dsp/2017/07/21/bit-growth.html) is recommended to understand the bit growth of the coefficients when performing polynomial operations. `N` and `DEG` must be provided at `keygen` time. Certain combinations of `N` and `DEG` can potentially lead to the risk of overflow during proof generation, which is something that can be maliciously exploited by the prover. `keygen` will fail if this is these cases.

View File

@@ -1,57 +0,0 @@
{
"pk0": [
"4030",
"4212",
"2848",
"192"
],
"pk1": [
"1238",
"2795",
"1419",
"1433"
],
"m": [
"4635",
"4635",
"3",
"1"
],
"u": [
"0",
"4636",
"0",
"4636"
],
"e0": [
"2",
"4634",
"4632",
"1"
],
"e1": [
"0",
"4636",
"4634",
"4635"
],
"c0": [
"1074",
"3543",
"3163",
"46"
],
"c1": [
"1980",
"408",
"4453",
"1360"
],
"cyclo": [
"1",
"0",
"0",
"0",
"1"
]
}

View File

@@ -1,57 +0,0 @@
{
"pk0": [
"0",
"0",
"0",
"0"
],
"pk1": [
"0",
"0",
"0",
"0"
],
"m": [
"0",
"0",
"0",
"0"
],
"u": [
"0",
"0",
"0",
"0"
],
"e0": [
"0",
"0",
"0",
"0"
],
"e1": [
"0",
"0",
"0",
"0"
],
"c0": [
"0",
"0",
"0",
"0"
],
"c1": [
"0",
"0",
"0",
"0"
],
"cyclo": [
"0",
"0",
"0",
"0",
"0"
]
}

View File

@@ -24,18 +24,11 @@ use zk_fhe::poly_chip::PolyChip;
///
/// Note: all the polynomials are expressed by their coefficients in the form [a_DEG, a_DEG-1, ..., a_1, a_0] where a_0 is the constant term
// These are the parameters used for the test - to match with input file `data/bfv_test/bfv.in`
const N: usize = 4;
const Q: u64 = 4637;
const N: usize = 1024;
const Q: u64 = 536870909;
const T: u64 = 7;
const B: u64 = 19;
// These are the parameters used for the real world application - to match with input file `data/bfv/bfv.in`
// const N: usize = 1024;
// const Q: u64 = 536870909;
// const T: u64 = 7;
// const B: u64 = 19;
/// # Assumptions (to be checked on the public inputs outside the circuit)
///
/// * `N` must be a power of 2