Fix several typos

docs/openzl/alloc.md

@@ -3,7 +3,7 @@
 The `alloc` module defines ECLAIR's interface for allocating values in a compiler. We use the term "allocation" here to refer to the process of declaring a variable in a ZK proof system and (maybe) assigning it a value. Note that we are *not* referring to memory-related abstractions like heap allocation.
 
 Variables in a ZK proof system can be private witnesses, public inputs, constants, or some mixture of these. For example, in a merkle tree membership proof we would have variables representing the values stored:
-- in some leaf of the tree 
+- in some leaves of the tree 
 - along the path from that leaf to the root
 - in the root of the tree.
 
@@ -46,7 +46,7 @@ pub trait Variable<M, COM = ()> {
     fn new_unknown(compiler: &mut COM) -> Self;
 
     /// Allocates a new known value from `this` into the `compiler`. The terminology 
-    /// "known" refers to the fact that we have access to the underyling value during 
+    /// "known" refers to the fact that we have access to the underlying value during 
     /// execution time where we are able to use its concrete value for execution.
     fn new_known(this: &Self::Type, compiler: &mut COM) -> Self;
 }
@@ -115,4 +115,4 @@ This time the compiler was able to compute a ZKP because the variables were allo
 
 As mentioned above, it was useful in this example to separate allocation and manipulation. All manipulation occurs within `fn membership_check`, which takes arguments that are assumed to be already allocated in the `compiler`. This ensured that the same manipulations would be performed on the symbolic and concrete forms of these variables. 
 
-(Of course many new variables are allocated as `fn membership_check` performs its computation, but their values are not provided directly by the prover. Perhaps it is more correct to say that one should separate variable *input* from variable manipulation.)
+(Of course many new variables are allocated as `fn membership_check` performs its computation, but their values are not provided directly by the prover. Perhaps it is more correct to say that one should separate variable *input* from variable manipulation.)

docs/openzl/poseidon_permutation_tutorial.md

@@ -9,7 +9,7 @@ The Poseidon permutation, defined in [GKRRS '19](https://eprint.iacr.org/2019/45
 This tutorial will walk through building the Poseidon permutation in ECLAIR. All OpenZL tutorials are accompanied by code examples, see [here](https://github.com/openzklib/openzl/tree/main/openzl-tutorials). Note that this code differs somewhat from our [optimized Poseidon implementation](https://github.com/openzklib/openzl/tree/main/openzl-crypto/src/poseidon).
 
 ### trait `Specification`
-The Poseidon permutation requires a choice of finite field. We will keep this example generic by using a Rust trait `Specification` to specify our assumptions on the field and defining the Poseidon permutation relative to any type that implements `Specification`.
+The Poseidon permutation requires a choice of a finite field. We will keep this example generic by using a Rust trait `Specification` to specify our assumptions on the field and define the Poseidon permutation relative to any type that implements `Specification`.
 ```rust
 /// Poseidon Specification
 ///
@@ -252,7 +252,7 @@ where
     }
 }
 ```
-Note that `fn full_round` and `fn partial_round` take the round number as an input; this is so that they will take correct constants for the given round. Note that they also take the `compiler` as an input. As we explained above, this enables these functions to generate constraints within the ZK proof system specified by the type `COM`. For example, when adding round constants the `add_const_assign` method will add a constraint to `compiler` that enforces the addition of a public constant to the secret witness. Similarly, `fn mds_matrix_multiply` generates constraints within `compiler` to enforce that `state` was multiplied by the MDS Matrix.
+Note that `fn full_round` and `fn partial_round` take the round number as an input; this is so that they will take the correct constants for the given round. Note that they also take the `compiler` as an input. As we explained above, this enables these functions to generate constraints within the ZK proof system specified by the type `COM`. For example, when adding round constants the `add_const_assign` method will add a constraint to `compiler` that enforces the addition of a public constant to the secret witness. Similarly, `fn mds_matrix_multiply` generates constraints within `compiler` to enforce that `state` was multiplied by the MDS Matrix.
 
 Again, when no `COM` type is specified the default `COM = ()` simply performs native computation without any constraint generation. The advantage of ECLAIR's `COM` abstraction is the certainty that `add_const_assign` or `mds_matrix_multiply` always conform to the same definition whether they are being used in native or non-native computation. 
 
@@ -278,4 +278,4 @@ where
     }
 }
 ```
-This function simply performs as many partial and full rounds as specified in the `Constants` trait.
+This function simply performs as many partial and full rounds as specified in the `Constants` trait.

docs/openzl/proposal.md

@@ -4,7 +4,7 @@
 
 ## Overview
 
-OpenZL is an open-source library that helps practioners (especially in Web3 space) to develop and deploy secure, high performance zero-knowledge proof code in production. It tries to bridge the gap between low level cryptographic primitives and devlopers' need to build scalable protocols using zero-knowlege proof cryptography securely and quickly. More specifically, many developers today want to leverage zero-knowledge proof systems to build powerful protocols like ZCash/Manta/ZKSync. However, they are facing two less than ideal choices; first, building a protocol using high-level languages like [Circom](https://docs.circom.io) or [Cairo](https://www.cairo-lang.org) loses many performance optimization opportunities, and second, building the protocol directly using libraries like [`arkworks/groth16`](https://github.com/arkworks-rs/groth16), [`zk-garage/plonk`](https://github.com/zk-garage/plonk), or [`microsoft/nova`](https://github.com/microsoft/Nova) requires expertise in cryptography and can be very error-prone. Also, zero-knowledge proof systems are a moving target. There have been many new, and "better", proof systems coming out every 2-3 years ([BCTV](https://eprint.iacr.org/2013/879.pdf) -> [Groth16](https://eprint.iacr.org/2016/260.pdf) -> [Plonk](https://eprint.iacr.org/2019/953) -> [Nova](https://eprint.iacr.org/2021/370)). OpenZL tries to solve this problem by building flexible, proof-system agnostic, and extensible libraries for Web3 practitioners.  
+OpenZL is an open-source library that helps practitioners (especially in Web3 space) to develop and deploy secure, high performance zero-knowledge proof code in production. It tries to bridge the gap between low level cryptographic primitives and developers' need to build scalable protocols using zero-knowlege proof cryptography securely and quickly. More specifically, many developers today want to leverage zero-knowledge proof systems to build powerful protocols like ZCash/Manta/ZKSync. However, they are facing two less than ideal choices; first, building a protocol using high-level languages like [Circom](https://docs.circom.io) or [Cairo](https://www.cairo-lang.org) loses many performance optimization opportunities, and second, building the protocol directly using libraries like [`arkworks/groth16`](https://github.com/arkworks-rs/groth16), [`zk-garage/plonk`](https://github.com/zk-garage/plonk), or [`microsoft/nova`](https://github.com/microsoft/Nova) requires expertise in cryptography and can be very error-prone. Also, zero-knowledge proof systems are a moving target. There have been many new, and "better", proof systems coming out every 2-3 years ([BCTV](https://eprint.iacr.org/2013/879.pdf) -> [Groth16](https://eprint.iacr.org/2016/260.pdf) -> [Plonk](https://eprint.iacr.org/2019/953) -> [Nova](https://eprint.iacr.org/2021/370)). OpenZL tries to solve this problem by building flexible, proof-system agnostic, and extensible libraries for Web3 practitioners.  
 
 OpenZL consists of 3 parts:
 * *Gadget libraries*: a library of gadgets that developers can use as building blocks for their protocols. The initial range of the gadgets includes accumulators (merkle tree with zero-knowledge membership proof), zk-friendly hash functions (poseidon hash), and commitment schemes. The gadget libraries are programmed in `eclair`.
@@ -31,7 +31,7 @@ OpenZL consists of 3 parts:
 
 ### Gadget Library
 
-OpenZL provides list of cryptographic primitives with *optimized* zero-knowledge proof implementations in `eclair`. 
+OpenZL provides a list of cryptographic primitives with *optimized* zero-knowledge proof implementations in `eclair`. 
 These gadgets are composable and can be combined to build more powerful protocols such as anonymous payment (ZCash/Manta) or zk-rollups. The gadget library that OpenZL provides on its initial release includes:
 * *hashing gadget*: an optimized implementation of the Poseidon Hash Function [1], with parameterized arity (2, 4, 8)
 * *accumulator gadget*: Merkle tree gadget that supports zero-knowlegde membership proofs. The Merkle tree gadget supports incremental updates as well.
@@ -41,8 +41,8 @@ These gadgets are composable and can be combined to build more powerful protocol
 
 Embedded Circuit Language And Intermediate Representation (`eclair`) is a shallow embedded DSL within Rust that serves the circuit description language in the OpenZL stack. It has the following design considerations:
 * *Proof system agnostic*: `eclair` is an IR that describes the circuit logic instead of lower-level proof-systems-specific semantics and optimizations.
-* *Unifying native and constraint code*: Writing zero-knowledge proof code in common framework like `arkworks`, it requires programmers to write the same logic twice -- one for constraints generation, one for native execution. This creates a huge burden on developers and is also error-prone. `eclair` solves this problem elegantly (see later an example) by introducing the concept of a "compiler". Developers only need to write the circuit logic in `eclair` once, and it compiles to both native code and constraints. Developers not only write circuit logic once, they also don't have to worry about the disparity between the native code and the constraint generating code (which could certainly be an existing bug in current applications). In addition, `eclair` automatically generates sanity check code for both native execution and constraints generation.
-* *ruling out common errors*: At *compile time*, `eclair` checks that private witnesses stay private and the public inputs stay public. For example, if a circuit implementer that is not using `eclair` misuses private witness allocation, this could cause a leakage of sercret key in the protocol implementation.   
+* *Unifying native and constraint code*: Writing zero-knowledge proof code in a common framework like `arkworks`, it requires programmers to write the same logic twice -- one for constraints generation, one for native execution. This creates a huge burden on developers and is also error-prone. `eclair` solves this problem elegantly (see later an example) by introducing the concept of a "compiler". Developers only need to write the circuit logic in `eclair` once, and it compiles to both native code and constraints. Developers not only write circuit logic once, they also don't have to worry about the disparity between the native code and the constraint generating code (which could certainly be an existing bug in current applications). In addition, `eclair` automatically generates sanity check code for both native execution and constraints generation.
+* *ruling out common errors*: At *compile time*, `eclair` checks that private witnesses stay private and the public inputs stay public. For example, if a circuit implementer that is not using `eclair` misuses private witness allocation, this could cause a leakage of secret key in the protocol implementation.   
 
 Below is an example of a sub-circuit defined in `eclair` (this is Manta testnet V2 code in [manta-rs](https://github.com/Manta-Network/manta-rs)):
 ```rust
@@ -103,7 +103,7 @@ One observation here is that the code passed in `compiler` as an argument. When
 
 ### Adaptors to Proof Systems
 
-OpenZL implements adaptors to different constraint systems used in different underlying proof systems. The current supported underlying constaint systems include:
+OpenZL implements adaptors to different constraint systems used in different underlying proof systems. The currently supported underlying constraint systems include:
 * R1CS in [`arkworks/groth16`](https://github.com/arkworks-rs/groth16) (support level: production)
 * Plonk constraints in [`zk-garage/plonk`](https://github.com/zk-garage/plonk) (support level: experimental)
 * Relaxed R1CS in [`microsoft/nova`](https://github.com/microsoft/Nova) (support level: experimental)
@@ -155,22 +155,22 @@ We will provide `substrate`-specific tutorials to show case how to code an end-t
 | CI/CD      |  5,000  |  CI/CD for OpenZL |
 | Misc.   | 500 | DNS, Website Hosting, etc |
 
-Totol budget: 1,010,500 USD (will be converted to DOT using the exchange rate on application)
+Total budget: 1,010,500 USD (will be converted to DOT using the exchange rate on application)
 
 ## OpenZL team
 
 ### Oversight Committee
 
-Oversight commitee will manage the overall execution and the financial budget of OpenZL:
+Oversight committee will manage the overall execution and the financial budget of OpenZL:
 * **Shumo Chu** (Co-founder, Manta Network)
 * **Luke Pearson** (Research Partner, Polychain Capital)
 * **Bryan Chen** (CTO, Acala Network)
 
-Funding and spendings will be managed in a 2/3 multisig.
+Funding and spending will be managed in a 2/3 multisig.
 
 ### Development Team (Alphabetical)
 
-* **Boyuan Feng**: Cryptogrpahic Engineer at Manta, PhD Computer Science from UCSB, extensive zero-knowledge proof compiler experiences (e.g. first author of [ZEN](https://eprint.iacr.org/2021/087)).
+* **Boyuan Feng**: Cryptographic Engineer at Manta, PhD Computer Science from UCSB, extensive zero-knowledge proof compiler experiences (e.g. first author of [ZEN](https://eprint.iacr.org/2021/087)).
 * **Brandon H. Gomes**: Cryptographic Engineer at Manta, BS Math from Rutgers, main author of [manta-rs](https://github.com/Manta-Network/manta-rs).
 * **Todd Norton**: Cryptographic Engineer at Manta, PhD Physics from Caltech.
 * **Tom Shen**: Cryptographic Engineer at Manta, BS Computer Science from UC Berkeley, [arkworks](https://github.com/arkworks-rs) core contributor. 

docs/performance/zkp-performance.md

@@ -8,8 +8,8 @@
 | Exchange | 11                      | 110           |
 | Reclaim  | 8.3                     | 89            | 
 
-Note: All verifier time are obtained from `frame-benchmark`. 
-The WASM time is substrate flavored WASM time using compiled setting. 
+Note: All verifier times are obtained from `frame-benchmark`. 
+The WASM time is substrate flavored WASM time using a compiled setting. 
 
 ## Prover Time
 

docs/zkShuffle/Circuits/01-ContractInterface.md

@@ -6,7 +6,7 @@ description: 'zkShuffle Contract desc'
 
 # Overview
 
-zkShuffle Contracts provide two contract interfaces to help developers build their own card games:
+zkShuffle Contracts provides two contract interfaces to help developers build their own card games:
 - [IShuffleStateManager](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/IShuffleStateManager.sol): The manager of shuffle state machine, which creates and registers shuffle state, deals and opens cards.
 - [IBaseGame](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/IBaseGame.sol): Developers need to inherit this interface when writing their own game contracts.
 
@@ -56,13 +56,13 @@ Enters the register state, which can only be called by the game owner.
 
 > **Note:** The ```gameId``` parameter in all the interfaces corresponds to the return value of the ```createShuffleGame``` function.
 
-> **Note:** ```register``` only initiate the registration phase so that players can register, it doesn't actually perform the registration.
+> **Note:** ```register``` only initiates the registration phase so that players can register, it doesn't actually perform the registration.
 
 ### playerRegister
 
 ```function playerRegister(uint256 gameId, address signingAddr, uint256 pkX, uint256 pkY) external returns (uint256)```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/ShuffleManager.sol#L228-L233)
 
-Performs the registration for a certain player, which can be called by game contract or directly called by user.
+Performs the registration for a certain player, which can be called by game contract or directly called by the user.
 
 **Parameters:**
 - ```gameId```: The created shuffle game ID.
@@ -119,13 +119,13 @@ Initiates the shuffle phase, which can only be called by game contract.
 - ```gameId```: The created shuffle game ID.
 - ```next```: The calldata that will be executed in the next invocation.
 
-> **Note:** ```shuffle``` only initiate the shuffle phase so that players can shuffle, it doesn't actually perform the shuffle.
+> **Note:** ```shuffle``` only initiates the shuffle phase so that players can shuffle, it doesn't actually perform the shuffle.
 
 ### dealCardsTo
 
 ```function shuffle(uint256 gameId, BitMaps.BitMap256 memory cards, uint256 playerId, bytes calldata next) external```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/ShuffleManager.sol#L332-L337)
 
-Specifies a set of cards to be dealed to a players, which can only be called by game contract.
+Specifies a set of cards to be dealt to a player, which can only be called by game contract.
 
 **Parameters:**
 - ```gameId```: The created shuffle game ID.
@@ -254,7 +254,7 @@ Gets the decryption record (i.e., which players have decrypted this card).
 
 ```function queryAggregatedPk(uint256 gameId) external returns(uint px, uint py)```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/ShuffleManager.sol#L96-L98)
 
-Queries the aggregated public key for card shuffling/dealing in `gameId`-th game. The public key is a elliptic curve point on BN254 G1 curve.
+Queries the aggregated public key for card shuffling/dealing in `gameId`-th game. The public key is an elliptic curve point on BN254 G1 curve.
 
 **Parameters:**
 - ```gameId```: The created shuffle game ID.
@@ -279,4 +279,4 @@ contract Game is IBaseGame {
     }
     ...
 }
-```
+```