# Proof of Authority¶

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 Blockchain Platform offers the option of a Proof of Authority (PoA) consensus algorithm. Mining permission is issued centrally in the PoA algorithm, which simplifies the decision-making compared to the PoS algorithm. The PoA model is based on a limited number of block validators, which makes it scalable. 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 parameters below. The parameters of the consensus are specified in the consensus block of the node configuration file.

• t - the duration of a round in seconds (the parameter of the node configuration file: round-duration).

• ts - the 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 - the duration of the miner ban in blocks (the parameter of the node configuration file: ban-duration-blocks).

• T0 - the unix time for generation the Genesis block.

• TH - the unix time for generation of H Block, a key block for NG.

• r - the round number, calculated as (TCurrent -T0 ) div (t+ ts ).

• Ar - the leader of round r, which has the right to create key blocks and microblocks for NG in the round r.

• H - the 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 - the miner issuing block at height H.

• QH - the queue of miners active at height H.

The QH queue is generated using addresses which are given mining permissions 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. To keep the network consistent, 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, a single leader, Ar , 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:

1. Miner MH-1 is defined, which created the previous key block at height H-1.

2. The QH queue of active miners is calculated.

3. Inactive miners are excluded from the queue (see more in Exclusion of inactive miners).

4. If the H-1 block miner (MH-1 ) is in the QH queue, the following miner becomes the leader A r .

5. 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.

6. If no miners of blocks (H-1..1) are in the queue, the first miner in the queue becomes the leader.

This algorithm identifies and checks the miner, which creates each block of the chain by calculating 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 that round, and the round is skipped. Leaders who skip block generation are temporarily excluded from the queue by the algorithm described in the paragraph Exclusion of inactive miners.

The block generated by the leader Ar with the time of the block TH from the half-interval (T0 +(r-1)*(t+ts ); T0 +(r-1)*(t+ts )+t] is determined to be valid. The block created by the miner out of its turn or not in time is considered invalid. After a round of t duration, the network synchronizes the data for ts . The leader Ar has ts seconds 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 .

Several consensus parameters — type (PoS or PoA), t, t s— are 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, which is determined by (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, 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 how non-valid blocks are created and distributed, as well as how miners skip the queue. Network administrators perform additional troubleshooting and blocking of malicious nodes.

To monitor the process of generating blocks using the PoA algorithm, the following details are entered in InfluxDB:

• Active list of miners sorted by granting of mining rights.

• Scheduled round timestamp.

• Actual round timestamp.

• Current miner.

## Changing consensus settings¶

Changing consensus parameters (time of round and synchronization period) is performed based on the node configuration file (see the insert) at the height from-height. If a node 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
}]
}