Precompile: 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]

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]

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