docs: cleanup(fix typo) documents

README.md

@@ -2,20 +2,20 @@
 
 This repo contains documentation about the ZKWASM and can be seen live at: [See the book live](https://zkwasmdoc.gitbook.io/delphinus-zkwasm/).
 
-The mission of DelphiusLab is to provide Web2 developers with a concise toolset to leverage the power of Web3 in their applications. The ZKWASM (ZKSNARK virtual machine that supports Web Assembly) serves as a trustless layer between rich applilcations running on WASM runtime and smart contracts on chain.
+The mission of DelphiusLab is to provide Web2 developers with a concise toolset to leverage the power of Web3 in their applications. The ZKWASM (ZKSNARK virtual machine that supports Web Assembly) serves as a trustless layer between rich applications running on WASM runtime and smart contracts on chain.
 
 WASM (or WebAssembly) is an open standard binary code format similar to assembly. Its initial objective was to provide an alternative to java-script with improved performance for the current web ecosystem. Benefiting from its platform independence, front-end flexibility (can be compiled from the majority of languages including C, C++, assembly script, rust, etc.), good isolated runtime and speed comes closer to the speed of a native binary, its usage is arising in distributed cloud and edge computing. Recently it has become a popular binary format for users to run customized functions on AWS Lambda, Open Yurt, AZURE, etc.
 
 The idea of ZKWASM is derived from ZKSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) which is a combination of SNARG (Succinct non-interactive arguments) and zero-knowledge proof. In general, the adoption of ZKSNARK usually requires implementing a program in arithmetic circuits or circuit-friendly languages (Pinocchio, TinyRAM, Buffet/Pequin, Geppetto, xJsnark framework, ZoKrates) that forms a barrier for existing programs to leverage it's power. An alternative approach is, instead of applying ZKSNARK on the source code, applying it on the bytecode level of a virtual machine and implementing a zksnark-backed virtual machine. In this work, we take the approach of writing the whole WASM virtual machine in ZKSNARK circuits so that existing WASM applications can benefit from ZKSNARK by simply running on the ZKWASM, without any modification. Therefore, the cloud service provider can prove to any user that the computation result is computed honestly and no private information is leaked.
 
 Docs include tutorials for the following audiences
 
-1. beginners to get familiar with developping WASM based applications that runs in ZKWASM virtual machine and specifications for zkWASM host circuits.
-2. sophisicated rollup application builders that would like to leverage the ability fo ZKWASM for their own application rollup.
-3. circuit integrators that would like to use WASM as a glue languague to connect different ZKP circuits for more customizable scenarios (eg. ML, ORACL, VRF, etc)
+1. beginners to get familiar with developing WASM based applications that runs in ZKWASM virtual machine and specifications for zkWASM host circuits.
+2. sophisticated rollup application builders that would like to leverage the ability of ZKWASM for their own application rollup.
+3. circuit integrators that would like to use WASM as a glue language to connect different ZKP circuits for more customizable scenarios (eg. ML, ORACL, VRF, etc)
 4. ZKVM builders that would like to use a core minimal set of WASM bytecode to build their own ZK virtual machine.
 
-This document also provides the information regarding the ZKP circuit disign, proof batching and aggregation, proof structure of continuation execution, WASM host circuit integration and WASI support.
+This document also provides the information regarding the ZKP circuit design, proof batching and aggregation, proof structure of continuation execution, WASM host circuit integration and WASI support.
 
 
 **This book is a WIP and being constantly updated.**

c1_beginner/c1_quickstart/c2_prepare.md

@@ -106,7 +106,7 @@ pub fn zkmain() -> {
 }
 ```
 
-Simlarly the Makefile used to generate WASM from RUST is the following:
+Similarly the Makefile used to generate WASM from RUST is the following:
 ```
 build:
 	wasm-pack build --release --out-name rust-sdk-test.wasm --out-dir pkg --features wasmbind

c1_beginner/c1_quickstart/c3_setup.md

@@ -1,6 +1,6 @@
 # Setup ZKWASM circuit
 
-With the wasm bytecode beinging generated, we can start setup the circuit of the VM. In the Setup Phase an application as a wasm image is used as input to zkWasm to generate a zkSNARK circuit for the application. The setup phase generates the output vkey.data for the image which is a circuit that commits its constant column.
+With the wasm bytecode being generated, we can start setup the circuit of the VM. In the Setup Phase an application as a wasm image is used as input to zkWasm to generate a zkSNARK circuit for the application. The setup phase generates the output vkey.data for the image which is a circuit that commits its constant column.
 
 There are two modes to setup ZKWASM, the uniform-circuit mode and the image specific mode.
 
@@ -49,7 +49,7 @@ This produces the output files in `./params/`
 As the default mode is more friendly for beginers that might only focus on a particular application, the following content will assume the default mode is enabled. (However all examples should also works in uniform-mode).
 
 ## The continuation mode
-When you are running a wasm image with unbounded execution trace, you need to use the continuation mode of zkWasm which will splits the excution trace into slices and generate proofs for each slice.
+When you are running a wasm image with unbounded execution trace, you need to use the continuation mode of zkWasm which will splits the execution trace into slices and generate proofs for each slice.
 ```
 cargo run --release --features continuation --params ./params testwasm setup
 ```

c1_beginner/c1_quickstart/c4_prove.md

@@ -1,6 +1,6 @@
 # Prove WASM execution
 
-## Proof Generation of a signle execution
+## Proof Generation of a single execution
 
 In the Proof Phase the web assembly interpreter (wasmi) outputs two traces; the web assembly bytecode as the execution trace & the host API call trace. These record the order of the host API calls and their output. The combination of the two traces ensures the host call trace is in the same order as the execution trace (including the same input arguments).<br>
 
@@ -12,7 +12,7 @@ $ZKWASMBIN/zkwasm-cli --params ./params testwasm prove --output ./output --wasm
 
 In the above command `--host` specifies the host api set we would like to use. Since our application does not relies on any special WASI functions, and `--params` tells the prover refer to `/params` folder for all circuit specific data. The `--output` argument specify the output folder for proof results (together with some intermediate files).
 
-After executing the commnad, it should produce the following files in the output directory `--output ./output`.
+After executing the command, it should produce the following files in the output directory `--output ./output`.
 
 ```
 .
@@ -59,7 +59,7 @@ The process of proof generation requires reading the vkey which is implied by th
 
 ## Proof Verification:
 
-The verification of a proof generated by zkWasm is done using the `verify` command line arguement. In the below bash script which is execuated from within `output_simple_program` a single verification run can be done by:
+The verification of a proof generated by zkWasm is done using the `verify` command line argument. In the below bash script which is executed from within `output_simple_program` a single verification run can be done by:
 
 ```
 $ZKWASMBIN/zkwasm-cli --params ./params testwasm verify --output ./output

c1_beginner/c2_builtin/README.md

@@ -14,8 +14,8 @@ Here are some key points about WASM host functions:
 
 In summary, WASM host functions are a crucial part of the WebAssembly ecosystem, enabling WASM modules to interact with their environment in a controlled and secure manner, thus extending the capabilities of WebAssembly beyond its sandboxed context.
 
-In the ZKWASM, we provide a wide range of pre-defined host functions to ease the burden of building solphiscated applications. We devides them into three major categores
+In the ZKWASM, we provide a wide range of pre-defined host functions to ease the burden of building sophisticated applications. We divides them into three major categories
 
 1. IO related host functions
 2. Constraint related host functions.
-3. Predefined host functiosn with external circuits support.
+3. Predefined host functions with external circuits support.

c1_beginner/c2_builtin/io.md

@@ -1,7 +1,7 @@
 # IO Functions
 
 ## Fetch External Inputs
-Since a ZKP circuits distinguish between public inputs(instances) and private inputs(witness), ZKWASM supports two different way to fetch inputs from the user, **zkwasm_input(1)** reads an public instance from the user and **zkwasm_input(0)** reads a private input(witness).
+Since a ZKP circuit distinguishes between public inputs(instances) and private inputs(witness), ZKWASM supports two different ways to fetch inputs from the user, **zkwasm_input(1)** reads a public instance from the user and **zkwasm_input(0)** reads a private input(witness).
 
 ```
 extern "C" {
@@ -22,7 +22,7 @@ fn get_inputs() -> [u64; 3] {
 ```
 
 ## Witness Queue.
-The ZKWASM run time supports multiple queue. When the ZKWASM runs an image, the input witness queues is initialzed by a sequence of u64 specified by the ZKWASM running API (See command line args --private). Once this queue is specified, we can not change it and all the witness can be fetched from the beginning (start from index 0) by **zkwasm_input(0)** one by one.
+The ZKWASM run time supports multiple queue. When the ZKWASM runs an image, the input witness queues is initialized by a sequence of u64 specified by the ZKWASM running API (See command line args --private). Once this queue is specified, we can not change it and all the witness can be fetched from the beginning (start from index 0) by **zkwasm_input(0)** one by one.
 
 Suppose that a list of witness inputs are specified via --private input1:i64 input2:i64 input3:i64 ..., then the following code should return an array of [input1, input2, input3]
 

c2_advance/README.md

@@ -1,9 +1,9 @@
 # Build a Rollup Application
 
-This document is suppose to be a complete reference for ZKWASM users that would like to make their own rollup application. Following topics will be covered:
+This document is supposed to be a complete reference for ZKWASM users that would like to make their own rollup application. Following topics will be covered:
 
 1. The architecture of a reference implementation of ZKWASM rollup application.
 2. The proof generation architecture.
 3. Customize and define your ZKWASM by extending host APIs.
 4. Customize your proof generation via proof batching scripts.
-3. Define settlement protocol and deploy your rollup verifier.
+5. Define settlement protocol and deploy your rollup verifier.

c2_advance/c1_circuit/README.md

@@ -1,15 +1,15 @@
 # ZKWASM Circuits 
 
-A ZK Circuit in abstract is a matrix that each column represents a function $$f_i(w_j)$$ where $$j=1,2,3 \cdots$$ and a set of constraints $$C$$. A constraint in $$C$$ can be describe as a function equation $$H(f_i(w * g^j) = 0$$. Given an arbitrary instance of matrix, if all cloumn of the matrix satisfies the constraints $$C$$ then it is a valid instanation of the given circuit.
+A ZK Circuit in abstract is a matrix that each column represents a function $$f_i(w_j)$$ where $$j=1,2,3 \cdots$$ and a set of constraints $$C$$. A constraint in $$C$$ can be described as a function equation $$H(f_i(w * g^j) = 0$$. Given an arbitrary instance of matrix, if all column of the matrix satisfies the constraints $$C$$ then it is a valid instantiation of the given circuit.
 
-Futhermore, given a matrix, we have 3 different type of columns.
+Furthermore, given a matrix, we have 3 different types of columns.
 
 1. Advice columns. Value of advice columns can vary among different valid instantiations.
-2. Fix columns. Value of fix columns must keep the same between different valid instantiations and the value of each fixed columns are provided at steup stage of the circuit.
+2. Fix columns. Value of fix columns must keep the same between different valid instantiations and the value of each fixed columns are provided at setup stage of the circuit.
 3. Instance columns. Value of instance columns usually decides the other value of the matrix and is used as the input of the verifier. We call the process of deducing other values in the matrix via the instance column to be the synthesize process. 
 
 ## Circuit Setup
-Circuit Setup contains two phases. One is to compute the the values of all fixed columns and the other is to compute the values of all implicit columns derived from lookups and permutations. Once the circuit was setup, the commitment of each pre-calculated columns are stored into a vkey file and the other information of the circuit is stored in to a circuit data file which uniquely defines the circuit.
+Circuit Setup contains two phases. One is to compute the values of all fixed columns and the other is to compute the values of all implicit columns derived from lookups and permutations. Once the circuit was setup, the commitment of each pre-calculated columns are stored into a vkey file and the other information of the circuit is stored into a circuit data file which uniquely defines the circuit.
 
 ## Circuit Synthesize
 The synthesize process calculates all the witness of the circuit matrix based on the provided value of instance columns. Once a circuit instance has been synthesized, we can start proof generation of this instantiation.
@@ -18,7 +18,7 @@ The synthesize process calculates all the witness of the circuit matrix based on
 Proof is generated after the syntehsize stage via PCS(polynomial commitment scheme). In short, the proof contains the commit of constraint polynomials $$C(x)$$, the commitment of the vanish polynomial V(x) and the quotient polynomial $$h(x)$$. All these info are stored in a file called `proof transcript` (usually has file name `XXX.transcript.data`).
 
 ## Verify proof
-The proof verification algorithm is simply open all the commintment of PCS to check that the polynomial constraints holds.
+The proof verification algorithm is simply open all the commitment of PCS to check that the polynomial constraints holds.
 
 ## Circuits involved in ZKWASM
 In ZKWASM, there are three different categories of circuits.

c2_advance/c3_proofgen/README.md

@@ -1,13 +1,13 @@
-# Proof Generation Architectrue
-When executing a WASM image, its generated trace can be very long (serveral billion instructions) while the ZKWASM guest circuits has a limit on how many instructions it can proof in a single execution segment. Thus we need a scheme to split the huge execution into small pieces and generate the proof of them separately. After that we need to add extra connecting proofs to connect those separated proofs and then batch them together to generate a single proof for the whole execution.
+# Proof Generation Architecture
+When executing a WASM image, its generated trace can be very long (several billion instructions) while the ZKWASM guest circuits has a limit on how many instructions it can proof in a single execution segment. Thus we need a scheme to split the huge execution into small pieces and generate the proof of them separately. After that we need to add extra connecting proofs to connect those separated proofs and then batch them together to generate a single proof for the whole execution.
 
-In ZKWASM we assume an applicatin is just like a standard desktop application that have a lifecycle of open, run and close. We say a single lifecycle from open to close is a bundle of execution while within that bundle there is a huge execution trace that contains billions of instructions. Further more, we split the execution of a bundle into many small execution segments.
+In ZKWASM we assume an application is just like a standard desktop application that have a lifecycle of open, run and close. We say a single lifecycle from open to close is a bundle of execution while within that bundle there is a huge execution trace that contains billions of instructions. Furthermore, we split the execution of a bundle into many small execution segments.
 
 The overall proof generation architecture is divided into three stages depends on the application executing style.
 
 1. Segment proof: guest and host circuit proof of a single execution segment.
 2. Continuation proof: connecting the segment proof and batch them into a single bundle execution proof.
-3. Bundle proof batching: combine the continuation proof of each bundle and generate a single proofs (This is usually for a application rollup which needs to submit the state differerent to a Blockchain with a execution proofs).
+3. Bundle proof batching: combine the continuation proof of each bundle and generate a single proofs (This is usually for an application rollup which needs to submit the state different to a Blockchain with a execution proofs).
 
 
 <p align="center">