Installation and usage of the platform

General platform configuration: consensus algorithm

The Waves Enterprise blockchain platform supports three consensus algorithms – PoS, PoA and CFT. Detailed information about the consensus algorithms used can be found in the Consensus algorithms article.

The consensus settings are located in the consensus block of the blockchain section:

consensus {
   type = ""
   ...
}

Select the preferred consensus type in the type field. Available values: pos, poa, and cft.

type = "pos" or the commented consensus block

If you do not select a consensus type in this field, leaving it blank, the default PoS algorithm will be used. This option is equivalent to selecting the pos value. In this case, other fields in the consensus block are not required, you only need to configure the PoS mining operation in the genesis block:

consensus {
   type = "pos"
}

...

genesis {
    average-block-delay = "60s"
    initial-base-target = 153722867
    initial-balance = "16250000 WEST"

    ...
}

Note

When you use the PoS algorithm (consensus.type = pos) and some other fields’ values are specified in the consensus section, they are ignored. For example

consensus {
   type = "pos"
   round-duration = 5500ms
}

The round-duration field value will not be taken into account.

The following parameters of the genesis block in the blockchain section are responsible for mining with PoS:

  • average-block-delay – average block creation delay. The default value is 60 seconds.

  • initial-base-target – the initial base number to regulate the mining process. The higher the value, the more often the blocks are created. Also, the value of the miner balance affects the use of this parameter in mining – the higher the balance of the miner, the lower the value of initial-base-target becomes when calculating the queue of node-miner in the current round.

  • initial-balance – the initial balance of the network. The greater the share of the miner’s balance from the initial balance of the network, the smaller the value of initial-base-target becomes for determining the miner node of the current round.

type = "poa"

To configure the PoA consensus algorithm, add the following parameters to the consensus block:

consensus {
   type = "poa"
   round-duration = "17s"
   sync-duration = "3s"
   ban-duration-blocks = 100
   warnings-for-ban = 3
   max-bans-percentage = 40
}

  • round-duration – length of the block mining round in seconds.

  • sync-duration – the block mining synchronization period in seconds. The total round time is the sum of round-duration and sync-duration.

  • ban-duration-blocks – the number of blocks for which the miner node is banned.

  • warnings-for-ban – the number of rounds during which the miner node receives warnings. At the end of this number of rounds, the node is banned.

  • max-bans-percentage – percentage of miner node from the total number of nodes in the network that can be banned.

type = "cft"

The basic settings of the CFT consensus algorithm are identical to those of the PoA consensus algorithm:

consensus {
   type: cft
   warnings-for-ban: 3
   ban-duration-blocks: 15
   max-bans-percentage: 33
   round-duration: 7s
   sync-duration: 2s
   max-validators: 7
   finalization-timeout: 4s
   full-vote-set-timeout: 4s
}

In comparison with the PoA, the CFT has the following additional configuration parameters needed to validate blocks in a voting round:

  • max-validators – limit of validators participating in a current round.

  • finalization-timeout – time period, during which a miner waits for finalization of the last block in a blockchain. After that time, the miner will return the transactions back to the UTX pool and start mining the round again.

  • full-vote-set-timeout – optional parameter which defines, how much time a miner will wait for the full set of votes from all validators after the end of the round (node configuration file parameter: round-duration).

While configuring CFT, please note the following recommendations:

  • The sync-duration parameter must be different from zero. It is recommended to set the value from 1 to 5 seconds, depending on the size and complexity of transactions.

  • Approximate calculation of the finalization-timeout parameter: (round-duration + sync-duration) / 2. It is not recommended to underestimate this value to speed up finalization: if the miner gathers the necessary number of votes before the end of this time, it will immediately release the finalizing microblock.

  • If there is a large number of miners in the network, limit the number of round validators by the max-validators parameter. The validator selection mechanism will ensure that all validators rotate evenly across rounds. Too many validators can adversely affect network performance. The recommended range of values is: from 5 to 10.

  • If the network is running under constant load, set the full-vote-set-timeout parameter. Until this timeout expires, the miner waits for a full set of votes from the validators. If the validator encounters any problem, the network uses the full-vote-set-timeout to create an additional time slot that allows the lagging validator to complete synchronization. The recommended value is sync-duration * 2, it should not exceed sync-duration + finalization-timeout.

See also