Problem: (fix#143) genesis page is not up to date (#154)

Solution:

getting-started/genesis.md : Updated and change "genesis hash" to "genesis fingerprint", align with the changes in #1759.
Extra: Some small fix/links redirecting for better communication.

docs/getting-started/README.md

@@ -7,15 +7,15 @@ For anyone interested in joining the Crypto.com chain testnet,
 please refer to our [testnet documentation](./thaler-testnet).
 :::
 
-By following this tutorial, you can compile and run latest version of Crypto.com Chain from scratch.
-With supported hardware, you can run the chain locally within a cup of coffee ☕. However, this document aims 
-to provide you a step-by-step guide to run Crypto.com Chain locally and not a guide for
+By following this tutorial, you can compile and run the latest version of Crypto.com Chain from scratch.
+With supported hardware, you can run the chain locally within a cup of coffee ☕. However, this document aims
+to provide you with a step-by-step guide to run Crypto.com Chain locally and not a guide for
 production usage.
 
 ## Pre-requisites
 
 Because we utilize the technology of `Intel® Software Guard Extensions (Intel® SGX)`
-for [payment data confidentiality](./transaction-privacy.md#motivation ), the pre-requisites are a little more strict than the other
+for [payment data confidentiality](./transaction-privacy.md#motivation), the pre-requisites are a little more strict than the other
 chains' setup. A special type of hardware is needed and the reference of [SGX-hardware](https://github.com/ayeks/SGX-hardware)
 could help you identify if your current hardware supports `Intel® SGX` or not.
 
@@ -28,6 +28,7 @@ Before diving into details, we would like to introduce you the big picture of Cr
 ![](./assets/big_pic.png)
 
 At the end of this getting-start document, you will be running four components:
+
 - `chain-abci` as main chain process.
 - `client-rpc` as rpc server for client's interactions.
 - `tendermint` for consensus.
@@ -44,53 +45,61 @@ Make sure include the Open Enclave SDK:
 ![](./assets/azure_setup_2.png)
 
 Then choose your desirable VM `location`, `size`, `storage` and `network configs`, or you can leave
- them as default.
+them as default.
 
 ## VM environment setup
 
 SSH to the Azure VM, and start the environment setup for Crypto.com Chain.
 
 - Install `Docker`: you can refer to following document [How To Install and Use Docker on Ubuntu 18.04
-](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04)
+  ](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04)
+
+Make sure you have complete the part of `Executing the Docker Command Without Sudo` by:
 
-Make sure you have complete the part of ` Executing the Docker Command Without Sudo` by:
 ```
 sudo usermod -aG docker ${USER}
 ```
 
 - Clone the main chain repo
+
 ```
 git clone https://github.com/crypto-com/chain.git
 ```
 
 ## Build binary and Docker images
 
 #### 1. Build the Crypto.com Chain binary files:
+
 ```
 $ cd chain/
 $ make build
 ```
 
 It will take you several minutes, and check the binary files share object files in following directory:
+
 ```
 $ ls target/debug/
 
 chain-abci client-rpc client-cli tx-query-app ...
 ```
 
 #### 2. Build the docker image with local binary files using following command:
+
 ```
 $ make image
 ```
+
 Check the current built image with:
+
 ```
 $ docker images
 
 REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
 crypto-chain            develop             817f6c7c7a76        - seconds ago      940MB
-``` 
+```
 
 ## Prepare SPID & KEY
+
 Before kicking off all the components, there is one more step to go, which is
 registering your own accessing ID and KEY for Intel SGX attestation service.
 
@@ -115,22 +124,29 @@ export IAS_API_KEY={YOUR_PRIMARY_KEY}
 ```
 
 Surely, remember to source the new `.profile` file:
+
 ```
 $ source ~/.profile
 ```
 
 ## Prepare environment to run the chain
+
 Prepare initial chain data and try to install Intel SGX if the SGX device is not ready.
+
 ```
 $ make prepare
 ```
 
 ## Run chain components
+
 Run all the components of Cryto.com Chain with following command:
+
 ```
 $ make run
 ```
+
 Then you can check if all containers are running normally:
+
 ```
 $ docker ps
 
@@ -141,7 +157,9 @@ ade1db657cd8     tendermint/tendermint:v0.32.8   "/usr/bin/tendermint…"   -
 800f173dccc7     crypto-chain:develop            "bash ./run_tx_query…"   -       -        0.0.0.0:26651->26651/tcp               sgx-query
 1c5c71c4047b     crypto-chain:develop            "bash ./run_tx_valid…"   -       -                                               sgx-validation
 ```
+
 Besides, you can check the chain-abci and Tendermint status by following commands:
+
 ```
 $ docker logs -f chain-abci
 [-T08:50:02Z INFO  chain_abci::app] received beginblock request
@@ -163,25 +181,30 @@ $ curl 'http://localhost:26657/health'
 Congratulations! Crypto.com Chain is now running on your machine!
 
 #### Re-initialize a Crypto.com Chain
+
 If you need to stop the processes and initialize a new chain, firstly you should stop all
 service and remove docker containers by:
+
 ```
 $ make stop-all
 $ make rm-all
 ```
 
 And then clean all the storage used by Tendermint, Cryto.com Chain by:
+
 ```
 $ make clean-data
 ```
 
 Finally you can initialize a new chain by:
+
 ```
 $ make prepare
 $ make run
 ```
-If no error Check all containers 
 
+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).

docs/getting-started/client-flow.md

@@ -11,20 +11,20 @@ The full node inserts the following data into the filter at the moment:
 1. “view keys” (secp256k1 public keys allowed to view the content) in the case of transactions producing UTXOs (see [transaction types](./transaction) and [transaction privacy mechanism](./transaction-privacy) for more details).
 2. Staked state addresses in the case of transactions manipulating accounts (see [accounting details](./transaction-accounting-model)).
 
-## Client knows transaction
+## Client knows the transaction data
 
 Each block header includes an application hash (“APP_HASH”, see [consensus](./consensus) for details). As a part of it is a root of a Merkle tree of valid transactions, a client can check whether its known transaction was included in a block:
 
 1. Get the block’s application hash / header information.
 2. Compute the transaction ID from transaction data (see [transaction](./transaction)).
 3. Check a Merkle inclusion proof where the transaction ID is one of the leaves, and a part of the application hash is the root.
 
-## Client doesn’t know transaction data
+## Client doesn’t know the transaction data
 
 If the client doesn’t know transaction data, it can collect valid transaction identifiers from blocks that matched its data using the block-level filter. If the transaction data was transparent (staked state operations), the client can decode transaction directly by requesting the full block data. If the transaction data was obfuscated (payments), the client needs to contact an enclave and prove they can access transaction data using view key signatures (see [transaction privacy](./transaction-privacy) and [enclave architecture](./enclave-architecture) for more details).
 
 Clients are responsible for their own confidential data treatment – the use of view keys (whether reused or not), requesting transaction data (e.g. from multiple enclaves when not the client isn’t running their own full node) etc.
 
 ## Payment transaction submission
 
-When the client wishes to submit a payment transaction (UTXO-based), they will construct a plain signed transaction and submit it to one of full node’s enclaves over a secure channel (see [enclave architecture](./enclave-architecture)).
+When the client wishes to submit a payment transaction (UTXO-based), they will construct a plain signed transaction and submit it to one of the full node’s enclaves over a secure channel (see [enclave architecture](./enclave-architecture)).

docs/getting-started/consensus.md

@@ -47,7 +47,7 @@ The **“application hash”** is a compact representation of the overall ABCI a
 
 In Crypto.com Chain, the application hash is a [Blake3](https://github.com/BLAKE3-team/BLAKE3) hash of several components:
 
-- Root of a Merkle tree of a valid transactions in a given block;
+- Root of a Merkle tree of a valid transaction in a given block;
 - Root of a sparse Merkle trie of staked states (see [accounting details](./transaction-accounting-model));
 - Binary serialized state of rewards pool (see [serialization](./serialization) for details on Chain binary format and [genesis](./genesis) for details on “state”);
 - Serialised [network parameters](./network-parameters.md).

docs/getting-started/enclave-architecture.md

@@ -48,7 +48,7 @@ For further details, please refer to the [transaction flow chat](https://github.
 
 ### Data sealing
 
-As previous transaction data is needed for transaction validation, it needs to be persisted locally. The enclave uses the process of “data sealing” for this purposes. To make the data accessible for future upgrades and other enclaves, it should be sealed with MRSIGNER-derived keys. For further details, please refer to [TEE primitives](https://github.com/crypto-com/chain-docs/blob/master/plan.md#tee-primitives).
+As previous transaction data is needed for transaction validation, it needs to be persisted locally. The enclave uses the process of “data sealing” for this purpose. To make the data accessible for future upgrades and other enclaves, it should be sealed with MRSIGNER-derived keys. For further details, please refer to [TEE primitives](https://github.com/crypto-com/chain-docs/blob/master/plan.md#tee-primitives).
 
 ## Transaction data bootstrapping
 

docs/getting-started/genesis.md

@@ -87,16 +87,16 @@ Specifically, the genesis file includes the following fields:
     - `"type"`: The validator public key types, which should be one of the supported types in _"pub_key_types"_.
     - `"value"`: The base64 encoding of validator's public key, which should correspond to the _"value"_ of the validator in _"council_nodes"_.
 
-### Genesis hash
+## Genesis fingerprint
 
-Light client allows users to access and interact with the blockchain without having to run a full node. To ensure the light client is served by a full node with the correct blockchain data, we can compute the **genesis hash** locally beforehand and check it against the full node that we are connecting to.
+Light client allows users to access and interact with the blockchain without having to run a full node. To ensure the light client is served by a full node with the correct blockchain data, we can compute the **genesis fingerprint** locally beforehand and check it against the full node that we are connecting to.
 
-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.
+Specifically, this **genesis fingerprint** is computed by the `compute_genesis_fingerprint` 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 tendermint directory `~/.tendermint/config`, for example:
+We can use the development tool _dev-utils_ to generate this genesis fingerprint from the `genesis.json` file in the default tendermint directory `~/.tendermint/config`, for example:
 
 ```bash
-$ ./dev-utils genesis hash
+$ ./dev-utils genesis fingerprint
 85828B9048F3A38C0446CFD8EFF1A33CE7F299E6605001238B63684E9633EE4E
 ```
 

docs/getting-started/local_full_node_development.md

@@ -22,7 +22,7 @@ To create a wallet, currently, we have [client-rpc](https://github.com/crypto-co
 - Create a new *basic* wallet with the name "Default" by running
 
   ```bash
-   ./target/debug/client-cli wallet new --name Default --type basic
+  $ ./target/debug/client-cli wallet new --name Default --type basic
   ```
 
   You will be prompted to enter a passphrase.

docs/getting-started/network-parameters.md

@@ -1,6 +1,6 @@
 # List of network parameters
 
-This section aims to collect and provide brief description of all the mentioned network parameters:
+This section aims to collect and provide brief a description of all the mentioned network parameters:
 
 #### Staking-related parameters
 

docs/getting-started/transaction.md

@@ -5,7 +5,7 @@
 Each transaction has an identifier (typically shortened as TX ID). It is defined as
 
 | blake3_hash(SCALE-encoded transaction binary data) |
-| --------------------------------------------------- |
+| -------------------------------------------------- |
 
 
 See [serialization](./serialization) for more details about the transaction binary format.
@@ -18,25 +18,27 @@ See [signature-schemes](./signature-schemes) for more details
 
 Crypto.com Chain supports threshold / multi-signature addresses that are represented as a single hash (see [signature-schemes](./signature-schemes)) which is different from Ethereum.
 
-To represent the underlying byte array in a textual form, [Bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) is used. The convention for the human-readable part is the following:
+To represent the underlying byte array in a textual form, [Bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) is used. The convention for the human-readable prefix is the following:
 
-- cro: mainnet payment
-- tcro: testnet payment
-- dcro: local devnet/regtest payment
+- `cro`: mainnet payment
+- `tcro`: testnet payment
+- `dcro`: local devnet/regtest payment
 - staking addresses (see [accounting](./transaction-accounting-model)) are textually represented in hexadecimal encoding to match the initial Ethereum ones
 
 ## Transaction Fees
+
 The purpose of transaction fees in the initial prototype is an anti-spam measure, i.e. to prevent broadcasting valid transactions indefinitely.
 The general scheme is:
 
-* If the transaction type allows indefinite valid transactions in an immediate time span (e.g. "transfer"), a fee (calculated as below) must be paid -- i.e. each transaction should be validated that it included this sufficient fee. Note that the fee amount must be exactly equal to the computed one (this is to prevent errors where a much larger fee could be accidentally paid if the fee amount could be set arbitrarily large).
-* If the transaction type allows a limited number of valid transactions, there is no fee. One example is "unjail" where only one valid transaction can be sent for a given state after the unjailing period.
+- If the transaction type allows indefinite valid transactions in an immediate time span (e.g. "transfer"), a fee (calculated as below) must be paid -- i.e. each transaction should be validated that it included this sufficient fee. Note that the fee amount must be exactly equal to the computed one (this is to prevent errors where a much larger fee could be accidentally paid if the fee amount could be set arbitrarily large).
+- If the transaction type allows a limited number of valid transactions, there is no fee. One example is "unjail" where only one valid transaction can be sent for a given state after the unjailing period.
 
 More details can be found in the [transactions document](../modules/transactions.md).
 
 (In the future, if necessary, a dynamic Dutch auction-style fee market may be introduced for congestion control -- this may, however, be outside of the consensus state machine, i.e. "off-chain", in order to incentivize full nodes or other network layers.)
 
 ### Fee Calculation
+
 The initial prototype uses a linear fee system. The minimal transaction fee is defined according to the formula:
 
 ```
@@ -74,10 +76,12 @@ Please also refer to this [flowchart](./send_your_first_transaction.md#send-your
 
 Besides the above-mentioned basic transactions, there are some advanced types of transactions related to the council node and service node state metadata management, for example:
 
-- `UnjailTx`: This transaction can be broadcasted to [un-jail](./staking.md#un-jailing) a node. It takes _nonce_, _account_ and has to be signed by the account’s corresponding key.
+- `UnjailTx`: This transaction can be broadcasted to [un-jail](../wallets/client-cli.md#unjail-unjailing-a-validator) a node. It takes _nonce_, _account_ and has to be signed by the account’s corresponding key.
 - `NodeJoinTx`: Anyone who wishes to become a council node can broadcast this transaction. It takes _council node data_, _staking address_ and has to be signed by the node's staking key. For further details on the process of joining the Crypto.com chain as a validator, please refer to this [documentation](./node-joining.md).
 
-Remarks: There will be no transaction fee for advanced types Tx in the initial prototype.
+:::tip Note
+There will be no transaction fee for advanced types Tx in the initial prototype.
+:::
 
 ## Cross-currency transactions and settlements