Update readme for static assets; Fix some latex issue; update some st…

…atic asset links

docs/README.md

@@ -10,7 +10,7 @@ If node.js or npm aren't installed, its suggested to use [nvm](https://github.co
 
 ## Install
 
-```
+```sh
 npm install
 ```
 
@@ -45,25 +45,58 @@ This command will:
 
 ### Removing old versions
 
-1. Remove the version from versions.json.
+- Remove the version from versions.json.
+
+```json
+  [
+    "3.2.0",
+    "3.1.0",
+    "3.0.0",
+    "2.8.0",
+  - "1.10.1"
+  ]
+```
+
+- Delete the versioned docs directory for that version. Example: versioned_docs/version-1.10.1.
+- Delete the versioned sidebars file. Example: versioned_sidebars/version-1.10.1-sidebars.json.
+
+## Static assets
+
+Static assets like images should be placed in the top level [static](./static/) directory **regardless** of which version it will be used in.
+
+Docusaurus adds all of the files in the directories listed as `staticDirectories` in the config to the root of the build output so they can be accessed directly from the root path.
+
+Read more on this [here](https://docusaurus.io/docs/static-assets)
+
+### Adding a new static directory
+
+To update where Docusaurus looks for static directories, add the directory name to the `statidDirectories` list in the config:
+
+```ts
+const config: Config = {
+  .
+  .
+  .
+  staticDirectories: ['static'/*, "another static dir" */],
+  .
+  .
+  .
+}
+```
+
+### Linking to static assets in docs
 
-[
-  "3.2.0",
-  "3.1.0",
-  "3.0.0",
-  "2.8.0",
-- "1.10.1"
-]
+Since the static assets are at the root of the build output, static assets can be linked to directly from the root, maintaining the directory hierarchy they have in the static directory.
 
+For example:
 
-2. Delete the versioned docs directory for that version. Example: versioned_docs/version-1.10.1.
-3. Delete the versioned sidebars file. Example: versioned_sidebars/version-1.10.1-sidebars.json.
+If an image is located at `static/images/poseidon.png`, it should be linked to as `/images/poseidon.png`
 
 ## Local development
 
 To render the site, run the following
 
-```
+```sh
 npm start
 ```
 

docs/docs/icicle/colab-instructions.md

@@ -9,11 +9,11 @@ First thing to do in a notebook is to set the runtime type to a T4 GPU.
 
 - in the upper corner click on the dropdown menu and select "change runtime type"
 
-![Change runtime](./static/img/colab_change_runtime.png)
+![Change runtime](/img/colab_change_runtime.png)
 
 - In the window select "T4 GPU" and press Save
 
-![T4 GPU](./static/img/t4_gpu.png)
+![T4 GPU](/img/t4_gpu.png)
 
 Installing Rust is rather simple, just execute the following command:
 

docs/docs/icicle/integrations.md

@@ -10,7 +10,7 @@ If you're interested in understanding these integrations better or learning how
 
 Lets illustrate an ICICLE integration, so you can understand the core API and design overview of ICICLE.
 
-![ICICLE architecture](./static/img/architecture-high-level.png)
+![ICICLE architecture](/img/architecture-high-level.png)
 
 Engineers usually use a cryptographic library to implement their ZK protocols. These libraries implement efficient primitives which are used as building blocks for the protocol; ICICLE is such a library. The difference is that ICICLE is designed from the start to run on GPUs; the Rust and Golang APIs abstract away all low level CUDA details. Our goal was to allow developers with no GPU experience to quickly get started with ICICLE.
 

docs/docs/icicle/primitives/poseidon2.md

@@ -3,7 +3,7 @@
 [Poseidon2](https://eprint.iacr.org/2023/323) is a recently released optimized version of Poseidon. The two versions differ in two crucial points. First, Poseidon is a sponge hash function, while Poseidon2 can be either a sponge or a compression function depending on the use case. Secondly, Poseidon2 is instantiated by new and more efficient linear layers with respect to Poseidon. These changes decrease the number of multiplications in the linear layer by up to 90% and the number of constraints in Plonk circuits by up to 70%. This makes Poseidon2 currently the fastest arithmetization-oriented hash function without lookups. Since the compression mode is efficient it is ideal for use in Merkle trees as well.
 
 An overview of the Poseidon2 hash is provided in the diagram below 
-![alt text](Poseidon2.png)
+![alt text](/img/Poseidon2.png)
 
 ## Description
 

docs/versioned_docs/version-3.2.0/icicle/primitives/poseidon2.md

@@ -2,8 +2,8 @@
 
 [Poseidon2](https://eprint.iacr.org/2023/323) is a recently released optimized version of Poseidon. The two versions differ in two crucial points. First, Poseidon is a sponge hash function, while Poseidon2 can be either a sponge or a compression function depending on the use case. Secondly, Poseidon2 is instantiated by new and more efficient linear layers with respect to Poseidon. These changes decrease the number of multiplications in the linear layer by up to 90% and the number of constraints in Plonk circuits by up to 70%. This makes Poseidon2 currently the fastest arithmetization-oriented hash function without lookups. Since the compression mode is efficient it is ideal for use in Merkle trees as well.
 
-An overview of the Poseidon2 hash is provided in the diagram below 
-![alt text](Poseidon2.png)
+An overview of the Poseidon2 hash is provided in the diagram below
+![alt text](/img/Poseidon2.png)
 
 ## Description
 
@@ -39,8 +39,8 @@ There are only two matrices: There is one type of matrix for full round and anot
 
 #### $t=4\cdot t'$ where $t'$ is an integer
 
-**Full Matrix** $M_{full}$ (Referred in paper as $M_{\mathcal{E}}$). These are hard coded (same for all primes $p>2^{30}$) for any fixed state size $t=4\cdot t'$ where $t'$ is an integer. 
- 
+**Full Matrix** $M_{full}$ (Referred in paper as $M_{\mathcal{E}}$). These are hard coded (same for all primes $p>2^{30}$) for any fixed state size $t=4\cdot t'$ where $t'$ is an integer.
+
 $$
 M_{4} = \begin{pmatrix}
 5 & 7 & 1 & 3 \\
@@ -49,25 +49,23 @@ M_{4} = \begin{pmatrix}
 1 & 1 & 4 & 6\\
 \end{pmatrix} $$
 
-As per the [paper](https://eprint.iacr.org/2023/323.pdf) this structure is always maintained and is always MDS for any prime $p>2^{30}$. 
+As per the [paper](https://eprint.iacr.org/2023/323.pdf) this structure is always maintained and is always MDS for any prime $p>2^{30}$.
 
 eg for $t=8$ the matrix looks like
 
-$$
-M_{full}^{8\times 8} = \begin{pmatrix}
+$$M_{full}^{8\times 8} = \begin{pmatrix}
 2\cdot M_4 & M_4 \\
 M_4 & 2\cdot M_4 \\
 \end{pmatrix} $$
 
 **Partial Matrix** $M_{partial}$(referred in paper as $M_{\mathcal{I}}$) - There is only ONE partial matrix for all the partial rounds and has non zero diagonal entries along the diagonal and $1$ everywhere else.
 
-$$
-M_{Partial}^{t\times t} = \begin{pmatrix}
+$$M_{Partial}^{t\times t} = \begin{pmatrix}
 \mu_0 &1 & \ldots & 1 \\
 1 &\mu_1 & \ldots & 1 \\
 \vdots & \vdots & \ddots & \vdots \\
  1 & 1 &\ldots & \mu_{t-1}\\
-\end{pmatrix} $$
+\end{pmatrix}$$
 
 where $\mu_i \in \mathbb{F}$. In general this matrix is different for each prime since one has to find values that satisfy some inequalities in a field. However unlike Poseidon there is only one $M_{partial}$ for all partial rounds.
 
@@ -132,25 +130,25 @@ pub fn compute_binary_tree<F:FieldImpl>(
     mut tree_config: MerkleTreeConfig,
 ) -> MerkleTree
 {
-let tree_height: usize = test_vec.len().ilog2() as usize;
-//just to be safe
-tree_config.padding_policy = PaddingPolicy::ZeroPadding;
-let layer_hashes: Vec<&Hasher> = std::iter::once(&hasher)
-    .chain(std::iter::repeat(&compress).take(tree_height))
-    .collect();
-let vec_slice: &mut HostSlice<F> = HostSlice::from_mut_slice(&mut test_vec[..]);
-let merkle_tree: MerkleTree = MerkleTree::new(&layer_hashes, leaf_size, 0).unwrap();
-
-let _ = merkle_tree
-    .build(vec_slice,&tree_config);
-merkle_tree
+    let tree_height: usize = test_vec.len().ilog2() as usize;
+    //just to be safe
+    tree_config.padding_policy = PaddingPolicy::ZeroPadding;
+    let layer_hashes: Vec<&Hasher> = std::iter::once(&hasher)
+        .chain(std::iter::repeat(&compress).take(tree_height))
+        .collect();
+    let vec_slice: &mut HostSlice<F> = HostSlice::from_mut_slice(&mut test_vec[..]);
+    let merkle_tree: MerkleTree = MerkleTree::new(&layer_hashes, leaf_size, 0).unwrap();
+
+    let _ = merkle_tree
+        .build(vec_slice,&tree_config);
+    merkle_tree
 }
 
 //poseidon2 supports t=2,3,4,8,12,16,20,24. In this example we build a binary tree with Poseidon2 t=2.
-let poseidon_state_size = 2; 
+let poseidon_state_size = 2;
 let leaf_size:u64 = 4;// each leaf is a 32 bit element 32/8 = 4 bytes
 
-let mut test_vec = vec![F::from_u32(random::<u32>()); 1024* (poseidon_state_size as usize)];   
+let mut test_vec = vec![F::from_u32(random::<u32>()); 1024* (poseidon_state_size as usize)];
 println!("Generated random vector of size {:?}", 1024* (poseidon_state_size as usize));
 //to use later for merkle proof
 let mut binding = test_vec.clone();
@@ -168,7 +166,7 @@ let random_test_index = rand::thread_rng().gen_range(0..1024*(poseidon_state_siz
 print!("Generating proof for element {:?} at random test index {:?} ",test_vec[random_test_index], random_test_index);
 let merkle_proof = merk_tree.get_proof::<F>(test_vec_slice, random_test_index.try_into().unwrap(), false, &tree_config).unwrap();
 
-//actually should construct verifier tree :) 
+//actually should construct verifier tree :)
 assert!(merk_tree.verify(&merkle_proof).unwrap());
 println!("\n Merkle proof verified successfully!");
-```
+```