Add section on AIRs to composition polynomial by varunthakore · Pull Request #34 · zksecurity/stwo-book

varunthakore · 2025-09-24T21:03:11Z

No description provided.

mellowcroc · 2025-09-26T09:27:26Z

+
+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.md#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.md). The prover then commits to the evaluations of trace polynomials from all components using a single [Merkle tree](../vcs/index.md).


is this correct? traces from different components are committed separately, no?

The execution trace which contains all the component tables of different sizes is committed in a single Merkle tree. This is an advantage of the Merkle tree construction used in Stwo where the internal nodes can also have values.

Consider this example: https://github.com/starkware-libs/stwo/blob/411d8c6a0142912d75fb38a5f28a767ef9dfb350/crates/examples/src/state_machine/mod.rs#L59-L74

The execution trace corresponding to both the opcodes i.e. op0 and op1 is committed using a single Merkle tree.

Ah yes you're right 😅 Please ignore

mellowcroc · 2025-10-02T07:24:23Z

+
+As shown in an earlier section (refer to [Components](../../air-development/components/index.md)), Stwo represents the trace using multiple tables where each table is referred to as a _component_. An AIR in Stwo 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.md#hash-function-example), the scheduling component and computing component interact with each other: the computing component looks up inputs from the scheduling component, and the scheduling component looks up outputs from the computing component. The consistency of this interaction is then verified by adding logUp constraints to each component.


I think this may have been from an earlier version, but now it's been changed to the scheduling component looking up the pair (input, output) from the computing component (or computing to scheduling component). It was changed because looking up the inputs and outputs separately can lead to a soundness issue (there's an example added in the linked section). Sorry if there was any confusion about this.

Thanks, updated this paragraph.

mellowcroc · 2025-10-02T07:58:42Z

+
+Finally, the prover computes the cross-domain composition polynomial as
+$$
+q = \gamma^{e_0} \cdot q_0 + \gamma^{e_1} \cdot q_1


I don't think randomness is used when combining the composition polynomials over multiple domains. (accumulate function, which is called here and defined here) We just use it for combining the constraints.

Instead, it would be nice to add an explanation that we expand all composition polynomials to the largest degree composition polynomial domain.

Instead, it would be nice to add an explanation that we expand all composition polynomials to the largest degree composition polynomial domain.

Just read to the end and saw that this is mentioned in the last section 😅 But I still think it would be nice to have an explanation here.

The implementation linked here is for the finalize() function called on the accumulator. But before calling the finalize() function, we evaluate the quotient for each component over their respective evaluation domain and then append those evaluations to the accumulator.

Finally, the finalize() function will combine all the evaluations of the quotients of all the components and then output a single composition quotient polynomial.

https://github.com/zksecurity/stwo/blob/26c65203535a467526d332412f84a9351c0df703/crates/stwo/src/prover/air/component_prover.rs#L61

This also matches the description in the Stwo whitepaper.

mellowcroc · 2025-10-02T08:01:24Z

+
+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. 
+
+The verifier sends $\gamma \in \mathsf{QM31}$ to the prover, which is used to compute the random linear combination of all constraints on component $\mathscr{T}_0$ to obtain the component-level composition polynomial $p_0$. Similarly, the prover uses powers of $\gamma$ to compute the component-level composition polynomial $p_1$ for component $\mathscr{T}_1$.


I think the explanation here is a little confusing. How about mentioning that we reuse the same \gamma to combine all constraints over all component tables? Also, adding an equation illustrating how we use the powers of \gamma over constraints would be nice.

mellowcroc · 2025-10-02T09:06:16Z

+
+The following are some important functions implemented for the `Components` struct.
+
+1. `composition_log_degree_bound`: This function determines the log of the degree of the composition polynomial.


It looks like the first line is shifted to the right because of the tab in L22?

mellowcroc · 2025-10-02T09:15:46Z

+    ```
+    From the perspective of the prover (and verifier), when they need to open the composition polynomial at a specific point sent by the verifier (for example, an out-of-domain point), they require additional polynomial evaluations to verify the constraints.
+
+    The composition polynomial combines many component-level constraint quotients. Each constraint involves relationships between multiple cells in the execution trace, potentially at different rows/offsets.


Should "multiple cells" be "multiple columns"?

I am referring to constraints between multiple cells using preprocessed selectors. I have omitted these details simplicity.

mellowcroc · 2025-10-02T09:20:21Z

+
+    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.md#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 = \gamma^{e_0} \cdot q_0 + \gamma^{e_1} \cdot q_1


Again, I don't think random linear combination is used here

Added a note on the previous comment.

mellowcroc

LGTM 👍

mellowcroc · 2025-10-14T06:25:02Z

+$$
+q = \gamma^{e_0} \cdot q_0 + \gamma^{e_1} \cdot q_1
+$$
+where $e_0, e_1$ are powers of $\gamma$ that have not been used earlier.


I guess e_0 and e_1 are not necessarily powers that have not been used earlier since they are set to e_0=gamma^0, e_1=gamma^{num_of_constraints_in_p_0}

Updated the section.

feat: add section on comp poly

bd9f4c7

varunthakore requested a review from mellowcroc September 24, 2025 21:03

mellowcroc reviewed Oct 2, 2025

View reviewed changes

fix: apply reviews

b61b153

varunthakore requested a review from mellowcroc October 8, 2025 20:55

mellowcroc approved these changes Oct 14, 2025

View reviewed changes

mellowcroc reviewed Oct 14, 2025

View reviewed changes

fix: powers of gamma

989e0ff

varunthakore merged commit 4e6504f into main Oct 15, 2025
1 check passed


		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.md#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.md). The prover then commits to the evaluations of trace polynomials from all components using a single [Merkle tree](../vcs/index.md).


		As shown in an earlier section (refer to [Components](../../air-development/components/index.md)), Stwo represents the trace using multiple tables where each table is referred to as a _component_. An AIR in Stwo 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.md#hash-function-example), the scheduling component and computing component interact with each other: the computing component looks up inputs from the scheduling component, and the scheduling component looks up outputs from the computing component. The consistency of this interaction is then verified by adding logUp constraints to each component.


		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.

		The verifier sends $\gamma \in \mathsf{QM31}$ to the prover, which is used to compute the random linear combination of all constraints on component $\mathscr{T}_0$ to obtain the component-level composition polynomial $p_0$. Similarly, the prover uses powers of $\gamma$ to compute the component-level composition polynomial $p_1$ for component $\mathscr{T}_1$.


		The following are some important functions implemented for the `Components` struct.

		1. `composition_log_degree_bound`: This function determines the log of the degree of the composition polynomial.

Uh oh!

Conversation

varunthakore commented Sep 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

varunthakore Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mellowcroc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

varunthakore Oct 8, 2025 •

edited

Loading