From 77477e9ef048c9f2f4dbc9d00b9e23fc06a2454a Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:30:59 +0900
Subject: [PATCH 03/13] fix typos README.md
"bytecods" -> "bytecodes"
"native supported runtime" -> "natively supported runtime"
"Serveless" -> "Serverless"
"selveless" -> "serverless"
"applification" -> "application"
"verfy" -> "very"
"buildin" -> "builtin"
"differen" -> "different"
"easiler" -> "easier"
"adopts itself quick" -> "adopts itself quickly"
"morden" -> "modern"
"compatiability" -> "compatibility"
"Further more" -> "Furthermore"
"an glue" -> "a glue"
"board" -> "broad"
---
c5_miscqa/README.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/c5_miscqa/README.md b/c5_miscqa/README.md
index 0f68f43..491f7c6 100644
--- a/c5_miscqa/README.md
+++ b/c5_miscqa/README.md
@@ -1,15 +1,15 @@
# MISC Q&A
-## Why pick WASM as the native bytecods our ZKVM
+## Why pick WASM as the native bytecodes our ZKVM
-1. Wasm run time is native supported runtime in Browser and Serveless application. Given the support of WASM in zkWASM, web2 application runs in browser and selveless server can quickly establish a trustless rollup via Delphinus ZKWasm applification specific rollup as a service.
+1. Wasm run time is natively supported runtime in Browser and Serverless application. Given the support of WASM in zkWASM, web2 application runs in browser and serverless server can quickly establish a trustless rollup via Delphinus ZKWasm application specific rollup as a service.
2. Wasm is the major alternative to ethereum bytecode. Wasmi for substrate, Wasmtimer for Cosmos. Give a zkWASM virtual machine, we can potentially turn a substrate blockchain into a etheurem rollup. This give existing ecosystem (substrate) a way to be adopted into another ecosystem (Etheurem)
-3. Wasm has a verfy concise but flexible specification. The buildin host function give a way for application and rollup service a native way to extend the runtime. Delphinuslab application rollup service can provide specific wasm runtime (with differen host functions) to provide applicification service.
-4. Wasm support a broad range of generic languages including C, C++, rust, assembly script, typescript, etc. Thus libraries written in different languages can be linked together via wasm module system which means it is more easiler to build an ecosystem than single backend language.
-5. Wasm is a bytecode that has regular evolution managed by World Wide Web Consortium (W3C). It means that wasm adopts itself quick than stable bytecodes like evm to fits the need of morden web2 applications.
+3. Wasm has a very concise but flexible specification. The builtin host function give a way for application and rollup service a native way to extend the runtime. Delphinuslab application rollup service can provide specific wasm runtime (with different host functions) to provide applicification service.
+4. Wasm support a broad range of generic languages including C, C++, rust, assembly script, typescript, etc. Thus libraries written in different languages can be linked together via wasm module system which means it is more easier to build an ecosystem than single backend language.
+5. Wasm is a bytecode that has regular evolution managed by World Wide Web Consortium (W3C). It means that wasm adopts itself quickly than stable bytecodes like evm to fits the need of modern web2 applications.
## Why support unmodified WASM specification is important.
-Delphinus-ZKWASM follows and supports the unmodified standard WASM bytecode specification https://www.w3.org/TR/wasm-core-1/ which are supported as a standard backend target by most of the generic programming languages (C, C++, Rust, Go, Assembly Script, etc). By providing full compatiability, wasm generated from the existing compilers can be executed in zkWASM emulator without further adjustment. Further more, zkWASM also follows the definition of WASM host functions, which are functions expressed outside WebAssembly but passed to a module as an import.
+Delphinus-ZKWASM follows and supports the unmodified standard WASM bytecode specification https://www.w3.org/TR/wasm-core-1/ which are supported as a standard backend target by most of the generic programming languages (C, C++, Rust, Go, Assembly Script, etc). By providing full compatibility, wasm generated from the existing compilers can be executed in zkWASM emulator without further adjustment. Furthermore, zkWASM also follows the definition of WASM host functions, which are functions expressed outside WebAssembly but passed to a module as an import.
Supporting the unmodified WebAssembly (WASM) bytecode specification has several advantages, particularly in terms of compatibility, security, performance, and cross-platform functionality. Here's a closer look at why it's beneficial to adhere to the standard, unmodified WASM specification:
@@ -21,7 +21,7 @@ Supporting the unmodified WebAssembly (WASM) bytecode specification has several
4. Future-Proofing: The WASM specification is continuously evolving with contributions from a wide range of industry experts. By following the unmodified specification, developers can more easily adapt to future changes and enhancements in the WASM ecosystem.
-5. Interoperability: WASM is designed to have native host api support, meaning it can support customization which allowing developers to seamlessly integrate code(or zk circuit) from external ecosystem. Delphinus-ZKWASM fully support WASM's native host api extension features thus can be used as an glue language for a board range of application specific circuits.
+5. Interoperability: WASM is designed to have native host api support, meaning it can support customization which allowing developers to seamlessly integrate code(or zk circuit) from external ecosystem. Delphinus-ZKWASM fully support WASM's native host api extension features thus can be used as a glue language for a broad range of application specific circuits.
## Why not just use LLVM bitcode as a binary format?
The LLVM compiler infrastructure has a lot of attractive qualities: it has an existing intermediate representation (LLVM IR) and binary encoding format (bitcode). It has code generation backends targeting many architectures and is actively developed and maintained by a large community. In fact PNaCl already uses LLVM as a basis for its binary format. However, the goals and requirements that LLVM was designed to meet are subtly mismatched with those of WebAssembly.
From 9fc8db7fc486338db24c7aaf79a2cb7863c4707f Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:31:58 +0900
Subject: [PATCH 04/13] Update README.md
"suppose" -> "supposed"
---
c2_advance/README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/c2_advance/README.md b/c2_advance/README.md
index e715472..3b20f8c 100644
--- a/c2_advance/README.md
+++ b/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.
From 4648c5bc4bab9edb9e5cead652ea9047074f448b Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:34:45 +0900
Subject: [PATCH 05/13] fix typos README.md
"initialobjective" -> "initial objective"
"webecosystems" -> "web ecosystems"
"fromthe" -> "from the"
"runtimeand" -> "runtime and"
"edgecomputing" -> "edge computing"
"functionson" -> "functions on"
"connecta" -> "connect a"
"building block andingredients" -> "building blocks and ingredients"
"validunder" -> "valid under"
"suchthat" -> "such that"
"inpractical" -> "in practical"
"a internal" -> "an internal"
---
c3_circuits/README.md | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/c3_circuits/README.md b/c3_circuits/README.md
index 27c7a1a..f12d878 100644
--- a/c3_circuits/README.md
+++ b/c3_circuits/README.md
@@ -1,12 +1,12 @@
# Circuit Design
## 1 INTRODUCTION
-WASM (or WebAssembly) is an open standard binary code format close to assembly. Its initialobjective is to provide an alternative to java-script with better performance in the current webecosystems. Benefiting from its platform independence, front-end flexibility (can be compiled fromthe majority of languages including C, C++, assembly script, rust, etc.), good isolated runtimeand speed that is close to native binary, its usage starts to arise in the distributed cloud and edgecomputing. Recently it has become a popular binary format for users to run customized functionson AWS Lambda, Open Yurt, AZURE, etc.
+WASM (or WebAssembly) is an open standard binary code format close to assembly. Its initial objective is to provide an alternative to java-script with better performance in the current web ecosystems. 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 that is close to native binary, its usage starts to arise in the 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 Problem.** To implement a ZKSNARK-backed WASM virtual machine, we need to connect the implementation of WASM runtime with the proof system of ZKSNARK. In general, a ZKSNARK system is represented in arithmetic circuits with polynomial constraints. Therefore we need to abstract the full imperative logic of a WASM virtual machine systematically and rewrite it into arithmetic circuits with constraints. Given two outputs, one is generated by emulating the WASM bytecode in WASM runtime that enforces the semantics of WASM specification, and the other satisfies the constraints imposed on the arithmetic circuits. If the circuits we write preserve the semantics, these two outputs must be the same. Hence the proof of the ZKSNARK derived from the circuits also shows that the output is valid as a result of emulating the bytecode in WASM runtime.
-**Organization of the document.** After a brief introduction to the basic ideas about how to connecta stateful virtual machine with ZKSNARK in Section 2, we describe the basic building block andingredients used to construct ZKWASM circuits in Section 3 and then present the circuits architecture in Section 4. After the architecture is settled, we discuss the circuits of every category of WASM instructions in Section 5. In addition, in Section 5.4 we discuss foreign instruction expansion which provides a way to extend the virtual machine for better performance and integration. In Section 6, we present the partition and proof batching technique to solve the long execution trace problem.
+**Organization of the document.** After a brief introduction to the basic ideas about how to connect a stateful virtual machine with ZKSNARK in Section 2, we describe the basic building block and ingredients used to construct ZKWASM circuits in Section 3 and then present the circuits architecture in Section 4. After the architecture is settled, we discuss the circuits of every category of WASM instructions in Section 5. In addition, in Section 5.4 we discuss foreign instruction expansion which provides a way to extend the virtual machine for better performance and integration. In Section 6, we present the partition and proof batching technique to solve the long execution trace problem.
Throughout the document, we use the notation $$a:A$$ to specify a variable of type $$A$$, $$F$$ to specify the number field, and $$F_n$$ to specify a multi-dimensional vector with dimension $$n$$. We denote by $$A \rightarrow B$$ the function type from $$A$$ to $$B$$ and use $$\circ$$ for function composition. Moreover, we use $$G[i][j]$$ to specify the value of the cell of matrix $$G$$ at the $$i$$ th row and $$j$$ th column.
@@ -17,17 +17,17 @@ Internally the WASM run-time maintains a state $$S$$ denoted by a tuple ($$iaddr
For simplicity, we will use the notation of record field to specify a field in state $$s:S$$. For example, $$s.iaddr$$ denotes the current instruction address of state $$s$$, $$s.IO.stdin$$ denotes the input of state $$s$$, etc. We also use $$s.iaddr.op$$ to denote the opcode (operation code that specifies the operation to be performed) at address $$s.iaddr$$ in the code section $$C$$ of image $$I$$.
-Based on the above definition, we define the criteria for a list of state transitions to be validunder $$(I(C, H), E, IO)$$, as follows.
+Based on the above definition, we define the criteria for a list of state transitions to be valid under $$(I(C, H), E, IO)$$, as follows.
--- **Definition 2.1** (Valid Execution Trace). Given a WASM machine with input $$(I(C, H), E, IO)$$, and $$s_0$$ is the initial state with $$s_0.iaddr = E$$. A valid execution trace is a list of transition functions $$t_i$$ suchthat the following holds:
+-- **Definition 2.1** (Valid Execution Trace). Given a WASM machine with input $$(I(C, H), E, IO)$$, and $$s_0$$ is the initial state with $$s_0.iaddr = E$$. A valid execution trace is a list of transition functions $$t_i$$ such that the following holds:
(1) For all $$k$$, $$s_k = t_{k-1} \circ \cdots \circ t_1 \circ t_0 (s_0)$$, $$t_k$$ enforces the semantics of $$s_k.iaddr.op$$.
(2) If $s_e$ is the last state, then the depth of the calling frame is zero: $se.F.depth = 0$.
## 3 IO of ZKWASM
-The outermost function of ZKWASM is of type `zkmain(void): (void)`. To access the external IO, we use two builtin host functions: *zkwasm_input* and *zkwasm_output*. Suppose that we have an array of instances [$$I_i$$] and a internal cursor $$k$$, *zkwasm_input(1)* binds the $$k$$th instance to the top of the stack and similarly *zkwasm_output()* binds the current top of the stack with $$I_k$$. Both *zkwasm_input* and *zkwasm_output* increase the cursor $$k$$. We can also access external witness by *zkwasm_input(0)*, when doing so we just fill the top of the stack with a witness which does not bind with any public instances.
+The outermost function of ZKWASM is of type `zkmain(void): (void)`. To access the external IO, we use two builtin host functions: *zkwasm_input* and *zkwasm_output*. Suppose that we have an array of instances [$$I_i$$] and an internal cursor $$k$$, *zkwasm_input(1)* binds the $$k$$th instance to the top of the stack and similarly *zkwasm_output()* binds the current top of the stack with $$I_k$$. Both *zkwasm_input* and *zkwasm_output* increase the cursor $$k$$. We can also access external witness by *zkwasm_input(0)*, when doing so we just fill the top of the stack with a witness which does not bind with any public instances.
## 4 Succinct Proof of the circuits
-Compared with a standard WASM run-time, ZKWASM aims to provide a proof to prove that the output is valid so that it can be used in scenarios which require trustless and privacy computation. Moreover, the verifying algorithm needs to be simple in the sense of complexity to be useful inpractical. In zkWasm we have three different categories of circuits.
+Compared with a standard WASM run-time, ZKWASM aims to provide a proof to prove that the output is valid so that it can be used in scenarios which require trustless and privacy computation. Moreover, the verifying algorithm needs to be simple in the sense of complexity to be useful in practical. In zkWasm we have three different categories of circuits.
1. Guest circuits: enforces the semantics of slices of execution traces.
2. Host circuits: enforces the semantics of host API calls
From 56b3ca7b8169274382c84f7dc3527234336c8f2a Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:36:43 +0900
Subject: [PATCH 06/13] fix typos c1_typescript.md
"typscript" -> "typescript"
"APIS" -> "APIs"
"informations" -> "information"
"A example" -> "An example"
---
c4_cloud/c1_typescript.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/c4_cloud/c1_typescript.md b/c4_cloud/c1_typescript.md
index fea107f..1051122 100644
--- a/c4_cloud/c1_typescript.md
+++ b/c4_cloud/c1_typescript.md
@@ -1,11 +1,11 @@
# Typescript SDK for connecting with ZKWASM cloud.
## Introduction
-zkWasm-service-helper(https://github.com/DelphinusLab/zkWasm-service-helper) is a typscript library to help communicate with zkwasm cloud service. It provides common APIS for ZKWASM application developers to use the cloud proving service to generate ZKWASM proofs.
+zkWasm-service-helper(https://github.com/DelphinusLab/zkWasm-service-helper) is a typescript library to help communicate with zkwasm cloud service. It provides common APIs for ZKWASM application developers to use the cloud proving service to generate ZKWASM proofs.
## How to use it
-The default RPC point for ZKWASM cloud is "https://rpc.zkwasmhub.com:8090". This lib main provide a ZkWasmServiceHelper class to help user to communicate to this RPC endpoint. It mainly provides the following APIs to perform proving tasks and query informations about submitted tasks.
+The default RPC point for ZKWASM cloud is "https://rpc.zkwasmhub.com:8090". This lib main provide a ZkWasmServiceHelper class to help user to communicate to this RPC endpoint. It mainly provides the following APIs to perform proving tasks and query information about submitted tasks.
Example APIs:
* async queryImage(md5: string);
@@ -13,7 +13,7 @@ Example APIs:
* async addNewWasmImage(task: WithSignature
From b24c77e2218317499b071eae2dc10aa4d49a2c48 Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:49:26 +0900
Subject: [PATCH 11/13] fix typos c3_setup.md
"beinging" -> "being"
"excution" -> "execution"
---
c1_beginner/c1_quickstart/c3_setup.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/c1_beginner/c1_quickstart/c3_setup.md b/c1_beginner/c1_quickstart/c3_setup.md
index dca6bd0..cb166dc 100644
--- a/c1_beginner/c1_quickstart/c3_setup.md
+++ b/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
```
From b3499bf21f9fd543b6ea126b32e3eda6676acac9 Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:50:57 +0900
Subject: [PATCH 12/13] fix typos c4_prove.md
"signle" -> "single"
"commnad" -> "command"
"arguement" -> "argument"
"execuated" -> "executed"
---
c1_beginner/c1_quickstart/c4_prove.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/c1_beginner/c1_quickstart/c4_prove.md b/c1_beginner/c1_quickstart/c4_prove.md
index e6ef9b9..6bb45cf 100644
--- a/c1_beginner/c1_quickstart/c4_prove.md
+++ b/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).
@@ -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
From c217bda15c1f2683d8d014f00526f81e00aa07f6 Mon Sep 17 00:00:00 2001
From: osrm <90407222+osrm@users.noreply.github.com>
Date: Tue, 3 Dec 2024 16:51:42 +0900
Subject: [PATCH 13/13] fix typo c2_prepare.md
"Simlarly" -> "Similarly"
---
c1_beginner/c1_quickstart/c2_prepare.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c1_beginner/c1_quickstart/c2_prepare.md b/c1_beginner/c1_quickstart/c2_prepare.md
index 23aa220..6962563 100644
--- a/c1_beginner/c1_quickstart/c2_prepare.md
+++ b/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