Docs fix spelling issues

README.md

@@ -2,7 +2,7 @@
 
 ![Build](https://github.com/Phala-Network/phala-blockchain/actions/workflows/build.yml/badge.svg)
 
-Phala Network is the offchain computing protocol, powering the decentralized execution layer for AI agents.
+Phala Network is the off-chain computing protocol, powering the decentralized execution layer for AI agents.
 
 ## Native Build
 
@@ -52,7 +52,7 @@ Make sure you have Rust and LLVM-10 installed.
 
 > Note for Mac users: you also need `llvm` and `binutils` from Homebrew or MacPort, and to add their binaries to your $PATH
 
-Run `git submodule update --init` to fetch submodules before build if you haven't add option `--recursive ` when clone code.
+Run `git submodule update --init` to fetch submodules before build if you haven't added option `--recursive ` when clone code.
 
 ```bash
 cargo build --release

docs/add-worker-to-cluster.md

@@ -8,8 +8,8 @@
 
         The new worker must stop at a block before we take the snapshot on the old worker, because the new worker will pre-load the snapshot, sync to the snapshot block, and load it in the future.
 
-- 4. Follow instructions in the [cluster-state-transfer.sh](/standalone/pruntime/scripts/cluster-state-transfer.sh) to transfer the state from the old worker to the new worker.
+- 4. Follow the instructions in the [cluster-state-transfer.sh](/standalone/pruntime/scripts/cluster-state-transfer.sh) to transfer the state from the old worker to the new worker.
 
-        Note: Make sure do the step 4 quickly after step 3, because the old worker will check the new worker's block height and reject the state transfer request if the new worker is too far behind(more than 128 blocks).
+        Note: Make sure to do step 4 quickly after step 3, because the old worker will check the new worker's block height and reject the state transfer request if the new worker is too far behind(more than 128 blocks).
 
 - 5. Resume syncing on the new worker.

docs/relayer.md

@@ -1,6 +1,6 @@
 # Relayer
 
-The relayer is responsible to sync data between the blockchain and pRuntime.
+The relayer is responsible for syncing data between the blockchain and pRuntime.
 
 Now we have two relayer implementations:
 
@@ -11,7 +11,7 @@ The code pointers in this doc are based on `pherry`.
 
 ## Blockchain -> Enclave Sync
 
-The relayer subscribes the blockchain, and sync new blocks (and the corresponding events and chain state) to `pRuntime`.
+The relayer subscribes to the blockchain, and sync new blocks (and the corresponding events and chain state) to `pRuntime`.
 
 However, all the data received by `pRuntime` must be validated. The secure enclave is supposed to be a trusted environment, but the relayer is not, because anyone controlling the relayer can modify or manipulate the data before it enters `pRuntime`. So besides the block data, we have to prove the ingested data is valid and finalized to `pRuntime`.
 
@@ -39,7 +39,7 @@ The relayer is responsible to get the initial validator set and the following au
 > - [Code: get the initial validator set](https://github.com/Phala-Network/phala-blockchain/blob/6da6386026fc240d8be3c43d3b0375d3bd2f7071/standalone/pherry/src/main.rs#L480)
 > - [Code: get authority change]((https://github.com/Phala-Network/phala-blockchain/blob/6da6386026fc240d8be3c43d3b0375d3bd2f7071/standalone/pherry/src/main.rs#L389-L394))
 
-Because the validator set rotation in every era, the relayer can only sync the block headers up to the last block in the current era to `pRuntime`. The sequence of syncing must follow:
+Because the validator sets rotation in every era, the relayer can only sync the block headers up to the last block in the current era to `pRuntime`. The sequence of syncing must follow:
 
 1. Init `pRuntime` with the genesis validator set
 2. Sync block headers in era 0
@@ -76,4 +76,4 @@ Handle block headers and authority changes (in `pRuntime`)
 
 ## Enclave -> Blockchain Sync
 
-WIP
+WIP

docs/replay.md

@@ -2,9 +2,9 @@
 
 ## Overview
 
-`replay` is an utility program designed to reproduce the tokenomic computation outside a Gatekeeper. It comes with the following features:
+`replay` is a utility program designed to reproduce the tokenomic computation outside a Gatekeeper. It comes with the following features:
 
-- Fetch chain blocks and Replay the tokenomic computuing just in-place without pRuntime needed.
+- Fetch chain blocks and Replay the tokenomic computing just in-place without pRuntime needed.
 - Provide a HTTP api to query worker's instant computing state.
 - Optionally write the workers ming finance events to a PostgreSQL or TimescaleDB database.
 

docs/rpc.md

@@ -17,11 +17,11 @@ To get better performance, the client should limit the amount of requested block
 
 ### **pha_getMqNextSequence**
 
-Return the next mq sequence number for given sender which take the ready transactions in txpool in count.
+Return the next mq sequence number for given sender which takes the ready transactions in txpool in count.
 
 **Args:**
 
-- `sender_hex`: `String` - the scale-codec encoded [`MessageOrigin`](https://github.com/Phala-Network/phala-blockchain/blob/df3037fd85ae0e673b4b42777975c718fce8d4c8/crates/phala-mq/src/types.rs#L23) hex of the offchain message sender to query
+- `sender_hex`: `String` - the scale-codec encoded [`MessageOrigin`](https://github.com/Phala-Network/phala-blockchain/blob/df3037fd85ae0e673b4b42777975c718fce8d4c8/crates/phala-mq/src/types.rs#L23) hex of the off-chain message sender to query
 
 **Returns:** `u64` - the next expected sequence number of the sender.
 

docs/threads-in-pruntime.md

@@ -4,7 +4,7 @@
 | ------- | --------------- | ------------- |
 | main thread | 1  | the entry of the program  |
 | benchmark | --cores  | threads to run the benchmark |
-| rayon pool | CPU cores  | The rayon is used by wasmer compiler implictly |
+| rayon pool | CPU cores  | The rayon is used by wasmer compiler implicitly |
 | web pool | workers in Rocket.toml  | tokio thread pool serving the web API |
 | sidevm pool | --cores + 2  | threads to run sidevm instance |
 | tokio blocking pool | max=16 | tokio's helper threads that turn the blocking api into async |
@@ -15,4 +15,4 @@ There are 3 threads runs libOS service
 | --------------- | --------------- |
 | IPC             | 1               |
 | Async events    | 1               |
-| TLS-handshaking | 1               |
+| TLS-handshaking | 1               |