Skip to content

Commit

Permalink
Added more comments to the RAPs example
Browse files Browse the repository at this point in the history
Update examples/src/rescue_raps/prover.rs

Co-authored-by: Robin Salen <30937548+Nashtare@users.noreply.github.com>
  • Loading branch information
Jasleen1 and Nashtare committed Sep 20, 2022
1 parent 0b76b68 commit 8be7a7e
Show file tree
Hide file tree
Showing 4 changed files with 21 additions and 8 deletions.
15 changes: 12 additions & 3 deletions examples/src/rescue_raps/air.rs
Original file line number Diff line number Diff line change
Expand Up @@ -104,6 +104,7 @@ impl Air for RescueRapsAir {
let ark = &periodic_values[2..];

// when hash_flag = 1, constraints for Rescue round are enforced (steps 0 to 14)
// Enforcing the round for the first hash chain
rescue::enforce_round(
&mut result[..STATE_WIDTH],
&current[..STATE_WIDTH],
Expand All @@ -112,6 +113,7 @@ impl Air for RescueRapsAir {
hash_flag,
);

// Enforcing the round for the second hash chain
rescue::enforce_round(
&mut result[STATE_WIDTH..],
&current[STATE_WIDTH..],
Expand Down Expand Up @@ -172,11 +174,18 @@ impl Air for RescueRapsAir {
let absorption_flag = periodic_values[1];

// We want to enforce that the absorbed values of the first hash chain are a
// permutation of the absorbed values of the second one. Because we want to
// copy two values per hash chain (namely the two capacity registers), we
// group them with random elements into a single cell via
// permutation of the absorbed values of the second one. Recall that the type
// for both seed and permuted_seed (the arrays being hashed into the chain), was
// [[BaseElement; 2]] and we never permute any of the internal arrays, since
// each [BaseElement; 2] represents the capacity registers for a single link in the
// hash chain. Due to this, we want to copy two values per hash chain at iteration
// (namely, the two capacity registers). To reduce the number of auxiliary registers needed
// to represent each link, we group them with random elements into a single cell via
// α_0 * c_0 + α_1 * c_1, where c_i is computed as next_i - current_i.

// Note that the reason we use next_i - current_i is that we are
// absorbing the new seed by adding it to the output of the previous hash.

// Note that storing the copied values into two auxiliary columns. One could
// instead directly compute the permutation argument, hence require a single
// auxiliary one. For the sake of illustrating RAPs behaviour, we will store
Expand Down
8 changes: 6 additions & 2 deletions examples/src/rescue_raps/prover.rs
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,10 @@ use super::{

// RESCUE PROVER
// ================================================================================================

/// This example constructs a proof for correct execution of
/// 2 hash chains simultaneously.
/// In order to demonstrate the power of RAPs, the two hash chains have seeds that are
/// permutations of each other.
pub struct RescueRapsProver {
options: ProofOptions,
}
Expand All @@ -19,7 +22,8 @@ impl RescueRapsProver {
pub fn new(options: ProofOptions) -> Self {
Self { options }
}

/// The parameter `seeds` is the set of seeds for the first hash chain.
/// The parameter `permuted_seeds` is the set of seeds for the second hash chain.
pub fn build_trace(
&self,
seeds: &[[BaseElement; 2]],
Expand Down
2 changes: 1 addition & 1 deletion fri/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -84,4 +84,4 @@ pub use proof::FriProof;
mod errors;
pub use errors::VerifierError;

mod utils;
pub mod utils;
4 changes: 2 additions & 2 deletions math/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ This crate contains modules with mathematical operations needed in STARK proof g
* Drawing random and pseudo-random elements from the field.
* Computing roots of unity of a given order.

Currently, there are two implementations of finite fields:
Currently, there are three implementations of finite fields:

* A 128-bit field with modulus 2<sup>128</sup> - 45 * 2<sup>40</sup> + 1. This field was not chosen with any significant thought given to performance, and the implementation of most operations is sub-optimal as well. Proofs generated in this field can support security level of ~100 bits. If higher level of security is desired, proofs must be generated in a quadratic extension of the field.
* A 62-bit field with modulus 2<sup>62</sup> - 111 * 2<sup>39</sup> + 1. This field supports very fast modular arithmetic including branchless multiplication and addition. To achieve adequate security (i.e. ~100 bits), proofs must be generated in a quadratic extension of this field. For higher levels of security, a cubic extension field should be used.
Expand Down Expand Up @@ -69,4 +69,4 @@ The number of threads can be configured via `RAYON_NUM_THREADS` environment vari
License
-------

This project is [MIT licensed](../LICENSE).
This project is [MIT licensed](../LICENSE).

0 comments on commit 8be7a7e

Please sign in to comment.