From 8f14c8b07bfde633b6cf5046a42dee52d8379fa1 Mon Sep 17 00:00:00 2001 From: Dimitris Apostolou Date: Fri, 5 Jan 2024 21:32:13 +0200 Subject: [PATCH] Fix typos --- book/src/deprecated/examples.md | 2 +- .../for-vampir/zk-proofs-for-vampir.md | 2 +- book/src/exec_examples.md | 2 +- book/src/spec.md | 4 ++-- book/src/spec_zk_garage.md | 16 ++++++++-------- taiga_halo2/src/circuit/gadgets/sub.rs | 6 +++--- .../src/circuit/vp_examples/cascade_intent.rs | 2 +- taiga_halo2/src/compliance.rs | 6 +++--- taiga_halo2/src/constant.rs | 2 +- taiga_halo2/src/taiga_api.rs | 2 +- taiga_halo2/src/transparent_ptx.rs | 4 ++-- 11 files changed, 24 insertions(+), 24 deletions(-) diff --git a/book/src/deprecated/examples.md b/book/src/deprecated/examples.md index 4bab4e19..939a38aa 100644 --- a/book/src/deprecated/examples.md +++ b/book/src/deprecated/examples.md @@ -67,7 +67,7 @@ let (proof, public_inputs) = blinding_circuit .gen_proof::(&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::( diff --git a/book/src/deprecated/for-vampir/zk-proofs-for-vampir.md b/book/src/deprecated/for-vampir/zk-proofs-for-vampir.md index 093c145f..b6a93905 100644 --- a/book/src/deprecated/for-vampir/zk-proofs-for-vampir.md +++ b/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})$. diff --git a/book/src/exec_examples.md b/book/src/exec_examples.md index 367e9049..9e7493e7 100644 --- a/book/src/exec_examples.md +++ b/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. diff --git a/book/src/spec.md b/book/src/spec.md index 2a7be733..ed12a013 100644 --- a/book/src/spec.md +++ b/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. diff --git a/book/src/spec_zk_garage.md b/book/src/spec_zk_garage.md index 3e6a0c0e..7f41292a 100644 --- a/book/src/spec_zk_garage.md +++ b/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` diff --git a/taiga_halo2/src/circuit/gadgets/sub.rs b/taiga_halo2/src/circuit/gadgets/sub.rs index 5ceb8391..0b67ccef 100644 --- a/taiga_halo2/src/circuit/gadgets/sub.rs +++ b/taiga_halo2/src/circuit/gadgets/sub.rs @@ -49,7 +49,7 @@ impl SubChip { ) -> >::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 SubInstructions for SubChip { 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 SubInstructions for SubChip { 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(); diff --git a/taiga_halo2/src/circuit/vp_examples/cascade_intent.rs b/taiga_halo2/src/circuit/vp_examples/cascade_intent.rs index f6feea9f..a4eaa0d3 100644 --- a/taiga_halo2/src/circuit/vp_examples/cascade_intent.rs +++ b/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::{ diff --git a/taiga_halo2/src/compliance.rs b/taiga_halo2/src/compliance.rs index 585470e8..4221a44e 100644 --- a/taiga_halo2/src/compliance.rs +++ b/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" diff --git a/taiga_halo2/src/constant.rs b/taiga_halo2/src/constant.rs index 193e3ebf..23164f1f 100644 --- a/taiga_halo2/src/constant.rs +++ b/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() { diff --git a/taiga_halo2/src/taiga_api.rs b/taiga_halo2/src/taiga_api.rs index 3ffe4243..4a1742dc 100644 --- a/taiga_halo2/src/taiga_api.rs +++ b/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 { diff --git a/taiga_halo2/src/transparent_ptx.rs b/taiga_halo2/src/transparent_ptx.rs index 4ced2b3f..99085aea 100644 --- a/taiga_halo2/src/transparent_ptx.rs +++ b/taiga_halo2/src/transparent_ptx.rs @@ -69,7 +69,7 @@ impl Executable for TransparentPartialTransaction { fn get_nullifiers(&self) -> Vec { 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 { - // 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()