# Node Election
# Overview
TOP Network node election system is under the following principles:
- Permissionless: The nodes are permissionless, meaning Permissionless means nodescan access and exit the network freely. Nodes are also free to participate regardless of the size of their stake.
- PoS* consensus mechanism: TOP's consensus mechanism ensures that node participation is directly proportional to their stake. More your stake, more your chances of getting selected.
- Consensus nodes are randomly generated and rotated regularly to avoid network monopoly.
- The more staking made the more secure consensus.
# Stake
In most PoS structure, the only factor that determines whether a node is eligible to join the network is the minimum deposit.
TOP expands this concept into what we call Comprehensive Stake—which is represented by the the * in hpPBFT-PoS*. Comprehensive stake takes into account multiple factors to determine how likely a node is to participate in consensus. These are:
Factor#1: Deposit
All nodes in the network will require a minimum deposit. Minimum deposit can be adjusted by on-chain governance. The creation initial values are as follows:
Factor #2: Credit score
The node's contribution history is taken into account to investigate their credit or reputation. The more tasks a node completes, the higher its reputation, increasing its overall comprehensive equity. If the bandwidth or computing power of a node is low compared to the other nodes, its reputation score will decrease.
Nodes fulfilling validator and auditor roles have their own credit points. Since advance miners can serve both of these functions, they can gain credit score from both the validator and auditor functions.
When you register the miner, your default credit score will be 0.1.
The credit scores of validator nodes and auditor nodes increase with the increase of new blocks. Under normal working conditions, the top 20% of the nodes with workload will increase by 0.01 points every 24 hours, and the highest score is 1. After the node credit score reaches the highest score, it will no longer increase.
The credit score of validator node and auditor node is increased from 0.1 point to 1 point, which requires 30 days of normal work.
In order to count the reputation scores, the table periodically reports to the Beacon system the number of blocks generated by each validator node and auditor node, and Beacon uses this information to update the credit score of the node. The Beacon system must meet the following two conditions to update the node credit score:
The system will schedule a table to report the number of signed blocks every 1 clock block (10s), and the number of signed blocks for a single table must reach 16 before reporting the number of signed blocks to the Beacon system.
There are currently 256 tables. Within one penalty period (24 hours), the total number of signed blocks for 256 tables must reach 138,240 before the number of signed blocks is reported to the Beacon system.
When a node's bandwidth or computing power lags far behind other nodes or a node commits malicious acts, its credit score will drop to the lowest score of 0.1. Please refer to Slashing.
Factor #3: Numbers of Votes
Any token holder can convert their token to votes and vote for advance nodes.
The more votes advance nodes get, the better their chances of getting elected.
The advance node has no control over the votes it receives and cannot use them to vote for other nodes.
After registering as an advance node. The election determines what role it will take.
- Advance nodes are elected as auditor. The votes obtained by the node need to be greater than or equal to the actual pledged deposit of the node (here, the node deposit is calculated as TOP, not uTOP).
- The node needs to increase the corresponding votes if it wants to be elected as the above four roles when it continues to increase the deposit.
- When the votes are lower than the actual staked deposit, the advance node can only be selected as the validator.
# Node Stake Algorithm
All nodes that need to participate in consensus have node stakes which include auditor, validator, Beacon, and Beacon. Different roles correspond to different node stakes and algorithms for different roles are different.
# Auditor stake
Auditor stake is related to node deposit, the votes obtained, and the auditor credit score.
Auditor Stake= (Miner Deposit+Votes/2) * Auditor Credit Score
# Validator stake
Validator stake is related to node deposit and votes obtained.
Validator Stake=sqrt[(Miner Deposit+Votes/2) /*Validator Credit Score]
The maximum validator stake is 5,000 (can be adjusted by on-chain governance).
# Node Election
As long as they meet certain requirements, nodes fulfill specific services in TOP Network.
There are several types of nodes in the TOP Network consensus network. Node registration and sorting are handled through smart contracts (Beacon and Beacon) that are deployed on Beacon and the VRF-FTS algorithm.
# VRF-FTS Random Sorting and Leader Election
The node classification and sorting process use the VRF-FTS algorithm. Essentially, VRF generates a publicly verifiable random seed based on some input data and then feeds it back to the FTS algorithm. The FTS algorithm is weighted by the comprehensive equity of a node. A series of smart contracts on Beacon track the node's workload contribution, total margin, voting and any bad behavior. These values are calculated by Beacon to form a comprehensive equity, which is used in the weighted FTS algorithm. The higher the comprehensive equity of a node, the higher the probability of being randomly divided into shards or clusters.
VRF-FTS process also determines the leader election.
The chance of being selected as a pBFT leader is also measured by the comprehensive equity of a node.
The election block is represented by a clock block, and a clock block is generated in 10s.
# Consensus Cluster Election
A consensus cluster includes one auditor group and multiple validator groups. The elections of different clusters are independent from each other and will not be conducted simultaneously. A cluster will first conduct the auditor group election and then the validator group election. However, two validator groups under the same cluster will conduct simultaneous elections.
Election frequency and trigger: Initially, elections will be rotated every 10 minutes, and will be changed to every 3 hours through on-chain proposals. When the Beacon leader finds that clock block height has reached 7 days he initiates a cluster election.
Election consensus group: Beacon group.
Election process: first confirm the list of auditor candidate pool → confirm the number of auditor cancellations in the group → confirm the number of auditors that rotate out and rotate in → rotate the auditor according to the policy → confirm the list of validator candidate pool (the auditors in the previous step will join this candidate pool)→confirm the number of validator cancellations in the group→confirm the number of validator out and in nodes→ rotate multiple validator groups under the cluster at the same time according to the strategy (nodes of the previous group will not be rotated into the next group).
# Auditor Group Election
Candidate node pool for rotating in nodes:
Among all the advance nodes in the Beacon candidate pool contract those are not elected as active auditors or validators in the current cluster and do not serve as active auditors in other clusters, includes creation nodes.
Auditor effective stake:
The auditor stake of each node is saved in the node registration contract.
When auditor stake=0 (such as creation node), the node does not participate in sorting, and directly assigns effective stake=1;
When auditor stake＞0, the system sorts the auditor stake from large to small with 27 nodes as a segment (27 is the governance parameter on the chain). The effective stake of the auditor in the same segment is the same, and the effective stake of the node in the next segment is more than that in the previous segment. The lower 10% is rounded down (10% on-chain governance parameters), the effective stake value in the first paragraph is 100 million, and the minimum effective stake is 1. This means, An+1=max (An*90% is rounded down, 1) .
Details as follows:
A1: 100000000
A2: 90000000
A3: 81000000
A4: 79000000
……
An+1: max (An*90% is rounded down, 1)
Node rotate out strategy:
Priority will be given to nodes that are not auditors (including insufficient votes, changing node types and no longer acting as auditors) and deregistered nodes (including nodes that are actively unregister and unregistered by the system). If the number of rotate out nodes has been exceeded, a random algorithm is used to determine which nodes will be rotating out; if the above nodes do not exceed the number of nodes to be turned in this round, the remaining nodes will be rounded down from the auditor group according to "(maximum effective auditor stake in candidate pool * 100 million / effective auditor stake of current node)" for FTS, That is, the higher the auditor_stake, the lower the probability of rotating out.
Node rotate in strategy:
There are 27 nodes in a group, sorted by auditor_stake from high to low. The effective stakes of the nodes in the group are the same. FTS is performed according to the effective stake, that is, the higher the effective stake of the auditor, the greater the probability of rotation.
Number of rotation nodes:
When candidate pool has sufficient nodes and if the auditor group is not fully selected, nodes only rotate in but not rotate out; if the candidate nodes is not enough or the candidate node is enough however the auditor group is full, the number of nodes rotate in and out are the same.
# Validator Group Election
Candidate node pool for rotating in nodes:
Among all the advance nodes in the Beacon candidate pool contract those are not selected as active validators and are not active auditors in the current cluster (including nodes that have just been selected as auditors in the group for this round), and are not active validators in other clusters.
Note that also includes the advance nodes have just been rotated out of the auditor group by the FTS algorithm in this round (the advance nodes that are turned out by logging out or changing the node type are not counted). The creation nodes are also included.
Node rotate out strategy:
Nodes that are not validator type(have changed their type) and have been unregistered are rotated out preferentially. However, what happens if the number of these nodes exceeds the number of nodes that need to be rotated out in this round? In this case, the FTS algorithm will be used to determine which nodes are rotated out. If these nodes are less than the nodes that need to be rotated out in this round, the remaining nodes will be selected by FTS from the validator group according to “The highest validator stake in the candidate pool*100 million/validator stake of the current node” . That is, the smaller validator stake is, the more likely it is to be rotated out.
Node rotate in strategy:
FTS is performed on validator candidate pool nodes according to sqrt(validator_stake). Higher the validator_stake, the greater the probability of rotation.
Number of rotation nodes:
When candidate pool has sufficient nodes and if the auditor group is not fully selected, nodes only rotate in but not rotate out.
# Edge Election
Election Frequency: 1 hour
Election of block consensus group: Beacon
Election object: All edge nodes and creation nodes in Beacon candidate pool contract.
Number of rotate in nodes: All candidate edge nodes.
Number of rotate out nodes: All edge nodes that are unregistered or replaced.
# Consensus Group Leader Election
# Beacon Group Leader Election
Election frequency: transaction level.
Election block consensus group: Beacon group.
Node pool includes: all active Beacon nodes in the group.
Number of election nodes: 1.
Election rules: FTS according to Beacon stake.
# Consensus Cluster Leader Election
The leader of the N round is selected from the validator group according to the validator stake, and the leader of the N+1 round is selected from the auditor group according to the auditor's stake. The leader is selected alternately, and one leader is selected for each transaction.
The consensus group elected by the leader is a consensus group composed of the validator group where the transaction sender account is located and the superior auditor group.