The election mechanism of XKN Ledger is embodied in:
- Anyone can initiate a transaction to apply for being a validator candidate (as long as they are willing to pay for the system fee);
- Anyone who holds the XKN token can vote to decide which validator candidate can become a consensus node and the number of consensus nodes at anytime.
The votes of consensus nodes are calculated by an algorithm described in this chapter. And voting is a dynamic and continuous process. If the XKN asset of a voter is changed (e.g. the XKN is transferred to another address), the number of votes at the previous voting address will also change, and the list of consensus nodes will change accordingly.
At the same time, each block contains Validator Candidates information, which locks the name list of consensus nodes for next block. That is to say, the current transaction determines the consensus nodes in the next block.
From Candidate to Validator
There are 2 steps in voting for consensus nodes:
- calculate the number of consensus nodes;
- determine the specific consensus nodes.
The number of consensus nodes
According to the voting described above, we may get a diagram of votes for the number of consensus nodes.
The following formula is to demonstrate the probability distribution function F(discrete function), in which the probability of the
i th consensus node equals its proportion of votes.
On the probability distribution function, take the portion F ∈ [0.25, 0.75] that covers consensus nodes. Then take the expected value for these points. Compare it with the count of backup validators. Take the larger one as the final number of consensus nodes.
⌈A⌉represents the first Fi>= 0.25 point
⌈B⌉represents the first Fi>= 0.75 point
- min(0.75, Fi) – max( Fi – 1, 0.25 ) is the shadow part
StandbyValidatorsis standby validators
We only consider the middle part in the voting diagram, filter out too large or too small points which may have great impact on the average value.
In the above steps, we calculate the number of consensus nodes as
Count , and take validators from the candidate list ranked by votes in descending order. When candidates is not enough, it will be supplemented from
StandbyValidators . Finally, the consensus nodes are determined.
Genesis Block is the first block, its
NextConsensusis set to the script hash of standby consensus nodes’ multi-signature contract.
From Delegate to Speaker
A speaker is a consensus node who creates the next proposal block. The list of consensus nodes is obtained by the method above, and the speaker is determined by the formula
p = (h - v) mod N in the dBFT algorithm.
h is the height of the proposal block.
v is view number, start from 0.
N is the number of consensus nodes.
During the consensus phase, a speaker will send
PrepareRequest message with
NextConsensus , which determines the next block consensus nodes. The Speaker calculates the next round of consensus nodes by combining the transactions in the proposal block with the previous votes in blockchain, and assign the script hash of 2/3 multi-signature contract to
NextConsensus . There are transactions that may affect the number of votes. Firstly, there may be a
StateTransaction to change vote directly. Secondly, there may be a transfer change in voter’s XKN assets.