Manta-Network · tudorpintea999 · Dec 2, 2023 · Dec 2, 2023 · Dec 2, 2023 · Dec 2, 2023
diff --git a/docs/concepts/Celestia.md b/docs/concepts/Celestia.md
@@ -1,6 +1,6 @@
 # Celestia
 
-Leveraging Celestia‘s [data availability (DA)](https://blockworks.co/news/data-availability-ethereum), Manta Pacific delivers a blazing-fast infrastructure at a fraction of the cost of monolothic L2s. Celestia employs cutting-edge data availability sampling techniques—two-dimensional Reed-Solomon coding and Namespaced Merkle Trees (NMTs)—to address L2 data availability concerns in a trust-minimized manner. By using Celestia as the DA (Data Availability) layer, Manta Pacific can significantly reduce transaction costs for users.
+Leveraging Celestia‘s [data availability (DA)](https://blockworks.co/news/data-availability-ethereum), Manta Pacific delivers a blazing-fast infrastructure at a fraction of the cost of monolithic L2s. Celestia employs cutting-edge data availability sampling techniques—two-dimensional Reed-Solomon coding and Namespaced Merkle Trees (NMTs)—to address L2 data availability concerns in a trust-minimized manner. By using Celestia as the DA (Data Availability) layer, Manta Pacific can significantly reduce transaction costs for users.
 
 ## What is Celestia?
 

diff --git a/docs/concepts/Roadmap.md b/docs/concepts/Roadmap.md
@@ -16,7 +16,7 @@ In its current availability, Manta Pacific is an Optimistic Rollup on Ethereum u
 
 On Manta Pacific, developers reap the benefits from Manta’s Universal Circuits and OP Stack’s low gas fee and scalability to build unique ZK-enabled dApps, which is unprecedented in existing Layer 2s. In particular, Manta Pacific provides Universal Circuits for popular use cases (e.g., [card shuffling/dealing](https://github.com/Manta-Network/zkShuffle) and private on-chain voting), solidity smart contracts for on-chain ZK logic, and a typescript SDK for front-end integration.
 
-Based on Manta’s Universal Circuits, developers without a ZK background can easily develop dApps with built-in ZK features from Manta Pacific such that they do not need to spend years of engineer efforts on customizing ZK circuits. Significantly different from Starkware and Aztec which re-design domain-specific language (DSL) for ZK such as Cario and Noir, Manta Pacific achieves EVM equivalence through adopting OP Stack Bedrock’s codebase. Thus, all existing smart contracts on Ethereum can be seamlessly adopted to Manta Pacific while enabling ZK-based features to unveil new application scenarios such as [verifiable private DID/KYC](https://www.binance.com/en/feed/post/458948), ZK-based fully-onchain games, and synergy between DeFi and decentralized private identity including zkSBT-based whitelist and off-ramp.
+Based on Manta’s Universal Circuits, developers without a ZK background can easily develop dApps with built-in ZK features from Manta Pacific such that they do not need to spend years of engineering efforts on customizing ZK circuits. Significantly different from Starkware and Aztec which re-design domain-specific language (DSL) for ZK such as Cario and Noir, Manta Pacific achieves EVM equivalence through adopting OP Stack Bedrock’s codebase. Thus, all existing smart contracts on Ethereum can be seamlessly adopted to Manta Pacific while enabling ZK-based features to unveil new application scenarios such as [verifiable private DID/KYC](https://www.binance.com/en/feed/post/458948), ZK-based fully-onchain games, and synergy between DeFi and decentralized private identity including zkSBT-based whitelist and off-ramp.
 
 ## **Chapter 2: Manta Pacific Alpha II (+Celestia DA)**
 

diff --git a/docs/concepts/TrustedSetup.md b/docs/concepts/TrustedSetup.md
@@ -37,7 +37,7 @@ In this way the MPC forms a chain of participants who each contribute their own
 
 > It's worth emphasizing: *if at least one single participant in the ceremony is honest then the resulting keys are secure.*
 
-This is where the term "trusted setup ceremony" comes from. *Setup* because it generates necessary infrastructure (prover/verifier keys) for ZKPs. *Ceremony* because it requires many participants to coordinate with each other to carry out the MPC. *Trusted* because the design of this MPC allows us to trust its output as long as we believe that at least one honest person participated.
+This is where the term "trusted setup ceremony" comes from. *Setup* because it generates the necessary infrastructure (prover/verifier keys) for ZKPs. *Ceremony* because it requires many participants to coordinate with each other to carry out the MPC. *Trusted* because the design of this MPC allows us to trust its output as long as we believe that at least one honest person participated.
 
 ## What attacks are possible?
 
@@ -79,4 +79,4 @@ Each Phase 2 ceremony must begin with the output of a Phase 1 ceremony. In our c
 
 Manta Network successfully held the Trusted Setup ceremony in 2022. Ending officially on December 29th, we saw over 13,000 registrations and 4,328 contributions from 177 countries; Manta Network has broken the world record for having [the largest trusted setup in history](https://mantanetwork.medium.com/the-record-breaking-conclusion-of-the-trusted-setup-441382e675d3).
 
-This means that it is unfortunately too late to contribute, but you can nevertheless [verify the results of the ceremony](https://github.com/Manta-Network/manta-rs/blob/main/manta-trusted-setup/README.md).
+This means that it is unfortunately too late to contribute, but you can nevertheless [verify the results of the ceremony](https://github.com/Manta-Network/manta-rs/blob/main/manta-trusted-setup/README.md).
diff --git a/docs/concepts/ZKP.md b/docs/concepts/ZKP.md
@@ -4,7 +4,7 @@
 
 The concept of Zero-Knowledge Proofs (ZKPs) was first invented by Shafi Goldwasser, Silvio Micali and Charles Rackoff in their seminal paper, [*The Knowledge Complexity of Interactive-Proof Systems*](https://dl.acm.org/doi/pdf/10.1145/22145.22178) in the 1980s.
 
- Despite being considered as a theoretical breakthrough, even the cryptography community labeled the scheme as impossible in practice when the idea was born. Thanks to many breakthroughs made in the recent years, especially the contribution made by many web3 projects like ZCash and Aztec, we have seen a Moore’s Law style improvement on the performance of zero-knowledge proof systems.
+ Despite being considered as a theoretical breakthrough, even the cryptography community labeled the scheme as impossible in practice when the idea was born. Thanks to many breakthroughs made in recent years, especially the contribution made by many web3 projects like ZCash and Aztec, we have seen a Moore’s Law style improvement on the performance of zero-knowledge proof systems.
 
 ## What is a Zero-Knowledge Proof System?
 A zero-knowledge proof system is a protocol by which someone (the prover) can prove the correctness of a statement to someone else (the verifier) without disclosing any additional information. It consists of the following elements and satisfies the following properties.
@@ -43,12 +43,12 @@ Let us check that the above protocol satisfies the desired properties:
 2. Soundness: A dishonest prover might try to trick the verifier by sending a $y$ in step 1 which is not a square. In that case the verifier would reject the proof in half the cases, when they choose $b = 0$. If $y$ is a square but $x$ is not, the verifier would reject the proof when $b = 1$. A dishonest prover has a $1/2$ probability to trick the protocol on each iteration, so this probability can be made negligible by iterating enough times.
 3. Zero-knowledge: If $b = 0$, the prover does not use $w$ at any point in the proof, it cannot be leaked. If $b=1$, the only place where the prover uses $w$ is in $\pi = w a$, from which the verifier cannot extract $w$ without the knowledge of $a$. As long as the prover does not repeat the above protocol with the same $a$ for different $b$'s, the protocol remains zero-knowledge.
 
-## Succint Non-Interactive Arguments of Knowledge (SNARKs)
+## Succinct Non-Interactive Arguments of Knowledge (SNARKs)
 A particularly important type of ZKP systems are SNARKs. They are zero-knowledge proof systems which satisfy the following extra properties:
 
 * **Argument of knowledge**: The prover wants to prove knowledge of the witness itself. In the example above, the statement would be "*I know a square root of $2$ in $\mathbb{F}_7$*". One can show the protocol above also proves this stronger statement, thus making it an argument of knowledge.
 
-* **Succinctness**: The proof size is constant or logarithmic compared with the circuit size (i.e. the amount of computations) of the statement. The protocol above is also succint, since the proof is just a number in $\mathbb{F}_7$.
+* **Succinctness**: The proof size is constant or logarithmic compared with the circuit size (i.e. the amount of computations) of the statement. The protocol above is also succinct, since the proof is just a number in $\mathbb{F}_7$.
 
 * **Non-Interactive**: Proof generation and proof verification happen in two consecutive rounds: first the prover runs a function $\textsf{prove}$ to generate a proof and then the verifier runs a function $\textsf{verify}$ to verify it. The protocol above is interactive, i.e., it does not satisfy this property because of the continuous communication between prover and verifier.
 

diff --git a/docs/guides/TrustedSetup.md b/docs/guides/TrustedSetup.md
@@ -77,7 +77,7 @@ For Powershell modify this to
 ./manta-trusted-setup-x86_64-pc-windows-msvc register
 ```
 
-That's all, you have installed the client and can move to the the next step: Registration.
+That's all, you have installed the client and can move to the next step: Registration.
 
 ### Source Code Installation
 If you prefer to build the client yourself from source code, follow the instructions [here](https://github.com/Manta-Network/manta-rs/tree/main/manta-trusted-setup).
@@ -91,7 +91,7 @@ manta-trusted-setup register
 ```
 (or the appropriate variant if you used the Windows or alternative Linux installation above).
 
-You will be asked for an email address and twitter account.  After providing them you will see output that looks something like this:
+You will be asked for an email address and twitter account.  After providing them you will see an output that looks something like this:
 ![registration prompt](./resources/ts_guide_register.png)
 
 
@@ -135,4 +135,4 @@ Once the server has verified your contribution you will receive a confirmation m
 ## Announcement
 Please finish your contribution by tweeting the message we provided (or posting to other public forums). While this step is not strictly necessary, it improves the security of the ceremony by creating a public record of your contribution.
 
-Thank you for your participation!
+Thank you for your participation!
diff --git a/docs/learn/Spec.md b/docs/learn/Spec.md
@@ -1,5 +1,5 @@
 # Core Protocol Specification
 
-MantaPay protocol defines a flexible private asset protocol that supports fungible tokens, non-fungible tokens (NFTs), and soul bound tokens (SBTs). MantaPay allows users to use a permenant address (`zkAddress`) to hold, transfer, and convert to public verious blockchain asset with privacy built in (`zkAsset`).
+MantaPay protocol defines a flexible private asset protocol that supports fungible tokens, non-fungible tokens (NFTs), and soul bound tokens (SBTs). MantaPay allows users to use a permanent address (`zkAddress`) to hold, transfer, and convert to public various blockchain asset with privacy built in (`zkAsset`).
 
-Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)
+Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)
diff --git a/docs/learn/ZkpChallenge.md b/docs/learn/ZkpChallenge.md
@@ -61,15 +61,15 @@ We support two ways of submitting proof hashes:
    * put the hash to the remark field (need to add `0x`)
    * submit the extrinsic to Polkadot blockchain, remember the extrinsic id 
 
-2. Submit an transaction with data field in Ethereum
+2. Submit a transaction with data field in Ethereum
    * choose a wallet that support data field, for example, MyCrypto
    * send an ethereum transaction with the hash as the data field, for example, in MyCrypto, click advanced options 
      ![my crypto](./resources/my-crypto-1.png)
     and add the hash of the zero-knowledge-proof in the data field.
      ![my crypto data](./resources/my-crypto-2.png)
    * send the transaction on chain 
 
-Next, submit this [form](https://forms.gle/ZpGua9DUmwmYgiGdA) with your addess to receive the award and ZKP.
+Next, submit this [form](https://forms.gle/ZpGua9DUmwmYgiGdA) with your address to receive the award and ZKP.
 
 ## Got Questions?
 

diff --git a/docs/openzl/alloc.md b/docs/openzl/alloc.md
@@ -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.)
diff --git a/docs/openzl/proposal.md b/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`.
@@ -42,7 +42,7 @@ 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.   
+* *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

diff --git a/docs/zkShuffle/Circuits/01-ContractInterface.md b/docs/zkShuffle/Circuits/01-ContractInterface.md
@@ -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 {
     }
     ...
 }
-```
+```