What is a validator?

Areon is built on Tendermint, which relies on a set of validators to secure the network. The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures signed by their private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake.

What is staking?

The Areon is a Delegated Proof of Area (PoA) blockchain, meaning that the weight of validators is determined by the total amount of staking tokens (AREA) bonded as collateral. These AREA can be self-delegated directly by the validator or delegated to them by other AREA holders. Any user in the system can declare their intention to become a validator by sending a create validator transaction, provided they meet the minimum self-delegated amount of 100.000 AREA and maxmimum 500.000 AREA. From there, they become validator candidates. The weight (i.e. voting power) of a validator determines whether or not they are an active validator. Initially, only the top 50 validators with the most voting power will be active validators.

Incentives

What is the incentive to stake?

There are essentailly 2 different types of revenue:

• Block rewards: Native tokens of applications run by validators (e.g. AREA on Areon) are inflated to produce block provisions. These provisions exist to incentivize AREA holders to bond their stake, as non-bonded AREA will be diluted over time.
• Transaction fees: Areon maintains a whitelist of token that are accepted as fee payment. The initial fee token is the AREA.

What is the incentive to run a validator?

Validators earn proportionally more revenue than their delegators because of commissions.

Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This gives validators a major responsibility in the ecosystem.

What are validators commission?

Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate and maximum commission. Areon enforces the parameter that each validator sets.

How are blocks rewards distributed?

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains AREA with each reward, all validators will maintain equal weight over time.

Let us take an example where we have 10 validators with equal voting power and a commission rate of 1%. Let us also assume that the reward for a block is 1000 AREA and that each validator has 20% of self-bonded AREA. These tokens do not go directly to the proposer. Instead, they are evenly distributed among validators based on their total weight. So now each validator's pool has 100 AREA. These 100 AREA will be distributed according to each participant's stake:

• Commission: 100 * 80% * 1% = 0.8
• Validator gets: 100 * 20% + commission = 20.8
• All delegators get: 100 * 80% - commision = 79.2

Then, each delegator can claim their part of the 79.2 AREA in proportion to their stake in the validator's staking pool.

How are fees distributed?

Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if they include more than the minimum number of required precommits.

When a validator is selected to propose the next block, they must include at least 2/3 precommits of the previous block. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer should not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between the waiting time to get the most signatures and the risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship.

What are the jailing coniditions for validators?

As stated in delegation part, delegators can easily re-allocate their bonds from one validator to another without having to wait 10 days to unbond. However, validators go through the 10 Day Cooldown.

When a user requests to undelegate from a validator, the amount of AREA that was requested for undelegation will be locked in unbonding state for 10 days. For simplicity, we call this the 10 day cooldown. After the 10 day cooldown passes, a user will be able to make transactions with the AREA that was previously in unbonding state. This cooldown also applies to certain scenarios in redelegation.

What are the slashing condiditons?

If a validator misbehaves, their delegated stake will be partially slashed. There are currently two conditions that can result in slashing of funds for a validator and their delegators:

• Double Signing: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator will get slashed by 5% on chain A. Validators who double sign will be jailed and CANNOT be unjailed thereafter.
• Downtime: If a validator misses more than 95% of the last 10000 blocks, they will get slashed by 0.1%. Validators may unjail their validators after a 600s (10minute) window.

Technical Requirements

What are hardware requirements?

Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs and servers.

We expect that a modest level of hardware specifications will be needed initially and that they might rise as network use increases. Participating in the testnet is the best way to learn more.

What are software requirements?

In addition to running an Areon node, validators should develop monitoring, alerting and management solutions.

What are bandwidth requirements?

Areon has the capacity for very high throughput compared to chains like Ethereum or Bitcoin.

As such, we recommend that the data center nodes only connect to trusted full nodes in the cloud or other validators that know each other socially. This relieves the data center node from the burden of mitigating denial-of-service attacks.

Ultimately, as the network becomes more used, one can realistically expect daily bandwidth on the order of several gigabytes.

What does running a validator imply in terms of logistics?

A successful validator operation will require the efforts of multiple highly skilled individuals and continuous operational attention. This will be considerably more involved than running a bitcoin miner for instance.

What are the maintenance requirements?

Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. There will inevitably be issues with the network early in its bootstrapping phase that will require substantial vigilance.

How can validators protect themselves from a Denial of Service attack?

Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet.

An attacker scans the network, tries to learn the IP address of various validator nodes and disconnect them from communication by flooding them with traffic.

One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture.

Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones.

Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.

It is expected that good operating procedures on that part of validators will completely mitigate these threats.