relocate imgs

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:
 

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,15 +52,15 @@ 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
 
 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/tree_height.png)
+![vector decommit](/img/starknet/tree_height.png)
 
 ### Note on commitment multiple evaluations under the same leaf
 

source/starknet/stark.md

@@ -25,6 +25,8 @@ This protocol is instantiated in several places to our knowledge:
 </ul>
 </aside>
 
+![STARK overview](/img/starknet/stark_overview.png)
+
 ### AIR Arithmetization
 
 TKTK