more on merkle

source/starknet/channel.md

@@ -9,6 +9,8 @@ tags: ["starknet", "fiat-shamir"]
 
 ## Overview
 
+<aside class="warning">This specification is work-in-progress.</aside>
+
 A channel is an object that mimics the communication channel between the prover and the verifier, and is used to abstract the [Fiat-Shamir transformation](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic) used to make the protocol non-interactive.
 
 The Fiat-Shamir transformation works on public-coin protocols, in which the messages of the verifier are pure random values. To work, the Fiat-Shamir transformation replaces the verifier messages with a hash function applied over the transcript up to that point.

source/starknet/fri.md

@@ -13,6 +13,8 @@ tags: ["starknet", "fri"]
 
 ## Overview
 
+<aside class="warning">This specification is work-in-progress.</aside>
+
 We briefly give an overview of the FRI protocol, before specifying how it is used in the StarkNet protocol.
 
 ### FRI
@@ -356,8 +358,6 @@ We use the following constants throughout the protocol.
 
 **`MAX_FRI_STEP = 4`**. The maximum number of layers that can be skipped in FRI (see the overview for more details).
 
-**`MONTGOMERY_R = 3618502788666127798953978732740734578953660990361066340291730267701097005025`**. The Montgomery form of $2^{256} \mod \text{STARK_PRIME}$:
-
 ### TODO: Step generators
 
 * we are in a coset, so a fixed value `g=3` is chosen

source/starknet/merkle.md

@@ -9,13 +9,18 @@ tags: ["starknet", "PCS", "Merkle tree", "hash-based commitments"]
 
 ## Overview
 
-Commitments of polynomials are done using [Merkle trees](https://en.wikipedia.org/wiki/Merkle_tree). The Merkle trees can be configured to hash some parameterized number of the lower layers using a circuit-friendly hash function (Poseidon).
+<aside class="warning">This specification is work-in-progress.</aside>
 
-* TODO: why montgomery form?
+Commitments of polynomials are done using [Merkle trees](https://en.wikipedia.org/wiki/Merkle_tree). The Merkle trees can be configured to hash some parameterized number of the lower layers using a circuit-friendly hash function (Poseidon).
 
 ## Dependencies
 
-TODO: hash
+* the verifier-friendly hash is `hades_permutation(s1, s2, 2)` always setting the last field element to $2$
+* the default hash is either keccak256 or blake2s
+
+## Constants
+
+**`MONTGOMERY_R = 3618502788666127798953978732740734578953660990361066340291730267701097005025`**. The Montgomery form of $2^{256} \mod \text{STARK_PRIME}$.
 
 ## Vector commitments
 
@@ -35,6 +40,8 @@ A few examples:
 * the composition polynomial in the [STARK verifier specification](stark.html) is a table commitment where each leaf is a hash of the evaluations of the composition polynomial columns at the same point
 * the FRI layer commitments in the [FRI verifier specification](fri.html) are table commitments where each leaf is a hash of the evaluations of the FRI layer columns at associated points (e.g. $v$ and $-v$)
 
+Note that values are multiplied to the `MONTGOMERY_R` constant before being hashed as leaves in the tree. TODO: explain why
+
 ## 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.
@@ -57,4 +64,4 @@ In the following example, the height of the table commitment is $6$ (and the hei
 
 ### Note on commitment multiple evaluations under the same leaf
 
-TKTK
+TKTK

source/starknet/stark.md

@@ -9,6 +9,8 @@ tags: ["starknet", "stark", "ethSTARK"]
 
 ## Overview
 
+<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>