improve consensus engine doc after bc fusion (#322)

docs/learn/consensus.md

@@ -1,10 +1,10 @@
 ---
-sidebar_label: Consensus Engine
+sidebar_label: Parlia Consensus Engine
 sidebar_position: 2
 hide_table_of_contents: false
 ---
 
-# Consensus Engine
+# Parlia Consensus Engine
 
 Although Proof-of-Work (PoW) has been recognized as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security.
 
@@ -18,27 +18,27 @@ BSC here proposes to combine DPoS and PoA for consensus, so that:
 2. Validators take turns to produce blocks in a PoA manner, similar to [Ethereum's Clique](https://eips.ethereum.org/EIPS/eip-225) consensus design
 3. Validator set are elected in and out based on a staking based governance
 
-Fast finalization can greatly improve user experience. The `Fast Finality` feature will be enabled upon the coming Plato upgrade. This will be a major advantage of BSC, and many dapps will benefit from it.
-
 The consensus protocol of BSC fulfills the following goals:
 1. Short Blocking time, 3 seconds on mainnet.
-2. It requires quite short time to confirm the finality of transactions, around 6s for mainnet after the coming Plato upgrade.
+2. It requires quite short time to confirm the finality of transactions, around 6s for mainnet.
 3. There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB.
-4. It is 100% compatible with Ethereum system .
+4. It is 100% compatible with Ethereum system.
 5. It allows modern proof-of-stake blockchain network governance.
 
+The implement of the consensus engine is named as Parlia.
+
+In addtion, Feyman hardfork has been enabled on BSC mainnet. The BNB Beacon related logic will be totally dropped in a few months, so it will be ignored in the following doc.
+
 ## Validator Quorum
-In the genesis stage, a few trusted nodes will run as the initial Validator Set. After the blocking starts, anyone can compete to join as candidates to elect as a validator. The staking status decides the top 32 most staked nodes to be the next validator set, and such an election will repeat every 24 hours.
+In the genesis stage, a few trusted nodes will run as the initial Validator Set. After the blocking starts, anyone can compete to join as candidates to elect as a validator. The staking status decides the top 45 most staked nodes to be the next validator set, and such an election will repeat every 24 hours.
 
 BNB is the token used to stake for BSC.
 
-In order to remain as compatible as Ethereum and upgradeable to future consensus protocols to be developed, BSC chooses to rely on the BC for staking management. There is a dedicated staking module for BSC on BC. It will accept BSC staking from BNB holders and calculate the highest staked node set. Upon every UTC midnight, BC will issue a verifiable **ValidatorSetUpdate** cross-chain message to notify BSC to update its validator set.
+Upon a new validator set elected, validators will update the validator set after an **epoch period**, i.e. a predefined number of blocking time. For example, if BSC produces a block every 3 seconds, and the epoch period is 200 blocks, then the current validator set will check and update the validator set for the next epoch in 600 seconds (10 minutes). 21 validators will be selected from the validator set to produce blocks every epoch.
 
-While producing further blocks, the existing BSC validators check whether there is a **ValidatorSetUpdate** message relayed onto BSC periodically. If there is, they will update the validator set after an **epoch period**, i.e. a predefined number of blocking time. For example, if BSC produces a block every 5 seconds, and the epoch period is 240 blocks, then the current validator set will check and update the validator set for the next epoch in 1200 seconds (20 minutes).
+## Differences with clique
 
-## Parlia
-
-The implement of the consensus engine is named as **Parlia** which is similar to [clique](https://ethereum-magicians.org/t/eip-225-clique-proof-of-authority-consensus-protocol/1853). This doc will focus more on the difference and ignore the common details.
+**Parlia** is similar to [clique](https://ethereum-magicians.org/t/eip-225-clique-proof-of-authority-consensus-protocol/1853). This doc will focus more on the difference and ignore the common details.
 
 ### Light Client Security
 Validators set changes take place at the (epoch+N/2) blocks. (N is the size of validatorset before epoch block). Considering the security of light client, we delay N/2 block to let validatorSet change take place.
@@ -53,15 +53,14 @@ The consensus engine may invoke system contracts, such transactions are called s
 In Clique consensus protocol, out-of-turn validators have to wait a randomized amount of time before sealing the block. It is implemented in the client-side node software and works with the assumption that validators would run the canonical version.
 However, given that validators would be economically incentivized to seal blocks as soon as possible, it would be possible that the validators would run a modified version of the node software to ignore such a delay. To prevent validator rushing to seal a block, every out-turn validator will get a specified time slot to seal the block. Any block with a earlier blocking time produced by an out-turn validator will be discarded by other witness node.
 
-### Extending the ruling of the current validator set via temporary censorship
-If the transaction that updates the validator is sent to the BSC right on the epoch period, then it is possible for the in-turn validator to censor the transaction and not change the set of validators for that epoch. While a transaction cannot be forever censored without the help of other n/2 validators, by this it can extend the time of the current validator set and gain some rewards. In general, the probability of this scheme can increase by colluding with other validators. It is relatively benign issue that a block may be approximately 3 secs and one epoch being 200 blocks, i.e. 20 mins so the validators could only be extended for another 10 mins.
-
-## Security
+## Liveness and Security
 Given there are more than ½\*N+1 validators are honest, PoA based networks usually work securely and properly. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the [Clone Attack](https://arxiv.org/pdf/1902.10244.pdf). BSC does introduce Slashing logic to penalize Byzantine validators for double signing or inavailability. This Slashing logic will expose the malicious validators in a very short time and make the "Clone Attack" very hard or extremely non-beneficial to execute.
 
 ## Fast Finality
+The `Fast Finality` is a major advantage of Parlia.
+
 Finality is critical for blockchain security, once the block is finalized, it wouldn’t be reverted anymore. The fast finality feature is very useful, the users can make sure they get the accurate information from the latest finalized block, then they can decide what to do next instantly. More details of design, please to refer [BEP-126](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP126.md)
 
-Before the coming Plato upgrade,to secure as much as BC, BSC users are encouraged to wait until receiving blocks sealed by more than ⅔*N+1 different validators. In that way, the BSC can be trusted at a similar security level to BC and can tolerate less than ⅓\*N Byzantine validators.With 21 validators, if the block time is 3 seconds, the ⅔\*N+1 different validator seals will need a time period of (⅔\*21+1)\*3 = 45 seconds. Any critical applications for BSC may have to wait for ⅔\*N+1 to ensure a relatively secure finality. With above enhancement by slashing mechanism, ½\*N+1 or even fewer blocks are enough as confirmation for most transactions.
+Without Fast Finality, BSC users are encouraged to wait until receiving blocks sealed by more than ⅔*N+1 different validators. With 21 validators, if the block time is 3 seconds, the ⅔\*N+1 different validator seals will need a time period of (⅔\*21+1)\*3 = 45 seconds.
 
-After the coming Plato upgrade, the feature `Fast Finality` will be enabled. The chain will be finalized within two blocks if ⅔*N or more validators vote normally, otherwise the chain has a fixed number of blocks to reach probabilistic finality as before.
+After Fast Finality applied, the chain will be finalized within two blocks if ⅔*N or more validators vote normally.