Skip to content

Commit

Permalink
Fix typos
Browse files Browse the repository at this point in the history
  • Loading branch information
rex4539 committed Jan 5, 2024
1 parent dca5934 commit 8f14c8b
Show file tree
Hide file tree
Showing 11 changed files with 24 additions and 24 deletions.
2 changes: 1 addition & 1 deletion book/src/deprecated/examples.md
Original file line number Diff line number Diff line change
Expand Up @@ -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>(
Expand Down
2 changes: 1 addition & 1 deletion book/src/deprecated/for-vampir/zk-proofs-for-vampir.md
Original file line number Diff line number Diff line change
Expand Up @@ -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})$.
Expand Down
2 changes: 1 addition & 1 deletion book/src/exec_examples.md
Original file line number Diff line number Diff line change
@@ -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.

Expand Down
4 changes: 2 additions & 2 deletions book/src/spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -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|
Expand Down Expand Up @@ -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.

Expand Down
16 changes: 8 additions & 8 deletions book/src/spec_zk_garage.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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`
Expand Down Expand Up @@ -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`

Expand Down Expand Up @@ -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`
Expand Down Expand Up @@ -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.

Expand All @@ -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`
Expand Down
6 changes: 3 additions & 3 deletions taiga_halo2/src/circuit/gadgets/sub.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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());
Expand Down Expand Up @@ -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)?;
Expand All @@ -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();

Expand Down
2 changes: 1 addition & 1 deletion taiga_halo2/src/circuit/vp_examples/cascade_intent.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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::{
Expand Down
6 changes: 3 additions & 3 deletions taiga_halo2/src/compliance.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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)
}
Expand All @@ -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()
}

Expand All @@ -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"
Expand Down
2 changes: 1 addition & 1 deletion taiga_halo2/src/constant.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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() {
Expand Down
2 changes: 1 addition & 1 deletion taiga_halo2/src/taiga_api.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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 {
Expand Down
4 changes: 2 additions & 2 deletions taiga_halo2/src/transparent_ptx.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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()
}

Expand All @@ -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()
Expand Down

0 comments on commit 8f14c8b

Please sign in to comment.