Proof of Authority Consensus Algorithm¶
In a private blockchain tokens are not always needed - for example, a blockchain can be used to store hashes of documents exchanged by organizations. In this case, in the absence of tokens and fees from transactions, a solution based on the PoS consensus algorithm is redundant. The Waves Enterprise platform gives a possibility to choose the Proof of Authority consensus algorithm. The mining permission is issued centrally in the PoA algorithm. Compared to the PoS algorithm this simplifies the decision-making. The Proof of Authority model is based on a limited number of block validators, which is making it a scalable system. Blocks and transactions are verified by pre-approved participants who act as moderators of the system.
Algorithm description¶
An algorithm determining the miner of the current block is formed based on the described below parameters. The parameters of the consensus are specified in the consensus
block of the node configuration file.
t - duration of a round in seconds (the parameter of the node configuration file: round-duration).
ts - duration of a synchronization period, calculated as t*0.1, but not more than 30 seconds (the parameter of the node configuration file: sync-duration).
Nban - a number of missed consecutive rounds for issuing the ban for the miner (the parameter of the node configuration file: warnings-for-ban);
Pban - a share of the maximum number of banned miners, in percentage from 0 to 100 (the parameter of the node configuration file: max-bans-percentage);
tban - duration of miner ban in blocks (the parameter of the node configuration file: ban-duration-blocks).
T0 - unix time for generation of Genesis block.
TH - unix time for generation of H Block - a key block for NG.
r - round number, calculated as (TCurrent -T0 ) div (t+ ts ).
Ar - leader of round r, which has the right to create key blocks and microblocks for NG in round r.
H - height of the chain in which the key block and microblocks for NG are created. The leader of round Ar has the right to generate a block at height H.
MH - miner issuing block at height H.
QH - queue of miners active at height H.
The QH queue is generated using addresses which are given the mining permission by a permission transaction which was not revoked until height H, and did not expire until the time TH .
The queue is sorted by the time stamp of the mining rights transaction - the node which was granted the rights earlier will be higher in the queue. For a consistent network, this queue will be the same on each node.
A new block is created at each round r. A round lasts t seconds. After each round, ts seconds count down to complete data synchronization in the network. During the synchronization period, microblocks and key blocks are not generated. For each round there is a single leader Ar , which has the right to create a block in this round. A leader can be defined on each node of the network with the same result. The leader of the round is defined as follows:
Miner MH-1 is defined, which created the previous key block at height H-1.
The QH queue of active miners is calculated.
Inactive miners are excluded from the queue (see more in Exclusion of inactive miners).
If the H-1 block miner (MH-1 ) is in the QH queue, the following miner becomes the leader A r .
If the H-1 block miner (M H-1 ) is not in the Q H queue the miner following the H-2 block miner (M H-2 ) becomes the leader A r and so on.
If no miners of blocks (H-1..1) are in the queue, the first miner in the queue becomes the leader.
This algorithm allows to identify and check deterministically the miner, which had to create each block of the chain by means of the ability to calculate the list of authorized miners for each moment of time. If the block was not created by the designated leader within the allotted time, no blocks are generated within the current round, and the round is skipped. Leaders who skip block generation are temporarily excluded from the queue by the algorithm described in paragraph Exclusion of inactive miners.
Valid is the block generated by the leader Ar with the time of block TH from the half-interval (T0 +(r-1)*(t+ts ); T0 +(r-1)*(t+ts )+t]. The block created by the miner out of its turn or not in time, is not considered valid. After a round of t duration, the network synchronizes the data for ts . The leader Ar has time ts to propagate the validation block over the network. If any node of the network during ts has not received a block from the leader Ar , this node recognizes the round as “skipped” and expects a new H block in the next round r+1, from the following leader Ar+1 .
Consensus parameters: type (PoS or PoA), t, t sare specified in the configuration file of the host network. The parameter T should be the same for all network participants, otherwise the network will fork.
Synchronization of time between network hosts¶
Each host should synchronize the application time with a trusted NTP server at the beginning of each round. The server address and port are specified in the node configuration file. The server must be available to each network node.
Exclusion of inactive miners¶
If any miner has missed the block creation Nban times in a row, this miner is excluded from the queue at tban subsequent blocks (ban-duration-blocks
parameter in the configuration file). The exception is made by each node on its own based on the calculated queue QH and information about block H and miner MH . The Pban parameter specifies the maximum allowable share of excluded miners in the network relative to all active miners at any given time. If at achievement of Nban round passes it is known that the maximum share of the excluded miners Pban is reached, the exception of the next miner is not made.
Monitoring¶
The PoA consensus monitoring helps to identify the facts of creation and distribution of non-valid blocks, as well as skipping queue by the miners. Further troubleshooting and blocking of malicious nodes are performed by network administrators.
In order to monitor the process of generation of blocks for the PoA algorithm the following details are entered in InfluxDB:
Active list of miners sorted in order of granting mining rights.
Scheduled round timestamp.
Actual round timestamp.
Current miner.
Changing consensus settings¶
Changing consensus parameters (time of round and synchronization period) is performed on the basis of the node configuration file (see the insert) at the height “from-height”. If one of the nodes fails to specify new parameters, the transaction will fork.
Sample configuration:
// specifying inside of the blockchain parameter consensus { type = poa sync-duration = 10s round-duration = 60s ban-duration-blocks = 100 changes = [ { from-height = 18345 sync-duration = 5s round-duration = 60s }, { from-height = 25000 sync-duration = 10s round-duration = 30s }] }