docs: fix katex math

docs/primer/collabSNARKs-primer.md

@@ -4,30 +4,30 @@
 
 To highlight what we can achieve with coSNARKs imagine two parties, Alice and Bob.
 
-<img src="figures/step1.png" alt="alice-bob" width="100%"/>
+<img src={require("./figures/step1.png").default} alt="alice-bob" width="80%"/>
 
-Alice and Bob own a secret value $$a$$ and $$b$$ respectively. They want to compute the [Poseidon](https://eprint.iacr.org/2019/458.pdf) hash of their combined secrets, but without revealing $$a$$ or $$b$$ to each other, while also producing a ZKP that their computation was correct and resulted in said public hash (a real use-case would also additionally prove properties about $$a,b$$).
+Alice and Bob own a secret value $a$ and $b$ respectively. They want to compute the [Poseidon](https://eprint.iacr.org/2019/458.pdf) hash of their combined secrets, but without revealing $a$ or $b$ to each other, while also producing a ZKP that their computation was correct and resulted in said public hash (a real use-case would also additionally prove properties about $a,b$).
 
 Sure, they could send their secrets to a trusted third party to compute the hash and return the result. But then that third party would learn both of their secrets, which they’re not comfortable with. This is where coSNARKs come into play, allowing them to securely compute the hash together without exposing their private values.
 
-First of all, Alice and Bob need to [secret-share](https://en.wikipedia.org/wiki/Secret_sharing) $$a$$ and $$b$$.
+First of all, Alice and Bob need to [secret-share](https://en.wikipedia.org/wiki/Secret_sharing) $a$ and $b$.
 
-<img src="figures/step2.png" alt="secret-share input" width="100%"/>
+<img src={require("./figures/step2.png").default} alt="secret-share input" width="80%"/>
 
 Remember, shares of a secret-shared value are safe to send around as one needs a certain threshold of shares to obtain the original secret. With that in mind, Alice and Bob send their shares to an MPC-network.
 
-<img src="figures/step3.png" alt="secret-share input" width="100%"/>
+<img src={require("./figures/step3.png").default} alt="secret-share input" width="100%"/>
 
 In our example, the MPC-network consists of three computing nodes. In a real-world example, Alice and Bob can also participate as one of the nodes, only Bob can participate, or neither Alice nor Bob joins! Zooming into the computing nodes, it looks like this:
 
-<img src="figures/step4.png" alt="secret-share input" width="100%"/>
+<img src={require("./figures/step4.png").default} alt="secret-share input" width="100%"/>
 
-The MPC network now computes the extended witness of $$a$$ and $$b$$. If you are confused what this means, we recommend reading the explanation in the [circom documentation](https://docs.circom.io/getting-started/computing-the-witness/)! TLDR: we compute the circuit with the inputs $$a$$ and $$b$$ and get the result of the circuit. In our case, this is the Poseidon hash of $$a$$ and $$b$$!
+The MPC network now computes the extended witness of $a$ and $b$. If you are confused what this means, we recommend reading the explanation in the [circom documentation](https://docs.circom.io/getting-started/computing-the-witness/)! TLDR: we compute the circuit with the inputs $a$ and $b$ and get the result of the circuit. In our case, this is the Poseidon hash of $a$ and $b$!
 
-<img src="figures/step5.png" alt="secret-share input" width="100%"/>
+<img src={require("./figures/step5.png").default} alt="secret-share input" width="100%"/>
 
 The last step is to compute the proof! Computing the proof can either be done by the same computing nodes as in the previous step, but they may differ in a real example.
 
-<img src="figures/step6.png" alt="secret-share input" width="100%"/>
+<img src={require("./figures/step6.png").default} alt="secret-share input" width="100%"/>
 
-The final result is the Poseidon hash of $$a$$ and $$b$$ and a coSNARK attesting the validity of the Poseidon hash!
+The final result is the Poseidon hash of $a$ and $b$ and a coSNARK attesting the validity of the Poseidon hash!

docs/primer/mpc-primer.md

@@ -1,5 +1,5 @@
 # MPC Primer
 
-MPC is a subfield of cryptography that enables multiple parties to jointly compute a function $$f$$ over their combined inputs, while keeping these inputs private.
+MPC is a subfield of cryptography that enables multiple parties to jointly compute a function $f$ over their combined inputs, while keeping these inputs private.
 
-Similar to ZK, the evaluated function is usually represented as an arithmetic circuit. The inputs are [secret-shared](https://en.wikipedia.org/wiki/Secret_sharing) among the parties. Every party evaluates the circuit locally on their shares and communicates with the other participants when necessary. After the parties finish their computation, they reconstruct the result of the function $$f$$ without ever telling anyone the secret inputs. In practice, the parties computing the function are not necessarily the same parties that provided the inputs.
+Similar to ZK, the evaluated function is usually represented as an arithmetic circuit. The inputs are [secret-shared](https://en.wikipedia.org/wiki/Secret_sharing) among the parties. Every party evaluates the circuit locally on their shares and communicates with the other participants when necessary. After the parties finish their computation, they reconstruct the result of the function $f$ without ever telling anyone the secret inputs. In practice, the parties computing the function are not necessarily the same parties that provided the inputs.

docs/resources/mpc.md

@@ -13,9 +13,11 @@ With $[x]$ we denote that $x\in\mathbb F_p$ is additively secret shared amongst
 
 Replicated secret sharing is based on additive secret sharing, with the twist that each party has multiple additive shares. Thus, in the 3-party case a secret $x\in\mathbb F_p$ is shared the following way. First, the $x$ is split into three random shares $x_1, x_2, x_3\in\mathbb F_p$ such that $x=x_1+x_2+x_3 \mod p$ and each party gets two shares:
 $$
+\begin{align*}
     P_1: (x_1, x_3)\\
     P_2: (x_2, x_1)\\
     P_3: (x_3, x_2)
+\end{align*}
 $$
 
 ### Rng Setup
@@ -27,19 +29,23 @@ Random values are required during many parts of MPC executions. For cheaper rand
 In order to create random shares $(r_i, r_{i-1})$, random additive shares of $0$ (i.e., $r_i - r_{i-1}$), or random binary shares of $0$ (i.e., $r_i \oplus r_{i-1}$) without interaction, Rep3 sets up a correlated random number generator during the setup phase. Each party $P_i$ chooses a seed $s_i$ and sends it to the next party $P_{i+1}$. Thus, each party has two seeds and can set up an RNG's, where two party are able to create the same random numbers:
 
 $$
+\begin{align*}
     P_1: (\text{RNG}_1, \text{RNG}_3)\\
     P_2: (\text{RNG}_2, \text{RNG}_1)\\
     P_3: (\text{RNG}_3, \text{RNG}_2)
+\end{align*}
 $$
 
 #### Binary To Arithmetic Conversion
 
 For the binary to arithmetic conversion, we need correlated randomness as well. The goal is to setup RNG's, such that:
 
 $$
-    P_1: (\text{RNG1}_1, \text{RNG1}_3), (\text{RNG2}_1, \text{RNG2}_2, \text{RNG2}_3)\\
-    P_1: (\text{RNG1}_1, \text{RNG1}_2, \text{RNG1}_3), (\text{RNG2}_2, \text{RNG2}_1)\\
-    P_3: (\text{RNG1}_1, \text{RNG1}_2, \text{RNG1}_3), (\text{RNG2}_1, \text{RNG2}_2, \text{RNG2}_3)
+\begin{align*}
+    P_1: (&\text{RNG1}_1, \text{RNG1}_3), (\text{RNG2}_1, \text{RNG2}_2, \text{RNG2}_3)\\
+    P_2: (&\text{RNG1}_1, \text{RNG1}_2, \text{RNG1}_3), (\text{RNG2}_2, \text{RNG2}_1)\\
+    P_3: (&\text{RNG1}_1, \text{RNG1}_2, \text{RNG1}_3), (\text{RNG2}_1, \text{RNG2}_2, \text{RNG2}_3)
+\end{align*}
 $$
 In other words, $P_2$ and $P_3$ can use RNG1 create the same field element, while all parties can sample valid shares for it. Similar, $P_1$ and $P_3$ can use RNG2 to create the same field element, while all parties can sample valid shares for it. This setup can be achieved by sampling seeds from the already set up RNG for shared random values and resharing the seeds correctly.
 
@@ -68,9 +74,11 @@ Thus, multiplications involve a local operation followed by a resharing of the r
 
 Thus, party $P_i$ calculates:
 $$
-    r_i = \text{RNG}_i - \text{RNG}_{i-1}\\
-    z_i = x_i \cdot y_i + x_i \cdot y_{i-1} + x_{i-1} \cdot y_i + r_i\\
-    z_{i-1} = \text{SendReceive}(z_i)
+\begin{align*}
+    r_i &= \text{RNG}_i - \text{RNG}_{i-1}\\
+    z_i &= x_i \cdot y_i + x_i \cdot y_{i-1} + x_{i-1} \cdot y_i + r_i\\
+    z_{i-1} &= \text{SendReceive}(z_i)
+\end{align*}
 $$
 
 The resharing, thereby, is simply implemented as $P_i$ sending $z_i$ to $P_{i+1}$.
@@ -80,9 +88,11 @@ The resharing, thereby, is simply implemented as $P_i$ sending $z_i$ to $P_{i+1}
 AND gates follow directly from multiplications:
 
 $$
-    r_i = \text{RNG}_i \oplus \text{RNG}_{i-1}\\
-    z_i = (x_i \wedge y_i) \oplus (x_i \wedge y_{i-1}) \oplus (x_{i-1} \wedge y_i) \oplus r_i\\
-    z_{i-1} = \text{SendReceive}(z_i)
+\begin{align*}
+    r_i &= \text{RNG}_i \oplus \text{RNG}_{i-1}\\
+    z_i &= (x_i \wedge y_i) \oplus (x_i \wedge y_{i-1}) \oplus (x_{i-1} \wedge y_i) \oplus r_i\\
+    z_{i-1} &= \text{SendReceive}(z_i)
+\end{align*}
 $$
 
 #### Arithmetic to Binary Conversion
@@ -177,7 +187,7 @@ $$
         1 & 2 & 3 & ... & n \\
         1 & 2^2 & 3^2 & ... & n^2 \\
         \vdots & \vdots & \vdots & \ddots & \vdots  \\
-        1 & 2^t & 3^t & ... & n^t \\
+        1 & 2^t & 3^t & ... & n^t
     \end{array}\right)
 $$
 

docusaurus.config.ts

@@ -32,6 +32,13 @@ const config: Config = {
     locales: ["en"],
   },
 
+  stylesheets: [
+    {
+      href: "/katex/katex.min.css",
+      type: "text/css",
+    },
+  ],
+
   presets: [
     [
       "classic",

sidebars.ts

@@ -17,8 +17,8 @@ const sidebars: SidebarsConfig = {
   // But you can create a sidebar manually
   coSnarkSidebar: [
     "overview",
-    "primer/collabSNARKs-primer",
     "primer/mpc-primer",
+    "primer/collabSNARKs-primer",
     {
       type: "category",
       label: "Use Cases",

src/pages/index.tsx

@@ -1,16 +1,16 @@
-import clsx from 'clsx';
-import Link from '@docusaurus/Link';
-import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
-import Layout from '@theme/Layout';
-import HomepageFeatures from '@site/src/components/HomepageFeatures';
-import Heading from '@theme/Heading';
+import clsx from "clsx";
+import Link from "@docusaurus/Link";
+import useDocusaurusContext from "@docusaurus/useDocusaurusContext";
+import Layout from "@theme/Layout";
+import HomepageFeatures from "@site/src/components/HomepageFeatures";
+import Heading from "@theme/Heading";
 
-import styles from './index.module.css';
+import styles from "./index.module.css";
 
 function HomepageHeader() {
-  const {siteConfig} = useDocusaurusContext();
+  const { siteConfig } = useDocusaurusContext();
   return (
-    <header className={clsx('hero hero--primary', styles.heroBanner)}>
+    <header className={clsx("hero hero--primary", styles.heroBanner)}>
       <div className="container">
         <Heading as="h1" className="hero__title">
           {siteConfig.title}
@@ -19,7 +19,8 @@ function HomepageHeader() {
         <div className={styles.buttons}>
           <Link
             className="button button--secondary button--lg"
-            to="/docs/getting-started/quickstart">
+            to="/docs/getting-started/quick-start"
+          >
             Get Started with coSNARKs
           </Link>
         </div>
@@ -29,11 +30,12 @@ function HomepageHeader() {
 }
 
 export default function Home(): JSX.Element {
-  const {siteConfig} = useDocusaurusContext();
+  const { siteConfig } = useDocusaurusContext();
   return (
     <Layout
       title={`${siteConfig.title}`}
-      description="Documentation for coSNARK libraries by TACEO.">
+      description="Documentation for coSNARK libraries by TACEO."
+    >
       <HomepageHeader />
       <main>
         <HomepageFeatures />