🎆Consensus engine
Although Proof-of-Work (PoW) has been recognized as a practical mechanism for implementing decentralized networks, it is not environmentally friendly and requires a large number of participants to maintain security.
Ethereum and some other blockchain networks like MATIC Bor, TOMOChain, GoChain, xDAI do use Proof of Authority (PoA) or its variants in different scenarios, including testnets and mainnets. PoA provides some defense against 51% attacks, increased efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It can be an easy choice as a basis for selection.
At the same time, the most criticized part of the PoA protocol is that it is not as decentralized as PoW, because the validators, the nodes that take turns to generate blocks, have all permissions and are vulnerable to corruption and security attacks. Other blockchains, such as EOS and Lisk, have introduced different types of Delegated Proof-of-Stake (DPoS) to allow token holders to vote and elect validator sets. It increases decentralization and facilitates community governance.
FSC hereby proposes to combine DPoS and PoA for consensus, so that:
Validator sets are elected in and out based on stake-based governance
Validators take turns producing blocks in PoA, similar to Ethereum's Clique consensus design
Blocks are produced by a limited set of validators
FSC's consensus protocol achieves the following goals:
The block time is short, 3 seconds on the mainnet.
Confirming the finality of a transaction takes a finite amount of time, about 45 seconds on mainnet.
There is no inflation in the native token FON, and block rewards are collected from transaction fees and paid in FON.
It is 100% compatible with the Ethereum system.
It allows modern proof-of-stake blockchain network governance.
Validator Quorum
During the genesis phase, some trusted nodes will operate as the initial set of validators. After the block starts, anyone can compete to join as a candidate to elect a validator. The staking state determines the top 21 most staked nodes to be the next validator set, and such an election will repeat every 3 hours.
FON is the token used to stake FSC.
In order to maintain compatibility with Ethereum and be able to upgrade to consensus protocols to be developed in the future, these rules of FSC are all written into the Genesis Contract. There is a dedicated staking module for Dapps on FSC.
Paglia
The implementation of the consensus engine is named Parlia, similar to clique. This document will focus more on differences and ignore common details.
Light client security
Validator set changes happen at (epoch+N/2) blocks. (N is the size of the validator set before the epoch block). Considering the safety of light clients, we delay N/2 blocks for validatorSet changes.
Every epoch block, the validator will query the validator set from the contract and fill it into the extra_data field of the block header. Full nodes will validate it against the set of validators in the contract. The light client will use it as a validatorSet for the next epoch block, however, it cannot verify it according to the contract, it must trust the signer of the epoch block. If the signer of the epoch block writes the wrong extra_data, light clients may go to the wrong chain. If we delay N/2 blocks for the validatorSet to change, the wrong epoch block will not get other N/2 subsequent blocks signed by other validators, so light clients will not be vulnerable to this attack.
System transaction
The consensus engine may call the system contract, and such transactions are called system transactions. System transactions are signed by validators who produce blocks. For the witness node, a system transaction (without signature) will be generated according to its internal logic, compared with the system transaction in the block, and then applied.
Forced retreat
In the Clique consensus protocol, out-of-order validators must wait for a random amount of time before sealing a block. It is implemented in the client node software and assumes that validators will be running the canonical version. However, given that validators are economically incentivized to seal blocks as quickly as possible, validators may run modified versions of node software to ignore this delay. To prevent validators from hastily blocking blocks, each validator whose turn it is is given a specified time period to block. Any block produced by a validator with an earlier block time will be discarded by other witness nodes.
Pass interim review
If a transaction updating a validator is sent to the FSC during an epoch, then validators may review the transaction and not change the validator set for that epoch. While a transaction cannot be reviewed forever without the help of n/2 other validators, it can extend the time of the current validator set and earn some rewards. In general, the probability of this scheme can be increased by colluding with other validators. This is a relatively benign problem, a block is maybe about 3 seconds, and an epoch is 200 blocks, or 20 minutes, so validators can only extend it by another 10 minutes.
Security and Finality
Assuming more than ½ * N+1 validators are honest, PoA-based networks can generally work securely and correctly. However, under certain circumstances, a certain number of Byzantine validators may still manage to attack the network, for example through cloning attacks. To be as secure as FC, FSC users are encouraged to wait until they have received blocks sealed by more than ⅔*N+1 different validators. In this way, FSC can be trusted with a similar level of security as FC, and can tolerate fewer than ⅓ * N Byzantine validators. With 50 validators, if the block time is 3 seconds, then ⅔ * N + 1 different validator stamps will require (⅔ * 21 + 1) * time period 3 = 45 seconds. Any critical application of the FSC will likely have to wait ⅔ * N+1 for relatively safe finality. However, in addition to such arrangements, the FSC does introduce slashing logic to penalize Byzantine validators for double-signing or unavailability. This slashing logic will expose malicious validators in a very short time and make "cloning attacks" very difficult or extremely unhelpful to execute. With this enhancement, ½ * N+1 or even fewer blocks are enough for most transactions to be confirmed.
Last updated