- Apr 12, 2024
-
-
STEVAN Antoine authored## changelog - rename the `encode` function to `prove` and have it take _shards_ instead of an _encoding matrix_: this is to isolate the "encoding" process inside the `fec` module and leave the main `komodo::prove` only compute the "proof", i.e. the commits of the data from ```rust fn encode<F, G, P>( bytes: &[u8], encoding_mat: &Matrix<F>, powers: &Powers<F, G>, ) -> Result<Vec<Block<F, G>>, KomodoError> ``` to ```rust fn prove<F, G, P>( bytes: &[u8], powers: &Powers<F, G>, k: usize, ) -> Result<Vec<Commitment<F, G>>, KomodoError> ``` - rename `fec::Shard.combine` to `fec::Shard.recode_with` to get rid of "combine" - rename `fec::recode` to `fec::recode_with_coeffs` to show that this version takes a list of coefficients - rename `Block.commit` to `Block.proof`: "commit" should be "commits" and it's usually refered to as "proof" - split `prove` further into `prove` and `build`: `prove` now outputs a `Vec<Commitment<F>>`, `build` simply takes a `Vec<Shard<F>>` and a `Vec<Commitment<F>>` and outputs a `Vec<Block<F>>` - add `fec::recode_random` that does the "shard" part of `recode` to wrap around `fec::recode_with_coeffs` - remove `R: RngCore` from the signature of `zk::setup`, to avoid having to pass a generic `_` annotation everywhere `zk::setup` is used, same change has been applied to `recode` and the `generate_random_powers` in `main.rs` from ```rust fn setup<R: RngCore, F: PrimeField, G: CurveGroup<ScalarField = F>>( max_degree: usize, rng: &mut R, ) -> Result<Powers<F, G>, KomodoError> { ``` to ```rust fn setup<F: PrimeField, G: CurveGroup<ScalarField = F>>( max_degree: usize, rng: &mut impl RngCore, ) -> Result<Powers<F, G>, KomodoError> { ``` ### some extra minor changes - remove some useles generic type annotations, e.g. `prove::<F, G, P>` can become a simpler `prove` most of the time, i.e. when there is at least one generic annotation somewhere in the scope
-
- Apr 10, 2024
-
-
STEVAN Antoine authored
i ended up adding a bunch of changes to the benchmarks
-
- Apr 09, 2024
-
-
STEVAN Antoine authored
... instead of the number of bytes that does not really make any sense because we only consider one polynomial, i.e. only one column / shard of data. the following relation between the degree of the polynomials and the size of the data holds still $$\text{deg}(P) = \frac{\#\text{bytes}}{k \times |f_r|}$$ where $|f_r|$ is the size of an element of the scalar finite prime field of the elliptic curve $F_r$ and $P$ is the polynomial of a single column / shard of data
-
- Apr 08, 2024
-
-
STEVAN Antoine authored
should address #8 ## changelog - move the internal `rng` to an argument of type `R: RngCore` for the following functions - `recode` in `lib.rs` - `linalg::Matrix::random` - `generate_random_setup` in `main.rs` - make sure - `ark_std::test_rng` is only used in tests modules - `rand::thread_rng` is used in benchmarks, examples and `main.rs`
-
STEVAN Antoine authored
## changelog - add `(komodo)` to the benchmark names for commit and setup for easier parsing - add `--bench commit` to plot the commit times - make the `plot.py` more robust - use `ns_to_ms` and `b_to_kb` to convert times and filesizes - remove the prefix from bench IDs and always take the first space-separated token as the input data size - remove the "bounds" from the labels - remove the "mean" from the labels when there's only the mean to show - plot the figures in fullscreen - add `--save` to save the figures directly to disk with a little message - add `--all` to plot / save all the figures at once ## examples   
-
STEVAN Antoine authored
this MR adds a benchmark for - the KZG10 trusted setup creating of `ark-poly-commit` - the KZG10 commit of `ark-poly-commit` - our own implement of the commit in `zk::commit` there is also a slight improvement to the previous benchmarking of our `zk::setup`: the degree of the _trusted setup_ is now computed once and for all before the benchmarking loop starts, because it's not what is of interest, let's not benchmark it.
-
- Apr 05, 2024
-
-
STEVAN Antoine authored
in 3c91ef12 and !54, a new implementation of the creation of the _trusted setup_ has been introduced, that gets rid of the `E: Pairing` requirement with a more general `<F: PrimeField, G: CurveGroup<_>>`. however, the size of the _trusted setup_ was incorrect. `zk::setup` requires the _maximum degree_ of the _trusted setup_, however, the number of bytes `nb_bytes` was consistently being given to it throughout the code base... this MR - introduces a new `zk::nb_elements_in_setup` that converts a number of bytes to the associated number of _trusted setup_ elements - uses that new `zk` function before calling `zK::setup` in all the code base ## results >
-
STEVAN Antoine authored
this is a minor proposition, get rid of the `UniPoly12_381` or `UniPoly381` type aliases that are just `DensePolynomial<Fr>`. now, it's enough to just change the import of `Fr` to another crate / another curve, without having an inconsistent mention to BLS-12-381 in the name of the _dense polynomial_.
-
- Apr 04, 2024
-
-
STEVAN Antoine authored
as per title, this is a minor MR that just makes sure the imports are consistent across modules. in order - `std` - `ark_...` - others - `komodo` or `crate` or `super`
-
STEVAN Antoine authored
-
STEVAN Antoine authored
## changelog - remove `ark-poly-commit` from the dependencies - remove the old `setup.rs` - add temporary `foo.rs` which define (some details are ommited for brevity) - `struct Powers<F, G>` - `struct Commitment<F, G>` - `fn build_powers<F, G>(...) -> Powers<F, G>` - `fn commit<F, G, P>(powers: &Powers<F, G>, polynomial: &P) -> Commitment<F, G>` - tests - `foo.rs` is then renamed to `setup.rs` - two new `KomodoError` variants have been created to replace `ark_poly_commit::Error` - `DegreeIsZero` - `TooFewPowersInTrustedSetup(usize, usize)` - finally, all the past mentions to `E: Pairing` and `setup::random` have been replaced with `F, G` and `setup::build_powers` respectively
-
- Apr 02, 2024
-
-
STEVAN Antoine authored
as per title ## changelog - add a `setup.rs` benchmark which measures - the creation of a random setup - the serialization of a setup - the deserialization of a setup - refactor `plot.py` a bit to - use `argparse` - take `--bench` to plot either _linalg_ or _setup_ results - write a complete `plot_setup` function - add a bit of documentation here and there ## example results 
-