R1CS blueprint is outdated and requires update according to new repository structure and PLONK-blueprint-alike concepts.

Fp6_2over3_cyclotomic_sqr_component assumes existence of fp2 extension of fp6_2over3 field. It would be great to remove this requirement.

Now we have new interfaces in zk d55a5288f76285c73404270a00099f4ec5563fc0 and need to update components

add real data to
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/test/verifiers/kimchi/batch_verify_scalar_field.cpp

Component-oriented selector choice is incorrect and may lead to potential efficiency issues, since we can not distinguish two instances of one component with different input params (parametrized with different input variables) - such instances will have same selectors. And if we directly use variables from params instead of using copy constraints (it may take place in small components, for example), it will lead to undefined behaviour - constraints are different, but selectors are the same.

Most obvious way to fix this is to switch to gate-oriented selectors. But it doesn't sound like an easy task, since it will require building gate ID based on it's content. Most likely we will do it after implementing stable math expression type: NilFoundation/crypto3-math#5 .

Until we closed this issue - we always must use copy constraints for params variables!

• Field extension components
• Merkle tree
• Poseidon

See https://github.com/NilFoundation/crypto3-zk/issues/47

It'd be cool to have a not equals component that would be more efficient that compare component or packing component + disjunction component.
The constraint I suggest is: inv * x =1 for some inv.
This can only be true if x is non zero.
on witness generation inv would be assigned the inverse of x.
It'd better to write it in a way that supports linear combinations and not just variables, this way it could be used to check that any two numbers/variables are different just by subtracting one from the other and using the not_zero component on the linear combination.

Add file with library version. If necessary, the developer will change the major and minor versions of the library in it.

Make automatic change of library patch version in case of merge to master. (In case of successful closing of PR)

Mina audit part one minor

If we would implement all the constraints as constexpr, we could use std::array's and other constexpr-demanding types in the zk for processing circuit without runtime information about the wires (witnesses).

Adding Pedersen hash implementation would be great. There is Ethereum description and zcash rust imlementation.

It looks like basic components require usage of set_input_sizes functions to be compatible with zk's r1cs_gg_ppzksnark. This hypothesis has to be checked and after that it's important to write corresponding tests.

add real data to these tests
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/test/verifiers/kimchi/detail/combine_proof_evals.cpp
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/test/verifiers/kimchi/detail/public_evaluations.cpp

https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/verify.ml#L30 - original implementation
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/include/nil/crypto3/zk/components/systems/snark/plonk/pickles/verify_heterogenous_base.hpp#L153 - elliptic curves base field (for point coordinates) calculations implementation.
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/include/nil/crypto3/zk/components/systems/snark/plonk/pickles/verify_heterogenous_scalar.hpp#L316 - scalar field calculations implementation.

For now, we can change it to vectors

For some tasks, including parallelization, we need to add many components to circuit and generate assignments for them independently or even at the same time. Since it's not possible with only one circuit and assignments state structs instance (because of memory management), we need to make it possible to construct many small circuits and then assemble these parts together.

The native field of PlonK is F_p (~ 255 bits) and the non_native is F_q (~255 bits). Determine how to avoid malicious behavior, when scalar bits are recovered into value from F_q in both cases: p < q and q > p.
The algorithm - https://github.com/NilFoundation/mina-state-proof/blob/master/docs/design/main.pdf (p. 7)

Non-native types require centralized keeping

update oracles scalar and prepare batch scalar tests and get rid of bugs
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/test/verifiers/kimchi/oracles_scalar.cpp
https://github.com/NilFoundation/zkllvm-blueprint/blob/mina-circuits/test/verifiers/kimchi/prepare_batch_scalar.cpp

Use github Actions to automate tests execution (or manually trigger tests execution)

Related to NilFoundation/crypto3-zk#9.

Many circuits we added for Mina are in-fact high-level wrappers on our components. They will be substituted by the code written upon the zkLLVM compiler. Since we need to use it while zkLLVM is WIP, we decided to move them to separate relevant repository. There they do not have to follow components constraints, since they are not components.

add data from mina to table_commitment test

• Components intersection check
• Constraints of all type satisfiability check

Currently, there are two different implementations of element_powers class. One of them is incomplete, another one has tests located in the wrong directory.

We should delete the incomplete one, and move the complete one to the correct directory. I also used this issue to slightly modify the implementation.

zkLLVM assigner requires components to have updated flexible interface, allowing advanced optimizations. Such updates need to be applied to all needed PLONK components.

This is the list of components to start with:

• non-native:
• • bit-decomposition +
• • bool_scalar_multiplication +/-
• • complete_addition_edwards25519
• • doubling_edwards25519
• • ec_point_edwards25519
• • fixed_base_multiplication_edwards25519
• • reduction +
• • scalar_non_native_range +
• • variable_base_multiplication_edwards25519
• • variable_base_multiplication_per_bit_edwards25519
• signatures_verification
• ed25519
• sha512