Fix typos (crypto-com#151)

* Fix broken url links due to polkadot rename and folder reorg

* fix typos in whole repository

* clearer text and fix duplicated word

Co-authored-by: ceruleanhu <[email protected]>

README.md

@@ -105,7 +105,7 @@ a PDF version of the site will be generated under the ``/docs`` path.
 
 ## Deploying Chain-doc to Github Pages
 
-1. Make sure you're working on a fork in your own account, not our original respository: `git remote show origin`
+1. Make sure you're working on a fork in your own account, not our original repository: `git remote show origin`
 2. Commit your changes: `git commit -a -m "YOUR MESSAGE"`
 3. Push the changes to GitHub: `git push`
 4. Run `./deploy.sh`

docs/getting-started/README.md

@@ -71,7 +71,7 @@ $ cd chain/
 $ make build
 ```
 
-It will take you serveral mins, and check the binary files share object files in following directory:
+It will take you several minutes, and check the binary files share object files in following directory:
 ```
 $ ls target/debug/
 
@@ -99,13 +99,13 @@ The Intel SGX attestation service is a public web service operated by Intel for
 :::
 
 In short, you should go to [Intel Portal](https://api.portal.trustedservices.intel.com/EPID-attestation)
-to sign up for the ID and KEY. It won't take you more than 5 mins.
+to sign up for the ID and KEY. It won't take you more than 5 minutes.
 
 Make sure what your subscription is [DEV Intel® Software Guard Extensions Attestation Service (Unlinkable)](https://api.portal.trustedservices.intel.com/Products/dev-intel-software-guard-extensions-attestation-service-unlinkable). Your `SPID` and `Primary key` will be shown on the portal as below:
 
 ![](./assets/intel_sub.png)
 
-After you obtained your `SPID` and `Primary key` from Intel, you should embeded them to your `.profile` file
+After you obtained your `SPID` and `Primary key` from Intel, you should embed them to your `.profile` file
 as environment variables with the other two variables (`SGX_MODE`, `NETWORK_HEX_ID`) we mentioned above. So, make sure append
 the following lines in your `.profile` file.
 
@@ -170,7 +170,7 @@ $ make stop-all
 $ make rm-all
 ```
 
-And then clean all the storages used by Tendemint, Cryto.com Chain by:
+And then clean all the storage used by Tendermint, Cryto.com Chain by:
 ```
 $ make clean-data
 ```
@@ -184,4 +184,4 @@ If no error Check all containers
 
 
 ### Congratulations
-Congratulations, now the environment to run Crypto.com Chain is all set. Let's on on and start [sending your first transaction](./send_your_first_transaction).
+Congratulations, now the environment to run Crypto.com Chain is all set. Let's on on and start [sending your first transaction](./send_your_first_transaction).

docs/getting-started/genesis.md

@@ -93,7 +93,7 @@ Light client allows users to access and interact with the blockchain without hav
 
 Specifically, this **genesis hash** is computed by the `compute_genesis_hash` function: where we take `"genesis_time"`,`"app_hash"`, `"consensus_params"`; and `"chain_id"` from the genesis file as inputs and hash it by the _blake3_ hash function.
 
-We can use the development tool _dev-utils_ to generate this genesis hash from the `genesis.json` file in the default tendetmint directory `~/.tendermint/config`, for example:
+We can use the development tool _dev-utils_ to generate this genesis hash from the `genesis.json` file in the default tendermint directory `~/.tendermint/config`, for example:
 
 ```bash
 $ ./dev-utils genesis hash

docs/getting-started/local_full_node_development.md

@@ -141,7 +141,7 @@ We can start the ABCI by running:
  chain-abci -g <APP_HASHx> -c <FULL_CHAIN_ID> --enclave_server tcp://127.0.0.1:25933
 ```
 
-If you need backtraces or logging, you may set the environment variables before it:
+If you need backtrace or logging, you may set the environment variables before it:
 
 ```bash
 $ RUST_BACKTRACE=1 RUST_LOG=info \

docs/getting-started/reward-and-punishments.md

@@ -18,7 +18,7 @@ pub struct RewardsPoolState {
     pub last_block_height: BlockHeight, // when was the pool last updated
     pub last_distribution_time: Timespec, // when was the pool last distributed
     pub minted: Coin,  // record the number of new coins ever minted, can't exceeds max supply
-    pub tau: u64,  // a decaying parameter in monetery expansion process
+    pub tau: u64,  // a decaying parameter in monetary expansion process
 }
 ```
 
@@ -160,7 +160,7 @@ rewards of a validator = total rewards in the pool * [Validatior's contribution]
 
 where
 
-- _"Validatior's contribution"_ is the total sum of the voting power participating in the consensus process by the validator throughout the reward period; and
+- _"Validator's contribution"_ is the total sum of the voting power participating in the consensus process by the validator throughout the reward period; and
 
 - _"Sum of the voting power"_ represents the total sum of the voting power involved in the consensus process from all of the active validators throughout the reward period.
 

docs/getting-started/send_your_first_transaction.md

@@ -116,7 +116,7 @@ Congratulations! You successfully withdraw all the unbonded genesis fund and now
 
 ## Transfer CRO to another address
 
-- Fisrt you can creat another wallet with the name `Bob`, or whatever name you like. The wallet type could be `hd`(Hierarchical Deterministic) or `basic`:
+- First you can creat another wallet with the name `Bob`, or whatever name you like. The wallet type could be `hd`(Hierarchical Deterministic) or `basic`:
 
 ```bash
 ./target/debug/client-cli wallet new --name bob --type hd
@@ -191,7 +191,7 @@ Enter authentication token:       // Input the Authentication token of Bob
 | Available | 12345678.00000000 |
 +-----------+-------------------+
 ```
-Congratulations! You successfully transfered `12345678 CRO` to Bob.
+Congratulations! You've successfully transferred `12345678 CRO` to Bob.
 
 If you are interested in contributing or joining our testnet, you can continue reading the following sections about `Running a Full Node to join Thaler Testnet` and `Local Full Node Development`.
 
@@ -236,4 +236,4 @@ As mentioned before, sender should add the receiver's view-key to the transactio
 
     ```bash
     $ ./target/debug/client-cli history --limit ? --offset ? --name <receiver_wallet>
-    ```
+    ```

docs/getting-started/signature-schemes.md

@@ -2,7 +2,7 @@
 
 There are two address types which require corresponding signature schemes:
 
-1. "RedeemAddress": Ethereum account address (for ERC20 reedem / backwards-compatibility); see `init/address.rs` in `chain-core`.
+1. "RedeemAddress": Ethereum account address (for ERC20 redeem / backwards-compatibility); see `init/address.rs` in `chain-core`.
 2. "Tree": threshold multisig addresses; records a root of a "Merklized Abstract Syntax Tree" where branches are "OR" operations and leafs are Blake3 hashes of aggregated X-only public keys:
 
 - [Merklized Abstract Syntax Tree](https://blockstream.com/2015/08/24/treesignatures/)

docs/getting-started/technical_glossary.md

@@ -170,6 +170,6 @@ The voting power is determined by the bonded amount in validator's staking addre
 
 #### W
 
-**Withdraw (Transcation type :`withdraw`)**
+**Withdraw (Transaction type :`withdraw`)**
 
 The transaction for withdrawing funds from a staking address to a transfer address.

docs/getting-started/transaction-accounting-model.md

@@ -34,7 +34,7 @@ The current account usage is self-contained limited. Each account (“staked sta
 
 and its slashing related information.
 
-For example, by using [clinent-cli](../wallets/client-cli.md#staking-operations), one can check the staking stake of a _Staking_ type address and obtain the following:
+For example, by using [client-cli](../wallets/client-cli.md#staking-operations), one can check the staking stake of a _Staking_ type address and obtain the following:
 
 ```bash
 ##### EXAMPLE: Staking state #####

docs/getting-started/transaction.md

@@ -64,7 +64,7 @@ All these types should also contain metadata, such as [network ID](./chain-id-an
 | Tx type              | Inputs                 | Outputs                                                                      | Fees involved? | Obfuscated? |
 | -------------------- | ---------------------- | ---------------------------------------------------------------------------- | -------------- | ----------- |
 | `TransferTx`         | UTXOs                  | UTXOs                                                                        | Yes            | Yes         |
-| `DepositStakeTx`     | UTXOs                  | Depostit to specified account’s `bonded` amount                              | Yes            | Yes         |
+| `DepositStakeTx`     | UTXOs                  | Deposit the bonded amount to the specified account                           | Yes            | Yes         |
 | `WithdrawUnbondedTx` | Nonce, account         | UTXOs                                                                        | Yes            | Yes         |
 | `UnbondStakeTx`      | Nonce, amount, account | Moves funds from `bonded` to `unbonded` under the same account with timelock | Yes            | No          |
 

docs/modules/jellyfish-merkle.md

@@ -76,7 +76,7 @@ can query the old state, unless we decide to prune the states that is too old.
 
   Replace a subtree which has single non-empty leaf node with the leaf node itself.
 
-  It further shortens the avarage depth of path greatly in sparse case.
+  It further shortens the average depth of path greatly in sparse case.
 
   > The merkle patrica tree in ethereum further utilize extension node to shorten the path, we don't implement that to
   > keep the logic simpler.
@@ -113,7 +113,7 @@ can query the old state, unless we decide to prune the states that is too old.
 
   This helps to keep data compact in underlying storage, because the nodes are inserted in key order.
 
-  > We use the block height as the version number, we'll use them interchangablely in this doc.
+  > We use the block height as the version number, we'll use them interchangeably in this doc.
 
 - We can compress the duplicates of placeholder hashes in the merkle proof.
 
@@ -304,10 +304,10 @@ fn put_at(node_key, key, value, version, i_visited) -> (NodeKey, Node) {
 
 ## Encoding
 
-The encoding is simply concatinate the fields together.
+The encoding is simply concatenate the fields together.
 
 - `H256`
-  It is encoded as fixed length byte array, which is just bytes themself, no length prefixed.
+  It is encoded as fixed length byte array, which is just bytes themselves, no length prefixed.
 
 - `Vec<u8>`
 
@@ -369,4 +369,4 @@ The key used to identify node in key-value storage.
 
 - `nibble_bytes: bytes`
 
-  One byte for two nibbles.
+  One byte for two nibbles.

docs/modules/punishment.md

@@ -28,8 +28,8 @@ pub struct PunishmentConfig {
 
 #### `LivenessTracker`
 
-`LivenessTracker` is used to track liveness of all the current active validators. A the beginning of each block,
-liveness of each active validator is updated using `update_liveness` function. Besides this, `LivenessTracker` also
+`LivenessTracker` is used to track liveness of all the current active validators. At the beginning of each block,
+liveness of each active validator is updated using `update_liveness` function. Besides, `LivenessTracker` also
 exposes function to `add` and `remove` a validator from liveness tracking. Finally, `is_live` function can be used to
 check if a given validator is live or not.
 

docs/modules/reward.md

@@ -6,14 +6,14 @@ Rewarding module enable crypto chain to reward protocol participators, the desig
 
 - The total supply of CRO is fixed.
 - The distribution should be "fair", i.e. all honest participators should get rewards, non-participators should not, and the amount of rewards get distributed to a validator should be proportional to it's contribution (sum of the voting power of each vote).
-- The newly emited coins for rewarding is adjusted according to [total staking](#total-staking) and current block time.
+- The newly emitted coins for rewarding is adjusted according to [total staking](#total-staking) and current block time.
 
 The basic procedure is:
 
 - Record participators for each block, sum the voting powers for each participator at the vote time.
 - Distribute the accumulated reward pool according to the recorded sum powers at the end of reward period.
 
-For example, in one reward period with N blocks, validator `A` only participate in the first block, and all the other validators particiate in all blocks, assuming the validator set is static during this period, then we have:
+For example, in one reward period with N blocks, validator `A` only participate in the first block, and all the other validators participate in all blocks, assuming the validator set is static during this period, then we have:
 
 ```
 p: voting power of validator A
@@ -64,7 +64,7 @@ The reward pool gets accumulated throughout the whole reward period; it gets dis
 
 Due to fixed point calculations, there may be a few remainders from arithmetic operations after distribution. These remainder amounts should be left in the rewards pool for the next period.
 
-If there is zero participator for the period, the rewards pool should be left to the next period, rather than get burned.
+If there is zero participant for the period, the rewards pool should be left to the next period, rather than get burned.
 
 #### Total staking
 
@@ -122,9 +122,9 @@ tau = (tau / 1000) * rate + (tau % 1000) * rate
 
 #### Fixed point arithmetic
 
-We should use continued fraction method to compute the `exp` and `pow` with fixed point arithemetics.
+We should use continued fraction method to compute the `exp` and `pow` with fixed point arithmetics.
 
-First we transform the power function into exponencial and natural logarithm functions:
+First we transform the power function into exponential and natural logarithm functions:
 
 ```
 pow(x, y) = exp(y * log(x))

docs/modules/staking-state.md

@@ -34,7 +34,7 @@ There are several variants of it:
 
 `validator.inactive_time.is_none()`
 
-> **_NOTE:_** Active validator doesn't nessesarily mean the final validator take effect in tendermint, please refer to
+> **_NOTE:_** Active validator doesn't necessarily mean the final validator take effect in tendermint, please refer to
 > [Choose final validators](#choose-final-validators)
 
 #### Inactive
@@ -57,7 +57,7 @@ The only way to transit to active validator is by executing `NodeJoinTx`, the pr
 
 - `bonded >= min_required_staking`
 - The validator pubkey/address is not already used by others, it's ok to re-use the old keys used by itself if it's a re-join from an inactive validator.
-- Not jailed if transitting from inactive validator
+- Not jailed if transiting from inactive validator
 
 ### From "active validator" to "inactive validator"
 
@@ -72,7 +72,7 @@ The reasons for dropping of bonded coins maybe:
 - Execute `UnbondTx` at `deliver_tx` event
 - Slashed for non-live or byzantine faults at `begin_block` event
 
-> **_NOTE:_** The transition happens immediatelly in `deliver_tx` or `begin_block` events, won't reverse automatically
+> **_NOTE:_** The transition happens immediately in `deliver_tx` or `begin_block` events, won't reverse automatically
 > when bonded coins become enough again even in the same block, so the activeness is always well-defined during the
 > whole process.
 
@@ -172,7 +172,7 @@ Disallowed transactions are:
 
 It won't distribute rewards to jailed validators, inactive(unjailed) validators will get the rewards as normal.
 
-When a validator is jailed, it's reward participation tracking records are removed immediatelly.
+When a validator is jailed, it's reward participation tracking records are removed immediately.
 
 #### Process byzantine faults
 

docs/wallets/client-cli.md

@@ -303,7 +303,7 @@ Enter view keys (comma separated) (leave blank if you don't want any additional
 
 :::
 
-#### Recieve funds
+#### Receive funds
 
 On the other hand, similarly, to receive funds, you will need to present your **address** and **view key** to the sender.
 

docs/wallets/sample-chain-wallet.md

@@ -15,7 +15,7 @@ Please follow the [instructions](https://github.com/crypto-com/sample-chain-wall
 
 ## Start ClientRPC
 
-Sample wallet is powered by [ClientRPC](./client-rpc). To run the Sammple Wallet, you will have to start the ClientRPC by following the [instructions](./client-rpc#build).
+Sample wallet is powered by [ClientRPC](./client-rpc). To run the Sample Wallet, you will have to start the ClientRPC by following the [instructions](./client-rpc#build).
 
 ## Wallet Management
 
@@ -64,7 +64,7 @@ To send funds to another address, you will have to first obtain the other party'
 To receive funds, you will need to present your address and view key to the sender; these can be obtained by:
 
 1. Unlock your wallet;
-2. Click *Receive* at the top right-hand cornder;
+2. Click *Receive* at the top right-hand corner;
 3. Copy your recipient address and view key.
 
 

plan.md

@@ -231,7 +231,7 @@ The transaction data bootstrapping enclave help with two use cases:
 Each node's transaction data bootstrapping enclave may optionally open a port to listen on for data/key retrieval requests.
 The communication is similar to the one described in the transaction query enclave (TLS + enclave attestation), but is bi-directional:
 
-* if transacation data is to be requested: before establishing the connection, the missing data is computed outside of the enclave using a light client + [utreexo](https://dci.mit.edu/utreexo) (Merkle forest commitments to the UTXO set). The transaction IDs to be retrieved are passed to the transaction data bootstrapping enclave
+* if transaction data is to be requested: before establishing the connection, the missing data is computed outside of the enclave using a light client + [utreexo](https://dci.mit.edu/utreexo) (Merkle forest commitments to the UTXO set). The transaction IDs to be retrieved are passed to the transaction data bootstrapping enclave
 * the requesting TDBE presents the client-side X.509 certificate with the IAS response payload in the v3 extension -- the responding TDBE verifies its content (response is OK and signed by IAS, the code is the same as the one it is executing, etc.) and vice versa.
 
 1) after establishing the TLS session, the requesting TDBE either sends a key retrieval or a data retrieval request
@@ -281,7 +281,7 @@ among validators. The protocol for the group communication channel follows the [
 * Each validator's transaction data bootstrapping enclave retrieves the identities of other validators,
 * Based on the validator identities (sorted by the validator staking address), each validator's transaction data bootstrapping enclave
 initializes GroupContext (constructs a ratchet tree with its leaves populated with the public keys and credentials from the UserInitKeys etc.)
-* If a validator validator is removed or added, the corresponding MLS handshake messages are generated and broadcasted as transactions using Tendermint P2P
+* If a validator is removed or added, the corresponding MLS handshake messages are generated and broadcasted as transactions using Tendermint P2P
 -- transaction validation enclave either only checks the outer signature (in the case of non-validator nodes) or relays it to the transaction 
 data bootstrapping enclave (in the case of validator nodes) where the node fully checks the messages and updates its group state
 * Once group communication channel is established or whenever the group state changes, the key for transaction data obfuscation is re-generated.
@@ -310,7 +310,7 @@ The additional burden is from the following facts:
 1) As view keys are inserted into public probabilistic filters, the client code is responsible for maintaining, watching and rotating view keys.
 
 2) As clients request transaction data from remote nodes, even though the actual data is in TEE and secure channels, the node operator may
-observe the I/O (what transaction IDs are looked up, how much traffic is being exchanged etc.) -- the client code is responsible for requesting from different nodes as well as introducing some noise in the requests (e.g. requesting extra abitrary transactions).
+observe the I/O (what transaction IDs are looked up, how much traffic is being exchanged etc.) -- the client code is responsible for requesting from different nodes as well as introducing some noise in the requests (e.g. requesting extra arbitrary transactions).
 
 To address this limitation, the future implementation of full nodes will be enhanced with 
 the capability of privacy-preserving view-key indexing -- instead of client keeping track of potentially relevant transactions through the use of probabilistic filters, it can directly request all relevant transactions