-
*Figure 1: Permutation check*
+
Let's move on to the implementation.
-```rust,ignore
+```rust
fn gen_trace(log_size: u32) -> Vec
-
*Figure 1: Preprocessed trace as a selector*
+
Another use case is to use the preprocessed trace to _express constant values used in constraints_. For example, when creating a hash function in an AIR, we often need to use round constants, which the verifier needs to be able to verify or the resulting hash may be invalid. We can also "look up" the constant values as an optimization technique, which we will discuss in more detail in the next section.
In this section, we will explore how to implement a preprocessed trace as a selector, and we will implement the simplest form: a single `IsFirst` column, where the value is 1 for the first row and 0 for all other rows.
-
-
*Figure 1: Range-check lookup*
+
If we add all the fractions in the two columns together, we get 0. This means that the verifier will be convinced with high probability that the values in the range-checked columns are a subset of the values in the range column.
@@ -53,7 +54,7 @@ If we add all the fractions in the two columns together, we get 0. This means th
Now let's move on to the implementation where we create a 4-bit range-check AIR. We do this by creating a preprocessed trace column with the integers $[0, 16)$, then using a lookup to force the values in the original trace columns to lie in the values of the preprocessed column.
-```rust,ignore
+```rust
struct RangeCheckColumn {
pub log_size: u32,
}
@@ -79,7 +80,7 @@ impl RangeCheckColumn {
First, we need to create the range-check column as a preprocessed column. This should look familiar to the code from the previous section.
-```rust,ignore
+```rust
fn gen_trace(log_size: u32) -> Vec
-
*Figure 1: Prover workflow: Commitment*
+
Now that we have created the trace polynomials, we need to commit to them.
-As we can see in [Figure 1](#fig-committing-to-the-trace-polynomials-1), S-two commits to the trace polynomials by first expanding the trace polynomials (i.e. adding more evaluations) and then committing to the expanded evaluations using a Merkle tree. The rate of expansion (commonly referred to as the _blowup factor_) is a parameter of the FRI protocol and for the purposes of this tutorial, we will use the default value.
+As we can see in [Figure 1](#figure-1), S-two commits to the trace polynomials by first expanding the trace polynomials (i.e. adding more evaluations) and then committing to the expanded evaluations using a Merkle tree. The rate of expansion (commonly referred to as the _blowup factor_) is a parameter of the FRI protocol and for the purposes of this tutorial, we will use the default value.
-```rust,ignore
+```rust
const LOG_CONSTRAINT_EVAL_BLOWUP_FACTOR: u32 = 1;
fn main() {
diff --git a/learn/S-two-book/air-development/writing-a-simple-air/constraints-over-trace-polynomials.mdx b/learn/S-two-book/air-development/writing-a-simple-air/constraints-over-trace-polynomials.mdx
index 6fd3c1732f..b87287a62b 100644
--- a/learn/S-two-book/air-development/writing-a-simple-air/constraints-over-trace-polynomials.mdx
+++ b/learn/S-two-book/air-development/writing-a-simple-air/constraints-over-trace-polynomials.mdx
@@ -3,9 +3,10 @@ title: "Evaluating Constraints Over Trace Polynomials"
---
+
-
*Figure 1: Prover workflow: Constraints*
+
## Proving Spreadsheet Functions
@@ -13,15 +14,16 @@ When we want to perform computations over the cells in a spreadsheet, we don't w
We can do the same thing with our table, except in addition to autofilling cells, we can also create a constraint that the result was computed correctly. Remember that the purpose of using a proof system is that the verifier can verify a computation was executed correctly without having to execute it themselves? Well, that's exactly why we need to create a constraint.
-Now let's say we want to add a new column `C` to our spreadsheet that computes the product of the previous columns plus the first column. We can set `C1` as `A1 * B1 + A1` as in [Figure 2](#fig-constraints-over-trace-polynomials-2). The corresponding constraint is expressed as `C1 = A1 * B1 + A1`. However, we use an alternate representation `A1 * B1 + A1 - C1 = 0` because we can only enforce constraints stating that an expression should equal zero. Generalizing this constraint to the whole column, we get `col1_row1 * col2_row1 + col1_row1 - col3_row1 = 0`.
+Now let's say we want to add a new column `C` to our spreadsheet that computes the product of the previous columns plus the first column. We can set `C1` as `A1 * B1 + A1` as in [Figure 2](#figure-2). The corresponding constraint is expressed as `C1 = A1 * B1 + A1`. However, we use an alternate representation `A1 * B1 + A1 - C1 = 0` because we can only enforce constraints stating that an expression should equal zero. Generalizing this constraint to the whole column, we get `col1_row1 * col2_row1 + col1_row1 - col3_row1 = 0`.
+
-
*Figure 2: Proving spreadsheet functions as constraints*
+
## Identical Constraints Every Row
-Obviously, as can be seen in [Figure 2](#fig-constraints-over-trace-polynomials-2), our new constraint is satisfied for every row in the table. This means that we can substitute creating a constraint for each row with a single constraint over the columns, i.e. the trace polynomials.
+Obviously, as can be seen in [Figure 2](#figure-2), our new constraint is satisfied for every row in the table. This means that we can substitute creating a constraint for each row with a single constraint over the columns, i.e. the trace polynomials.
Thus, `col1_row1 * col2_row1 + col1_row1 - col3_row1 = 0` becomes:
@@ -29,11 +31,11 @@ $$
f_1(x,y) \cdot f_2(x,y) + f_1(x,y) - f_3(x,y) = 0
$$
-
-
*Figure 3: Evaluate function*
+
We also need to implement `FrameworkEval::max_constraint_log_degree_bound(&self)` for `FrameworkEval`. As mentioned in the [Composition Polynomial section](#composition-polynomial), we need to expand the trace polynomial evaluations because the degree of our composition polynomial is higher than that of the trace polynomial. Expanding it by `LOG_CONSTRAINT_EVAL_BLOWUP_FACTOR=1` is sufficient for our example as the total degree of the highest degree term $f_1(x,y) \cdot f_2(x,y)$ is 2, so we return `self.log_size + LOG_CONSTRAINT_EVAL_BLOWUP_FACTOR`. For those who are interested in how to set this value in general, we leave a detailed note below.
-
-
*Figure 1: Prover workflow: Trace polynomials*
-
+
In the previous section, we created a table (aka spreadsheet). In this section, we will convert the table into something called trace polynomials.
+
-
*Figure 2: From spreadsheet to trace polynomials*
+
In STARKs, the computation trace is represented as evaluations of a polynomial over some domain. Typically this domain is a coset of a multiplicative subgroup. But since the multiplicative subgroup of M31 is not smooth, S-two works over the circle group which is the subgroup of degree-2 extension of M31 (as explained in the [Mersenne Primes](../../how-it-works/mersenne-prime) and [Circle Group](../../how-it-works/circle-group) sections). Thus the domain in S-two is formed of points $(x_i, y_i)$ on the circle curve. Note that when we interpolate a polynomial over the points on the circle curve, we get a bivariate trace polynomial $f_j(x, y)$.
We will explain why using a polynomial representation is useful in the next section, but for now, let's see how we can create trace polynomials for our code. Note that we are building upon the code from the previous section, so there's not much new code here.
-```rust,ignore
+```rust
fn main() {
// --snip--
@@ -31,6 +32,6 @@ fn main() {
}
```
-Here, `domain` refers to the $(x_i, y_i)$ values used to interpolate the trace polynomials. For example, $(x_1, y_1), (x_2, y_2)$ in [Figure 2](#fig-from-spreadsheet-to-trace-polynomials-2) are the domain values for our example. Note that when creating the domain, we set the `log_num_rows` to the log of the actual number of rows that are used in the table. In our example, we set it to 4 since S-two requires that we use at least 16 rows. For a background on what `CanonicCoset` and `.circle_domain()` mean, you can refer to the [Circle Group](../../how-it-works/circle-group) section.
+Here, `domain` refers to the $(x_i, y_i)$ values used to interpolate the trace polynomials. For example, $(x_1, y_1), (x_2, y_2)$ in [Figure 2](#figure-2) are the domain values for our example. Note that when creating the domain, we set the `log_num_rows` to the log of the actual number of rows that are used in the table. In our example, we set it to 4 since S-two requires that we use at least 16 rows. For a background on what `CanonicCoset` and `.circle_domain()` mean, you can refer to the [Circle Group](../../how-it-works/circle-group) section.
Now that we have created 2 trace polynomials for our 2 columns, let's move on to the next section where we commit to those polynomials!
diff --git a/learn/S-two-book/air-development/writing-a-simple-air/index.mdx b/learn/S-two-book/air-development/writing-a-simple-air/index.mdx
index fa979cbad2..4c3462f6f8 100644
--- a/learn/S-two-book/air-development/writing-a-simple-air/index.mdx
+++ b/learn/S-two-book/air-development/writing-a-simple-air/index.mdx
@@ -1,11 +1,12 @@
---
-title: "First Breath of AIR"
+title: "Introduction"
---
+
-
*Figure 1: Proving lifecycle in S-two*
+
Welcome to the guide for writing AIRs in S-two!
diff --git a/learn/S-two-book/air-development/writing-a-simple-air/proving-an-air.mdx b/learn/S-two-book/air-development/writing-a-simple-air/proving-an-air.mdx
index 4a86308153..3fb878a2b8 100644
--- a/learn/S-two-book/air-development/writing-a-simple-air/proving-an-air.mdx
+++ b/learn/S-two-book/air-development/writing-a-simple-air/proving-an-air.mdx
@@ -2,16 +2,15 @@
title: "Proving and Verifying an AIR"
---
-
+
-
*Figure 1: Prover workflow: perform FRI and PoW*
-
+
We're finally ready for the last step: prove and verify an AIR!
Since the code is relatively short, let us present it first and then go over the details.
-```rust,ignore
+```rust
fn main() {
// --snip--
@@ -33,14 +32,16 @@ fn main() {
## Prove
-As you can see, there is only a single line of code added to create the proof. The `prove` function performs the FRI and PoW operations under the hood, although, technically, the constraint-related steps in [Figure 1](#fig-proving-an-air-1) were not performed in the previous section and are only performed once `prove` is called.
+As you can see, there is only a single line of code added to create the proof. The `prove` function performs the FRI and PoW operations under the hood, although, technically, the constraint-related steps in [Figure 1](#figure-1) were not performed in the previous section and are only performed once `prove` is called.
## Verify
In order to verify our proof, we need to check that the constraints are satisfied using the commitments from the proof. In order to do that, we need to set up a `Blake2sChannel` and `CommitmentSchemeVerifier
-
*Figure 1: Prover workflow: Create a table*
+
-In order to write a proof, we first need to create a table of rows and columns. This is no different from writing integers to an Excel spreadsheet as we can see in [Figure 2](#fig-writing-a-spreadsheet-2).
+In order to write a proof, we first need to create a table of rows and columns. This is no different from writing integers to an Excel spreadsheet as we can see in [Figure 2](#figure-2).
+
-
*Figure 2: From spreadsheet to table*
+
But there is a slight caveat to consider when creating the table. S-two implements [SIMD operations](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data) to speed up the prover in the CPU, but this requires providing the table cells in chunks of 16 rows. Simply put, this is because S-two supports 16 lanes of 32-bit integers, which means that the same instruction can be run simultaneously for 16 different data.
-Alas, for our table, we will need to create 14 dummy rows to make the total number of rows equal to 16, as shown in [Figure 3](#fig-writing-a-spreadsheet-3). For the sake of simplicity, however, we will omit the dummy rows in the diagrams of the following sections.
+Alas, for our table, we will need to create 14 dummy rows to make the total number of rows equal to 16, as shown in [Figure 3](#figure-3). For the sake of simplicity, however, we will omit the dummy rows in the diagrams of the following sections.
+
-
*Figure 3: Creating a table with 16 rows*
+
+
Given all that, let's create this table using S-two.
-```rust,ignore
+```rust
use stwo::prover::{
backend::{
simd::{column::BaseColumn, m31::N_LANES},
diff --git a/learn/S-two-book/cairo-air/add-opcode/index.mdx b/learn/S-two-book/cairo-air/add-opcode/index.mdx
index aba4756efc..05d8a3fea4 100644
--- a/learn/S-two-book/cairo-air/add-opcode/index.mdx
+++ b/learn/S-two-book/cairo-air/add-opcode/index.mdx
@@ -5,13 +5,14 @@ title: "ADD Opcode Walkthrough"
To better understand how `Opcode` components work, let's walk through the implementation of the `AddOpcode` component.
+
-
*Figure 1: The `AddOpcode` columns*
+
Above is the list of all the columns used in the `AddOpcode` component. Note that the `dst_val`, `op0_val`, and `op1_val` columns are actually 28 columns each (to support 28 9-bit limbs), but we show them as single columns for brevity.
-To reiterate what an `Opcode` component does from the [Main Components](../main-components/index.mdx#opcode-component) section, it verifies the following:
+To reiterate what an `Opcode` component does from the [Main Components](./main-components/index#opcode-component) section, it verifies the following:
1. The offsets and flag values are correct using the `VerifyInstruction` component.
2. The instruction is correctly mapped to the current `Opcode` component using the flags.
@@ -19,25 +20,27 @@ To reiterate what an `Opcode` component does from the [Main Components](../main-
4. The operation for the current `Opcode` component is done correctly.
5. The state transition of the three registers (`pc`, `ap`, `fp`) is done correctly using the flags.
-
-
*Figure 1: Cairo instruction (little-endian)*
+
-As the figure above from the [Cairo paper](https://eprint.iacr.org/2021/1063.pdf) shows, an instruction is 64 bits, where the first three 16-bit integers are signed offsets to the operands `dst`, `op0`, and `op1`.
+As the figure above from the Cairo paper shows, an instruction is 64 bits, where the first three 16-bit integers are signed offsets to the operands `dst`, `op0`, and `op1`.
The next 15 bits are flags. The `dst_reg` and `op0_reg` 1-bit flags indicate whether to use the `ap` or the `fp` register as the base for the `dst` and `op0` operands. The `op1_src` flag supports a wider range of base values for the `op1` operand: `op0`, `pc`, `fp`, and `ap`. The `res_logic` flag indicates how to compute the `res` operand: `op1`, `op0 + op1`, or `op0 * op1`. The `pc_update` and `ap_update` flags show how to update the `pc` and `ap` registers after computing the operands. The `opcode` flag indicates whether this instruction belongs to a predefined opcode (e.g., `CALL`, `RET`, `ASSERT_EQ`) and also defines how the `ap` and `fp` registers should be updated.
-
-
*Figure 2: New instruction format with opcode extension*
+
As of [this commit](https://github.com/starkware-libs/stwo-cairo/blob/b712c77887f8f8ce0d39a8a9741221c89846836e/stwo_cairo_prover/crates/adapter/src/decode.rs#L4), the following opcode extension values are supported:
@@ -58,6 +60,6 @@ As of [this commit](https://github.com/starkware-libs/stwo-cairo/blob/b712c77887
- `2`: BlakeFinalize
- `3`: QM31Operation
-
-
*Figure 1: A single CPU step in Cairo*
+
Since we need to prove the correctness of all CPU steps, the Cairo AIR writes the results of fetching, decoding, and executing an instruction at every CPU step into a trace and proves that the constraints over the trace are satisfied—i.e., consistent with the semantics of Cairo.
@@ -39,7 +40,7 @@ The first constraint is implemented by using a preprocessed column that contains
The second constraint is guaranteed because the `address` value is always unique.
-
-
*Figure 2: Limb decomposition*
+
Note that the decomposition will be constrained by range checking that each integer is within its corresponding range.
@@ -85,9 +87,10 @@ On the left-hand side, we can see lookups that are computed directly by the veri
Each component has a **claimed sum** value that corresponds to the sum of all the lookups in the component. These claimed sums are provided by the prover as part of the proof, and the verifier adds them together along with the lookups on the left-hand side. If the total sum is zero, the verifier is convinced that the proof is valid.
+
-
*Figure 3: Lookups between the main components*
+
### Memory Lookups
diff --git a/learn/S-two-book/how-it-works/air/components.mdx b/learn/S-two-book/how-it-works/air/components.mdx
index 1a2af5013b..4cbe3c54fe 100644
--- a/learn/S-two-book/how-it-works/air/components.mdx
+++ b/learn/S-two-book/how-it-works/air/components.mdx
@@ -3,7 +3,7 @@ title: "Components"
---
-This section examines how the components are implemented and covers some important functions defined on them, without diving into AIR-specific details since they are already covered in the [earlier sections](../../air-development/index).
+This section examines how the components are implemented and covers some important functions defined on them, without diving into AIR-specific details since they are already covered in the [earlier sections](/learn/S-two-book/air-development/index).
The `Components` struct is a collection of components, implemented as follows:
```rust
@@ -13,7 +13,7 @@ pub struct Components<'a> {
}
```
-Here, `components` is a collection of objects that implement the `Component` trait, and `n_preprocessed_columns` is the total number of preprocessed columns used across all components (refer to [Preprocessed Trace](../../air-development/preprocessed-trace/index)).
+Here, `components` is a collection of objects that implement the `Component` trait, and `n_preprocessed_columns` is the total number of preprocessed columns used across all components (refer to [Preprocessed Trace](/learn/S-two-book/air-development/preprocessed-trace/index)).
The `Component` trait represents a trace table along with a set of constraints. It implements the following functions:
@@ -59,7 +59,7 @@ The `composition_log_degree_bound` function determines the log of the degree of
}
```
-For each component, this calls the `max_constraint_log_degree_bound()` function, which returns the log of the highest polynomial degree among all constraints in that component. It then takes the maximum value across all components. For the [example AIR containing two components](./overview.mdx#air-to-composition-polynomial), this function returns $\max({\log{(\deg{(p_0)})}, \log{(\deg{(p_1)})}})$.
+For each component, this calls the `max_constraint_log_degree_bound()` function, which returns the log of the highest polynomial degree among all constraints in that component. It then takes the maximum value across all components. For the [example AIR containing two components](/learn/S-two-book/how-it-works/air/overview#air-to-composition-polynomial), this function returns $\max({\log{(\deg{(p_0)})}, \log{(\deg{(p_1)})}})$.
## Mask Points
The `mask_points` function determines all evaluation points needed to verify constraints at a given point
@@ -123,7 +123,7 @@ The inputs to this function are as follows:
- `mask_values`: The evaluations of the polynomials at the mask points that were previously determined by the `mask_points` function. These provide the constraint polynomial values needed to compute the composition polynomial at the input `point`.
- `random_coeff`: An element from the `SecureField` (i.e. $\mathsf{QM31}$). In the example, this is represented as $\gamma$, which is used to compose all constraints into a single composition polynomial.
-The function body operates as follows. First, an `evaluation_accumulator` is instantiated. Then, for each component, the evaluation of the component-level quotient is added to the `evaluation_accumulator`. For the [example AIR containing two components](./overview.mdx#air-to-composition-polynomial), this adds the evaluations of component-level quotients $q_0$ and $q_1$ at the input `point` to the `evaluation_accumulator`. Finally, the `finalize()` function is called on the `evaluation_accumulator`, which outputs the random linear combination evaluated at the input `point`.
+The function body operates as follows. First, an `evaluation_accumulator` is instantiated. Then, for each component, the evaluation of the component-level quotient is added to the `evaluation_accumulator`. For the [example AIR containing two components](/learn/S-two-book/how-it-works/air/overview#air-to-composition-polynomial), this adds the evaluations of component-level quotients $q_0$ and $q_1$ at the input `point` to the `evaluation_accumulator`. Finally, the `finalize()` function is called on the `evaluation_accumulator`, which outputs the random linear combination evaluated at the input `point`.
$$
q = q_0 + \gamma^{c_0} \cdot q_1
$$
diff --git a/learn/S-two-book/how-it-works/air/index.mdx b/learn/S-two-book/how-it-works/air/index.mdx
index 231f4ad2ff..1c15c16e2a 100644
--- a/learn/S-two-book/how-it-works/air/index.mdx
+++ b/learn/S-two-book/how-it-works/air/index.mdx
@@ -1,5 +1,5 @@
---
-title: "AIR to Composition Polynomial"
+title: "Introduction"
---
@@ -7,10 +7,10 @@ title: "AIR to Composition Polynomial"
This section is organized as follows:
-- **[Technical Overview](./overview)**: Provides a high-level explanation of how multiple components are combined into a composition polynomial.
+- **[Technical Overview](/learn/S-two-book/how-it-works/air/overview)**: Provides a high-level explanation of how multiple components are combined into a composition polynomial.
-- **[Components](./components)**: Examines the implementation of the `Components` struct and key functions like `mask_points` and `eval_composition_polynomial_at_point`.
+- **[Components](/learn/S-two-book/how-it-works/air/components)**: Examines the implementation of the `Components` struct and key functions like `mask_points` and `eval_composition_polynomial_at_point`.
-- **[Prover Components](./prover_components)**: Details the `ComponentProvers` struct and its specialized functions for computing composition polynomials during the proving process, including the main `compute_composition_polynomial` function.
+- **[Prover Components](/learn/S-two-book/how-it-works/air/prover_components)**: Details the `ComponentProvers` struct and its specialized functions for computing composition polynomials during the proving process, including the main `compute_composition_polynomial` function.
diff --git a/learn/S-two-book/how-it-works/air/overview.mdx b/learn/S-two-book/how-it-works/air/overview.mdx
index b2bd86d1f8..d0ba93fec7 100644
--- a/learn/S-two-book/how-it-works/air/overview.mdx
+++ b/learn/S-two-book/how-it-works/air/overview.mdx
@@ -3,11 +3,11 @@ title: "Technical Overview"
---
-As shown in an earlier section (refer to [Components](../../air-development/components/index)), S-two represents the trace using multiple tables where each table is referred to as a _component_. An AIR in S-two is a collection of multiple components. Components can interact with one another, and the consistency of these interactions is verified using [_logUp_](https://eprint.iacr.org/2022/1530.pdf).
+As shown in an earlier section (refer to [Components](/learn/S-two-book/air-development/components/index)), S-two represents the trace using multiple tables where each table is referred to as a _component_. An AIR in S-two is a collection of multiple components. Components can interact with one another, and the consistency of these interactions is verified using [_logUp_](https://eprint.iacr.org/2022/1530.pdf).
-For example, in the [hash function example](../../air-development/components/index.mdx#hash-function-example), the scheduling component and computing component interact with each other, where both the components lookup the input and output pair. The consistency of this interaction is then verified by adding logUp constraints to each component.
+For example, in the [hash function example](/learn/S-two-book/air-development/components/index#hash-function-example), the scheduling component and computing component interact with each other, where both the components lookup the input and output pair. The consistency of this interaction is then verified by adding logUp constraints to each component.
-Each component consists of a trace table of a specific height along with a set of constraints. These constraints include computation constraints as well as lookup constraints (refer to [Lookups](../lookups)).
+Each component consists of a trace table of a specific height along with a set of constraints. These constraints include computation constraints as well as lookup constraints (refer to [Lookups](/learn/S-two-book/how-it-works/lookups)).
This section provides an overview of how these components are converted into a composition polynomial. This composition polynomial is then used by a polynomial commitment scheme to commit and generate evaluation proofs.
@@ -15,9 +15,9 @@ This section provides an overview of how these components are converted into a c
This section explains how a composition polynomial is computed using an example.
-Consider an AIR composed of two components with trace tables: $\mathscr{T}_0$ and $\mathscr{T}_1$. The component table $\mathscr{T}_0$ is defined over the trace domain $D_{n_0}$, which is a [canonic coset](../circle-group.mdx#canonic-coset) of size $N_0 = 2^{n_0}$. Similarly, component table $\mathscr{T}_1$ is defined over the trace domain $D_{n_1}$ of size $N_1 = 2^{n_1}$.
+Consider an AIR composed of two components with trace tables: $\mathscr{T}_0$ and $\mathscr{T}_1$. The component table $\mathscr{T}_0$ is defined over the trace domain $D_{n_0}$, which is a [canonic coset](/learn/S-two-book/how-it-works/circle-group#canonic-coset) of size $N_0 = 2^{n_0}$. Similarly, component table $\mathscr{T}_1$ is defined over the trace domain $D_{n_1}$ of size $N_1 = 2^{n_1}$.
-The prover interpolates the trace polynomials for each component and then evaluates the trace polynomials over an evaluation domain that is a blowup factor $B = 2^\beta$ times larger than the trace domain. Thus, the evaluation domain for component table $\mathscr{T}_0$ is $D_{n_0 + \beta}$ of size $2^{n_0 + \beta}$. Similarly, the evaluation domain for component table $\mathscr{T}_1$ is $D_{n_1 + \beta}$ of size $2^{n_1 + \beta}$. Both interpolation and evaluation use [circle FFT](../circle-fft/index). The prover then commits to the evaluations of trace polynomials from all components using a single [Merkle tree](../vcs/index).
+The prover interpolates the trace polynomials for each component and then evaluates the trace polynomials over an evaluation domain that is a blowup factor $B = 2^\beta$ times larger than the trace domain. Thus, the evaluation domain for component table $\mathscr{T}_0$ is $D_{n_0 + \beta}$ of size $2^{n_0 + \beta}$. Similarly, the evaluation domain for component table $\mathscr{T}_1$ is $D_{n_1 + \beta}$ of size $2^{n_1 + \beta}$. Both interpolation and evaluation use [circle FFT](/learn/S-two-book/how-it-works/circle-fft/index). The prover then commits to the evaluations of trace polynomials from all components using a single [Merkle tree](/learn/S-two-book/how-it-works/vcs/index).
Both component tables define computation constraints and lookup constraints for their specific component. The component constraints are proven table-wise, each with its separate domain quotient, which are then combined into a single cross-domain composition polynomial. Suppose the component tables $\mathscr{T}_0$ and $\mathscr{T}_1$ have a total of $c_0$ and $c_1$ constraints, respectively.
diff --git a/learn/S-two-book/how-it-works/air/prover_components.mdx b/learn/S-two-book/how-it-works/air/prover_components.mdx
index 4ec48ce40a..cccf1110fb 100644
--- a/learn/S-two-book/how-it-works/air/prover_components.mdx
+++ b/learn/S-two-book/how-it-works/air/prover_components.mdx
@@ -58,7 +58,7 @@ The main function defined on the `ComponentProvers` struct to compute the compos
}
```
-Let us examine the above function for our [example AIR containing two components](./overview.mdx#air-to-composition-polynomial). It takes the following three inputs:
+Let us examine the above function for our [example AIR containing two components](/learn/S-two-book/how-it-works/air/overview#air-to-composition-polynomial). It takes the following three inputs:
- `&self`: This is the `ComponentProvers` on which the function is called.
- `random_coeff`: This is an element from the `SecureField` (i.e. $\mathsf{QM31}$). In our example, this is represented as $\gamma$.
- `trace`: The `Trace` struct which contains all the polynomials that make up the entire trace including all the components. For efficiency, it stores each polynomial in both coefficients and evaluations form.
@@ -77,6 +77,6 @@ For each component, we call `evaluate_constraint_quotients_on_domain`, which com
After adding all component quotient evaluations to the accumulator, we call the `finalize()` function, which:
1. Combines the accumulated evaluations at different domain sizes to compute the evaluations of the quotient composition polynomial $q$ over the domain $D_{n + \beta}$ where $n = \max{(n_1, n_2)}$.
-2. Interpolates $q$ over $D_{n + \beta}$ using [circle FFT](../circle-fft/index) to convert it into coefficient representation.
+2. Interpolates $q$ over $D_{n + \beta}$ using [circle FFT](/learn/S-two-book/how-it-works/circle-fft/index) to convert it into coefficient representation.
-Note that the output is a [`SecureCirclePoly`](../circle-polynomials/secure-evals-and-poly.mdx#secure-circle-polynomials) since the evaluations of $q$ are in the secure field $\mathsf{QM31}$ (as $\gamma$ is randomly sampled from $\mathsf{QM31}$).
\ No newline at end of file
+Note that the output is a [`SecureCirclePoly`](/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly#secure-circle-polynomials) since the evaluations of $q$ are in the secure field $\mathsf{QM31}$ (as $\gamma$ is randomly sampled from $\mathsf{QM31}$).
\ No newline at end of file
diff --git a/learn/S-two-book/how-it-works/circle-fft/algorithm.mdx b/learn/S-two-book/how-it-works/circle-fft/algorithm.mdx
index f7d751eca7..68bf0d1bde 100644
--- a/learn/S-two-book/how-it-works/circle-fft/algorithm.mdx
+++ b/learn/S-two-book/how-it-works/circle-fft/algorithm.mdx
@@ -9,33 +9,39 @@ Circle FFT follows a divide-and-conquer strategy, as in the classical Cooley–T
## Sequence of Domains for Circle FFT
-In Circle FFT, we use a 2-to-1 map to halve the domain size at each recursive layer. The domain used here is the [circle domain](../circle-group.mdx#circle-domain) $D_n$ of size $|D_n| = 2^n$.
+In Circle FFT, we use a 2-to-1 map to halve the domain size at each recursive layer. The domain used here is the [circle domain](/learn/S-two-book/how-it-works/circle-group#circle-domain) $D_n$ of size $|D_n| = 2^n$.
$$D_n = q + \langle g_{n-1} \rangle \cup -q + \langle g_{n-1} \rangle$$
This section describes two specific 2-to-1 maps that are central to the Circle FFT construction:
1. **Projection map $\pi_x$**: The projection map $\pi_x$ projects the points $(x,y)$ and $(x,-y)$ to the same $x$-coordinate i.e.
+
$$\pi_x: D_n \rightarrow S_n, \quad \pi_x((x, y)) = x$$
+
where $S_n$ is the set containing all the $x$-coordinates from $D_n$. This can be interpreted as saying that two points are considered equivalent if they differ only by sign. Since $\pi_x$ maps two points from $D_n$ to a single element in $S_n$, the size of $S_n$ will be half the size of $D_n$.
2. **Squaring map $\pi$**: The squaring map $\pi$ is a 2-to-1 map defined by:
+
$$\pi: S_n \rightarrow S_{n-1}, \quad \pi(x) = 2x^2 - 1$$
+
This is obtained using the doubling map and the equality $y^2 = 1 - x^2$ to compute the $x$-coordinate:
$$\pi(x, y) = (x, y) + (x, y) = (x^2 - y^2, 2xy) = (2x^2-1, 2xy)$$
In Circle FFT, we use both the projection map $\pi_x$ and the squaring map $\pi$ to construct the sequence of domains. The sequence of domains for Circle FFT is shown as follows:
+
$$D_n \xrightarrow{\pi_x} S_n \xrightarrow{\pi} S_{n-1} \xrightarrow{\pi} \cdots \xrightarrow{\pi} S_1$$
Now that we know the sequence of domains, let us dive into the Circle FFT algorithm.
## Circle FFT
-The Circle FFT interpolates a bivariate polynomial $p(x,y)$ from the [polynomial space](../circle-polynomials/evals-and-poly.mdx#polynomials-over-the-circle) $L_N(F)$, given the evaluations over a circle domain $D_n$ of size $N=2^n$. The algorithm is a three step process described as follows.
+The Circle FFT interpolates a bivariate polynomial $p(x,y)$ from the [polynomial space](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly#polynomials-over-the-circle) $L_N(F)$, given the evaluations over a circle domain $D_n$ of size $N=2^n$. The algorithm is a three step process described as follows.
#### Step 1: Decompose $p(x, y)$ into sub-polynomials
In the first step, we decompose the bivariate polynomial $p(x, y)$ over $D_n$ using the projection map $\pi_x$ into two univariate polynomials $p_0(x)$ and $p_1(x)$ as follows:
+
$$p(x, y) = p_0(\pi_x(x, y)) + y \cdot p_1(\pi_x(x, y)) = p_0(x) + y \cdot p_1(x)$$
Now to continue with the FFT algorithm, we want to compute the evaluations of $p_0(x)$ and $p_1(x)$ over the smaller domain $S_n = \pi_x(D_n)$, given the evaluations of $p(x, y)$ over $D_n$. This is done using the following equations:
@@ -52,20 +58,50 @@ To compute the evaluations of $p_1(x)$ over the domain $S_n$, we subtract the ev
+> > $$D_3 = [(7, 18), (13, 7), (24, 13), (18, 24), (7, 13), (13, 24), (24, 18), (18, 7)]$$ +> +>
+> > and we want to compute the coefficients of $p(x, y)$ i.e. interpolate $p(x, y)$ given its evaluations $\vec{v}$ over $D_3$. > -> **Step 1**: . First, decompose the polynomial $p(x, y)$ using the map $\pi_x(x, y) = x$: +>
+>
+> +> **Step 1**: First, decompose the polynomial $p(x, y)$ using the map $\pi_x(x, y) = x$: +> +>
> > $$p(x, y) = p_0(\pi_x(x, y)) + y \cdot p_1(\pi_x(x, y)) = p_0(x) + y \cdot p_1(x)$$ > +>
+> > Given the evaluations $\vec{v}$ of $p(x, y)$ over the circle domain $D_3$ we aim to compute the evaluations of $p_0$ and $p_1$ over the smaller domain $S_3$: +> +>
+> > $$S_3 = \pi_x(D_3) = [7, 13, 24, 18]$$ +> +>
+> > For $(x, y)=(7, 18)$ and $(x, -y) = (7, 13)$ in $D_3$, substituting them into the following equations give: +> +>
+> > $$p_0(x) = \frac{p(x, y) + p(x, -y)}{2} = \frac{p(7, 18) + p(7, 13)}{2} = \frac{13 + 29}{2} = 21$$ +> +>
+> > $$p_1(x) = \frac{p(x, y) - p(x, -y)}{2 \cdot y} = \frac{p(7, 18) - p(7, 13)}{2 \cdot 18} = \frac{13 - 29}{2 \cdot 18} = 3$$ > +>
+> > Repeating this process for other pairs $(x, y)$ and $(x, -y)$ in $D_3$, we obtain: +> +>
+> > $$\vec{v_0} = [21, 6, 11, 10], \quad \vec{v_1} = [3, 28, 7, 6]$$ #### Step 2: Recursively apply FFT to sub-polynomials @@ -93,15 +129,33 @@ Similar to _circle twiddles_, to compute the evaluations of $p_{01}(x)$ over $S_
+> > $$\vec{v_0} = [21, 6, 11, 10], \quad \vec{v_1} = [3, 28, 7, 6]$$ +> +>
+> > we recursively apply the FFT algorithm to compute the coefficients of $p_0$ and $p_1$. > +>
+> > At each layer, we decompose the polynomial using the polynomial map $\pi(x)$. For example, the decomposition of $p_0(x)$ is: > +>
+> > $$p_0(x) = p_{00}(\pi(x)) + x \cdot p_{01}(\pi(x))$$ > +>
+> > Omitting the intermediate steps of the recursive calls, we eventually obtain the coefficients of $p_0(x)$ and $p_1(x)$ as follows: +> +>
+> > $$p_0(x) = 12 + 26 \cdot x + \pi(x) + 28 \cdot x \cdot \pi(x)$$ +> +>
+> > $$p_1(x) = 11 + 26 \cdot x + 14 \cdot \pi(x) + 20 \cdot x \cdot \pi(x)$$ #### Step 3: Combine the coefficients @@ -110,14 +164,37 @@ Finally, we combine the coefficients of $p_0(x)$ and $p_1(x)$ to compute the coe $$p(x, y) = p_0(x) + y \cdot p_1(x)$$ > **Step 3**: Given the coefficients of $p_0(x)$ and $p_1(x)$: +> +>
+> > $$p_0(x) = 12 + 26 \cdot x + \pi(x) + 28 \cdot x \cdot \pi(x)$$ +> +>
+> > $$p_1(x) = 11 + 26 \cdot x + 14 \cdot \pi(x) + 20 \cdot x \cdot \pi(x)$$ +> +>
+> > we reconstruct the original polynomial $p(x, y)$ using the decomposition: +> +>
+> > $$p(x, y) = p_0(x) + y \cdot p_1(x)$$ > +>
+> > Substituting the expressions for $p_0$ and $p_1$, we get: +> +>
+> > $$p(x, y) = 12 + 26 \cdot x + \pi(x) + 28 \cdot x \cdot \pi(x) + y \cdot (11 + 26 \cdot x + 14 \cdot \pi(x) + 20 \cdot x \cdot \pi(x))$$ +> +>
+> > $$p(x, y) = 12 + 26 \cdot x + \pi(x) + 28 \cdot x \cdot \pi(x) + \quad \quad \quad \quad \quad \quad$$ +> +>
+> > $$\quad \quad \quad \quad \quad \quad 11 \cdot y + 26 \cdot x \cdot y + 14 \cdot y \cdot \pi(x) + 20 \cdot x \cdot y \cdot \pi(x)$$ This completes an overview of the interpolation algorithm using Circle FFT. In the next section, we will see how the twiddle values are computed and stored for Circle FFT. diff --git a/learn/S-two-book/how-it-works/circle-fft/basis.mdx b/learn/S-two-book/how-it-works/circle-fft/basis.mdx index 9c07a9df1e..4d53a54695 100644 --- a/learn/S-two-book/how-it-works/circle-fft/basis.mdx +++ b/learn/S-two-book/how-it-works/circle-fft/basis.mdx @@ -7,7 +7,7 @@ The circle FFT algorithm outputs coefficients $c_j$ with respect to some basis $ $$p(x, y) = \sum_{j = 0}^{2^n - 1} c_j \cdot b_j^{(n)}(x, y)$$ -In the concrete example (covered in the [Algorithm section](./algorithm)) of Circle FFT over twin-coset $D_3$, we saw that the algorithm computed the coefficient with respect to the following basis: +In the concrete example (covered in the [Algorithm section](/learn/S-two-book/how-it-works/circle-fft/algorithm)) of Circle FFT over twin-coset $D_3$, we saw that the algorithm computed the coefficient with respect to the following basis: $$b^{(3)}_j(x, y) = [1, x, \pi(x), x \cdot \pi(x), y, y \cdot x, y \cdot \pi(x), y \cdot x \cdot \pi(x)]$$ @@ -21,7 +21,7 @@ $$j = j_0 + j_1 \cdot 2 + \cdots + j_{n-1} \cdot 2^{n-1}$$ # Dimension Gap -We will now explore the space of polynomials interpolated by the Circle FFT algorithm. Let the space spanned by the basis polynomials in $b^{(n)}(x, y)$ be $L'_N(F)$. The basis $b^{(n)}(x, y)$ has a total of $N=2^n$ elements and thus the dimension of the space $L'_N(F)$ is $N$. However, the space of bivariate polynomials over the circle curve is $L_N(F)$, which has dimension $N+1$ (as covered in the [section on polynomials over the circle](../circle-polynomials/evals-and-poly.mdx#polynomials-over-the-circle)). +We will now explore the space of polynomials interpolated by the Circle FFT algorithm. Let the space spanned by the basis polynomials in $b^{(n)}(x, y)$ be $L'_N(F)$. The basis $b^{(n)}(x, y)$ has a total of $N=2^n$ elements and thus the dimension of the space $L'_N(F)$ is $N$. However, the space of bivariate polynomials over the circle curve is $L_N(F)$, which has dimension $N+1$ (as covered in the [section on polynomials over the circle](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly#polynomials-over-the-circle)). We can identify the missing highest total degree element in $L'_N(F)$ by examining the basis. The highest total degree element in basis $b^{(n)}(x, y)$ is: $$y \cdot x \cdot \pi(x) \cdot \pi^2(x) \cdot \pi^3(x) \cdots \pi^{n-2}(x)$$ diff --git a/learn/S-two-book/how-it-works/circle-fft/index.mdx b/learn/S-two-book/how-it-works/circle-fft/index.mdx index b7892eb1a9..4bd9ee35af 100644 --- a/learn/S-two-book/how-it-works/circle-fft/index.mdx +++ b/learn/S-two-book/how-it-works/circle-fft/index.mdx @@ -1,5 +1,5 @@ --- -title: "Circle FFT" +title: "Introduction" --- @@ -7,7 +7,7 @@ title: "Circle FFT" This section is organized as follows: -- **[Algorithm](./algorithm)**: Overview of the Circle FFT algorithm with concrete examples showing the three-step interpolation process. -- **[Twiddles](./twiddles)**: Precomputation and storage of twiddle values required for efficient FFT operations. -- **[Interpolate](./interpolation)**: Detailed implementation walkthrough of the interpolation function with code breakdown. -- **[Basis and Dimension Gap](./basis)**: FFT basis for Circle FFT and analysis of the dimension gap in circle polynomial spaces. \ No newline at end of file +- **[Algorithm](/learn/S-two-book/how-it-works/circle-fft/algorithm)**: Overview of the Circle FFT algorithm with concrete examples showing the three-step interpolation process. +- **[Twiddles](/learn/S-two-book/how-it-works/circle-fft/twiddles)**: Precomputation and storage of twiddle values required for efficient FFT operations. +- **[Interpolate](/learn/S-two-book/how-it-works/circle-fft/interpolation)**: Detailed implementation walkthrough of the interpolation function with code breakdown. +- **[Basis and Dimension Gap](/learn/S-two-book/how-it-works/circle-fft/basis)**: FFT basis for Circle FFT and analysis of the dimension gap in circle polynomial spaces. diff --git a/learn/S-two-book/how-it-works/circle-fft/interpolation.mdx b/learn/S-two-book/how-it-works/circle-fft/interpolation.mdx index 394ea6ad2d..d3b9fd7a74 100644 --- a/learn/S-two-book/how-it-works/circle-fft/interpolation.mdx +++ b/learn/S-two-book/how-it-works/circle-fft/interpolation.mdx @@ -71,7 +71,7 @@ The function includes hardcoded implementations for circle domains of small size - The `circle_twiddles` are twiddles required at the first layer where all points are projected to the $x$-axis. These correspond to the $y$-coordinate points in the half coset. - The `line_twiddles` are twiddles required to compute FFT at the subsequent recursive layers where the squaring map $\pi$ is used as the 2-to-1 map. - > For the example of the [half coset](./twiddles.mdx#fig-half-coset), there are three FFT layers: one layer with the projection map $\pi_x$ and two recursive layers with the squaring map $\pi$. + > For the example of the [half coset](/learn/S-two-book/how-it-works/circle-fft/twiddles#fig-half-coset), there are three FFT layers: one layer with the projection map $\pi_x$ and two recursive layers with the squaring map $\pi$. > > The `line_twiddles` for the two recursive layers are computed using the inverse twiddles $[a^{-1}, b^{-1}, \pi(a)^{-1}, 1]$. For the first recursive layer, the twiddles are the inverse of the $x$-coordinates: $[a^{-1}, b^{-1}]$. For the second recursive layer, the twiddles are the inverse of the square of the $x$-coordinates: $[\pi(a)^{-1}]$. Thus for this example, the `line_twiddles` are $[[a^{-1}, b^{-1}], [\pi(a)^{-1}]]$. diff --git a/learn/S-two-book/how-it-works/circle-fft/twiddles.mdx b/learn/S-two-book/how-it-works/circle-fft/twiddles.mdx index 52d063269b..485d87886d 100644 --- a/learn/S-two-book/how-it-works/circle-fft/twiddles.mdx +++ b/learn/S-two-book/how-it-works/circle-fft/twiddles.mdx @@ -27,7 +27,7 @@ For `CpuBackend`, `B::Twiddles` is a vector of `BaseField` elements. Here, `root Now we will understand how the twiddle tree is computed using an example. Consider the following half coset $q + \langle g_2 \rangle$ of a circle domain $D_3$.
- 
+ 
*Figure 1: Half Coset of size 4*
diff --git a/learn/S-two-book/how-it-works/circle-fri/fri_prover.mdx b/learn/S-two-book/how-it-works/circle-fri/fri_prover.mdx
index 88df4ff41c..8aac1a19fe 100644
--- a/learn/S-two-book/how-it-works/circle-fri/fri_prover.mdx
+++ b/learn/S-two-book/how-it-works/circle-fri/fri_prover.mdx
@@ -30,7 +30,7 @@ We calculate the security bits of our protocol as follows:
self.log_blowup_factor * self.n_queries as u32
}
```
-This is as we discussed in the [Security Analysis section](./overview.mdx#security-analysis).
+This is as we discussed in the [Security Analysis section](/learn/S-two-book/how-it-works/circle-fri/overview#security-analysis).
## Proving
@@ -44,10 +44,10 @@ pub struct FriProver<'a, B: FriOps + MerkleOps
- 
-
-*Figure 1: Sequence of domains for Circle FRI*
+ {
assert!(n <= M31_CIRCLE_LOG_ORDER); // M31_CIRCLE_LOG_ORDER = 31
let s = 1 << (M31_CIRCLE_LOG_ORDER - n);
diff --git a/learn/S-two-book/how-it-works/circle-polynomials/index.mdx b/learn/S-two-book/how-it-works/circle-polynomials/index.mdx
index 31b19efe21..e81e971a43 100644
--- a/learn/S-two-book/how-it-works/circle-polynomials/index.mdx
+++ b/learn/S-two-book/how-it-works/circle-polynomials/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Circle Polynomials"
+title: "Introduction"
---
@@ -7,6 +7,6 @@ title: "Circle Polynomials"
This section is organized as follows:
-- **[Columns](./columns)**: How computation trace data is stored in columns, including both base field and secure field representations.
-- **[Circle Evaluations and Polynomials](./evals-and-poly)**: Point-value and coefficient representations of polynomials, their mathematical foundations, and conversion between forms.
-- **[Secure Evaluations and Polynomials](./secure-evals-and-poly)**: Extension to secure field polynomials using the quartic extension QM31, with implementation details.
\ No newline at end of file
+- **[Columns](/learn/S-two-book/how-it-works/circle-polynomials/columns)**: How computation trace data is stored in columns, including both base field and secure field representations.
+- **[Circle Evaluations and Polynomials](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly)**: Point-value and coefficient representations of polynomials, their mathematical foundations, and conversion between forms.
+- **[Secure Evaluations and Polynomials](/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly)**: Extension to secure field polynomials using the quartic extension QM31, with implementation details.
diff --git a/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly.mdx b/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly.mdx
index e909bbc751..d8f1a1436d 100644
--- a/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly.mdx
+++ b/learn/S-two-book/how-it-works/circle-polynomials/secure-evals-and-poly.mdx
@@ -1,9 +1,10 @@
---
-title: "Secure Evaluations"
+title: "Secure Evaluations and Polynomials"
---
+# Secure Evaluations
-Similar to `CircleEvaluation`, `SecureEvaluation` is a [point-value representation](./evals-and-poly.mdx#point-value-representation) of a polynomial whose evaluations over the `CircleDomain` are from the `SecureField` (an alias for `QM31`). This is implemented as follows:
+Similar to `CircleEvaluation`, `SecureEvaluation` is a [point-value representation](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly#point-value-representation) of a polynomial whose evaluations over the `CircleDomain` are from the `SecureField` (an alias for `QM31`). This is implemented as follows:
```rust
pub struct SecureEvaluation, EvalOrder> {
@@ -13,7 +14,7 @@ pub struct SecureEvaluation, EvalOrder> {
}
```
-As discussed in the [previous subsection](./columns.mdx#secure-field-columns), each `SecureField` element is represented by four base field elements and stored in four consecutive columns. Thus the evaluations are represented as `SecureColumnByCoords`, as shown above.
+As discussed in the [previous subsection](/learn/S-two-book/how-it-works/circle-polynomials/columns#secure-field-columns), each `SecureField` element is represented by four base field elements and stored in four consecutive columns. Thus the evaluations are represented as `SecureColumnByCoords`, as shown above.
Similar to `CircleEvaluation`, we can interpolate a `SecureCirclePoly` with coefficients from the `SecureField` as shown below:
@@ -34,12 +35,16 @@ impl SecureEvaluation {
# Secure Circle Polynomials
-Similar to `CirclePoly`, `SecureCirclePoly` is a [coefficient representation](./evals-and-poly.mdx#coefficient-representation) of a polynomial whose coefficients are from the `SecureField`. As discussed in the [earlier section](./evals-and-poly.mdx#eq-circle-poly), we can define a circle polynomial as follows:
+Similar to `CirclePoly`, `SecureCirclePoly` is a [coefficient representation](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly#coefficient-representation) of a polynomial whose coefficients are from the `SecureField`. As discussed in the [earlier section](/learn/S-two-book/how-it-works/circle-polynomials/evals-and-poly#eq-circle-poly), we can define a circle polynomial as follows:
+
$$p(x, y) = \sum_{j=0}^{2^n -1} v_j \cdot y^{j_0} \cdot x^{j_1} \cdot \pi(x)^{j_2} \cdot \pi^2(x)^{j_3} \cdots \pi^{n-2}(x)^{j_{n-1}}$$
+
Here, $v_j$ are the coefficients from `SecureField` (i.e. $\mathsf{QM31}$). We can represent the coefficient $v_j$ using four elements from the `BaseField` (i.e. $\mathsf{M31}$) as follows:
+
$$v_j = (a_j + i \cdot b_j) + (c_j + i \cdot d_j) \cdot u$$
where $a_j, b_j, c_j, d_j \in \mathsf{M31}$. Substituting the above representation in the equation of $p(x, y)$ we get:
+
$$p(x, y) = \sum_{j=0}^{2^n -1} \Big(a_j + i \cdot b_j + u \cdot c_j + i \cdot u \cdot d_j \Big) \cdot y^{j_0} \cdot x^{j_1} \cdot \pi(x)^{j_2} \cdot \pi^2(x)^{j_3} \cdots \pi^{n-2}(x)^{j_{n-1}}$$
$$p(x, y) = \sum_{j=0}^{2^n -1} a_j \cdot y^{j_0} \cdot x^{j_1} \cdot \pi(x)^{j_2} \cdots \pi^{n-2}(x)^{j_{n-1}} \\ + \\ i \cdot \sum_{j=0}^{2^n -1} b_j \cdot y^{j_0} \cdot x^{j_1} \cdot \pi(x)^{j_2} \cdots \pi^{n-2}(x)^{j_{n-1}} \\ + \\$$
@@ -71,4 +76,4 @@ Similar to `CirclePoly`, we can evaluate the `SecureCirclePoly` at points on the
}
```
-In the next section, we will see how the `interpolate` and `evaluate` functions convert between the two polynomial representations using Circle FFT. As you may have noticed, the twiddles are precomputed for efficiency, and we will explore this in the next section on Circle FFT.
\ No newline at end of file
+In the next section, we will see how the `interpolate` and `evaluate` functions convert between the two polynomial representations using Circle FFT. As you may have noticed, the twiddles are precomputed for efficiency, and we will explore this in the next section on Circle FFT.
diff --git a/learn/S-two-book/how-it-works/index.mdx b/learn/S-two-book/how-it-works/index.mdx
index 5effe6f5af..82466378e4 100644
--- a/learn/S-two-book/how-it-works/index.mdx
+++ b/learn/S-two-book/how-it-works/index.mdx
@@ -1,5 +1,5 @@
---
-title: "S-two: Under the Hood"
+title: "Introduction"
---
@@ -7,13 +7,13 @@ title: "S-two: Under the Hood"
The following topics are covered:
-- [**Mersenne Primes**](./mersenne-prime): Introduction to the Mersenne31 prime field used in S-two for efficient arithmetic.
-- [**Circle Group**](./circle-group): Explains the algebraic structure underlying FFT and polynomial operations.
-- [**Circle Polynomials**](./circle-polynomials/index): Details the representation and evaluation of polynomials in the circle group.
-- [**Circle FFT**](./circle-fft/index): Describes the fast Fourier transform algorithm adapted for the circle group.
-- [**Vector Commitment Scheme (VCS)**](./vcs/index): Covers the use of Merkle trees for committing to vectors and enabling efficient proofs of inclusion.
-- [**AIR to Composition Polynomial**](./air/index): Shows how algebraic constraints are encoded as polynomials for proof generation.
-- [**Circle FRI**](./circle-fri/index): Explains the FRI protocol for low-degree testing of polynomials over the circle group.
-- [**Polynomial Commitment Scheme (PCS)**](./pcs/index): Describes the protocol for committing to and opening polynomials with soundness guarantees.
-- [**Proof Generation and Verification**](./stark_proof/index): Walks through the process of generating and verifying a STARK proof in S-two.
-- [**Lookups**](./lookups): Discusses lookup arguments and their implementation in S-two for efficient constraint checking.
+- [**Mersenne Primes**](/learn/S-two-book/how-it-works/mersenne-prime): Introduction to the Mersenne31 prime field used in S-two for efficient arithmetic.
+- [**Circle Group**](/learn/S-two-book/how-it-works/circle-group): Explains the algebraic structure underlying FFT and polynomial operations.
+- [**Circle Polynomials**](/learn/S-two-book/how-it-works/circle-polynomials/index): Details the representation and evaluation of polynomials in the circle group.
+- [**Circle FFT**](/learn/S-two-book/how-it-works/circle-fft/index): Describes the fast Fourier transform algorithm adapted for the circle group.
+- [**Vector Commitment Scheme**](/learn/S-two-book/how-it-works/vcs/index): Covers the use of Merkle trees for committing to vectors and enabling efficient proofs of inclusion.
+- [**AIR to Composition Polynomial**](/learn/S-two-book/how-it-works/air/index): Shows how algebraic constraints are encoded as polynomials for proof generation.
+- [**Circle FRI**](/learn/S-two-book/how-it-works/circle-fri/index): Explains the FRI protocol for low-degree testing of polynomials over the circle group.
+- [**Polynomial Commitment Scheme**](/learn/S-two-book/how-it-works/pcs/index): Describes the protocol for committing to and opening polynomials with soundness guarantees.
+- [**Proof Generation and Verification**](/learn/S-two-book/how-it-works/stark_proof/index): Walks through the process of generating and verifying a STARK proof in S-two.
+- [**Lookups**](/learn/S-two-book/how-it-works/lookups): Discusses lookup arguments and their implementation in S-two for efficient constraint checking.
diff --git a/learn/S-two-book/how-it-works/lookups.mdx b/learn/S-two-book/how-it-works/lookups.mdx
index bdc8c04c5b..f55ca670b0 100644
--- a/learn/S-two-book/how-it-works/lookups.mdx
+++ b/learn/S-two-book/how-it-works/lookups.mdx
@@ -85,7 +85,7 @@ To create a constraint over the LogUp columns, S-two modifies the LogUp columns
*Figure 4: Cumulative sum columns*
-A constraint is created using the values of two rows of the cumulative sum LogUp column. For example, as in [Figure 5](#fig-lookup-implementation-5), we can create a constraint by subtracting $row_1$ from $row_2$ and checking that it equals the LogUp fraction created using values $a_2$ and $m_2$:
+A constraint is created using the values of two rows of the cumulative sum LogUp column. For example, as in **Figure 5**, we can create a constraint by subtracting $row_1$ from $row_2$ and checking that it equals the LogUp fraction created using values $a_2$ and $m_2$:
$$
\frac{m_2}{X - a_2} = row\_2 - row\_1
@@ -109,7 +109,7 @@ Where $\text{avg}$ is a witness value provided by the prover.
*Figure 6: Trick to not create a separate constraint for the first row*
-The right column in [Figure 6](#fig-lookup-implementation-6) is the final form of the LogUp column that S-two commits to as part of the interaction trace.
+The right column in **Figure 6** is the final form of the LogUp column that S-two commits to as part of the interaction trace.
## Batching
diff --git a/learn/S-two-book/how-it-works/mersenne-prime.mdx b/learn/S-two-book/how-it-works/mersenne-prime.mdx
index 99787c6fed..152ba6e4e8 100644
--- a/learn/S-two-book/how-it-works/mersenne-prime.mdx
+++ b/learn/S-two-book/how-it-works/mersenne-prime.mdx
@@ -17,15 +17,28 @@ The key advantage is extremely cheap modular reduction after a 31-bit multiplica
Suppose $x = a \cdot b$ then we can decompose $x$ into two 31-bit values $b$ and $s$, such that $x = 2^{31} \cdot b + s$, as shown in the following figure.
-
+ 
+ Figure 1: Sequence of domains for Circle FRI
As shown in the above diagram, we use two different maps, as in the circle FFT algorithm: the projection map $\pi_x$ and the squaring map $\pi$. Here, $I_i$ is the "line" domain; for every $i$ in $\{0,1,2\}$, $I_i = S_{3-i}$, where $S_{3-i}$ is the "line" domain of size $|S_{3-i}| = |D_{3-i}| / 2 = 2^{2-i+\beta}$.
@@ -64,7 +74,7 @@ Using circle FRI, the prover will prove proximity of functions $h_{0}$ to polyno
$$
h_{0,0}(x) = \frac{h_0(x,y)+h_0(x,-y)}{2} \quad, \quad h_{0,1}(x) = \frac{h_0(x,y)-h_0(x,-y)}{2y}.
$$
- Note that this decomposition and the process of finding evaluations of the decomposed functions is very similar to the circle FFT algorithm. Now the prover will fold the evaluations of $h_{0,0}$ and $h_{0,1}$ over the domain $I_0$ using the randomness $\lambda_0 \xleftarrow{\$} F$ from the verifier as follows:
+ Note that this decomposition and the process of finding evaluations of the decomposed functions is very similar to the circle FFT algorithm. Now the prover will fold the evaluations of $h_{0,0}$ and $h_{0,1}$ over the domain $I_0$ using the randomness $\lambda_0 \in F$ from the verifier as follows:
$$
g_0(x) = {\lambda_0}^2 \cdot (h_{0,0}(x) + \lambda_0 \cdot h_{0, 1}(x))
$$
@@ -77,7 +87,7 @@ Using circle FRI, the prover will prove proximity of functions $h_{0}$ to polyno
$$
g_{0,0}(2x^2 - 1) = \frac{g_0(x)+g_0(-x)}{2} \quad, \quad g_{0,1}(2x^2 - 1) = \frac{g_0(x)-g_0(-x)}{2x}.
$$
- Now the prover will fold the evaluations of $h_{1,0}$, $h_{1,1}$, $g_{0,0}$, and $g_{0,1}$ over the domain $I_1$ using the randomness $\lambda_1 \xleftarrow{\$} F$ from the verifier as follows:
+ Now the prover will fold the evaluations of $h_{1,0}$, $h_{1,1}$, $g_{0,0}$, and $g_{0,1}$ over the domain $I_1$ using the randomness $\lambda_1 \in F$ from the verifier as follows:
$$
g_1(x) = g_{0,0}(x) + \lambda_1 \cdot g_{0, 1}(x) + \lambda_1^2 \cdot (h_{1,0}(x) + \lambda_1 \cdot h_{1,1}(x))
$$
@@ -88,7 +98,7 @@ Using circle FRI, the prover will prove proximity of functions $h_{0}$ to polyno
$$
This is the final round, so the prover will send $g_2(x) \in F^{I_2}$ to the verifier in plain.
- Let us describe the protocol for the general case. In each round $i = \{0, \dots, r\}$, the prover has previous evaluations $g_{i-1} \in F^{I_{i-1}}$ (for round $i = 0$ we take $g_{-1} = 0$). The verifier sends $\lambda_i \xleftarrow{\$} F$ and the prover commits to $g_i \in F^{I_i}$, defined as follows:
+ Let us describe the protocol for the general case. In each round $i = \{0, \dots, r\}$, the prover has previous evaluations $g_{i-1} \in F^{I_{i-1}}$ (for round $i = 0$ we take $g_{-1} = 0$). The verifier sends $\lambda_i \in F$ and the prover commits to $g_i \in F^{I_i}$, defined as follows:
$$
g_i = g_{i-1,0} + \lambda_i \cdot g_{i-1,1} + \lambda_i^2 \cdot (h_{i,0} + \lambda_i \cdot h_{i,1})
@@ -123,4 +133,3 @@ Using circle FRI, the prover will prove proximity of functions $h_{0}$ to polyno
In this section, we analyze the security of the FRI protocol at a high level. There are roughly two ways a prover can cheat:
- The functions $h_{i} \in F^{H_i}$ are "far" from the polynomial space $L'_{3-i}(F)$ but somehow the prover gets lucky and ends up with $g_2 \in \mathcal{L}_0$. The [proximity gaps paper](https://eprint.iacr.org/2020/654.pdf) analyzes that this happens with negligible probability. That is, if even one of the functions $h_{i} \in F^{H_i}$ is "far" from the polynomial space $L'_{3-i}(F)$, then the function $g_2$ will be "far" from $\mathcal{L}_0$ with high probability.
- Now suppose $h_{i} \in F^{H_i}$ are "far" from the polynomial space $L'_{3-i}(F)$, then the function $g_2$ will be "far" from $\mathcal{L}_0$, but to cheat the verifier, the prover cheats in the folding rounds and sends some valid $g_2 \in \mathcal{L}_0$. Now the verifier must ensure that the prover has performed the folding correctly in each round using the oracles sent by the prover. This is exactly what the verifier checks in the query phase. From the "Toy Problem Conjecture" ([ethSTARK, Section 5.9](https://eprint.iacr.org/2021/582.pdf)), each query done by the verifier gives $\beta$ (i.e. log of blowup $B$) bits of security. Thus, for $s$ queries, the security is $s \cdot \beta$ bits.
-
diff --git a/learn/S-two-book/how-it-works/circle-group.mdx b/learn/S-two-book/how-it-works/circle-group.mdx
index 877c114b5d..c372453c61 100644
--- a/learn/S-two-book/how-it-works/circle-group.mdx
+++ b/learn/S-two-book/how-it-works/circle-group.mdx
@@ -60,7 +60,7 @@ In S-two implementation, the generator $g$ of the group $C(\textsf{M31})$ is def
$$g = (2, 1268011823)$$
Subgroups of $C(\textsf{M31})$ of size $2^n$ can be generated using the following function:
-```rust,no_run,noplayground
+```rust
pub fn subgroup_gen(n: u32) -> CirclePoint
+ Figure 1: Sequence of domains for Circle FRI
- 
-
-*Figure 1: Product decomposition*
+, MC: MerkleChannel> {
@@ -22,7 +22,7 @@ pub struct CommitmentTreeProver, MC: MerkleChannel> {
Here, `pub type ColumnVec = Vec`. It contains the following fields:
- `polynomials`: The set of polynomials committed in a single Merkle tree.
- `evaluations`: The evaluations of these polynomials over their respective domains.
-- `commitment`: The `MerkleProver` struct as described in the [Merkle tree section](../vcs/merkle_prover.mdx#merkleprover-structure).
+- `commitment`: The `MerkleProver` struct as described in the [Merkle tree section](/learn/S-two-book/how-it-works/vcs/merkle_prover#merkleprover-structure).
It is initialized as follows:
```rust
@@ -77,7 +77,7 @@ The security of the polynomial commitment scheme is computed as:
self.pow_bits + self.fri_config.security_bits()
}
```
-- `twiddles`: This contains [precomputed twiddle factors](../circle-fft/twiddles.mdx#twiddle-tree).
+- `twiddles`: This contains [precomputed twiddle factors](/learn/S-two-book/how-it-works/circle-fft/twiddles#twiddle-tree).
Now we will see some key functions defined on the `CommitmentSchemeProver` struct.
@@ -222,16 +222,16 @@ Here is a detailed breakdown:
- The `sampled_values` are mixed into the channel, ensuring they are bound to the proof and used for subsequent randomness generation.
2. **Compute FRI Quotients**:
- - The function computes FRI quotient polynomials using `compute_fri_quotients` to open the committed polynomials at sampled points in `samples`. This follows the same quotienting process as described in the [overview section](./overview.mdx#polynomial-commitment-scheme).
+ - The function computes FRI quotient polynomials using `compute_fri_quotients` to open the committed polynomials at sampled points in `samples`. This follows the same quotienting process as described in the [overview section](/learn/S-two-book/how-it-works/pcs/overview#polynomial-commitment-scheme).
3. **FRI Commitment Phase**:
- - The FRI protocol is run on the quotient polynomials, committing to their evaluations in Merkle trees and initializing the `fri_prover`. For more details, refer to the [FRI prover section](../circle-fri/fri_prover).
+ - The FRI protocol is run on the quotient polynomials, committing to their evaluations in Merkle trees and initializing the `fri_prover`. For more details, refer to the [FRI prover section](/learn/S-two-book/how-it-works/circle-fri/fri_prover).
4. **Proof of Work**:
- A proof-of-work step is performed, with the result mixed into the channel.
6. **FRI Decommitment Phase**:
- - The function generates random query positions using the channel and decommits the FRI layers at those positions, providing Merkle decommitments for all queried values. For more details, refer to the [FRI prover section](../circle-fri/fri_prover).
+ - The function generates random query positions using the channel and decommits the FRI layers at those positions, providing Merkle decommitments for all queried values. For more details, refer to the [FRI prover section](/learn/S-two-book/how-it-works/circle-fri/fri_prover).
7. **Decommitment of Committed Trees**:
- For each commitment tree, the function decommits the Merkle tree at the FRI query positions, providing the queried values and authentication paths.
diff --git a/learn/S-two-book/how-it-works/pcs/verifier.mdx b/learn/S-two-book/how-it-works/pcs/verifier.mdx
index e956a8b0df..d04baefc2b 100644
--- a/learn/S-two-book/how-it-works/pcs/verifier.mdx
+++ b/learn/S-two-book/how-it-works/pcs/verifier.mdx
@@ -9,7 +9,7 @@ In this section, we describe the implementation of the polynomial commitment sch
## Commitment Scheme Verifier
-The `CommitmentSchemeVerifier` struct manages the verification process for the polynomial commitment scheme. It maintains a collection of [Merkle verifiers](../vcs/merkle_verifier) (one for each commitment tree) and the protocol configuration.
+The `CommitmentSchemeVerifier` struct manages the verification process for the polynomial commitment scheme. It maintains a collection of [Merkle verifiers](/learn/S-two-book/how-it-works/vcs/merkle_verifier) (one for each commitment tree) and the protocol configuration.
```rust
pub struct CommitmentSchemeVerifier {
pub trees: TreeVec>,
diff --git a/learn/S-two-book/how-it-works/stark_proof/index.mdx b/learn/S-two-book/how-it-works/stark_proof/index.mdx
index 31a98704f7..ec854ce542 100644
--- a/learn/S-two-book/how-it-works/stark_proof/index.mdx
+++ b/learn/S-two-book/how-it-works/stark_proof/index.mdx
@@ -1,12 +1,12 @@
---
-title: "Proof Generation and Verification"
+title: "Introduction"
---
-> In this final section, we cover the implementation of the STARK prover and verifier. This section brings together all the components from previous sections and describes the complete STARK proof generation and verification algorithms. We explain the `prove` and `verify` functions used to generate and verify proofs, as introduced in the [Writing a Simple AIR section](../../air-development/writing-a-simple-air/proving-an-air).
+> In this final section, we cover the implementation of the STARK prover and verifier. This section brings together all the components from previous sections and describes the complete STARK proof generation and verification algorithms. We explain the `prove` and `verify` functions used to generate and verify proofs, as introduced in the [Writing a Simple AIR section](/learn/S-two-book/air-development/writing-a-simple-air/proving-an-air).
This section is organized as follows:
-- [**STARK Prover**](./prove): Details the implementation of the proof generation algorithm.
-- [**STARK Verifier**](./verify): Describes the verification algorithm.
+- [**STARK Prover**](/learn/S-two-book/how-it-works/stark_proof/prove): Details the implementation of the proof generation algorithm.
+- [**STARK Verifier**](/learn/S-two-book/how-it-works/stark_proof/verify): Describes the verification algorithm.
diff --git a/learn/S-two-book/how-it-works/stark_proof/prove.mdx b/learn/S-two-book/how-it-works/stark_proof/prove.mdx
index 5472d4ba6e..f55239175a 100644
--- a/learn/S-two-book/how-it-works/stark_proof/prove.mdx
+++ b/learn/S-two-book/how-it-works/stark_proof/prove.mdx
@@ -73,9 +73,9 @@ Let us go through the function in detail.
It takes the following as input:
-- `components`: A list of AIR components. For more details, refer to the [Components](../air/components) and [Prover Components](../air/prover_components) sections.
+- `components`: A list of AIR components. For more details, refer to the [Components](/learn/S-two-book/how-it-works/air/components) and [Prover Components](/learn/S-two-book/how-it-works/air/prover_components) sections.
- `channel`: A Fiat-Shamir channel for non-interactive randomness.
-- `commitment_scheme`: A `CommitmentSchemeProver` for committing to trace and composition polynomials. For more details, refer to the [PCS Prover section](../pcs/prover).
+- `commitment_scheme`: A `CommitmentSchemeProver` for committing to trace and composition polynomials. For more details, refer to the [PCS Prover section](/learn/S-two-book/how-it-works/pcs/prover).
It outputs a `StarkProof` object if successful, or a `ProvingError` if any constraint is not satisfied. The `StarkProof` object is a wrapper around `CommitmentSchemeProof`.
@@ -96,7 +96,7 @@ pub struct StarkProof(pub CommitmentSchemeProof);
3. **Composition Polynomial Construction**
- A `random_coeff` is drawn from the channel.
- - The `composition_poly` is computed as a random linear combination of all constraint quotient polynomials, using powers of the random coefficient. For more details, refer to the [Prover Components](../air/prover_components) section.
+ - The `composition_poly` is computed as a random linear combination of all constraint quotient polynomials, using powers of the random coefficient. For more details, refer to the [Prover Components](/learn/S-two-book/how-it-works/air/prover_components) section.
4. **Commit to the Composition Polynomial**
@@ -104,7 +104,7 @@ pub struct StarkProof(pub CommitmentSchemeProof);
5. **Out-of-Domain Sampling (OODS)**
- - An `oods_point` is drawn randomly from the channel. This point is used to bind the prover to a unique low-degree polynomial, preventing ambiguity in the list decoding regime. For more details, refer to the [Out-of-Domain Sampling](../pcs/overview.mdx#out-of-domain-sampling) section.
+ - An `oods_point` is drawn randomly from the channel. This point is used to bind the prover to a unique low-degree polynomial, preventing ambiguity in the list decoding regime. For more details, refer to the [Out-of-Domain Sampling](/learn/S-two-book/how-it-works/pcs/overview#out-of-domain-sampling) section.
6. **Determine Sample Points**
@@ -112,7 +112,7 @@ pub struct StarkProof(pub CommitmentSchemeProof);
7. **Openings and Proof Generation**
- - The `commitment_scheme` is asked to open all committed polynomials at the sampled points, producing the required evaluations and Merkle authentication paths. This is handled by the `prove_values` function, which also integrates the FRI protocol for low-degree testing. For more details, refer to the [PCS Prover](../pcs/prover.mdx#prove) section.
+ - The `commitment_scheme` is asked to open all committed polynomials at the sampled points, producing the required evaluations and Merkle authentication paths. This is handled by the `prove_values` function, which also integrates the FRI protocol for low-degree testing. For more details, refer to the [PCS Prover](/learn/S-two-book/how-it-works/pcs/prover#prove) section.
8. **Sanity Check**
diff --git a/learn/S-two-book/how-it-works/stark_proof/verify.mdx b/learn/S-two-book/how-it-works/stark_proof/verify.mdx
index b144da9973..d37a532a75 100644
--- a/learn/S-two-book/how-it-works/stark_proof/verify.mdx
+++ b/learn/S-two-book/how-it-works/stark_proof/verify.mdx
@@ -75,9 +75,9 @@ Let us go through the function in detail.
The `verify` function is the entry point for verifying a STARK proof. It takes as input:
-- `components`: A list of AIR components. For more details, refer to the [Components](../air/components) section.
+- `components`: A list of AIR components. For more details, refer to the [Components](/learn/S-two-book/how-it-works/air/components) section.
- `channel`: A Fiat-Shamir channel for non-interactive randomness.
-- `commitment_scheme`: A `CommitmentSchemeVerifier` for verifying Merkle commitments and FRI proofs. For more details, refer to the [PCS Verifier section](../pcs/verifier).
+- `commitment_scheme`: A `CommitmentSchemeVerifier` for verifying Merkle commitments and FRI proofs. For more details, refer to the [PCS Verifier section](/learn/S-two-book/how-it-works/pcs/verifier).
- `proof`: The `StarkProof` object to be verified.
diff --git a/learn/S-two-book/how-it-works/vcs/index.mdx b/learn/S-two-book/how-it-works/vcs/index.mdx
index 645fd3beae..c5738fa92d 100644
--- a/learn/S-two-book/how-it-works/vcs/index.mdx
+++ b/learn/S-two-book/how-it-works/vcs/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Vector Commitment Scheme"
+title: "Introduction"
---
@@ -9,6 +9,6 @@ title: "Vector Commitment Scheme"
This section is organized as follows:
-- **[Hash Functions](./hash_functions)**: Overview of the hash function traits and implementations used in Merkle trees.
-- **[Merkle Prover](./merkle_prover)**: The commitment process that builds Merkle trees from column data and the decommitment process that generates proofs for queried elements.
-- **[Merkle Verifier](./merkle_verifier)**: The verification process that checks the validity of Merkle proofs against a committed root.
+- **[Hash Functions](/learn/S-two-book/how-it-works/vcs/hash_functions)**: Overview of the hash function traits and implementations used in Merkle trees.
+- **[Merkle Prover](/learn/S-two-book/how-it-works/vcs/merkle_prover)**: The commitment process that builds Merkle trees from column data and the decommitment process that generates proofs for queried elements.
+- **[Merkle Verifier](/learn/S-two-book/how-it-works/vcs/merkle_verifier)**: The verification process that checks the validity of Merkle proofs against a committed root.
diff --git a/learn/S-two-book/how-it-works/vcs/merkle_prover.mdx b/learn/S-two-book/how-it-works/vcs/merkle_prover.mdx
index b24ee4130c..2ae2c088b6 100644
--- a/learn/S-two-book/how-it-works/vcs/merkle_prover.mdx
+++ b/learn/S-two-book/how-it-works/vcs/merkle_prover.mdx
@@ -72,10 +72,21 @@ Let's walk through the function step by step:
Suppose the input column data is as shown below:
-
+ 
+ Figure 1: Product decomposition
To perform modular reduction, we start with:
+
$$x \equiv (2^{31} \cdot b + s) \quad mod \quad (2^{31} - 1)$$
+
Substituting $2^{31} \equiv 1 \mod (2^{31} - 1)$ gives:
+
$$x \equiv (b + s) \quad mod \quad (2^{31} - 1)$$
Since $b$ and $s$ are both 31-bit values, they can be directly represented as field elements. Consequently, modular reduction is performed with a single field addition. This makes arithmetic over Mersenne primes exceptionally fast, making them an ideal choice for our STARK protocol. The above field multiplication is implemented as:
@@ -58,8 +71,8 @@ impl_field!(M31, P);
Since we work over extensions of $\textsf{M31}$, it has the type alias `BaseField`, as follows:
-```rust,no_run,noplayground
-{{#webinclude https://raw.githubusercontent.com/starkware-libs/stwo/0790eba46b8af5697083d84fb75bd34b08a0b31f/crates/stwo/src/core/fields/m31.rs 33}}
+```rust
+pub type BaseField = M31;
```
# Extensions of Mersenne Prime Field
diff --git a/learn/S-two-book/how-it-works/pcs/index.mdx b/learn/S-two-book/how-it-works/pcs/index.mdx
index b374c2fcf9..0ecd491a71 100644
--- a/learn/S-two-book/how-it-works/pcs/index.mdx
+++ b/learn/S-two-book/how-it-works/pcs/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Polynomial Commitment Scheme"
+title: "Introduction"
---
@@ -7,6 +7,6 @@ title: "Polynomial Commitment Scheme"
This section is organized as follows:
-- [**Overview**](./overview): Describes the polynomial commitment scheme of S-two.
-- [**PCS Prover**](./prover): Details the implementation of the prover for the polynomial commitment scheme, including commitment and opening protocol.
-- [**PCS Verifier**](./verifier): Describes the verifier implementation for checking commitments and evaluation proofs.
\ No newline at end of file
+- [**Overview**](/learn/S-two-book/how-it-works/pcs/overview): Describes the polynomial commitment scheme of S-two.
+- [**PCS Prover**](/learn/S-two-book/how-it-works/pcs/prover): Details the implementation of the prover for the polynomial commitment scheme, including commitment and opening protocol.
+- [**PCS Verifier**](/learn/S-two-book/how-it-works/pcs/verifier): Describes the verifier implementation for checking commitments and evaluation proofs.
\ No newline at end of file
diff --git a/learn/S-two-book/how-it-works/pcs/overview.mdx b/learn/S-two-book/how-it-works/pcs/overview.mdx
index 885ea8aacf..2f695411f7 100644
--- a/learn/S-two-book/how-it-works/pcs/overview.mdx
+++ b/learn/S-two-book/how-it-works/pcs/overview.mdx
@@ -50,7 +50,7 @@ One key property of a polynomial commitment scheme is binding. Informally, the b
## Out of Domain Sampling
-Out-of-domain sampling relates to the notion of "closeness" described in the [FRI section](../circle-fri/overview.mdx#introduction). Informally, the FRI protocol tests whether a function provided by the prover is "close" to some bounded degree polynomial. There are two notions of "closeness":
+Out-of-domain sampling relates to the notion of "closeness" described in the [FRI section](/learn/S-two-book/how-it-works/circle-fri/overview#introduction). Informally, the FRI protocol tests whether a function provided by the prover is "close" to some bounded degree polynomial. There are two notions of "closeness":
1. **Unique Decoding Regime**: We operate in this regime if there is at most a single polynomial which is "close" to the function provided by the prover. If the function is "close" to a single polynomial, then we can infer that the function represents that _unique_ polynomial.
2. **List Decoding Regime**: We operate in this regime if there is a list of polynomials which are "close" to the function provided by the prover. In this case, since the function can be "close" to a _list_ of polynomials, we cannot be sure that it represents a unique polynomial.
@@ -62,7 +62,7 @@ In practice, we are usually operate in the list decoding regime. So there can be
To bind the prover to a unique polynomial from the list, we ask the prover to open the polynomial at an out-of-domain point. This is also referred to as _Domain Extension for Eliminating Pretenders_ (or the _DEEP method_). This is the informal motivation for out-of-domain sampling. For more details, please refer to ["A summary on the FRI low degree test"](https://eprint.iacr.org/2022/1216.pdf).
-As we have seen in the [Security Analysis section](../circle-fri/overview.mdx#security-analysis), we can improve security by increasing the number of verifier queries. But this will lead to more prover work, because the prover will have to send a Merkle decommitment for each verifier query and also increase the proof size. We will now see a method to increase the security of our protocol without significantly increasing the prover's work.
+As we have seen in the [Security Analysis section](/learn/S-two-book/how-it-works/circle-fri/overview#security-analysis), we can improve security by increasing the number of verifier queries. But this will lead to more prover work, because the prover will have to send a Merkle decommitment for each verifier query and also increase the proof size. We will now see a method to increase the security of our protocol without significantly increasing the prover's work.
## Proof of Work
diff --git a/learn/S-two-book/how-it-works/pcs/prover.mdx b/learn/S-two-book/how-it-works/pcs/prover.mdx
index 2285dc6574..fa54faaab4 100644
--- a/learn/S-two-book/how-it-works/pcs/prover.mdx
+++ b/learn/S-two-book/how-it-works/pcs/prover.mdx
@@ -9,7 +9,7 @@ In this section, we will see the implementation of the commitment scheme prover.
## Commitment Tree Prover
-The `CommitmentTreeProver` struct represents the data for a single Merkle tree commitment. As we have seen in the [Merkle tree section](../vcs/merkle_prover.mdx#merkle-prover), we can commit to multiple polynomials of different degrees in the same Merkle tree. It is implemented as follows:
+The `CommitmentTreeProver` struct represents the data for a single Merkle tree commitment. As we have seen in the [Merkle tree section](/learn/S-two-book/how-it-works/vcs/merkle_prover#merkle-prover), we can commit to multiple polynomials of different degrees in the same Merkle tree. It is implemented as follows:
```rust
pub struct CommitmentTreeProver
+ Figure 1: Product decomposition
- 
-
-*Figure 1: Example column data to commit using a Merkle tree*
+
+ 
+ Figure 1: Example column data to commit using a Merkle tree
For this example, the columns are already in the sorted order: $\textcolor{red}{\text{\textit{Column} 0}}$, $\textcolor{green}{\text{\textit{Column} 1}}$, $\textcolor{blue}{\text{\textit{Column} 2}}$ (from longest to shortest). We will now compute the hashes stored at each layer.
@@ -90,10 +101,21 @@ For this example, the columns are already in the sorted order: $\textcolor{red}{
The resulting Merkle tree is illustrated below:
-
+ Figure 1: Example column data to commit using a Merkle tree
- 
-
-*Figure 2: Merkle tree structure after commitment*
+
+ 
+ Figure 2: Merkle tree structure after commitment
@@ -222,7 +244,7 @@ Let's break down the function step by step:
### Example: Decommit Process
-For the column data in [Figure 1](#fig-merkle-tree-data), consider the query indices $[(2, [0]), (1, [1])]$, where the query indices are maps from log size to a vector of query indices for columns of that size. This corresponds to querying the following elements:
+For the column data in **Figure 1**, consider the query indices $[(2, [0]), (1, [1])]$, where the query indices are maps from log size to a vector of query indices for columns of that size. This corresponds to querying the following elements:
- The 0th element of columns of size $2^2=4$: $\textcolor{red}{a}$ from $\textcolor{red}{\text{\textit{Column} 0}}$ and $\textcolor{green}{p}$ from $\textcolor{green}{\text{\textit{Column} 1}}$.
- The 1st element of the column of size $2^1=2$: $\textcolor{blue}{v}$ from $\textcolor{blue}{\text{\textit{Column} 2}}$.
@@ -272,4 +294,4 @@ Below is a walkthrough of the main loop in the `decommit` function, showing the
- `hash_witness`: $[h_{01}, h_{10}, h_{11}]$
- `column_witness`: $[\textcolor{blue}{u}]$
-In the next section, we describe the verification process to verify the inclusion of the queried values using the Merkle decommitment.
\ No newline at end of file
+In the next section, we describe the verification process to verify the inclusion of the queried values using the Merkle decommitment.
diff --git a/learn/S-two-book/how-it-works/vcs/merkle_verifier.mdx b/learn/S-two-book/how-it-works/vcs/merkle_verifier.mdx
index 66f1fab1f4..814a808cd7 100644
--- a/learn/S-two-book/how-it-works/vcs/merkle_verifier.mdx
+++ b/learn/S-two-book/how-it-works/vcs/merkle_verifier.mdx
@@ -173,7 +173,7 @@ Let's break down the function step by step:
### Example: Verify the decommitment
-The same example from the [decommit process](./merkle_prover.mdx#example-decommit-process) is used to verify the output of the `decommit` function. The input to the `verify` function is as follows:
+The same example from the [decommit process](/learn/S-two-book/how-it-works/vcs/merkle_prover#example%3A-decommit-process) is used to verify the output of the `decommit` function. The input to the `verify` function is as follows:
- `queries_per_log_size`: $[(2, [0]), (1, [1])]$
- `queried_values`: $[\textcolor{red}{a}, \textcolor{green}{p}, \textcolor{blue}{v}]$
- `decommitment`:
@@ -226,4 +226,4 @@ Below is a walkthrough of the main loop in the `verify` function, showing how th
**Final verification:**
- Check that all iterators are exhausted: `hash_witness`, `queried_values`, and `column_witness` should all be empty.
- Compare the computed `root` with the expected root stored in the `MerkleVerifier`.
-- If they match, return `Ok(())`; otherwise, return `Err(MerkleVerificationError::RootMismatch)`.
\ No newline at end of file
+- If they match, return `Ok(())`; otherwise, return `Err(MerkleVerificationError::RootMismatch)`.
diff --git a/learn/S-two-book/why-stwo.mdx b/learn/S-two-book/why-stwo.mdx
index 4daec1797c..004255434d 100644
--- a/learn/S-two-book/why-stwo.mdx
+++ b/learn/S-two-book/why-stwo.mdx
@@ -17,18 +17,17 @@ S-two's backend is also optimized for prover performance. This is due to largely
2. Even amongst multiple STARK backends, however, S-two provides state-of-the-art prover performance by running the **Mersenne-31 prime field** (modulo $2^{31} - 1$), which is faster than another popular 32-bit prime field like BabyBear (modulo $2^{31} - 2^{27} + 1$). We suggest going through [this post](https://blog.zksecurity.xyz/posts/circle-starks-1/) for a breakdown of why this is the case.
-3. Finally, S-two offers **various CPU and GPU optimizations** that improves prover performance as shown in [Figure 1](#fig-optimizations) below. It can also be compiled to WASM, allowing for fast proving in web environments.
+3. Finally, S-two offers **various CPU and GPU optimizations** that improves prover performance as shown in [Figure 1](#figure-1) below. It can also be compiled to WASM, allowing for fast proving in web environments.
-
+ Figure 2: Merkle tree structure after commitment
+
-On zero-knowledge:
+
+**On zero-knowledge:**
As of the time of this writing, S-two does not provide the "zero-knowledge" feature. "Zero-knowledge" here refers to the fact that the proof should not reveal any additional information other than the validity of the statement, which is not true for S-two as it reveals to the verifier commitments to its witness values without hiding them by e.g. adding randomness. This reveals **some information** about the witness values, which may be used in conjunction with other information to infer the witness values.
-
+
-
*Figure 1: Prover performance optimizations in S-two*
One of the drawbacks of STARKs is that they have a larger proof size compared to elliptic curve-based SNARKs. One way to mitigate this drawback is by batching multiple proofs together to form a single proof.
-