Fix typos

book/src/fundamentals/zkbook_rings.md

@@ -8,7 +8,7 @@ A ring is like a field, but where elements may not be invertible. Basically, it'
 
 - subtract
 
-but not necessarily divide. If you know what polynomials are already, you can think of it as the minimal necessary structure for polynomials to make sense. That is, if $R$ is a ring, then we can define the set of polynomials $R[x]$ (basically arithmetic expressions in the variable $x$) and think of any polynomial $f \in R[x]$ giving rise to a function $R \to R$ defined by substituing in for $x$ in $f$ and computing using $+$ and $\cdot$ as defined in $R$.
+but not necessarily divide. If you know what polynomials are already, you can think of it as the minimal necessary structure for polynomials to make sense. That is, if $R$ is a ring, then we can define the set of polynomials $R[x]$ (basically arithmetic expressions in the variable $x$) and think of any polynomial $f \in R[x]$ giving rise to a function $R \to R$ defined by substituting in for $x$ in $f$ and computing using $+$ and $\cdot$ as defined in $R$.
 
 So, in full, a ring $R$ is a set equipped with
 

book/src/kimchi/maller_15.md

@@ -84,7 +84,7 @@ To compute it, there are two rules to follow:
 
 * when two commitment are **added** together, their associated blinding factors get added as well:
     $$\mathsf{com}(a) + \mathsf{com}(b) \implies r_a + r_b$$
-* when **scaling** a commitment, its blinding factor gets scalled too:
+* when **scaling** a commitment, its blinding factor gets scaled too:
     $$n \cdot \mathsf{com}(a) \implies n \cdot r_a$$
 
 As such, if we know $r_f$ and $r_t$, we can compute:

book/src/pickles/deferred.md

@@ -41,7 +41,7 @@ The solution to the first problem is simple:
 
 In the $\mathbb{F}_q$-side decompose $v = 2 \cdot h + l$ with $h \in [0, 2^{\lfloor \log p \rfloor})$ (high bits) and $l \in \{ 0, 1 \}$ (low bit). Note $l, h < p$ since $2 p > q$; always the case for any cycle of curves, $p$ is only $\approx \sqrt{q}$ smaller than $q$, by Hasse. Now "$\tilde{v}$" is "represented" by the two values $\tilde{h}, \tilde{l} \in \mathbb{F}_p$.
 
-Note that no decomposition is nessary if the "original value" $v$ was in $\mathbb{F}_p$, since $\mathbb{F}_q$ is big enough to hold the lift of any element in $\mathbb{F}_p$.
+Note that no decomposition is necessary if the "original value" $v$ was in $\mathbb{F}_p$, since $\mathbb{F}_q$ is big enough to hold the lift of any element in $\mathbb{F}_p$.
 
 #### Problem 2: Compute Commitment to the Public Input of other side
 
@@ -67,7 +67,7 @@ $$
 
 ### We recurse onwards...
 
-At this point the statement of the proof in $\mathbb{F}_q$-side is: the $\mathbb{F}_q$-proof is sound, __condition__ on providing an opening of $P_p$ that satisifies the $\mathbb{F}_p$-relation.
+At this point the statement of the proof in $\mathbb{F}_q$-side is: the $\mathbb{F}_q$-proof is sound, __condition__ on providing an opening of $P_p$ that satisfies the $\mathbb{F}_p$-relation.
 
 At this point you can stop and verify the proof (in the case of a "step proof" you would), by recomputing $P_p$ outside the circuit while checking the $\mathbb{F}_p$-relation manually "in the clear".
 

book/src/pickles/diagrams.md

@@ -6,7 +6,7 @@ The legend of the diagrams is quite straightforward:
 - The black boxes are data structures that have names and labels following the implementation.
   - `MFNStep`/`MFNWrap` is an abbreviation from `MessagesForNextStep` and `MessagesForNextWrap` that is used for brevity. Most other datatypes are exactly the same as in the codebase.
 - The blue boxes are computations. Sometimes, when the computation is trivial or only vaguely indicated, it is denoted as a text sign directly on an arrow.
-- Arrows are blue by default and denote moving a piece of data from one place to another with no (or very little) change. Light blue arrows are denoting witness query that is implemented through the `handler` mechanism. The "chicken foot" connector means that this arrow accesses just one field in an array: such an arrow could connect e.g. a input field of type `old_a: A` in a structure `Vec<(A,B)>` to an output `new_a: A`, which just means that we are inside a `for` loop and this computation is done for all the elemnts in the vector/array.
+- Arrows are blue by default and denote moving a piece of data from one place to another with no (or very little) change. Light blue arrows are denoting witness query that is implemented through the `handler` mechanism. The "chicken foot" connector means that this arrow accesses just one field in an array: such an arrow could connect e.g. a input field of type `old_a: A` in a structure `Vec<(A,B)>` to an output `new_a: A`, which just means that we are inside a `for` loop and this computation is done for all the elements in the vector/array.
 - Colour of the field is sometimes introduced and denotes how many steps ago was this piece of data created. The absence of the colour means either that (1) the data structure contains different subfields of different origin, or that (2) it was not coloured but it could be. The colours are assigned according to the following convention:
 
 ![](./pickles_structure_legend_1.svg)

book/src/plonk/inner_product_api.md

@@ -40,7 +40,7 @@ Note that this kind of aggregation forces us to provide all combinations of eval
 
 ### Splitting a polynomial
 
-If a polynomial is too large to fit in one SRS, you can split it in chuncks of size at most $n$
+If a polynomial is too large to fit in one SRS, you can split it in chunks of size at most $n$
 
 ### Proof of correct commitment to a polynomial
 

book/src/snarky/kimchi-backend.md

@@ -20,7 +20,7 @@ One can also perform two additional operations once the constraint system has be
 
 ## A circuit
 
-A circuit is either being built, or has been contructed during a circuit generation phase:
+A circuit is either being built, or has been constructed during a circuit generation phase:
 
 ```rust
 enum Circuit<F>

folding/src/error_term.rs

@@ -185,7 +185,7 @@ pub(crate) fn eval_exp_error<'a, C: FoldingConfig>(
 /// Computes the error terms of a folding/homogeneous expression.
 /// The extended environment contains all the evaluations of the columns,
 /// including the ones added by the quadraticization process.
-/// `u` is the variables used to homogeneize the expression.
+/// `u` is the variables used to homogenize the expression.
 /// The output is a pair of error terms. To see how it is computed, see the
 /// [top-level documentation of the expressions module](crate::expressions).
 pub(crate) fn compute_error<C: FoldingConfig>(

folding/src/standard_config.rs

@@ -35,7 +35,7 @@ impl<G: KimchiCurve, Col> Index<Col> for EmptyStructure<G> {
 /// use mina_poseidon::FqSponge;
 /// use folding::{examples::{BaseSponge, Curve, Fp}, FoldingScheme};
 ///
-/// // instanciating the config with our types and the defaults for selectors and structure
+/// // instantiating the config with our types and the defaults for selectors and structure
 /// type MyConfig = StandardConfig<Curve, MyCol, MyChallenge, MyInstance<Curve>, MyWitness<Curve>>;
 /// let constraints = vec![constraint()];
 /// let domain = Radix2EvaluationDomain::<Fp>::new(2).unwrap();
@@ -265,7 +265,7 @@ mod memoization {
         where
             I: FnOnce() -> Vec<F>,
         {
-            // this will find or asign an id for the column and then
+            // this will find or assign an id for the column and then
             // search the segments using the id
             let mut ids = self.ids.borrow_mut();
             let new_id = || self.next.fetch_add(1, Ordering::Relaxed);

folding/tests/test_vanilla_folding.rs

@@ -33,7 +33,7 @@ type SpongeParams = PlonkSpongeConstantsKimchi;
 type BaseSponge = DefaultFqSponge<ark_bn254::g1::Config, SpongeParams>;
 
 /// The instance is the commitments to the polynomials and the challenges
-/// There are 3 commitments and challanges because there are 3 columns, A, B and
+/// There are 3 commitments and challenges because there are 3 columns, A, B and
 /// C.
 #[derive(PartialEq, Eq, Debug, Clone)]
 struct TestInstance {
@@ -228,7 +228,7 @@ fn instance_from_witness(
         .collect_vec();
     let commitments: [_; 3] = commitments.try_into().unwrap();
 
-    // here we should absorve the commitments and similar things to later
+    // here we should absorb the commitments and similar things to later
     // compute challenges but for this example I just use random values
     let mut rng = thread_rng();
     let mut challenge = || Fp::rand(&mut rng);

o1vm/src/interpreters/keccak/column.rs

@@ -380,7 +380,7 @@ impl ColumnIndexer for ColumnAlias {
     }
 }
 
-// IMPLEMENTAIONS FOR SELECTOR
+// IMPLEMENTATIONS FOR SELECTOR
 
 impl<T: Clone> Index<Steps> for KeccakWitness<T> {
     type Output = T;

o1vm/src/interpreters/keccak/tests.rs

@@ -317,7 +317,7 @@ fn test_keccak_fake_witness_wont_satisfy_constraints() {
     assert_eq!(witness_env[0].pad_suffix(0), Fp::zero());
     assert_eq!(witness_env[0].pad_suffix(1), Fp::zero());
     assert_eq!(witness_env[0].pad_suffix(2), Fp::zero());
-    // Check that the padding blocks are corrrect
+    // Check that the padding blocks are correct
     assert_eq!(witness_env[0].block_in_padding(0), Fp::zero());
     assert_eq!(witness_env[0].block_in_padding(1), Fp::zero());
     assert_eq!(witness_env[0].block_in_padding(2), Fp::zero());

o1vm/src/interpreters/mips/column.rs

@@ -110,7 +110,7 @@ impl From<Instruction> for usize {
 /// - the current instruction pointer
 /// - the next instruction pointer
 /// - the heap pointer
-/// - the preimage key, splitted in 8 consecutive columns representing 4 bytes
+/// - the preimage key, split in 8 consecutive columns representing 4 bytes
 /// of the 32 bytes long preimage key
 /// - the preimage offset, i.e. the number of bytes that have been read for the
 /// currently processing preimage

o1vm/src/legacy/trace.rs

@@ -81,7 +81,7 @@ where
     }
 
     /// Returns a boolean indicating whether the witness for the given selector
-    /// was ever found in the cirucit or not.
+    /// was ever found in the circuit or not.
     pub fn in_circuit(&self, opcode: C::Selector) -> bool {
         self.number_of_rows(opcode) != 0
     }

o1vm/src/pickles/prover.rs

@@ -272,7 +272,7 @@ where
 
         let fail_final_q_division = || panic!("Fail division by vanishing poly");
         let fail_remainder_not_zero =
-            || panic!("The constraints are not satisifed since the remainder is not zero");
+            || panic!("The constraints are not satisfied since the remainder is not zero");
         // We compute the polynomial t(X) by dividing the constraints polynomial
         // by the vanishing polynomial, i.e. Z_H(X).
         let (quotient, rem) = expr_evaluation_interpolated