deploy: 620fc0e

rfcs/starknet/fri.html

@@ -476,12 +476,15 @@ <h3>Query Phase</h3>
 <h4>Generating The First Queries</h4>
 <p>The generation of each FRI query goes through the same process:</p>
 <ul>
-<li>Sample a random challenge from the <a href="">channel</a>.</li>
+<li>Sample a random challenge from the <a href="#channel">channel</a>.</li>
 <li>Truncate the challenge to obtain the lower 128-bit chunk.</li>
 <li>Reduce it modulo the size of the evaluation domain.</li>
 </ul>
 <p>Finally, when all FRI queries have been generated, they are sorted in ascending order.</p>
-<p>TODO: this is important due to the decommit algorithm.</p>
+<aside class="note">This gives you a value that is related to the path to query in a [Merkle tree commitment](#commitments), and can be used to derive the actual evaluation point at which the polynomial is evaluated. Commitments should reveal not just one evaluation, but correlated evaluations in order to help the protocol move forward. For example, if a query is generated for the evaluation point <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>v</mi></mrow></math>, then the commitment will reveal the evaluation of a polynomial at <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>v</mi></mrow></math> but also at <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mo>&#x02212;</mo><mi>v</mi></mrow></math> and potentially more points (depending on the number of layers skipped).</aside>
+
+<p>TODO: include how we provide the <code>y_value</code> and how we verify the first layer's evaluations still</p>
+<p>TODO: also talk about how the first query is fixed to move away from the coset</p>
 </section>
 <section>
 <h4>Converting A Query To An Evaluation Point</h4>
@@ -497,9 +500,10 @@ <h4>Converting A Query To An Evaluation Point</h4>
 <section>
 <h4>Verify A Layer's Query</h4>
 <p>TODO: refer to the section on the first layer evaluation stuff (external dependency)</p>
-<p>Besides the first and last layers, each layer verification of a query happens by simply decommiting a layer's queries.</p>
+<p>Besides the last layer, each layer verification of a query happens by simply decommiting a layer's queries.</p>
 <pre><code class="language-rust">table_decommit(commitment, paths, leaves_values, witness, settings);
 </code></pre>
+<p>To verify the last layer's query, as the last layer polynomial is received in clear, simply evaluate it at the queried point <code>1/fri_layer_query.x_inv_value</code> and check that it matches the expected evaluation <code>fri_layer_query.y_value</code>.</p>
 <p>TODO: As explained in the section on Merkle Tree Decommitment, witness leaves values have to be given as well.</p>
 <p>TODO: link to section on merkle tree</p>
 </section>
@@ -514,8 +518,6 @@ <h4>Computing the next layer's queries</h4>
 </ul>
 <p>where coset_size is 2, 4, 8, or 16 depending on the layer (but always 2 for the first layer).</p>
 <p>TODO: explain the relation between coset_size and the step size. coset_size = 2^step_size</p>
-<section>
-<h5>FRI formula</h5>
 <p>The next evaluations expected at the queried layers are derived as:</p>
 <p>Queries between layers verify that the next layer <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>p</mi><mrow><mi>i</mi><mo>&#x0002B;</mo><mi>j</mi></mrow></msub></mrow></math> is computed correctly based on the currently layer <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>p</mi><mrow><mi>i</mi></mrow></msub></mrow></math>.
 The next layer is either the direct next layer <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>p</mi><mrow><mi>i</mi><mo>&#x0002B;</mo><mn>1</mn></mrow></msub></mrow></math> or a layer further away if the configuration allows layers to be skipped.
@@ -568,7 +570,6 @@ <h5>FRI formula</h5>
 <p>TODO: reconcile with constants used for elements and inverses chosen in subgroups of order <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mi>i</mi></msup></mrow></math> (the <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>&#x003C9;</mi></mrow></math>s)</p>
 </section>
 </section>
-</section>
 <section>
 <h3>Proof of work</h3>
 <p>In order to increase the cost of attacks on the protocol, a proof of work is added at the end of the commitment phase.</p>

source/starknet/fri.md

@@ -491,13 +491,17 @@ See the [Converting A Query to a Path section of the Merkle tree specification](
 
 The generation of each FRI query goes through the same process:
 
-* Sample a random challenge from the [channel]().
+* Sample a random challenge from the [channel](#channel).
 * Truncate the challenge to obtain the lower 128-bit chunk.
 * Reduce it modulo the size of the evaluation domain.
 
 Finally, when all FRI queries have been generated, they are sorted in ascending order.
 
-TODO: this is important due to the decommit algorithm.
+<aside class="note">This gives you a value that is related to the path to query in a [Merkle tree commitment](#commitments), and can be used to derive the actual evaluation point at which the polynomial is evaluated. Commitments should reveal not just one evaluation, but correlated evaluations in order to help the protocol move forward. For example, if a query is generated for the evaluation point $v$, then the commitment will reveal the evaluation of a polynomial at $v$ but also at $-v$ and potentially more points (depending on the number of layers skipped).</aside>
+
+TODO: include how we provide the `y_value` and how we verify the first layer's evaluations still
+
+TODO: also talk about how the first query is fixed to move away from the coset
 
 #### Converting A Query To An Evaluation Point
 
@@ -521,16 +525,20 @@ TODO: explain why not just do $3 \cdot \omega_e{q}$
 
 TODO: refer to the section on the first layer evaluation stuff (external dependency)
 
-Besides the first and last layers, each layer verification of a query happens by simply decommiting a layer's queries.
+Besides the last layer, each layer verification of a query happens by simply decommiting a layer's queries.
 
 ```rust
 table_decommit(commitment, paths, leaves_values, witness, settings);
 ```
 
+To verify the last layer's query, as the last layer polynomial is received in clear, simply evaluate it at the queried point `1/fri_layer_query.x_inv_value` and check that it matches the expected evaluation `fri_layer_query.y_value`.
+
 TODO: As explained in the section on Merkle Tree Decommitment, witness leaves values have to be given as well.
 
 TODO: link to section on merkle tree
 
+
+
 #### Computing the next layer's queries
 
 Each reduction will produce queries to the next layer, which will expect specific evaluations.
@@ -545,8 +553,6 @@ where coset_size is 2, 4, 8, or 16 depending on the layer (but always 2 for the
 
 TODO: explain the relation between coset_size and the step size. coset_size = 2^step_size
 
-##### FRI formula
-
 The next evaluations expected at the queried layers are derived as:
 
 Queries between layers verify that the next layer $p_{i+j}$ is computed correctly based on the currently layer $p_{i}$.