doc: update website docs (#37)

* doc: update website docs

* chore: fix linting issues

content/get-started/pactus-gui.md

@@ -135,11 +135,5 @@ The reward address is the account address where you collect the
 [rewards](/protocol/blockchain/incentive/) earned by participating in
 the consensus algorithm and proposing new blocks.
 
-To become a validator and participate in the
-consensus algorithm to earn rewards, you first need to
-[stake](/protocol/consensus/proof-of-stake/) some coins. In the next
-[tutorial](/tutorials/send-transaction-gui/),
-we will explain how to send a Bond transaction to become a validator.
-
 By running a Pactus node, you contribute to the decentralization and security of the Pactus blockchain network.
 Thank you for your participation!

content/protocol/blockchain/incentive.md

@@ -16,13 +16,13 @@ maintain the security and integrity of the network.
 To better understand the incentive model in Pactus, let's compare it with the Bitcoin reward model.
 This comparison will help to understand how the incentive model works in Pactus.
 
-| Pactus                                           | Bitcoin                                      |
-| ------------------------------------------------ | -------------------------------------------- |
-| Consensus engine is Proof of Stake               | Consensus engine is Proof of Work            |
-| _Exactly_ every 10 seconds one block is _minted_ | Around every 10 minutes one block is _mined_ |
-| Total supply is 42,000,000 coin                  | Total supply is 21,000,000 coin              |
-| Always one coin per block                        | Initial block reward is 50 coin              |
-| No halving                                       | Halving happens every 4 years                |
+| Pactus                                 | Bitcoin                                      |
+| -------------------------------------- | -------------------------------------------- |
+| Consensus engine is Proof of Stake     | Consensus engine is Proof of Work            |
+| every 10 seconds one block is _minted_ | Around every 10 minutes one block is _mined_ |
+| Total supply is 42,000,000 coins       | Total supply is 21,000,000 coins             |
+| Always one coin per block              | Initial block reward is 50 coins             |
+| No halving                             | Halving happens every 4 years                |
 
 The halving mechanism in Bitcoin rewards early contributors more significantly.
 However, in a Proof-of-Stake blockchain, this mechanism can lead to wealth centralization,

content/protocol/consensus/_index.md

@@ -6,7 +6,7 @@ next: /protocol/consensus/proof-of-stake
 ---
 
 {{< cards >}}
-  {{< card link="proof-of-stake" title="Solid State Proof of Stake">}}
+    {{< card link="solid-state-proof-of-stake" title="Solid State Proof of Stake">}}
     {{< card link="protocol" title="Consensus Protocol">}}
     {{< card link="specification" title="Consensus Specification">}}
     {{< card link="sortition" title="Sortition Algorithm">}}

content/protocol/consensus/protocol.md

@@ -32,13 +32,13 @@ the resiliency of the algorithm is optimal if we have at least 3 non-faulty
 validators. So the minimum number of validators should be $3+1=4$.
 
 We denote a message as $\langle m \rangle$ tuple and a signed message by node $i$ as
-$$\langle m \rangle_{\sigma_i}$$.
+$\langle m \rangle_{\sigma_i}$.
 
 Pactus consensus algorithms has two phases: Block creation phase and change proposer phase.
 
 ### Block Creation
 
-The block creation phase in Pactus consensus algorithm includes these three steps[^1]:
+The block creation phase in Pactus consensus algorithm includes these three steps [^1]:
 **Propose**, **Prepare** and **Precommit**.
 The protocol proceeds in rounds $r = 0, 1, 2, \ldots$.
 
@@ -244,3 +244,7 @@ This ensures that each round can begin with a new proposal.
   </tr>
 </tbody>
 </table>
+
+[^1]: In [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf)
+  these steps are: pre-prepare, prepare and commit
+[^2]: [Random Oracles in Constantinople: Practical Asynchronous Byzantine Agreement Using Cryptography](https://link.springer.com/article/10.1007/s00145-005-0318-0)

content/protocol/consensus/proof-of-stake.md → content/protocol/consensus/solid-state-proof-of-stake.md

@@ -3,40 +3,43 @@ title: Solid State Proof of Stake
 weight: 1
 ---
 
-Proof of Stake is a way to secure a blockchain through requesting users to stake some amount of their coins.
-These stakeholders, called validators, are responsible to collect, validate and add transactions to the blockchain.
-The validators will be rewarded with native coins.
+## Proof of Stake
+
+Proof of Stake is a method used to keep a blockchain network secure and running smoothly.
+Instead of using a lot of computer power to solve complex puzzles (like in Proof of Work),
+Proof of Stake asks users to put some of their coins at stake.
+These users, known as validators, verify and add new transactions to the blockchain.
+In return, they earn extra coins as a reward.
 
 Unlike Proof of Work, which is based on competition, Proof of Stake is based on collaboration.
 Validators work together to manage the expansion of the blockchain.
 A Proof of Stake blockchain becomes more decentralized and secure as more validators participate in it.
 
-## An example
+### Community Bank Example
 
-To understand how Proof of Stake works, imagine a community bank without any centralized authority.
-In this bank, users decide to run it together.
-Some of these users volunteer to collect, validate, and record transactions,
-ensuring that everything runs smoothly.
+To understand how Proof of Stake works, think of a community bank run by its members without a central authority.
+The members decide to manage the bank together.
+Some members volunteer to collect, check, and record transactions to keep everything running smoothly.
 
-These volunteers, known as validators, must temporarily lock or freeze some of their money as a stake.
-This stake can't be transferred or used.
+These volunteers, known as validators, must temporarily lock up some of their money as a stake.
+This staked money can’t be moved or used.
 The more money a validator stakes, the more influence they have in the system.
 
 From time to time, one of the validators is chosen by the others to collect all the recent transactions,
 bundle them together, and send a copy to the other validators.
 If a supermajority of the validators agree with the proposed bundle by signing it,
 the bundle will be committed to the bank's ledger.
 
-In this system, validators have no incentive to behave maliciously or dishonestly.
-If they do, they risk harming the bank's reputation and the value of their own stakes as well.
+In this system, validators are encouraged to act honestly.
+If they don’t, they risk damaging the bank’s reputation and losing the value of their staked money.
 
 ## Delegated Proof of Stake
 
 In Proof of Stake, if the number of validators increases,
-the voting time will also increase, and this can lead to an inefficient consensus mechanism.
+the voting time will also increase, and this makes the consensus process less efficient.
 In our community bank example, running the bank becomes more difficult as the number of validators increases.
 
-To solve this problem, some blockchains use the concept of "delegators".
+To address this problem, some blockchains use the concept of "delegators".
 In Delegated Proof of Stake, users entrust their stakes to a small group of "delegates".
 These delegates are responsible for validating transactions and creating blocks.
 The number of delegates is limited to ensure accountability and efficiency in the validation process.
@@ -46,11 +49,10 @@ The number of delegates is limited to ensure accountability and efficiency in th
 The delegation model puts a lot of trust in the hands of a small number of delegates,
 which goes against the principle of "don't trust, verify".
 
-## Consensus without delegation or Solid State Proof of Stake (SSPoS)
+## Solid State Proof of Stake (SSPoS)
 
-Pactus introduced a mechanism that doesn't rely on delegation, we call it Solid State Proof of Stake.
-It utilizes a dynamic [committee](/protocol/consensus/committee/) of validators
-that are responsible for creating new blocks.
+Pactus introduced a new mechanism called Solid State Proof of Stake that operates without delegation.
+It employs a dynamic [committee](/protocol/consensus/committee/) of validators that are responsible for creating new blocks.
 The size of the committee is fixed, but the members of the committee are randomly changed.
 On the other hand, the number of validators outside the committee is unlimited, allowing anyone to
 become a validator by staking coins.

content/protocol/consensus/sortition.md

@@ -38,11 +38,11 @@ The pseudocode below demonstrates the evaluation of the VRF for the sortition al
 
 $$
 \begin{align*}
-& \textbf{function} \ VRF(sk, seed, total\_stake) \newline
+& \textbf{function} \ generateVRF(sk, seed, stake_{total}) \newline
 & \qquad pk \gets P_{BLS}(sk) \newline
 & \qquad proof \gets S_{BLS}(sk, seed \| pk) \newline
 & \qquad rnd \gets H(proof) \newline
-& \qquad index \gets \frac{(rnd \times total\_stake)}{2^{256}} \newline
+& \qquad index \gets \frac{(rnd \times stake_{total})}{2^{256}} \newline
 & \qquad \newline
 & \qquad \textbf{return} \ index, proof \newline
 & \textbf{end function}
@@ -53,22 +53,22 @@ where:
 
 - $sk$ is the secret key of the validator
 - $seed$ is the sortition seed
-- $total\_stake$ is the total stake of the blockchain
+- $stake_{total}$ is the total stake of the blockchain
 - $P_{BLS}$ is a cryptographic function that derives the public key from the secret key for the BLS signature
-- $S_{BLS}$ is a cryptographic function that signs a message with the secret key for the BLS signature.
-- $H$ is a cryptographic hash function that generates a number between $0$to $2 ^{256}$
+- $S_{BLS}$ is a cryptographic function that signs a message with the secret key for the BLS signature
+- $H$ is a cryptographic hash function that generates a number between $0$ to $2 ^{256}$
 - $\|$ denotes the concatenation of two values
 
 To verify a sortition proof, both the validator's public key and stake are required:
 
 $$
 \begin{align*}
-& \textbf{function} \ verifyVRF(pk, seed, proof, stake, total\_stake) \newline
+& \textbf{function} \ verifyVRF(pk, seed, proof, stake, stake_{total}) \newline
 & \qquad \textbf{if} \ V_{BLS}(pk, seed \| pk, proof) = True \ \textbf{then} \newline
 & \qquad \qquad rnd \gets H(proof) \newline
-& \qquad \qquad index \gets \frac{(rnd \times total\_stake)}{2^{256}} \newline
+& \qquad \qquad index \gets \frac{(rnd \times stake_{total})}{2^{256}} \newline
 & \qquad \newline
-& \qquad  \qquad \textbf{return} \ index \leqslant stake \newline
+& \qquad  \qquad \textbf{return} \ index < stake \newline
 & \qquad  \textbf{else} \newline
 & \qquad  \qquad \textbf{return} \ False \newline
 & \qquad  \textbf{end if} \newline
@@ -79,6 +79,7 @@ $$
 where:
 
 - $V_{BLS}$ is a cryptographic function used to verify a signed message using the BLS signature scheme
+- $stake$ is the validator's stake in the blockchain
 
 There is no need to send $index$ alongside $proof$ because the
 result should be less than the validator's stake, and the validator's stake is known at each block.
@@ -94,8 +95,8 @@ In each block, the block proposer generates a new sortition seed based on the pr
 
 $$
 \begin{align*}
-& \textbf{function} \ generateSeed(sk, prev\_seed) \newline
-& \qquad \textbf{return} \ S_{BLS}(sk, H(prev\_seed)) \newline
+& \textbf{function} \ generateSeed(sk, seed_{prev}) \newline
+& \qquad \textbf{return} \ S_{BLS}(sk, H(seed_{prev})) \newline
 & \textbf{end function}
 \end{align*}
 $$
@@ -106,8 +107,8 @@ The verification function is as follows:
 
 $$
 \begin{align*}
-& \textbf{function} \ verifySeed(pk, prev\_seed, seed) \newline
-& \qquad \textbf{return} \ V_{BLS}(pk, H(prev\_seed), seed) \newline
+& \textbf{function} \ verifySeed(pk, seed_{prev}, seed) \newline
+& \qquad \textbf{return} \ V_{BLS}(pk, H(seed_{prev}), seed) \newline
 & \textbf{end function}
 \end{align*}
 $$
@@ -158,6 +159,6 @@ An active validator is a validator that has not yet [unbonded](/protocol/transac
 
 The height at which the validator joined the committee is recorded as the "Last Joined Height" field in
 the [validator](/protocol/blockchain/validator/) structure.
-The validator with the lowest "Last Joined Height" is considered the oldest.
+The validator with the lowest "Last Joined Height" in the committee is considered the oldest.
 
 [^first]: [Verifiable Random Function](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf)

content/protocol/transaction/sortition.md

@@ -9,6 +9,7 @@ in the [committee](/protocol/consensus/committee/).
 By committing a sortition transaction, the validator will enter the committee.
 Sortition transactions are valid for 7 blocks, which is defined as "sortition interval" in the
 [consensus parameters](/protocol/consensus/parameters/).
+Sortition is free. This means there are no fees associated with the process of sortition transaction.
 
 ## Payload Structure
 

content/protocol/transaction/unbond.md

@@ -5,8 +5,10 @@ math: false
 ---
 
 Unbond transaction is used to unbond a [validator](/protocol/blockchain/validator/).
-An unbonded validator cannot participate in the sortition algorithm anymore, and after 21 days, the stake can be withdrawn.
-This is called the "unbond interval" and is defined in the [consensus parameter](/protocol/consensus/parameters/).
+An unbonded validator becomes inactive and can no longer participate in the sortition algorithm.
+After 21 days, the stake can be withdrawn.
+This period is called the "unbond interval" and is defined in the [consensus parameter](/protocol/consensus/parameters/).
+Unbonding is free. This means there are no fees associated with the process of unbond transaction.
 
 ## Payload Structure
 

content/protocol/transaction/withdraw.md

@@ -4,8 +4,10 @@ weight: 7
 math: false
 ---
 
-Withdraw transaction is used to withdraw the staked coins from an unbonded
-[validator](/protocol/blockchain/validator/)
+A withdraw transaction is used to retrieve the staked coins from an unbonded
+[validator](/protocol/blockchain/validator/).
+If the validator is still in the unbond period, the transaction will be rejected.
+The unbond period is a 21-day interval during which the validator is inactive, but their stake cannot yet be withdrawn.
 
 ## Payload Structure
 
@@ -17,6 +19,6 @@ The withdraw transaction has a payload consists the following fields:
 | Receiver address | 21 bytes |
 | Amount           | Variant  |
 
-- **Sender address** is the address of the sender validator.
+- **Sender address** is the address of the unbonded validator.
 - **Receiver address** is the address of the receiver [account](/protocol/blockchain/account/).
 - **Amount** is the amount of coins that should be withdrawn

content/tutorials/_index.md

@@ -6,11 +6,11 @@ next: /tutorials/pactus-wallet
 ---
 
 {{< cards >}}
-  {{< card link="pactus-wallet" title="How to use wallet in Command Line Mode?">}}
   {{< card link="send-transaction-gui" title="How to send transactions in Graphic Mode?">}}
+  {{< card link="pactus-wallet" title="How to use wallet in Command Line Mode?">}}
+  {{< card link="pactus-shell" title="How to use Pactus Shell?">}}
   {{< card link="grpc-sign-transactions" title="How to sign transaction using gRPC?">}}
   {{< card link="grpc-basic-auth" title="How to secure gRPC using basic authentication?">}}
-  {{< card link="pactus-shell" title="How to use Pactus Shell?">}}
   {{< card link="reduce-network" title="How to reduce the network usage?">}}
   {{< card link="pactus-metrics" title="How to run Pactus Metrics?">}}
   {{< card link="linux-systemd" title="How to run Pactus with systemd linux?">}}

content/tutorials/grpc-basic-auth.md

@@ -1,6 +1,6 @@
 ---
 title: How to Secure gRPC Using Basic Authentication
-weight: 4
+weight: 5
 ---
 
 ## Preface

content/tutorials/grpc-sign-transactions.md

@@ -1,6 +1,6 @@
 ---
 title: How to Sign Transactions Using gRPC?
-weight: 3
+weight: 4
 ---
 
 ## Preface

content/tutorials/pactus-shell.md

@@ -1,6 +1,6 @@
 ---
 title: How to use Pactus Shell?
-weight: 5
+weight: 3
 ---
 
 Pactus Shell is a command-line tool designed for interacting with the Pactus blockchain.

content/tutorials/pactus-wallet.md

@@ -1,6 +1,6 @@
 ---
-title: How to use wallet in Command Line Mode?
-weight: 1
+title: How to use Pactus Wallet?
+weight: 2
 ---
 
 ## Preface

content/tutorials/send-transaction-gui.md

@@ -1,6 +1,6 @@
 ---
 title: How to send transactions in Graphic Mode?
-weight: 2
+weight: 1
 ---
 
 ## Preface
@@ -48,12 +48,17 @@ Therefore, if you want to stake on your own validators, you don't need to set th
 
 ## Unbond
 
-**Unbonding**: Unbonding is free. This means there are no fees associated with the process of unbonding your Pactus coins.
+To send a [unbond transaction](/protocol/transaction/unbond/), click on the "Transaction" menu
+and select "Unbond".
+A new window will appear where you can select the validator address from which you wish to "unbond".
 
 ![Unbond Transaction Dialog](/images/unbond-transaction-dialog.png)
 
 ## Withdraw
 
-**Withdrawals**: After you've unbonded your Pactus coins from staking, it will take 21 days before your coins can be withdrawn.
+To send a [withdraw transaction](/protocol/transaction/withdraw/), click on the "Transaction" menu
+and select "Withdraw".
+A new window will appear where you can select the validator address from which you wish to withdraw their stake,
+as well as the recipient's account address and the amount you wish to withdraw.
 
 ![Withdraw Transaction Dialog](/images/withdraw-transaction-dialog.png)