Run_stage function in ProverState
run_stage function is called in prove function, prover.
it takes a stage as input, as stage is defined as:
AirStage is defined as
it seems to have all the info to run a stage
back to the first picture,
stage0 is like this
A test case has challenge
use the challenge test in plonky3 stark.rs to test,
let N: int = 8;
namespace Global(N);
let alpha: expr = std::prelude::challenge(0, 41);
let beta: expr = std::prelude::challenge(0, 42);
col witness x;
col witness stage(1) y;
x = y + beta * alpha;
Steps to implement challenges
- challenges without stages, able to get a random from the hasher
- need to know how many challenges are needed for a stage
Questions
Q1 (answered) why we need this sanity check in the prove function?
thoughts: challenges are used for next stage, if not used, should not created?
Q2 (answered) which phase in the proving process a challenges should be created?
should be created at the end of the stage so it can include all the witness in the last stage as the digest? Yes
Q3 (answered) why the stage challenge trait definition here says the challenge is drawn from base field, isn’t all the challenge should come from extension field?
the extension is handled in pil.
in plonky3 traits.rs
The challenge thus need to come from based field.
Implementing following plonky3
plonky3 constraintSystem built from whole analyze?
no, it is for a single namespace. see how it is built from split when the prover is created:
and in the prove function in prover, you can see constraintSystem is for a single machine, but it might have different stages though. kind of make sense, since in different stages, the constraint System should be repeated.
but PowdrEval is for a single machine.
make witness column has stage info
in the constraintSystem and Terminal access, the witness both include stage info.
to figure out how this stage info is used:
in stark.rs prove function, witness_by_machine is generated without stage info explicitly. then this witness_by_machine is passed to the prove function in prover.rs
it is processed immediately
The first parameter tables, it is BTreeMap<string, Table>, Table contains PowdrTable and degree, powdrtable has constraint_system
The second parameter stage_0, handles columns, Airstage has the trace for this stage
no specification for handling column, about the stage, cause it all belongs to stage 0
data struct:
in plonky3, the PowdrTable, which implement eval to define circuit, is kind of equivalent to PowdrEval now in stwo.
plonky3 has constraintSystem, which is one level “wrapper” for PowdrTable, handling stages stuff, need to check if I need to introduce one more layer as well.
powdrTable contains only the constraint system, for now, let’s try without this more layer
Controlling the prover run stage by stage: ProverState
in prover prove function, ProverState is to store the info for prover to run stage by stage.
program can compute the info to run a stage, but it just plug in all the info, and store it in processed_stages, at the end compute the composite poly together
in the run stage, the processage stage is store in processed_stages vec for “at the end compute the composite poly together”
program is multitable, contains table, contains PowdrTable, so it has Eval for each machine in each namespace in each stage.
ProverState has the circuit of each stage, but it doesn’t have the trace of each stage, the trace is relevant to the other structs, AirStage, Stage, CallbackResult.
Do I need constraint system?
challenge need to be generated after witness commitment, constant trace generated.
then generated challenge,
then generated circuit, and plug in the challenge.
PowdrEval is