TKTK
none
+draft
Overview
@@ -81,22 +81,37 @@Overview
- TODO: why montgomery form?
Dependencies
+TODO: hash
+Table commitments
+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.
+
Vector membership proofs
+Index to Path conversion
+Random evaluation of the polynomial might produce an index in the range with 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 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:
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 (and the height of the vector commitment is ). As such, a n_verifier_friendly_layers of would mean that only the table would use the verifier-friendly hash. A n_verifier_friendly_layers of would mean that the last / bottom layer of the Merkle tree would also use the verifier-friendly hash. A n_verifier_friendly_layers of would mean that all layers would use the verifier-friendly hash.
Note on commitment multiple evaluations under the same leaf
- the following array contains all the 16-th roots of unity, handily ordered diff --git a/rfcs/starknet/stark.html b/rfcs/starknet/stark.html index a63e4a2..39901f9 100644 --- a/rfcs/starknet/stark.html +++ b/rfcs/starknet/stark.html @@ -154,7 +154,7 @@
- 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 with the
log_trace_domain_size, and there is cosets, then the evaluation domain size is expected to be
+ - if every coset is of size with the
log_trace_domain_size, and there is cosets, then the evaluation domain size is expected to be (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 @@ -198,8 +198,15 @@
- The trace domain, this is the domain chosen to evaluate the execution trace polynomials. It is typically the smallest subgroup of order for some , such that it can include all the constraints. +
- The evaluation domain, which is chosen as a subgroup of a power of two that encompasses the trace domain (i.e. ). 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?) +
Configuration
Main STARK functions / Buiding blocks
}Domain
-TODO: StarkDomainsImpl::new()
+Trace and Evaluation Domains
+TODO: is this section useful?
+There are three types of domains:
+-
+
As such, the generator of the trace domain can be found as (since ), and the generator of the evaluation domain can be found as .
STARK commit
@@ -218,7 +225,7 @@STARK 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).
To do this, we simply call the fri_verify_initial function contained in the FRI specification, and giving it the following oracle:
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:
diff --git a/source/starknet/polynomial_commitment.md b/source/starknet/polynomial_commitment.md index 23a9d1b..ec749a8 100644 --- a/source/starknet/polynomial_commitment.md +++ b/source/starknet/polynomial_commitment.md @@ -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"] @@ -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. +  -### 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:  +## 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. + + + ### Note on commitment multiple evaluations under the same leaf * the following array contains all the 16-th roots of unity, handily ordered diff --git a/source/starknet/stark.md b/source/starknet/stark.md index b957e9b..dd464c5 100644 --- a/source/starknet/stark.md +++ b/source/starknet/stark.md @@ -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 @@ -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 @@ -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).