deploy: 3766c21

index.html

@@ -18,7 +18,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet STARK Verifier</h2>
                 <p class="text-gray-600">Short Name: starknet-stark</p>
                 <!--                <p class="text-gray-600">Editor: David Wong</p> -->
                 <p class="text-gray-600">State of This Document: draft</p>
-                <p class="text-gray-600">Updated: October 17, 2024</p>
+                <p class="text-gray-600">Updated: October 18, 2024</p>
                 <a href="rfcs/starknet/stark.html"
                     class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
                     View RFC
@@ -30,7 +30,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet FRI Verifier</h2>
                 <p class="text-gray-600">Short Name: starknet-fri</p>
                 <!--                <p class="text-gray-600">Editor: David Wong</p> -->
                 <p class="text-gray-600">State of This Document: draft</p>
-                <p class="text-gray-600">Updated: October 17, 2024</p>
+                <p class="text-gray-600">Updated: October 18, 2024</p>
                 <a href="rfcs/starknet/fri.html"
                     class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
                     View RFC
@@ -42,7 +42,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet Merkle Tree Polynomial Commitmen
                 <p class="text-gray-600">Short Name: starknet-commit</p>
                 <!--                <p class="text-gray-600">Editor: David Wong</p> -->
                 <p class="text-gray-600">State of This Document: draft</p>
-                <p class="text-gray-600">Updated: October 17, 2024</p>
+                <p class="text-gray-600">Updated: October 18, 2024</p>
                 <a href="rfcs/starknet/merkle.html"
                     class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
                     View RFC
@@ -54,7 +54,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet Channels for Fiat-Shamir Instant
                 <p class="text-gray-600">Short Name: starknet-channel</p>
                 <!--                <p class="text-gray-600">Editor: David Wong</p> -->
                 <p class="text-gray-600">State of This Document: draft</p>
-                <p class="text-gray-600">Updated: October 17, 2024</p>
+                <p class="text-gray-600">Updated: October 18, 2024</p>
                 <a href="rfcs/starknet/channel.html"
                     class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
                     View RFC

rfcs/starknet/fri.html

@@ -286,14 +286,14 @@ <h3>FRI-PCS</h3>
 <p>Specifically, FRI-PCS proves that they can produce such a (commitment to a) polynomial <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>q</mi></mrow></math>.</p>
 </section>
 <section>
-<h3>Aggregating multiple FRI proofs</h3>
+<h3>Aggregating Multiple FRI Proofs</h3>
 <p>To prove that two polynomials <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>a</mi></mrow></math> and <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>b</mi></mrow></math> exist and are of degree at most <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>d</mi></mrow></math>, a prove simply prove that a random linear combination of <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>a</mi></mrow></math> and <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>b</mi></mrow></math> exists and is of degree at most <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>d</mi></mrow></math>.</p>
 <p>TODO: what if the different polynomials are of different degrees?</p>
 <p>TODO: we do not make use of aggregation here, the way the first layer polynomial is created is sort of transparent here, is it still worth having this section?</p>
 </section>
 </section>
 <section>
-<h2>Notable differences with vanilla FRI</h2>
+<h2>Notable Differences With Vanilla FRI</h2>
 <p>Besides obvious missing implementation details from the description above, the protocol is pretty much instantiated as is, except for a few changes to the folding and querying process.</p>
 <p>As explained above, in the "vanilla FRI" protocol the verifier gets evaluations of <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>p</mi><mn>0</mn></msub><mo stretchy="false">&#x00028;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo></mrow></math> and <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>p</mi><mn>0</mn></msub><mo stretchy="false">&#x00028;</mo><mo>&#x02212;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo></mrow></math> and computes the next layer's evaluation at <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mi>v</mi><mn>2</mn></msup></mrow></math> as</p>
 <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mrow><msub><mi>p</mi><mrow><mi>i</mi><mo>&#x0002B;</mo><mn>1</mn></mrow></msub><mo stretchy="false">&#x00028;</mo><msup><mi>v</mi><mn>2</mn></msup><mo stretchy="false">&#x00029;</mo><mo>&#x0003D;</mo><mfrac><mrow><msub><mi>p</mi><mrow><mi>i</mi></mrow></msub><mo stretchy="false">&#x00028;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo><mo>&#x0002B;</mo><msub><mi>p</mi><mrow><mi>i</mi></mrow></msub><mo stretchy="false">&#x00028;</mo><mo>&#x02212;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo></mrow><mrow><mn>2</mn></mrow></mfrac><mo>&#x0002B;</mo><msub><mi>&#x003B6;</mi><mrow><mi>i</mi></mrow></msub><mfrac><mrow><msub><mi>p</mi><mrow><mi>i</mi></mrow></msub><mo stretchy="false">&#x00028;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo><mo>&#x02212;</mo><msub><mi>p</mi><mrow><mi>i</mi></mrow></msub><mo stretchy="false">&#x00028;</mo><mo>&#x02212;</mo><mi>v</mi><mo stretchy="false">&#x00029;</mo></mrow><mrow><mn>2</mn><mi>v</mi></mrow></mfrac></mrow></math>

rfcs/starknet/stark.html

@@ -79,7 +79,6 @@
 <h2>Overview</h2>
 <aside class="warning">This specification is work-in-progress.</aside>
 
-<p>In this section we give an overview of the STARK protocol.</p>
 <aside class="note">Note that the protocol implemented closely resembles the high-level explanations of the <a href="https://eprint.iacr.org/2021/582">ethSTARK paper</a>, as such we refer to it in places.</aside>
 
 <aside class="note">
@@ -92,16 +91,45 @@ <h2>Overview</h2>
 </ul>
 </aside>
 
+<p>In this section we give a brief overview of the Starknet STARK protocol.</p>
+<p>The protocol is divided in three main parts, which we will explain in more detail below:</p>
 <p><img alt="STARK overview" src="/RFCs/img/starknet/stark_overview.png" /></p>
 <section>
 <h3>AIR Arithmetization</h3>
-<p>TKTK</p>
+<p>But first, we quickly remind the reader that the Starknet STARK protocol allows a prover to convince a verifier that an AIR (Algebraic Intermediate Representation) arithmetization is satisfied by their witness. This is generally augmented to also include a public input, usually via a <a href="https://zksecurity.github.io/stark-book/cairo/memory.html">public memory</a> extension.</p>
+<p>AIR is essentially an indexed table of runtime values, on which a number of fixed constraints are agreed on:</p>
+<p><img alt="air" src="/RFCs/img/starknet/air.png" /></p>
 </section>
 <section>
 <h3>Interactive Arithmetization</h3>
 <p>TKTK</p>
 </section>
 <section>
+<h3>Composition Polynomial</h3>
+<p>TKTK</p>
+<section>
+<h4>Constraints To Prove</h4>
+<p>TKTK</p>
+</section>
+<section>
+<h4>Composition Polynomial and Schwartz-Zippel</h4>
+<p>TKTK</p>
+</section>
+<section>
+<h4>Evaluations And Evaluation Proofs</h4>
+<ul>
+<li>we use FRI-PCS as described in <a href="fri.html#fri-pcs">the FRI-PCS section of the Starknet FRI Verifier Specification</a>.</li>
+</ul>
+</section>
+</section>
+<section>
+<h3>Aggregation and FRI Proof</h3>
+<ul>
+<li>we use FRI Aggregation as described in <a href="fri.html#aggregating-multiple-fri-proofs">the Aggregating Multiple FRI Proofs section of the Starknet FRI Verifier Specification</a>.</li>
+<li>we use FRI as described in <a href="fri.html">the Starknet FRI Verifier Specification</a>.</li>
+</ul>
+</section>
+<section>
 <h3>STARK</h3>
 <p>TKTK</p>
 </section>

source/starknet/fri.md

@@ -255,15 +255,15 @@ $$
 
 Specifically, FRI-PCS proves that they can produce such a (commitment to a) polynomial $q$.
 
-### Aggregating multiple FRI proofs
+### Aggregating Multiple FRI Proofs
 
 To prove that two polynomials $a$ and $b$ exist and are of degree at most $d$, a prove simply prove that a random linear combination of $a$ and $b$ exists and is of degree at most $d$.
 
 TODO: what if the different polynomials are of different degrees?
 
 TODO: we do not make use of aggregation here, the way the first layer polynomial is created is sort of transparent here, is it still worth having this section?
 
-## Notable differences with vanilla FRI
+## Notable Differences With Vanilla FRI
 
 Besides obvious missing implementation details from the description above, the protocol is pretty much instantiated as is, except for a few changes to the folding and querying process.
 

source/starknet/stark.md

@@ -11,8 +11,6 @@ tags: ["starknet", "stark", "ethSTARK"]
 
 <aside class="warning">This specification is work-in-progress.</aside>
 
-In this section we give an overview of the STARK protocol.
-
 <aside class="note">Note that the protocol implemented closely resembles the high-level explanations of the <a href="https://eprint.iacr.org/2021/582">ethSTARK paper</a>, as such we refer to it in places.</aside>
 
 <aside class="note">
@@ -25,16 +23,45 @@ This protocol is instantiated in several places to our knowledge:
 </ul>
 </aside>
 
+In this section we give a brief overview of the Starknet STARK protocol.
+
+The protocol is divided in three main parts, which we will explain in more detail below:
+
 ![STARK overview](/img/starknet/stark_overview.png)
 
 ### AIR Arithmetization
 
-TKTK
+But first, we quickly remind the reader that the Starknet STARK protocol allows a prover to convince a verifier that an AIR (Algebraic Intermediate Representation) arithmetization is satisfied by their witness. This is generally augmented to also include a public input, usually via a [public memory](https://zksecurity.github.io/stark-book/cairo/memory.html) extension.
+
+AIR is essentially an indexed table of runtime values, on which a number of fixed constraints are agreed on:
+
+![air](/img/starknet/air.png)
 
 ### Interactive Arithmetization
 
 TKTK
 
+### Composition Polynomial
+
+TKTK
+
+#### Constraints To Prove
+
+TKTK
+
+#### Composition Polynomial and Schwartz-Zippel
+
+TKTK
+
+#### Evaluations And Evaluation Proofs
+
+* we use FRI-PCS as described in [the FRI-PCS section of the Starknet FRI Verifier Specification](fri.html#fri-pcs).
+
+### Aggregation and FRI Proof
+
+* we use FRI Aggregation as described in [the Aggregating Multiple FRI Proofs section of the Starknet FRI Verifier Specification](fri.html#aggregating-multiple-fri-proofs).
+* we use FRI as described in [the Starknet FRI Verifier Specification](fri.html).
+
 ### STARK
 
 TKTK