Fix typos

book/src/deprecated/examples.md

@@ -67,7 +67,7 @@ let (proof, public_inputs) = blinding_circuit
       .gen_proof::<Opc>(&pp_blind, pk, b"Test")
       .unwrap();
 ```
-From a proof, the verifier can check the public inputs against the blinded verifier key `vk_blind` (see [here](https://github.com/anoma/taiga/blob/main/src/doc_examples/blinding.rs)), and verifiy the proof:
+From a proof, the verifier can check the public inputs against the blinded verifier key `vk_blind` (see [here](https://github.com/anoma/taiga/blob/main/src/doc_examples/blinding.rs)), and verify the proof:
 ```rust
 let verifier_data = VerifierData::new(vk, public_inputs);
 verify_proof::<Fq, OP, Opc>(

book/src/deprecated/for-vampir/zk-proofs-for-vampir.md

@@ -2,7 +2,7 @@
 
 ## ZK proofs in a nutshell
 Zero-knowledge proofs are new cryptographic primitives leading to very useful applications. Two entities called *prover* and *verifier* interact.
-They both know an arithmetic circuit and the prover knows a witness for the circuit. It means that pluging the witness into the circuit makes the circuit consistent. The verifier computes the verifier key from the circuit, and can verify a proof using the verifier key. 
+They both know an arithmetic circuit and the prover knows a witness for the circuit. It means that plugging the witness into the circuit makes the circuit consistent. The verifier computes the verifier key from the circuit, and can verify a proof using the verifier key. 
 * Setting. The prover and the verifier know a circuit $\mathcal C$. The verifier key can be derived as $\text{vk} = \text{Precomputation}(\mathcal C)$.
 * Proof. The prover computes a proof $π$ of from the circuit $\mathcal C$ and the witness $ω$: $π = \text{Proof}(ω, \mathcal C)$.
 * Verification. The verifier can check the proof by computing the boolean $\text{Verify}(π, \text{vk})$.

book/src/exec_examples.md

@@ -1,4 +1,4 @@
-# Exectuion model examples
+# Execution model examples
 
 Let's see how different use cases can be handled with the Taiga execution model.
 

book/src/spec.md

@@ -19,7 +19,7 @@ Cycles of curves serve as a solution to the problem of non-native arithmetic by
 ### 1.3 Proving system interfaces
 ||Interface|Description|
 |-|-|-|
-|__Generate Verifier key__|`keygen_vk(C) ⟶ vk`|`C` is turned into a *circuit description* or *verifying key* `vk`, a succint representation of the circuit that the verifier uses to verify a proof|
+|__Generate Verifier key__|`keygen_vk(C) ⟶ vk`|`C` is turned into a *circuit description* or *verifying key* `vk`, a succinct representation of the circuit that the verifier uses to verify a proof|
 |__Generate Proving key__|`keygen_pk(C, vk) ⟶ pk`|Generate a proving key from a verifying key and an instance of circuit|
 |__Prove__|`P(C, pk, x, w) ⟶ π`|Prove that a circuit is satisfied given instance `x` and witness `w`|
 |__Verify__|`V(vk, x, π) ⟶ 0/1`|Verify the proof|
@@ -308,7 +308,7 @@ For each epoch the state consists of:
     - Only `cm` is hashed in derivation of `rt`, note encryption `ce` is simply stored alongside `cm`
 - Set of input note nullifiers, $NF$
     - Supporting add: $NF.add(nf)$
-    - Supports memership checks
+    - Supports membership checks
 
 The state should make past `rt` accessible as well.
 

book/src/spec_zk_garage.md

@@ -68,7 +68,7 @@ We blend commitments / hash into a single abstract interface.
 - `Com_r(...) ⟶ com` efficient over $\mathbb{F}_r$
 - `Com(...) ⟶ com` efficient over **both** $\mathbb{F}_q$ and $\mathbb{F}_r$
 
-Commitments are binding by default (i.e. can be instantiated with hash). If we want blinding (possibly across differnt commitments), we add `rcm` explicitly.
+Commitments are binding by default (i.e. can be instantiated with hash). If we want blinding (possibly across different commitments), we add `rcm` explicitly.
 
 TODO: Fix the exact instantiations / implementations.
 
@@ -170,7 +170,7 @@ Public inputs (`x`):
     - a public parameter to `vp`, i.e. immutable data, so that user can customize a global `vp` for example.
 - vp public output: `vp_memo` 
     - a public "output" of vp can encode arbitrary data.
-    - e.g. encode `rk` to support Sapling/Orchard-type auth. But if we make this choice, then a signature verfication needs to be done on every `rk`.
+    - e.g. encode `rk` to support Sapling/Orchard-type auth. But if we make this choice, then a signature verification needs to be done on every `rk`.
 - spent note nullifiers, `nf_1, …, nf_m`
 - created note commitments, `cm_1, …, cm_n`
 - for receiving vp: `ce_1, …, ce_n`
@@ -198,11 +198,11 @@ Arithmetized over $\mathbb{F}_r$. Represented as a Plonk circuit, `ActionCircuit
 Public inputs (`x`):
 - Merkle root `rt`
 - Spent note nullifier `nf`, which commits to note application type, value, and data
-    - User VP commitment: `com_vp_addr_send` (commiting to `desc_vp_addr_send`)
+    - User VP commitment: `com_vp_addr_send` (committing to `desc_vp_addr_send`)
     - Application VP commitment: `com_vp_app`
     - `EnableSpend`
 - Output note commitment `cm`
-    - User VP commitment: `com_vp_addr_recv` (commiting to `desc_vp_addr_recv`)
+    - User VP commitment: `com_vp_addr_recv` (committing to `desc_vp_addr_recv`)
     - Application VP commitment: `com_vp_app`
     - `EnableOutput`
 
@@ -283,14 +283,14 @@ For each epoch the state consists of:
     - Only `cm` is hashed in derivation of `rt`, note encryption `ce` is simply stored alongside `cm`
 - Set of spent note nullifiers, $NF$
     - Supporting add: $NF.add(nf)$
-    - Supports memership checks
+    - Supports membership checks
 
 The state should make past `rt` accessible as well (TODO: can be simplify this?)
 
 ### Taiga Transaction `tx`
 
 A Taiga transaction `tx` contains k actions, upto k spent notes, and upto k created notes:
-- Each $i$-th action specfies:
+- Each $i$-th action specifies:
     - `ActionCircuit` proof `π_action_i`
     - public input `(rt_i, nf_i, enableSpend, cm_i, enableOutput)`, resulting in overall list of `NF_tx` and `CM_tx`:
         - If `enableSpend = 1`, then `nf_i` is added to `NF_tx`
@@ -334,7 +334,7 @@ Why? We can verify a collection of Action and VP proofs efficiently for all proo
 
 ### Decomposition of Plonk verifier
 
-Verification `Verify(desc, x, π)` requires both $F_p$ and $F_q$ arithmetics are needed. To make recursive proof verification more efficient, we can decompose the verifer computation into $F_p$ part and $F_q$ part.
+Verification `Verify(desc, x, π)` requires both $F_p$ and $F_q$ arithmetics are needed. To make recursive proof verification more efficient, we can decompose the verifier computation into $F_p$ part and $F_q$ part.
 
 Specifically, we need to construct two circuits `V_q(desc_C, x, π, intval), V_p(intval)`, efficient over $\mathbb{F}_r$ and $\mathbb{F}_q$ respectively, such that `V(desc_C, x, π) = 1` iff `V_q(desc_C, x, π, intval) = 1` and `V_p(intval) = 1`. Note that `V_p` only take input the intermediate value.
 
@@ -356,7 +356,7 @@ Specifically, we need to construct two circuits `V_q(desc_C, x, π, intval), V_p
 ### Transaction w/ recursive proof
 
 A (recursive) Taiga transaction `tx` contains k actions, upto k spent notes, and upto k created notes:
-- Each $i$-th action specfies:
+- Each $i$-th action specifies:
     - public input `(rt_i, nf_i, enableSpend, cm_i, enableOutput)`, resulting in overall list of `NF_tx` and `CM_tx`:
         - If `enableSpend = 1`, then `nf_i` is added to `NF_tx`
         - If `enableOutput = 1`, then `cm_i` is added to `CM_tx` and `tx` also provide `ce_i`, which is added to `CE_tx`

taiga_halo2/src/circuit/gadgets/sub.rs

@@ -49,7 +49,7 @@ impl<F: Field> SubChip<F> {
     ) -> <Self as Chip<F>>::Config {
         let s_sub = meta.selector();
 
-        // Define our substraction gate!
+        // Define our subtraction gate!
         meta.create_gate("sub", |meta| {
             let lhs = meta.query_advice(advice[0], Rotation::cur());
             let rhs = meta.query_advice(advice[1], Rotation::cur());
@@ -85,7 +85,7 @@ impl<F: Field> SubInstructions<F> for SubChip<F> {
         layouter.assign_region(
             || "sub",
             |mut region: Region<'_, F>| {
-                // We only want to use a single substraction gate in this region,
+                // We only want to use a single subtraction gate in this region,
                 // so we enable it at region offset 0; this means it will constrain
                 // cells at offsets 0 and 1.
                 config.s_sub.enable(&mut region, 0)?;
@@ -97,7 +97,7 @@ impl<F: Field> SubInstructions<F> for SubChip<F> {
                 a.copy_advice(|| "lhs", &mut region, config.advice[0], 0)?;
                 b.copy_advice(|| "rhs", &mut region, config.advice[1], 0)?;
 
-                // Now we can compute the substraction result, which is to be assigned
+                // Now we can compute the subtraction result, which is to be assigned
                 // into the output position.
                 let value = a.value().copied() - b.value();
 

taiga_halo2/src/circuit/vp_examples/cascade_intent.rs

@@ -2,7 +2,7 @@
 /// In this example, Alice wants to spend three(more than the fixed NUM_RESOURCE) different kinds of tokens/resources simultaneously.
 /// She needs to distribute the resources to two partial transactions. She can use the intent to cascade the partial transactions.
 /// In the first partial transaction, she spends two resources and creates a cascade intent resource to encode and check the third resource info.
-/// In the sencond partial transaction, she spends the cascade resource and the third resource.
+/// In the second partial transaction, she spends the cascade resource and the third resource.
 ///
 use crate::{
     circuit::{

taiga_halo2/src/compliance.rs

@@ -164,7 +164,7 @@ impl ComplianceInfo {
         self.rseed.get_vp_cm_r(PRF_EXPAND_OUTPUT_VP_CM_R)
     }
 
-    // Only used in transparent scenario: the achor is untrusted, recalculate root when executing it transparently.
+    // Only used in transparent scenario: the anchor is untrusted, recalculate root when executing it transparently.
     pub fn calculate_root(&self) -> Anchor {
         self.input_resource.calculate_root(&self.input_merkle_path)
     }
@@ -174,7 +174,7 @@ impl ComplianceInfo {
         DeltaCommitment::commit(&self.input_resource, &self.output_resource, blind_r)
     }
 
-    pub fn get_input_resource_nullifer(&self) -> Nullifier {
+    pub fn get_input_resource_nullifier(&self) -> Nullifier {
         self.input_resource.get_nf().unwrap()
     }
 
@@ -183,7 +183,7 @@ impl ComplianceInfo {
     }
 
     pub fn build(&self) -> (CompliancePublicInputs, ComplianceCircuit) {
-        let nf = self.get_input_resource_nullifer();
+        let nf = self.get_input_resource_nullifier();
         assert_eq!(
             nf, self.output_resource.nonce,
             "The nf of input resource must be equal to the nonce of output resource"

taiga_halo2/src/constant.rs

@@ -6139,7 +6139,7 @@ fn export_params() {
 
 // It takes 4 seconds to generate one proving key.
 // It may be fine to generate the key once when compiling.
-// Consider loading the key from file when the keys are stablized.
+// Consider loading the key from file when the keys are stabilized.
 // #[ignore]
 // #[test]
 // fn export_compliance_proving_key() {

taiga_halo2/src/taiga_api.rs

@@ -58,7 +58,7 @@ pub fn create_output_resource(
     label: pallas::Base,
     value: pallas::Base,
     quantity: u64,
-    // The owner of output resource has the nullifer key and exposes the nullifier_key commitment to output creator.
+    // The owner of output resource has the nullifier key and exposes the nullifier_key commitment to output creator.
     npk: pallas::Base,
     is_ephemeral: bool,
 ) -> Resource {

taiga_halo2/src/transparent_ptx.rs

@@ -69,7 +69,7 @@ impl Executable for TransparentPartialTransaction {
     fn get_nullifiers(&self) -> Vec<Nullifier> {
         self.compliances
             .iter()
-            .map(|compliance| compliance.get_input_resource_nullifer())
+            .map(|compliance| compliance.get_input_resource_nullifier())
             .collect()
     }
 
@@ -89,7 +89,7 @@ impl Executable for TransparentPartialTransaction {
     }
 
     fn get_anchors(&self) -> Vec<Anchor> {
-        // TODO: We have easier way to check the anchor in transparent scenario, but keep consistent with sheilded right now.
+        // TODO: We have easier way to check the anchor in transparent scenario, but keep consistent with shielded right now.
         // TODO: we can skip the root if the is_ephemeral flag is true?
         self.compliances
             .iter()