Can we afford to not expose the constraint system from snarky?

[mimoo]

Snarky exposes a R1CS_constraint_system module (the "R1CS_" part is legacy cruft and needs to be removed).
It's an internal component that is being exposed in a number of places (mostly through the snarky API constraint_system which compiles the circuit and then returns that constraint system object).
Can we stop exposing this internal?

The short answer is no. Since I did some investigation to find out the answer, I'll share why here for curious ears.

to get a digest of the circuit

Most of the uses come from retrieving it and directly calling R1CS_constraint_system.digest to obtain a hash of the circuit.
Not super useful and we should implement digest on the state to avoid a clone here.

Note: Impl.constraint_system doesn't actually "finalize" the circuit, and as such the constraint_system object you get is often not finalized yet (finalization being a number of steps that needs to be followed to finish compilation, like build the wiring). Fortunately, the digest function will call the finalize function if needed (so a constraint system object is lazily finalized).

to compile the circuit and generate witnesses

Some code will call finalize manually. For example, when you want to generate a witness (via snarky's generate_witness or generate_witness_conv), snarky will make sure to first call finalize:

    Option.iter system ~f:(fun system ->
        R1CS_constraint_system.finalize system ) ;

IMO we could replicate the same logic as with digest and lazily finalize in the internal compute_witness function of the constraint system.

To generate keypairs and to generate a witness later

In Kimchi_backend.Dlog_plonk_based_keypair:

module Make (Inputs : Inputs_intf) = struct
  open Core_kernel

  type t = { index : Inputs.Index.t; cs : Inputs.Constraint_system.t }

You need to store the constraint system (in addition to the prover/verifier keys/indexes here) because this is what you use to generate witnesses later.

Note: I'm wondering why the keys/indexes are not an option, as they are pretty large I would guess that we would want the option to sometimes only store the CS.

Note2: The CS is actually not enough to generate witnesses. We also need input_typ, return_typ, handlers. I'm wondering why we don't store all of these info in the same place and just the CS/keys.

The same module exposes a function create that creates the previously discussed type out of a constraint system object.

Get public input size and number of rows

Sometimes we use it to obtain information on the circuit like size of the public input and number of rows. For example, in Pickles.Fix_domains:

  let domains2 sys : Domains.t =
    let open Domain in
    let public_input_size =
      Impl.R1CS_constraint_system.get_primary_input_size sys
    in
    let rows =
      zk_rows + public_input_size + Impl.R1CS_constraint_system.get_rows_len sys
    in
    { h = Pow_2_roots_of_unity Int.(ceil_log2 rows) }
  in
  domains2 (Impl.constraint_system ~input_typ:typ ~return_typ main)

which is used in Pickles to obtain the domains of the step circuit and wrap circuit.

[mimoo]

action items:

• the constraint system (and its serialization) should include which domain it is using (why?)
• the constraint system (and its serialization) should include which field it is using (because a circuit is only correct for a given field)
• the constraint system (and its serialization) should include parameters like the foreign field used in the foreign field gates