diff --git a/img/starknet/fri/folding.png b/img/starknet/folding.png similarity index 100% rename from img/starknet/fri/folding.png rename to img/starknet/folding.png diff --git a/img/starknet/fri/queries.png b/img/starknet/queries.png similarity index 100% rename from img/starknet/fri/queries.png rename to img/starknet/queries.png diff --git a/img/starknet/fri/skipped_layers.png b/img/starknet/skipped_layers.png similarity index 100% rename from img/starknet/fri/skipped_layers.png rename to img/starknet/skipped_layers.png diff --git a/img/starknet/stark_overview.png b/img/starknet/stark_overview.png new file mode 100644 index 0000000..c42eb92 Binary files /dev/null and b/img/starknet/stark_overview.png differ diff --git a/img/starknet/fri/tree_height.png b/img/starknet/tree_height.png similarity index 100% rename from img/starknet/fri/tree_height.png rename to img/starknet/tree_height.png diff --git a/img/starknet/fri/tree_indexing.png b/img/starknet/tree_indexing.png similarity index 100% rename from img/starknet/fri/tree_indexing.png rename to img/starknet/tree_indexing.png diff --git a/img/starknet/fri/vector_commit.png b/img/starknet/vector_commit.png similarity index 100% rename from img/starknet/fri/vector_commit.png rename to img/starknet/vector_commit.png diff --git a/img/starknet/fri/vector_decommit.png b/img/starknet/vector_decommit.png similarity index 100% rename from img/starknet/fri/vector_decommit.png rename to img/starknet/vector_decommit.png diff --git a/source/starknet/fri.md b/source/starknet/fri.md index 75501cf..6209640 100644 --- a/source/starknet/fri.md +++ b/source/starknet/fri.md @@ -71,7 +71,7 @@ assert find_gen2(3)^8 == 1 #### Reduction -![folding](/img/starknet/fri/folding.png) +![folding](/img/starknet/folding.png) A reduction in the FRI protocol is obtained by interpreting an input polynomial $p$ as a polynomial of degree $2n$ and splitting it into two polynomials $g$ and $h$ of degree $n$ such that $p(x) = g(x^2) + x h(x^2)$. @@ -129,7 +129,7 @@ assert p3.degree() == 0 #### Queries -![queries](/img/starknet/fri/queries.png) +![queries](/img/starknet/queries.png) In the real FRI protocol, each layer's polynomial would be sent using a hash-based commitment (e.g. a Merkle tree of its evaluations over a large domain). As such, the verifier must ensure that each commitment consistently represent the proper reduction of the previous layer's polynomial. To do that, they "query" commitments of the different polynomials of the different layers at points/evaluations. Let's see how this works. @@ -181,7 +181,7 @@ assert p3 == g2_square + zeta2 * h2_square # we already received p3 at the end o #### Skipping FRI layers -![skipped layers](/img/starknet/fri/skipped_layers.png) +![skipped layers](/img/starknet/skipped_layers.png) Section 3.11.1 "Skipping FRI Layers" of the ethSTARK paper describes an optimization which skips some of the layers/rounds. The intuition is the following: if we removed the first round commitment (to the polynomial $p_1$), then the verifier would not be able to: diff --git a/source/starknet/merkle.md b/source/starknet/merkle.md index 12bf948..d511c24 100644 --- a/source/starknet/merkle.md +++ b/source/starknet/merkle.md @@ -26,9 +26,9 @@ Commitments of polynomials are done using [Merkle trees](https://en.wikipedia.or A vector commitment is simply a Merkle tree. -![tree indexing](/img/starknet/fri/tree_indexing.png) +![tree indexing](/img/starknet/tree_indexing.png) -![vector commit](/img/starknet/fri/vector_commit.png) +![vector commit](/img/starknet/vector_commit.png) ## Table commitments @@ -52,7 +52,7 @@ For example, the index `0` becomes the path `10000` which correctly points to th 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) +![vector decommit](/img/starknet/vector_decommit.png) ## Verifier-Friendly Layers @@ -60,7 +60,7 @@ A `n_verifier_friendly_layers` variable can be passed which dictates at which la 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/tree_height.png) +![vector decommit](/img/starknet/tree_height.png) ### Note on commitment multiple evaluations under the same leaf diff --git a/source/starknet/stark.md b/source/starknet/stark.md index fcd0f83..3732002 100644 --- a/source/starknet/stark.md +++ b/source/starknet/stark.md @@ -25,6 +25,8 @@ This protocol is instantiated in several places to our knowledge: +![STARK overview](/img/starknet/stark_overview.png) + ### AIR Arithmetization TKTK