Comment on page
Validator Nodes
Currently, public blockchains primarily adopt PoW (Proof of Work) and PoS (Proof of Stake) consensus mechanisms. The consensus mechanism of PoW is achieved through successful mining by a miner, followed by other miners who similarly perform PoW computations for their blocks. PoS, on the other hand, usually adopts a BFT-style consensus mechanism, achieving consensus by relying on more than a certain number (e.g. two-thirds) of Validators to vote consistently on a block. A PoS public chain that requires consensus from validators usually prevents attacks from malicious nodes by using a built-in validator, in which the number of nodes is relatively small. For example, some public chains use 21 validator nodes and others only use 5 to 7. This is contrary to the decentralized spirit of blockchain and is easy to reach the fault point where one-third of the validators do not agree and consensus cannot be achieved.
In order to solve the problems above, Plian adopts its own unique PDBFT consensus mechanism which supports thousands of validator nodes while maintaining efficient consensus. It also enables a dynamic-join-and-exit mechanism for the validators, eliminates manual intervention, and automatically replaces the validator nodes, thus effectively maintaining the decentralization features of blockchain.
In Plian, the list of validators is not allowed to changes within an Epoch (about one month) to ensure stability. When preparing to enter the next Epoch, validators can bid to be included. This is done in a voting scheme where each validator secretly votes for their inclusion in the validator list by offering their balance as stake. As the next Epoch is entered, the validators will be rotated according to the voting results, and the next Epoch will use the new set of validators for reaching consensus. The dynamic join-and-exit process of validators is divided into three stages: participation in the sealed vote, revealing of the open vote, and determination of validator probability.
Once the Epoch reaches 75% of the total time period (the number of Epoch blocks), participation in the next round of validator voting can begin. Before voting, users prepare the following parameters: {address, public key, number of votes, Hash}
Address – the account identifier on Plian and the primary identifier of the validator
Public key – used for verification of the validator signature to ensure that messages are sent or approved by the validator. The user should save the corresponding private key and use it when signing the information.
Number of votes – The number of PI that is staked as a Validator, either delegated or self-staked. (PI is the native token of Plian).
Hash – SHA3 hash of the first three parameters.
The user keeps {address, public key, number of bets}, and sends only the hash to the Plain blockchain via vote transaction.
This stage ends when 85% of the total Epoch time period is reached. The validators collected during this period will be the competitors of the next Epoch. Only the Hash is sent out during this stage and the address, public key, and the number of votes are hidden so that other competitors will not know the voting information and maliciously raise the number of votes required.
When an Epoch reaches 85% of the total time period (the number of Epoch Blocks), the sealed vote period ends and the next round of validator voting begins.
The voting is carried out in the following manner. The user will send the address, public key, and number of votes prepared for the previous vote transaction in a reveal transaction. After receiving these parameters, the Plian network will calculate the SHA3 hash of the three parameters and compare them with the Hash sent during the sealed vote stage to determine whether they are equal. If they are equal, the validator will be included in the competition scope. If not, the validator will be excluded.
This round of voting ends when 95% of the total time period is reached. At the end of this stage, all validators who will participate in the competition for the next Epoch will be determined.
After all the validators participating in the competition are determined, the ValidatorSet for the next Epoch will be determined as follows:
- Set MinValidator, the minimum number of validators, to ensure the stability of the system; set MaxValidator, the maximum number of validators, to avoid exceeding the performance limit of the system.
- If all validators in the previous Epoch did not participate in voting, the parameters of the validators are calculated according to their original {address, public key, number of votes}, and sorted together with the new voting validators according to the number of votes.
- The resulting distribution of the number of votes by staked weight determines the probability of each validator to be selected by the VRF to be the consensus leader.