Technical description of the platform

PoA 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 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 on the basis of the parameters stated 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 maximum percentage of banned miners, 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 - unix timestamp of genesis block creation.

  • TH - unix timestamp of creation of the H block — the NG key block.

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

  • Ar - the leader of the round r, who is entitled to create key blocks and microblocks for NG in the round r.

  • H – blockchain height, at that the NG key block and microblocks are created. The Ar round leader is entitled to generate the block.

  • MH - the miner who creates a block at the H height.

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

The QH queue consists of addresses that have the miner permission. At the same time, the miner permission should not be removed from the addresses before the H height or expiry before the TH time.

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 generated during each r round. A duration of a round is t seconds. Each round is followed with ts seconds for network data synchronization. During the synchronization, microblocks and key blocks are not generated. Each round has a leader Ar , who is entitled to generate a block in this round. A leader can be defined at each network node with the same result.

The round leader is defined as follows:

  1. The miner MH-1 is defined, who has created a previous block at the H-1 height.

  2. The queue of active miners QH is calculated.

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

  4. If the miner of the H-1 (MH-1 ) block is in the QH queue, a next miner in the queue becomes the leader of the Ar round.

  5. If the miner H-1 (MH-1 ) block is not in the QH queue, the miner next to the miner of the H-2(MH-2 ) block becomes a leader of the Ar round, and so on.

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

This algorithm identifies and checks the miner, who 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 .

The consensus parameters t and ts are configured in the node configuration file. 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 misses generation of a block Nban times in a row, this miner is excluded from the queue for tban of next blocks (the ban-duration-blocks parameter in the node configuration file). Each node excludes an inactive miner on its own based on the calculated queue QH and information about the H block and the MH miner. The Pban parameter specifies the maximum percentage of excluded miners in the network in comparison with all active miners at any moment. If the Nban of misses is achieved by a miner, but at the same time the Pban is also achieved, this miner will not be excluded from the queue.


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 the timestamp of granting of mining rights.

  • Scheduled round timestamp.

  • Actual round timestamp.

  • Current miner.

Changing consensus settings

The consensus parameters (round time and synchronization period) are changed on the basis of the node configuration file at the from-height of the blockchain. If any node does not specify new parameters, the blockchain will fork.

Configuration example:

// 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