The election mechanism of XKN Ledger is embodied in:

  1. Anyone can initiate a transaction to apply for being a validator candidate (as long as they are willing to pay for the system fee);
  2. 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:

  1. calculate the number of consensus nodes;
  2. 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
  • StandbyValidators is 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.


Consensus Nodes

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 NextConsensus is 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.


ETH: 0x8A27d371Eb6e28a7725033E3814274F7816786fA

© Krona Network 2021 Released under the MIT license.