matter-labs / bellman Goto Github PK

The current codebase does not expose the multiexp module to the users.
It would be beneficial to make this module public for benchmarking and comparability (see, e.g. this issue).

Looks like in ZKP space there is a good separation like in LLVM toolchain - there is a set of tools to define circuits (R1CS) and calculate witness, and bellman or libsnark can be a proof generation backend. For this purpose there is a need to have a byte-level interface for the following uses:

• export/import R1CS for purposes of proving/verifying key generation
• export/import of proving/verifying keys
• export/import witness for proof generation

A challenge for this is that there is no even a unified way how points or field elements are serialized (there is an official RFC with 0x02, 0x03, 0x04 to indicate compressed/decompressed points, but e.g. bellman uses pairing crate that has it's own definitions).

In the next posts I'll give some concrete proposals, and any external contributions are welcome!

The following is supposed to be the benchmark for large data:
cargo test --release -- --ignored --nocapture test_multiexp_performance_on_large_data

Apparently, it's broken. I tried it on my local PC as well as Google Cloud instance. In both cases, no test or benchmark is run.

Am I missing something?

Should it be the element size rather than the fr size?

commit_fe is used as follows, input a fq as parameter.

It has the same size on bn curv, with result 32bytes.
It will be different on bls12_381 curv.

When input an invalid ec point and call into_affine, then get GroupDecodingError. It will cause panic, stack overflowed.

The error may be from the recent commit in pairing_ce verison 0.21.
https://github.com/matter-labs/pairing/blob/977b192b3fe9a14acf943fa0f04a41add1208725/src/lib.rs#L330
In pairing_ce verison 0.21, modified to "self.to_string()" from "self.description()" would cause recursive calling.

For example when having zero private variables, the chunk size ends up being 0.

I tried following this example, but it seems like verification is not succinct for a batch size of 1?

I wonder why in exit we use prove_by_steps (

Is it because prove_by_steps has a better performance?

Currently we have to point to commit 9e35737 to benefit from the singlecore fix.

It seems like the commits after that have breaking changes due to futures, so I was wondering if you could release 9e35737 to crates.io so that the latest version before these changes is out there?

Thanks!

This code fails when compiled to wasm with

panicked at 'attempt to shift left with overflow', 
/home/darko/.cargo/registry/src/github.com-1ecc6299db9ec823/bellman_ce-0.3.5/src/domain.rs:64:26

when E::Fr::S is greater or equal to 32, which seems to be the case with curve bls12_381.

hi, experts
I see bellman plonk proof structure
pub struct Proof<E: Engine, P: PlonkConstraintSystemParams> {
pub num_inputs: usize,
pub n: usize,
pub input_values: Vec<E::Fr>,
pub wire_commitments: Vec<E::G1Affine>,
pub grand_product_commitment: E::G1Affine,
pub quotient_poly_commitments: Vec<E::G1Affine>,
pub wire_values_at_z: Vec<E::Fr>,
pub wire_values_at_z_omega: Vec<E::Fr>,
pub grand_product_at_z_omega: E::Fr,
pub quotient_polynomial_at_z: E::Fr,
pub linearization_polynomial_at_z: E::Fr,
pub permutation_polynomials_at_z: Vec<E::Fr>,
pub opening_at_z_proof: E::G1Affine,
pub opening_at_z_omega_proof: E::G1Affine,
pub(crate) _marker: std::marker::PhantomData

}
my understanding of filed num_inputs is number of public input elements
and field " input_values" is public input element 's values , So the input_values.length should be equal to num_inputs? if yes, num_inputs can be omit , am I right ? correct me if I am wrong ,
Thanks a lot

in latest better_better_cs module, PlonkConstraintSystemParams as follow:
pub trait PlonkConstraintSystemParams<E: Engine>: Sized + Copy + Clone + Send + Sync {
const STATE_WIDTH: usize;
const WITNESS_WIDTH: usize;
const HAS_WITNESS_POLYNOMIALS: bool;
const HAS_CUSTOM_GATES: bool;
const CAN_ACCESS_NEXT_TRACE_STEP: bool;
}

here what does field STATE_WIDTH and CAN_ACCESS_NEXT_TRACE_STEP mean?
and what is difference between STATE_WIDTH and WITNESS_WIDTH? looks confusing .
Can anybody explain ?

Thanks in advance !

Hi! I have the following test using the current tip of dev (09474a):

  #[test]
  fn setup_prove_verify() {
      // the program `def main(public field a) -> field { return a }`
      let program: Prog<Bn128Field> = Prog {
          arguments: vec![Parameter::public(Variable::new(0))],
          return_count: 1,
          statements: vec![Statement::constraint(Variable::new(0), Variable::public(0))],
      };

      // generate a dummy universal setup of size 2**10
      let crs: Crs<<Bn128Field as BellmanFieldExtensions>::BellmanEngine, CrsForMonomialForm> =
      Crs::<<Bn128Field as BellmanFieldExtensions>::BellmanEngine, CrsForMonomialForm>::dummy_crs(2usize.pow(10) as usize);

      // transpile
      let hints = transpile(Computation::without_witness(program.clone())).unwrap();

      // run a circuit specific (transparent) setup
      let pols = setup(Computation::without_witness(program.clone()), &hints).unwrap();

      // generate a verification key from the circuit specific setup and the crs
      let vk = make_verification_key(&pols, &crs).unwrap();

      // run the program
      let interpreter = Interpreter::default();

      // extract the witness
      let witness = interpreter
          .execute(program.clone(), &[Bn128Field::from(42)])
          .unwrap();

      // bundle the program and the witness together
      let computation = Computation::with_witness(program.clone(), witness);
      // transpile
      let hints = transpile(Computation::without_witness(program.clone())).unwrap();

      // check that the circuit is satisfied
      assert!(is_satisfied(computation.clone(), &hints).is_ok());

      // generate a proof with no setup precomputations and no init params for the transcript, using Blake2s
      let proof: BellmanProof<<Bn128Field as BellmanFieldExtensions>::BellmanEngine, PlonkCsWidth4WithNextStepParams> =
              prove_by_steps::<_, _, Blake2sTranscript<_>>(
                  computation,
                  &hints,
                  &pols,
                  None,
                  &crs,
                  None,
              )
              .unwrap();

      // verify the proof using Blake2s
      let ans = verify::<_, Blake2sTranscript<_>>(&proof, &vk).unwrap();

      // check that the proof is verified
      assert!(ans);
  }

I would have expected the proof to be verified correctly because the circuit is satisfied, but this test fails. I checked and it fails in the last check in verification.

Is there something I am doing wrong here? Thanks!

Some code can be found in the gm17/sonic branch of the repo, full implementation is needed.

I am trying to verify the result with snarkjs generated files (proof.json, public.json and verfication_key.json). But I didn't see any example for it. How to achieve this?

Thank you for writing this library! I'm experimenting with using it to produce Plonk proofs in WASM. However, I'm facing an issue.

If I compile using the wasm feature, the Plonk proofs produced are invalid. If I do so with multicore, however, the proofs are valid. This can be seen through this demonstration: https://github.com/weijiekoh/bellman_ce_bug

The underlying issue is that the opening_at_z_omega_proof differs. All other values of the proof match.

In the enforce function for Transpiler, when handle the type of constraint LC * const = LC or const * LC = LC, the free_constant_term is set as follows.

I find that beta branch adds a lot of optimizations and bug fixes after plonk_release.

Just wondering when can beta be considered stable?

Integrate a recently published SONIC proof system

Other crates like https://github.com/matter-labs/franklin-crypto are depending on this crate on multiple branches.
Because those branches, namely dev and snark-wrapper are using the same crate name and version, this prevents a cargo vendor of e.g. https://github.com/matter-labs/zksync-era

See matter-labs/zksync-era#1086 matter-labs/franklin-crypto#65

Recommendation: change the package name to ${orig}-${branchname} in the branches in question, or change the version.