Frontend and backend for building circuits

[dreamATD]

This is an implementation of the expression-based and plonkish-like GKR IOP protocol. The circuit is denoted as Chip, holding all information to process commit phases and GKR proving phase. In the current implementation, we assume there are two commit phases. To process the GKR phase, we extract a GKRCircuit from it and run the GKR protocol. For the implementation status, the GKR phase is ready for review, while the commit phases hasn't been finalized.

Define a GKR IOP protocol for a chip includes defining build_commit_phase, build_commit_phase2 and build_gkr_phase. Specially, build_gkr_phase is mainly to build GKR layers in the reverse order. In addition to specify the expressions, to simplify the case of either transferring evaluations from an input of a succeeding layer to an output of the current layer or even make some computations before feeding to the current layer, we use an evaluation tape to place the evaluations and EvalExpression to define the computation. Each layer input will be assigned a position in the evaluation tape. EvalExpression is defined as follows:

#[derive(Clone, Debug)]
pub enum EvalExpression {
    Single(usize),
    Linear(usize, Constant, Constant),
    Partition(Vec<Box<EvalExpression>>, Vec<(usize, Constant)>),
}

of which the items denote how to compute the output evaluations. For more details please refer to gkr_iop/src/evaluation.rs.

Here are some subsequent tasks:

• Parallelize the vector evaluations under subprotocols/src/expression/.
• Devirgo migration.
• Benchmarks.
• Keccak example and benchmarks.

Although the previous tasks should be done, I suggest to start the first round of review first. Would like to see comments from @naure and @hero78119 so that I can adjust the design before moving forward.

Upd: The design doc: https://hackmd.io/@sphere-liu/HyLR-h2L1g.

[naure]

First pass on gkr_iop. It makes sense so far.

[hero78119]

We can separate ChipBuilder vs ConstrainSystem.
Refer similar design in ceno_zkvm https://github.com/scroll-tech/ceno/blob/master/ceno_zkvm/src/circuit_builder.rs#L487-L488
All the information store in this chip struct should belong to ConstrainSystem.
So it can be Serializable.

similar as commment here https://github.com/scroll-tech/ceno/pull/799/files#r1904053980

[hero78119]

we can reuse FieldType as it's exactly same functionality

[dreamATD]

Sure, can I rename it to be VectorType?

[hero78119]

we should avoid heavily vector clone internally, by wrap into Rc or Arc so we only clone pointer
Also we should improve it with parallel version to boost the performance

[dreamATD]

Are there any "parallel clone"? Here I only clone for single vector, of which the space will be reused when applying operations, such as follows:

define_commutative_op_mle2!(VectorType, Add, add, |x, y| {
    zip_eq(&mut x, y).for_each(|(x, y)| *x += y);
    x
});

[hero78119]

Awesome job!
I leave few comments in separate section due to large PR so I did the review in segmented time.

Most of the utility of code reused can be done later, I think the most important point might be trying one pre-compile (e.g. keccak-f) first, and benchmark the preliminary performance. Once it meet the requirements, we proceed to more engineering polishing works :)

[hero78119]

related to #191

[hero78119]

Some quick question

[hero78119]

We had MultilinearExtension + op_mle_xxx macro to deal with base/ext poly in unified code flow.
Could you elaborate more on the benefits for splitting them explicitly?

[hero78119]

same as above, could we make them all inDenseMultiliearPoly format? with that we can make vector + num_vars in same structure