Validator Penalties and Impact on Rewards

Validators are a new entity on the Helium Blockchain that will perform the work of the consensus group including verifying transactions and adding new blocks to the blockchain. As Validators will play an important role in the expansion, stability and success of the Helium network moving forward, it's critical that community run Validators meet the performance requirements of their role.

The consensus group is made up of Validator nodes that are rewarded with $HNT for working together to verify transactions and producing blocks.

However, if a Validator node prevents the consensus group from performing its task, for example if it provides insuffient computing resources or has a weak network connection (equally strong upstream and downstream is needed), the Validator node will incur penalties that can affect the amount of rewards earned.

Before you continue

Be sure to first review the Validator Technical Requirements

First, we'll discuss the consensus group election process and the roles penalties play during these events. Then we'll discuss how penalties are "earned" and "burned" to better understand the overall process.

The Election Process

At the end of each consensus group, an election is performed. During this election process, 25% of the Validators in the current consensus group are chosen to be ejected and replaced with non-elected Validators.

Penalties play a role in both the ejection and election processes:

25% of the Validators in the consensus group are ejected:

  • This is a probabilistic determination based on the current penalty scores of the Validators in the current consensus group.
  • Validators with higher penalty score will have a higher chance of being ejected
  • Validators with lower penalty score will have a lower chance of being ejected

The ejected 25% is replaced by available Validators:

  • This is also probabilistic, based on the current penalty scores of the Validators available to be included in the consensus group.
  • Validators with higher penalty score will have a lower chance of being elected
  • Validators with lower penalty score will have a higher chance of being elected

It's important to understand that elections are still based on probability. Merely having a high penalty will not ensure a Validator is removed from a consensus group. By contrast, having a low penalty score does not ensure that a Validator will remain in a consensus group.

info

HNT rewards are earned by Validators when they participate in Consensus Groups.

Therefore, Validators with higher penalties than their peers will be chosen less and will participate in consensus for shorter time periods. Penalties directly affect your rewards.

Upon joining the Network, Validator nodes start with a base penalty of 0.0.

Penalty Types

Now that there's a high-level description of how penalties affect the election process, let's define how penalties are assessed:

Tenure Penalty (Consensus Group Participation)

To ensure that consensus groups members are continually churned, and that no individual Validator participates for too long, penalties are added. This is not a performance based penalty and is added to all Validators that participate in a consensus group.

  • A penalty of 1.0 is added at the end of each consensus group for each Validator that participated in that group. If the Validator is not ejected from the consensus group, it will receive another 1.0 penalty at the end of the 2nd consensus group, now having a score of 2.0.
  • This penalty of 1.0 is added even if the Validator is ejected from the consensus group as it is a penalty added for participating in the ending consensus group. This penalty is called the tenure_penalty.

DKG (Distributed Key Generation) Penalty

A DKG penalty can occur if an election fails, and the Validator was part of the reason for the election to fail. This can occur throughout the dkg process or signature phase.

  • At the end of the election, all Validators vote and sign the election result. If the election fails, Validators that a majority agree did not sign the election results are penalized.
  • This penalty can be assessed for Validators in the current consensus group or Validators attempting to be elected into the consensus group.
  • This penalty can be applied once per consensus group per Validator.
  • The amount applied is a chain variable, currently set at 1.0. The variable is viewable by running miner ledger variables dkg_penalty.
info

Performance Penalty

The details of the HoneyBadgerBFT protocol used is out of scope for this document, but this can be read more about here. What's important is that there are a few different types of failures that will create performance penalties that can be applied to a Validator while in consensus:

Seen Penalties

  • This penalty can occur if a majority of other Validators in the consensus group report your Validator as not being "seen"
  • This is equivalent to the Validator being offline, not available, or not communicating with the group.
  • This penalty is applied for each occurrence, which can happen multiple times during a consensus group.
  • The amount applied per occurrence is a chain variable, currently set at 0.33. The variable is viewable by running miner ledger variables election_seen_penalty.

BBA (Byzantine Binary Agreement) Penalties

  • This penalty can occur when the Validator is seen but fails to contribute a bundle of transactions and metadata to the block.
  • Acquiring this penalty usually means the Validator is slow/underpowered, or poorly connected.
  • This may also occur if the time on your Validator is skewed vs the group time. Run ntp!
  • This penalty is applied for each occurrence, which can happen multiple times during a consensus group.
  • The amount applied per occurrence is a chain variable, currently set at 0.1. The variable is viewable by running miner ledger variables election_bba_penalty.
info

Learn more about Byzantine Agreements and their affect on Consensus

Penalty Decay

Penalties decay over time.

Each penalty, when assessed, also decays at the same rate. This decay rate is in blocks, and is stored as a chain variable. View the current decay block limit by running miner ledger variables penalty_history_limit.

Every time a penalty is assessed, it begins to decay at penalty * (1 - age/penalty_history_limit), where age is the number of blocks that have occurred since the penalty was put in place. This means that as blocks are formed, each penalty decays over time bringing a Validator back down to 0.0.

Penalty Objectives

Through these rules, the penalties help maintain the the goals of the Validator network:

  • Ensuring that poor performing Validators have a less favorable chance of being included in a consensus group
  • Ensuring that poor performing Validators have an increased chance of being ejected in an election
  • A more even distribution of rewards by increasing a Validator's chance for ejection as they participate in sequential consensus groups

Viewing Your Penalties

There are a several tools available to you to view the current penalties of your validator, all validators, or ones currently elected to the consensus group.

Viewing the Ledger

Metadata about validators, as well as current penalty data, is available in the ledger. View the ledger by running the following command:

miner ledger validators

You'll receive an output similar to this:

+--------------+--------------------------+-------+-------+----+----+-------+------+----------+-------+
|     name     |      owner_address       |last_he| stake |stat|vers|tenure_|dkg_pe|performanc|total_p|
+--------------+--------------------------+-------+-------+----+----+-------+------+----------+-------+
|keen-coral-min|1bfah9veuFkxYgaGEDKgGh9JrY| 14603 |1000000|stak| 1  | 0.00  | 0.00 |   0.00   | 0.00  |
|delightful-clo|1aSAasGu9RtEAe1Y5pVbnyfBiS|   4   |1000000|stak|1004| 3.96  | 0.00 |   0.24   | 4.20  |
|precise-licori|1auUZpo3qEfXSucsjfxzgE1miS|   5   |1000000|stak|1004| 2.78  | 0.00 |   0.17   | 2.95  |
|ripe-coconut-g|1bJQA258NXetXqvMmPG7uAJ2B1|  11   |1000000|stak|1004| 0.00  | 2.52 |   0.00   | 2.52  |
|skinny-iron-co|1at2MZk8Cdv15ApcCeLGSm3N5N|  11   |1000000|stak|1004| 2.68  | 0.00 |   0.08   | 2.76  |
|handsome-pickl|1aSAasGu9RtEAe1Y5pVbnyfBiS| 11200 |   0   |unst|1004| 0.00  | 0.00 |   0.00   | 0.00  |
+--------------+--------------------------+-------+-------+----+----+-------+------+----------+-------+
  • name Validator name. These will be cut-off if using Docker due to console width limitations.

  • owner_address Validator address

  • last_heartbeat The age, in blocks, of the last heartbeat received

  • stake Stake amount

  • status staked or unstaked

  • version Version of miner being reported from the client

  • tenure_penalty As defined above

  • dkg_penalty As defined above

  • performance_penalty This is a combination of both the Seen and BBA penalties as defined above

  • total_penalty This is the simple addition of tenure_penalty, dkg_penalty and performance_penalty

    You can get the Docker console width limitation by adding --format csv to the miner command to receive a csv formatted output that should not be cut off. This is useful for scripting output into other systems, especially combined with | grep 3word-validator-name commands to filter output:

    miner ledger validators --format csv | grep 3word-validator-name

Viewing the Current Consensus Group

Similar functionality can be found in querying the current consensus group:

miner hbbft perf

This produces the following output:

+--------------------------+---------------+----------+--------+---------+-------+
|           name           |bba_completions|seen_votes|last_bba|last_seen|penalty|
+--------------------------+---------------+----------+--------+---------+-------+
|    immense-lilac-seal    |      6/6      | 132/132  |   0    |    0    | 7.32  |
|  hidden-glass-seahorse   |      6/6      | 132/132  |   0    |    0    | 2.82  |
|   fantastic-tiger-duck   |      6/6      | 132/132  |   0    |    0    | 4.48  |
|   itchy-vermilion-pony   |      6/6      | 130/132  |   0    |    0    | 3.66  |
|      cold-mint-ant       |      6/6      | 130/132  |   0    |    0    | 0.97  |
|   tangy-umber-hedgehog   |      6/6      | 132/132  |   0    |    0    | 3.07  |
|    magic-cedar-ferret    |      6/6      | 132/132  |   0    |    0    | 3.24  |
|  future-arctic-scallop   |      6/6      | 132/132  |   0    |    0    | 2.82  |
|   macho-grey-porcupine   |      6/6      | 132/132  |   0    |    0    | 1.91  |
|    nice-navy-chipmunk    |      6/6      | 132/132  |   0    |    0    | 0.00  |
|    large-carrot-panda    |      6/6      | 132/132  |   0    |    0    | 4.66  |
|      high-taffy-dog      |      6/6      | 131/132  |   0    |    0    | 0.00  |
|    silly-slate-gecko     |      6/6      | 132/132  |   0    |    0    | 2.82  |
|      hot-syrup-lion      |      6/6      | 132/132  |   0    |    0    | 3.66  |
|     fast-wool-rhino      |      6/6      | 132/132  |   0    |    0    | 0.00  |
|    docile-black-gecko    |      6/6      | 132/132  |   0    |    0    | 1.05  |
| restless-alabaster-puma  |      6/6      | 132/132  |   0    |    0    | 3.66  |
| wobbly-tiger-nightingale |      6/6      | 132/132  |   0    |    0    | 0.97  |
|  massive-metal-mammoth   |      6/6      | 132/132  |   0    |    0    | 2.06  |
|  dizzy-lemonade-python   |      6/6      | 132/132  |   0    |    0    | 1.91  |
| petite-tangerine-raccoon |      6/6      | 132/132  |   0    |    0    | 2.86  |
|amateur-walnut-mockingbird|      6/6      | 132/132  |   0    |    0    | 2.62  |
+--------------------------+---------------+----------+--------+---------+-------+
  • name Validator name
  • bba_completions Shows a metric for BBA competions, as defined above.
  • seen_votes Shows a tally of seen votes across the consensus group, as defined above.
  • last_bba Number of recent BBA failures
  • last_seen Number of recent seen failures
  • penalty The current total_penalty as defined above