Fix typos (privacy-scaling-explorations#210)

book/part1_chapter1.md

@@ -51,7 +51,7 @@ Negative values are obtained by the formula `a + (-a) mod p = 0`.
 
 The prime `p` is usually a very big number when used in ZKP, but we can see an easy example with `p = 7`.
 
-The posible values would be `0, 1, 2, 3, 4, 5` and `6`. If we go over `p` it overflows around to `0`. So for example `6 + 1 = 0` or `5 + 3 = 1`.
+The possible values would be `0, 1, 2, 3, 4, 5` and `6`. If we go over `p` it overflows around to `0`. So for example `6 + 1 = 0` or `5 + 3 = 1`.
 
 Then for example  `-3 + 3 mod 7 = 0 ` which is satisfied by `4 + 3 mod 7 = 0 => -3 = 4`.
 

book/part1_chapter3.md

@@ -80,7 +80,7 @@ Step types are part of the setup, which means that they cannot change between pr
 
 Signals represent elements of the witness that have an independent value for each trace step, but in chiquito paradigm you can see them as variables on the trace steps.
 
-Rotation refer to the capability of creating rules that involved the value of signals in other trace steps with an offset relative to the trace step, not just the value of a signal. A rotation of 0, represent the value of the signal in the same trace step, a rotation of 1 in the next step, a rotation of -1 in the previous step, in general any rotation number is posible.
+Rotation refer to the capability of creating rules that involved the value of signals in other trace steps with an offset relative to the trace step, not just the value of a signal. A rotation of 0, represent the value of the signal in the same trace step, a rotation of 1 in the next step, a rotation of -1 in the previous step, in general any rotation number is possible.
 
 ## Types of signals
 

book/part2_chapter4.ipynb

@@ -13,7 +13,7 @@
    "id": "d7a26b56-e0c7-4e35-a064-5899aa2ef6b7",
    "metadata": {},
    "source": [
-    "To avoid the soundness error from `evil_witness` in Chapter 3, we need to constrain that forward signals \"a\" and \"b\" are both 1 in the first step instance. Because this isn't true for all step instances, we need to create a new step type, called `FiboFirstStep`, which is idential to `FiboStep` except two additional constraints for \"a\" and \"b\":\n",
+    "To avoid the soundness error from `evil_witness` in Chapter 3, we need to constrain that forward signals \"a\" and \"b\" are both 1 in the first step instance. Because this isn't true for all step instances, we need to create a new step type, called `FiboFirstStep`, which is identical to `FiboStep` except two additional constraints for \"a\" and \"b\":\n",
     "\n",
     "| Step Type | Step Instance Index || Signals |||| Setups |||\n",
     "| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |\n",
@@ -293,7 +293,7 @@
     "\n",
     "Besides, we learned that with multiple step types, Chiquito can create step instances with different signals and constraints, thereby allowing great versatility in circuit design.\n",
     "\n",
-    "Finally, this example shows again that circuit setup and witness generation are separate processes. There can be multiple witnesses for the same circuit setup. As a great analogy, a circuit can be considered a piece of \"hardware\" whereas its witnesses \"softwares\" that are compatible with the hardware."
+    "Finally, this example shows again that circuit setup and witness generation are separate processes. There can be multiple witnesses for the same circuit setup. As a great analogy, a circuit can be considered a piece of \"hardware\" whereas its witnesses \"software\" that are compatible with the hardware."
    ]
   }
  ],

book/part2_chapter5.ipynb

@@ -6,7 +6,7 @@
    "metadata": {},
    "source": [
     "# Chapter 5: Padding and Exposing Signals\n",
-    "In prior examples, all Fibonacci circuit witnesses have the same number of step instances. According to our analogy where a circuit is considered a piece of hardware and its witnesses compatible softwares, it's natural to think that we'd allow for more flexibility for our witnesses. Most immediately, and we shouldn't limit all Fibonacci circuit witnesses to have the same number of step instances.\n",
+    "In prior examples, all Fibonacci circuit witnesses have the same number of step instances. According to our analogy where a circuit is considered a piece of hardware and its witnesses compatible software, it's natural to think that we'd allow for more flexibility for our witnesses. Most immediately, and we shouldn't limit all Fibonacci circuit witnesses to have the same number of step instances.\n",
     "\n",
     "However, you might wonder, doesn't `self.pragma_num_steps(4)` limit the number of step instances to 4? Besides, doesn't this function guarantee the Fibonacci circuit's security, such that we have a fixed circuit setup with a specific number of step instances, thereby making the circuit a piece of \"hardware\" that cannot be tampered with? How can we allow for BOTH a fixed circuit setup AND flexible witnesses? This problem is frequently encountered in projects like PSE's zkEVM, where witnesses with very different sizes are passed into the same circuit.\n",
     "\n",

src/frontend/python/mod.rs

@@ -1825,39 +1825,39 @@ mod tests {
 #[pyfunction]
 fn convert_and_print_ast(json: &PyString) {
     let circuit: SBPIR<Fr, ()> =
-        serde_json::from_str(json.to_str().expect("PyString convertion failed."))
+        serde_json::from_str(json.to_str().expect("PyString conversion failed."))
             .expect("Json deserialization to Circuit failed.");
     println!("{:?}", circuit);
 }
 
 #[pyfunction]
 fn convert_and_print_trace_witness(json: &PyString) {
     let trace_witness: TraceWitness<Fr> =
-        serde_json::from_str(json.to_str().expect("PyString convertion failed."))
+        serde_json::from_str(json.to_str().expect("PyString conversion failed."))
             .expect("Json deserialization to TraceWitness failed.");
     println!("{:?}", trace_witness);
 }
 
 #[pyfunction]
 fn ast_to_halo2(json: &PyString) -> u128 {
-    let uuid = chiquito_ast_to_halo2(json.to_str().expect("PyString convertion failed."));
+    let uuid = chiquito_ast_to_halo2(json.to_str().expect("PyString conversion failed."));
 
     uuid
 }
 
 #[pyfunction]
 fn ast_map_store(json: &PyString) -> u128 {
-    let uuid = chiquito_ast_map_store(json.to_str().expect("PyString convertion failed."));
+    let uuid = chiquito_ast_map_store(json.to_str().expect("PyString conversion failed."));
 
     uuid
 }
 
 #[pyfunction]
 fn halo2_mock_prover(witness_json: &PyString, rust_id: &PyLong, k: &PyLong) {
     chiquito_halo2_mock_prover(
-        witness_json.to_str().expect("PyString convertion failed."),
-        rust_id.extract().expect("PyLong convertion failed."),
-        k.extract().expect("PyLong convertion failed."),
+        witness_json.to_str().expect("PyString conversion failed."),
+        rust_id.extract().expect("PyLong conversion failed."),
+        k.extract().expect("PyLong conversion failed."),
     );
 }
 
@@ -1870,7 +1870,7 @@ fn super_circuit_halo2_mock_prover(rust_ids: &PyList, super_witness: &PyDict, k:
                 .downcast::<PyLong>()
                 .expect("PyAny downcast failed.")
                 .extract()
-                .expect("PyLong convertion failed.")
+                .expect("PyLong conversion failed.")
         })
         .collect::<Vec<UUID>>();
 
@@ -1881,20 +1881,20 @@ fn super_circuit_halo2_mock_prover(rust_ids: &PyList, super_witness: &PyDict, k:
                 key.downcast::<PyLong>()
                     .expect("PyAny downcast failed.")
                     .extract()
-                    .expect("PyLong convertion failed."),
+                    .expect("PyLong conversion failed."),
                 value
                     .downcast::<PyString>()
                     .expect("PyAny downcast failed.")
                     .to_str()
-                    .expect("PyString convertion failed."),
+                    .expect("PyString conversion failed."),
             )
         })
         .collect::<HashMap<u128, &str>>();
 
     chiquito_super_circuit_halo2_mock_prover(
         uuids,
         super_witness,
-        k.extract().expect("PyLong convertion failed."),
+        k.extract().expect("PyLong conversion failed."),
     )
 }
 

src/plonkish/backend/halo2.rs

@@ -317,7 +317,7 @@ impl<F: Field + From<u64> + Hash> ChiquitoHalo2<F> {
                 .advice_columns
                 .get(&column.uuid())
                 .unwrap_or_else(|| panic!("column not found {}", column.annotation)),
-            _ => panic!("worng column type"),
+            _ => panic!("wrong column type"),
         }
     }
 
@@ -327,7 +327,7 @@ impl<F: Field + From<u64> + Hash> ChiquitoHalo2<F> {
                 .fixed_columns
                 .get(&column.uuid())
                 .unwrap_or_else(|| panic!("column not found {}", column.annotation)),
-            _ => panic!("worng column type"),
+            _ => panic!("wrong column type"),
         }
     }
 }

src/poly/mod.rs

@@ -243,7 +243,7 @@ pub trait SignalFactory<V> {
 pub struct ConstrDecomp<F, V> {
     /// PI constraint for the new signals introduced.
     constrs: Vec<Expr<F, V>>,
-    /// Expressions for how to create the witness for the generated signals the orginal expression
+    /// Expressions for how to create the witness for the generated signals the original expression
     /// has be decomposed into.
     auto_signals: HashMap<V, Expr<F, V>>,
 }

src/poly/reduce.rs

@@ -21,7 +21,7 @@ pub fn reduce_degree<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
 
 /// Actual recursive implementation of `reduce_degre`. Key here to understand the difference
 /// between:  + total_max_degree: maximum degree of the PI the input expression is decomposed of.
-///  + partial_max_degree: maximum degree of the root PI, that can substitute the orginal
+///  + partial_max_degree: maximum degree of the root PI, that can substitute the original
 /// expression.
 ///
 /// The value of `partial_max_degree` can be less than `total_max_degree` when this
@@ -99,7 +99,7 @@ fn reduce_degree_mul<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
     partial_max_degree: usize,
     signal_factory: &mut SF,
 ) -> Expr<F, V> {
-    // base case, if partial_max_degree == 1, the root expresion can only be a variable
+    // base case, if partial_max_degree == 1, the root expression can only be a variable
     if partial_max_degree == 1 {
         let reduction = reduce_degree_mul(
             decomp,
@@ -141,7 +141,7 @@ fn reduce_degree_mul<F: Field, V: Clone + Eq + PartialEq + Hash + Debug, SF: Sig
 
     // for_root will be multipliers that will be included in the root expression
     let mut for_root = Vec::default();
-    // to_simplify will be multipliers that will be recursively decomposed and subsituted by a
+    // to_simplify will be multipliers that will be recursively decomposed and substituted by a
     // virtual signal in the root expression
     let mut to_simplify = Vec::default();