Figure 1: Prover workflow: Commitment
PcsConfig
instance, which sets the values for the FRI and PoW operations.
Setting non-default values is related to the security of the proof, which is out of the scope for this tutorial.
Next, we precompute twiddles, also known as the domain over which the rows in the table are evaluated on.
The log size of this domain is set to log_num_rows + CONSTRAINT_EVAL_BLOWUP_FACTOR + config.fri_config.log_blowup_factor
, which is the max log size of the domain that is needed throughout the proving process.
Why we need to add CONSTRAINT_EVAL_BLOWUP_FACTOR
will be explained in the next section.
The final setup is creating a commitment scheme and a channel.
The commitment scheme will be used to commit to the trace polynomials as merkle trees, while the channel will be used to keep a running hash of all data in the proving process (i.e. transcript of the proof).
This is part of the Fiat-Shamir transformation where randomness can be generated safely even in a non-interactive setting.
Here, we use the Blake2sChannel
and Blake2sMerkleChannel
for the channel and commitment scheme, respectively, but we can also use the Poseidon252Channel
and Poseidon252MerkleChannel
pair.
Now that we have our setup, we can commit to the trace polynomials.
But before we do so, we need to first commit to an empty vector called a preprocessed trace, which doesn’t do anything but is required by S-two.
Then, we need to commit to the size of the trace, which is a vital part of the proof system that the prover should not be able to cheat on.
Once we have done these, we can finally commit to the original trace polynomials.