Skip to content

Commit

Permalink
deploy: 9704665
Browse files Browse the repository at this point in the history
  • Loading branch information
mimoo committed Oct 16, 2024
1 parent 830d576 commit 65c1774
Show file tree
Hide file tree
Showing 7 changed files with 67 additions and 19 deletions.
Binary file added img/starknet/fri/tree_height.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added img/starknet/fri/tree_indexing.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion index.html
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet FRI Verifier</h2>
<h2 class="text-xl font-semibold mb-2">Starknet Merkle Tree Polynomial Commitments</h2>
<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: none</p>
<p class="text-gray-600">State of This Document: draft</p>
<p class="text-gray-600">Updated: October 16, 2024</p>
<a href="rfcs/starknet/polynomial_commitment.html"
class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
Expand Down
25 changes: 20 additions & 5 deletions rfcs/starknet/polynomial_commitment.html
Original file line number Diff line number Diff line change
Expand Up @@ -73,30 +73,45 @@
<p>TKTK</p>
</section>
<section id="sotd">
<p>none</p>
<p>draft</p>
</section>
<section>
<h2>Overview</h2>
<p>Commitments of polynomials are done using <a href="">Merkle trees</a>. The Merkle trees can be configured to hash some parameterized number of the lower layers using a circuit-friendly hash function (Poseidon).</p>
<ul>
<li>TODO: why montgomery form?</li>
</ul>
</section>
<section>
<h2>Dependencies</h2>
<p>TODO: hash</p>
</section>
<section>
<h3>Table commitments</h3>
<h2>Table commitments</h2>
<p>A table commitment in this context is a vector commitment where leaves are potentially hashes of several values (tables of multiple columns and a single row).</p>
</section>
<section>
<h3>Vector commitments</h3>
<h2>Vector commitments</h2>
<p>A vector commitment is simply a Merkle tree. </p>
<p>TODO: diagram.</p>
<p><img alt="tree indexing" src="/RFCs/img/starknet/fri/tree_indexing.png" /></p>
<p><img alt="vector commit" src="/RFCs/img/starknet/fri/vector_commit.png" /></p>
</section>
<section>
<h3>Vector membership proofs</h3>
<h2>Index to Path conversion</h2>
<p>Random evaluation of the polynomial might produce an index in the range <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mo stretchy="false">[</mo><mn>0</mn><mo>&#x0002C;</mo><msup><mn>2</mn><mi>h</mi></msup><mo stretchy="false">&#x00029;</mo></mrow></math> with <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>h</mi></mrow></math> the height of the tree. Due to the way the tree is indexed, we have to convert that index into a path. To do that, the index is added with the value <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mi>h</mi></msup></mrow></math> to set its MSB.</p>
<p>For example, the index <code>0</code> becomes the path <code>10000</code> which correctly points to the first leaf in our example.</p>
</section>
<section>
<h2>Vector membership proofs</h2>
<p>A vector decommitment/membership proof must provide a witness (the neighbor nodes missing to compute the root of the Merkle tree) ordered in a specific way. The following algorithm dictates in which order the nodes hash values provided in the proof are consumed:</p>
<p><img alt="vector decommit" src="/RFCs/img/starknet/fri/vector_decommit.png" /></p>
</section>
<section>
<h2>Verifier-Friendly Layers</h2>
<p>A <code>n_verifier_friendly_layers</code> variable can be passed which dictates at which layer the Merkle tree starts using a verifier-friendly hash.</p>
<p>In the following example, the height of the table commitment is <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>6</mn></mrow></math> (and the height of the vector commitment is <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>5</mn></mrow></math>). As such, a <code>n_verifier_friendly_layers</code> of <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>6</mn></mrow></math> would mean that only the table would use the verifier-friendly hash. A <code>n_verifier_friendly_layers</code> of <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>5</mn></mrow></math> would mean that the last / bottom layer of the Merkle tree would also use the verifier-friendly hash. A <code>n_verifier_friendly_layers</code> of <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>1</mn></mrow></math> would mean that all layers would use the verifier-friendly hash.</p>
<p><img alt="vector decommit" src="/RFCs/img/starknet/fri/vector_decommit.png" /></p>
<section>
<h3>Note on commitment multiple evaluations under the same leaf</h3>
<ul>
<li>the following array contains all the 16-th roots of unity, handily ordered</li>
Expand Down
15 changes: 11 additions & 4 deletions rfcs/starknet/stark.html
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@ <h2>Configuration</h2>
<ul>
<li>proof of work is validated as part of the FRI configuration validation</li>
<li>compute the log of the evaluation domain size as the log of the trace domain size plus the log of the number of cosets</li>
<li>if every coset is of size <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>e</mi></msub></mrow></msup></mrow></math> with <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>n</mi><mi>e</mi></msub></mrow></math> the <code>log_trace_domain_size</code>, and there is <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>c</mi></msub></mrow></msup></mrow></math> cosets, then the evaluation domain size is expected to be <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>e</mi></msub><mo>&#x0002B;</mo><msub><mi>n</mi><mi>c</mi></msub></mrow></msup></mrow></math></li>
<li>if every coset is of size <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>t</mi></msub></mrow></msup></mrow></math> with <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>n</mi><mi>t</mi></msub></mrow></math> the <code>log_trace_domain_size</code>, and there is <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>c</mi></msub></mrow></msup></mrow></math> cosets, then the evaluation domain size is expected to be <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>t</mi></msub><mo>&#x0002B;</mo><msub><mi>n</mi><mi>c</mi></msub></mrow></msup></mrow></math> (TODO: explain why we talk about cosets here)</li>
<li>traces.validate() (TODO)</li>
<li>composition.vector.validate()</li>
<li>the FRI configuration is validated as part of the FRI configuration validation</li>
Expand Down Expand Up @@ -198,8 +198,15 @@ <h2>Main STARK functions / Buiding blocks</h2>
}
</code></pre>
<section>
<h3>Domain</h3>
<p>TODO: StarkDomainsImpl::new() </p>
<h3>Trace and Evaluation Domains</h3>
<p>TODO: is this section useful?</p>
<p>There are three types of domains:</p>
<ol>
<li>The trace domain, this is the domain chosen to evaluate the execution trace polynomials. It is typically the smallest subgroup of order <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>t</mi></msub></mrow></msup></mrow></math> for some <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>n</mi><mi>t</mi></msub></mrow></math>, such that it can include all the constraints.</li>
<li>The evaluation domain, which is chosen as a subgroup of a power of two <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msup><mn>2</mn><mrow><msub><mi>n</mi><mi>e</mi></msub></mrow></msup></mrow></math> that encompasses the trace domain (i.e. <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>e</mi><mo>&#x02265;</mo><mi>t</mi></mrow></math>). The "blown up factor" typically dictates how much larger the evaluation domain as a multiple.
(TODO: and then typically moved to a coset). (TODO: why n_cosets then? can this be seen as a union of cosets formed from the trace domain?)</li>
</ol>
<p>As such, the generator of the trace domain can be found as <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msub><mi>&#x003C9;</mi><mi>e</mi></msub><mo>&#x0003D;</mo><msup><mn>3</mn><mrow><mo stretchy="false">&#x00028;</mo><mi>p</mi><mo>&#x02212;</mo><mn>1</mn><mo stretchy="false">&#x00029;</mo><mo>&#x0002F;</mo><msub><mi>n</mi><mi>t</mi></msub></mrow></msup></mrow></math> (since <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><msubsup><mi>&#x003C9;</mi><mrow><mi>e</mi></mrow><mrow><msub><mi>n</mi><mi>t</mi></msub></mrow></msubsup><mo>&#x0003D;</mo><mn>1</mn></mrow></math>), and the generator of the evaluation domain can be found as <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>&#x003C9;</mi><mo>&#x0003D;</mo><msup><mn>3</mn><mrow><mo stretchy="false">&#x00028;</mo><mi>p</mi><mo>&#x02212;</mo><mn>1</mn><mo stretchy="false">&#x00029;</mo><mo>&#x0002F;</mo><msub><mi>n</mi><mi>e</mi></msub></mrow></msup></mrow></math>.</p>
</section>
<section>
<h3>STARK commit</h3>
Expand All @@ -218,7 +225,7 @@ <h3>STARK commit</h3>
</ol>
</section>
<section>
<h3>STARK verify (TODO: consolidate with above)</h3>
<h3>STARK verify</h3>
<p>The goal of STARK verify is to verify evaluation queries (by checking that evaluations exist in the committed polynomials) and the FRI queries (by running the FRI verification).</p>
<p>To do this, we simply call the <code>fri_verify_initial</code> function contained in the FRI specification, and giving it the following oracle:</p>
<p>The oracle should provide the evaluations, under the same set of FRI queries (and specifically the point they are requesting the evaluations at) of the following polynomials:</p>
Expand Down
28 changes: 23 additions & 5 deletions source/starknet/polynomial_commitment.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: "Starknet Merkle Tree Polynomial Commitments"
abstract: "TKTK"
sotd: "none"
sotd: "draft"
shortName: "starknet-commit"
editor: "David Wong"
tags: ["starknet", "PCS", "Merkle tree", "hash-based commitments"]
Expand All @@ -13,24 +13,42 @@ Commitments of polynomials are done using [Merkle trees](). The Merkle trees can

* TODO: why montgomery form?

### Table commitments
## Dependencies

TODO: hash

## Table commitments

A table commitment in this context is a vector commitment where leaves are potentially hashes of several values (tables of multiple columns and a single row).

### Vector commitments
## Vector commitments

A vector commitment is simply a Merkle tree.

TODO: diagram.
![tree indexing](/img/starknet/fri/tree_indexing.png)

![vector commit](/img/starknet/fri/vector_commit.png)

### Vector membership proofs
## Index to Path conversion

Random evaluation of the polynomial might produce an index in the range $[0, 2^h)$ with $h$ the height of the tree. Due to the way the tree is indexed, we have to convert that index into a path. To do that, the index is added with the value $2^h$ to set its MSB.

For example, the index `0` becomes the path `10000` which correctly points to the first leaf in our example.

## Vector membership proofs

A vector decommitment/membership proof must provide a witness (the neighbor nodes missing to compute the root of the Merkle tree) ordered in a specific way. The following algorithm dictates in which order the nodes hash values provided in the proof are consumed:

![vector decommit](/img/starknet/fri/vector_decommit.png)

## Verifier-Friendly Layers

A `n_verifier_friendly_layers` variable can be passed which dictates at which layer the Merkle tree starts using a verifier-friendly hash.

In the following example, the height of the table commitment is $6$ (and the height of the vector commitment is $5$). As such, a `n_verifier_friendly_layers` of $6$ would mean that only the table would use the verifier-friendly hash. A `n_verifier_friendly_layers` of $5$ would mean that the last / bottom layer of the Merkle tree would also use the verifier-friendly hash. A `n_verifier_friendly_layers` of $1$ would mean that all layers would use the verifier-friendly hash.

![vector decommit](/img/starknet/fri/vector_decommit.png)

### Note on commitment multiple evaluations under the same leaf

* the following array contains all the 16-th roots of unity, handily ordered
Expand Down
16 changes: 12 additions & 4 deletions source/starknet/stark.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ To validate:

* proof of work is validated as part of the FRI configuration validation
* compute the log of the evaluation domain size as the log of the trace domain size plus the log of the number of cosets
* if every coset is of size $2^{n_e}$ with $n_e$ the `log_trace_domain_size`, and there is $2^{n_c}$ cosets, then the evaluation domain size is expected to be $2^{n_e + n_c}$
* if every coset is of size $2^{n_t}$ with $n_t$ the `log_trace_domain_size`, and there is $2^{n_c}$ cosets, then the evaluation domain size is expected to be $2^{n_t + n_c}$ (TODO: explain why we talk about cosets here)
* traces.validate() (TODO)
* composition.vector.validate()
* the FRI configuration is validated as part of the FRI configuration validation
Expand Down Expand Up @@ -132,9 +132,17 @@ struct StarkUnsentCommitment {
}
```

### Domain
### Trace and Evaluation Domains

TODO: StarkDomainsImpl::new()
TODO: is this section useful?

There are three types of domains:

1. The trace domain, this is the domain chosen to evaluate the execution trace polynomials. It is typically the smallest subgroup of order $2^{n_t}$ for some $n_t$, such that it can include all the constraints.
2. The evaluation domain, which is chosen as a subgroup of a power of two $2^{n_e}$ that encompasses the trace domain (i.e. $e \geq t$). The "blown up factor" typically dictates how much larger the evaluation domain as a multiple.
(TODO: and then typically moved to a coset). (TODO: why n_cosets then? can this be seen as a union of cosets formed from the trace domain?)

As such, the generator of the trace domain can be found as $\omega_e =3^{(p-1)/n_t}$ (since $\omega_{e}^{n_t} = 1$), and the generator of the evaluation domain can be found as $\omega = 3^{(p-1)/n_e}$.

### STARK commit

Expand All @@ -151,7 +159,7 @@ The goal of the STARK commit is to process all of the commitments produced by th
9. Sample the oods_alpha challenge with the channel.
10. Call `fri_commit`

### STARK verify (TODO: consolidate with above)
### STARK verify

The goal of STARK verify is to verify evaluation queries (by checking that evaluations exist in the committed polynomials) and the FRI queries (by running the FRI verification).

Expand Down

0 comments on commit 65c1774

Please sign in to comment.