Validator FAQ

If you want to run a validator on Humans.ai, consult the FAQ.

General Concepts

What is a validator?

Humans.ai is powered by CometBFT, a software solution that utilizes a network of validators to secure its operations. These validators operate full nodes and participate in the consensus process, which involves broadcasting votes that are cryptographically signed with their private key. In exchange for their efforts, validators are rewarded with revenue and play an active role in governance through voting on proposals. The weight of a validator's vote is directly proportional to their total stake in the system.

What is "staking"?

Humans.ai operates as a public Proof-of-Stake (PoS) blockchain, where the weight of a validator is determined by the number of staking tokens (HEART) they have bonded as collateral. This weight can be increased by staking additional tokens directly or by having other HEART holders delegate their tokens to the validator.

Becoming a validator is as simple as sending a create-validator transaction. Once a user sends this transaction, they become a validator and start participating in the consensus process.

The weight of a validator plays a crucial role in determining its status and roles within the system. The top 50 validators with the most weight are designated as active validators and are responsible for proposing blocks and receiving revenue. However, validators who engage in malicious behavior, such as double-signing or being frequently offline, risk having their staked tokens, including delegated HEART, "slashed" by the protocol. This penalty aims to discourage negligent or misbehavioural actions.

What is a full node?

A full node is a software program that thoroughly verifies and confirms the legitimacy of transactions and blocks on a blockchain. Unlike light client nodes, which only process a limited number of transactions and block headers, full nodes require more resources to operate. However, running a full node is a necessary step for those who wish to become validators.

While running a full node requires more resources, it is not limited to validators. Any user can run a full node, even if they do not plan to become a validator. In fact, it is encouraged for users to run full nodes to help maintain the integrity and decentralization of the blockchain.

To run a full node, it is important to have a non-compromised and up-to-date version of the software, low network latency, and minimal downtime. This ensures that the full node can effectively validate transactions and blocks without any issues.

What is a delegator?

Delegators are HEART holders who choose to delegate their stake to a validator instead of running their own validator node. By doing so, they receive a portion of the validator's revenue in exchange. However, it's important to note that delegators also share the responsibility of the validator's actions. If a validator misbehaves, the delegators will be penalized in proportion to their stake.

Therefore, it's crucial for delegators to perform due diligence on validators before delegating their stake and to diversify their stake across multiple validators to minimize their risk. Delegators play a vital role in the system by choosing validators and monitoring their actions. It's important to note that being a delegator is not a passive role, and they must remain vigilant and actively monitor their validators, ready to switch to a different validator if necessary.

Becoming a Validator

How to become a validator?

Any participant in the network can signal their intent to become a validator by creating a validator and registering its validator profile. To do so, the candidate broadcasts a create-validator transaction, which requires the following information:

• Validator's PubKey: The public key associated with the private key the validator will use to sign prevotes and precommits.
• Validator's Address: humanvaloper1- is a unique address used to identify the validator publicly. The private key associated with this address is used for bonding, unbonding, and claiming rewards.
• Validator's name (also known as the moniker)
• Validator's website (optional)
• Validator's description (optional)
• Initial commission rate: The commission rate on block provisions, block rewards, and fees charged to delegators.
• Maximum commission: The maximum commission rate that the validator is allowed to charge.
• Commission change rate: The maximum daily increase of the validator commission.
• Minimum self-bond amount: The minimum amount of HEART the validator must have bonded at all times. If the validator's self-bonded stake falls below this limit, its entire staking pool will be unbonded.
• Initial self-bond amount: The initial amount of HEART the validator wants to self-bond.

Once the create-validator transaction is broadcasted, the candidate becomes a validator and can start receiving rewards for their services. The information submitted in the create-validator transaction is publicly available and can be used by delegators to evaluate the validator's credentials and reputation.

Any participant in the network can signal their intent to become a validator by creating a validator and registering its validator profile. To do so, the candidate broadcasts a create-validator transaction, in which they must submit the following information:

humansd tx staking create-validator
--pubkey humanvalconspub1jhgdymthzk7t85n23m56e06vjcr3742hkpqsxp0s5ym24t0d42h00xlzbw6374789
--amount "1000000000000000000aheart"
--from tmp
--commission-rate="0.05"
--commission-max-rate="0.20"
--commission-max-change-rate="0.01"
--min-self-delegation "1"
--moniker "MyValidator"
--chain-id "humans_1089-1"
--gas auto
--node tcp://127.0.0.1:26647

danger

🚨 DANGER: Never create your mainnet validator keys using a test keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the eth_sendTransaction JSON-RPC endpoint.

Ref: Security Advisory: Insecurely configured geth can make funds remotely accessible

Holders of HEART can assign HEART to a validator after it has been created and registered, essentially increasing the stake in its pool. The sum of the HEART self-bonded by the validator's operator and the HEART bonded by external delegators constitutes the validator's entire stake.

Only the top 50 validators with the highest stake are regarded as "active validators" and "bonded validators", respectively. A validator enters unbonding mode and eventually becomes unbonded if its total stake ever falls below the top 50. This results in the validator losing its validator privileges (i.e., it won't generate rewards) and ceasing to be a member of the active set (i.e., participating in consensus).

Validator keys and states

What are the different types of keys?

There are two types of keys in the context of Humans.ai:

• Tendermint key: A unique key used to sign block hashes, associated with a public key humanvalconspub. This key is generated when a node is created with humansd init and can be retrieved using humansd tendermint show-validator. Example: humanvalconspub1jhgdymthzk7t85n23m56e06vjcr3742hkpqsxp0s5ym24t0d42h00xlzbw6374789
• Application key: These keys are created by the application and used to sign transactions. As a validator, you may use one key to sign staking-related transactions and another key to sign oracle-related transactions. Application keys are associated with a public key humanpub- and an address human-, both of which are derived from account keys generated by humansd keys add.

note

A validator's operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: humanvaloper and humanvaloperpub

What are the different states a validator can be in?

After a validator is created with a create-validator transaction, it can be in one of three states:

• bonded: The validator is active and participates in consensus, earning rewards and subject to slashing for misbehavior.
• unbonding: The validator is not active and does not participate in consensus. It is not earning rewards, and can still be slashed for misbehavior. This is a transition state from bonded to unbonded. If the validator does not send a rebond transaction while in unbonding mode, the state transition will take two weeks to complete.
• unbonded: The validator is not active and does not participate in consensus. It cannot be slashed, but also does not earn any rewards from its operation. It is still possible to delegate HEART to this validator, and un-delegating from an unbonded validator is immediate.

Delegators have the same state as their validator.

note

Delegations are not necessarily bonded. HEART can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid.

What is "self-bond"? How can I increase my "self-bond"?

The amount of HEART stake that the validator operator has assigned to themselves is referred to as its "self-bond". By delegating your validator more HEART, you can increase your self-bond.

Is there a testnet faucet?

Utilizing the faucet will allow you to get tokens for the testnet.

Is there a minimum amount of HEART that must be staked to be an active (bonded) validator?

No minimum exists. The active validators are the top 50 validators with the highest total stake (defined as total stake = self-bonded stake + delegators stake).

How will delegators choose their validators?

Delegators are free to select validators based on any subjective standards they please. However, the following characteristics are anticipated to be significant:

• Amount of self-bonded HEART: Number of HEART a validator self-bonded to its staking pool. A validator with higher amount of self-bonded HEART has more skin in the game, making it more liable for its actions.

• Amount of delegated HEART: Total HEART assigned to a validator as a whole. A high stake demonstrates the community's confidence in this validator but also makes it a more attractive target for hackers. With more HEART assigned to them, validators should become less and less desirable. Larger validators also cause the network to become more centralized.

• Commission rate: Prior to being given to their delegators, validators apply a commission to revenue.

• Track record: The track record of the validators they intend to delegate to will probably be examined by delegators. This provides the node's seniority, previous votes on proposals, historical uptime on average, and frequency of node compromises.

In addition to these requirements, there will be a chance for validators to indicate a website address to complete their resume. In order to draw delegators, validators will need to develop their reputation. For instance, having a third party audit the setup would be a good practice for validators. But keep in mind that the Humans.ai team won't authorize or carry out any audit themselves.

Responsibilities

Do validators need to be publicly identified?

They don't. Validators will be valued by each delegator according to their own standards. When submitting their nomination, validators will have the option (and are encouraged to) establish a website address that will allow them to promote their business as they see fit. While some delegators might favor anonymous validators with a good track record, others could prefer websites that prominently feature the team managing the validator and their resume. Most likely, the validator set will include both identified and anonymous validators.

What are the responsibilities of a validator?

Validators are primarily responsible for three things:

• Able to run a correct version of the software continuously: Validators must ensure that their servers are always online and that their private keys are secure.

• Provide oversight and input on proper community pool fund deployment: The Humans.ai protocol offers a governance structure for proposed changes to help with currency adoption. Budget executors are expected to answer to validators in order to ensure transparency and effective use of resources.

• Validators are required to be active community members: They should always be knowledgeable about the ecosystem's present condition so they can quickly respond to any changes.

What does staking imply?

Staking HEART is like to making a security deposit on validation efforts. A validator or delegator sends an unbonding transaction when they desire to withdraw all or part of their deposit. The deposit then goes through a 14 days unbonding period during which they could lose money for alleged misconduct on the part of the validator prior to the unbonding process.

Validators, and by association delegators, receive block provisions, block rewards, and fee rewards. If a validator misbehaves, a certain portion of its total stake is slashed (the severity of the penalty depends on the type of misbehavior). This means that every user that bonded HEART to this validator gets penalized in proportion to its stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.

Can a validator run away with its delegators' HEART?

By delegating to a validator, a user delegates staking power. The more staking power a validator has, the more weight it has in the consensus and processes. This does not mean that the validator has custody of its delegators' HEART. By no means can a validator run away with its delegator's funds.

Delegators are nonetheless responsible if their validators act improperly even though delegated funds cannot be stolen by their validators. In this situation, each delegate's stake will be slased in proportion to their respective stake to some extent.

How often will a validator be chosen to propose the next block? Does it go up with the quantity of HEART staked?

The proposer, the "leader" in the consensus for the round, is the validator chosen to mine the following block. Each proposer is chosen deterministically, and the likelihood of being picked is proportional to the validator's relative total stake (where total stake equals self-bonded stake + delegator stake). A validator will be selected as the proposer 10% of the time if, for instance, the total bonded stake across all validators is 100 HEART and validator's combined stake is 10 HEART.

Read more in their official docs to learn more about the Tendermint BFT consensus proposer selection procedure.

Incentives

What is the incentive to stake?

On Humans.ai, each member of a validator's staking pool can earn two types of revenue: block rewards and transaction fees.

• Block rewards:The native tokens of applications run by validators, such as HEART on Humans.ai, are inflated to produce block provisions. These provisions are designed to incentivize HEART holders to bond their stake, as non-bonded HEART will be diluted over time.
• Transaction fees: Humans.ai maintains a whitelist of tokens that are accepted as fee payment. The initial fee token is HEART. The total revenue generated from transaction fees is divided among validators' staking pools according to each validator's weight.

Within each validator's staking pool, the revenue is divided among delegators in proportion to each delegator's stake. However, a commission is applied by the validator on the delegators' revenue before it is distributed.

What is the incentive to run a validator?

Because of commissions, validators make a proportionately larger income than their delegators.

Validators are crucial to governance as well. If a delegator doesn't cast a vote, their validator casts the voteon their behalf. As a result, validators now have a significant role in the ecosystem.

What is a validator's commission?

Revenue received by a validator's pool is split between the validator and its delegators. The validator can apply a commission on the part of the revenue that goes to its delegators. This commission is set as a percentage. Each validator is free to set its initial commission, maximum daily commission change rate and maximum commission. Humans.ai enforces the parameter that each validator sets and it has to be ≥ 0.05. These parameters can only be defined when initially declaring candidacy, and may only be constrained further after being declared, but it still will not be able to be lower than 5%.

How are block provisions distributed?

Block rewards and transaction fees are allocated to validators and their delegators in a decentralized manner, ensuring that all participants are incentivized to contribute to the network's growth and security. The distribution mechanism is designed to maintain equal weight among validators, ensuring that each validator has an equal chance of receiving rewards and fees.

To illustrate, let's consider a scenario with 10 validators, all with equal staking power, and a commission rate of 5%. assume that the block provision for a particular block is 1000 HEART. Each validator will receive an equal share of the block provision, which is 100 HEART in this case. The validator's commission is not applied to the block provision.

• Commission: 100*80%*5% = 4 HEART
• Validator gets: 100\*20% + Commission = 24 HEART
• All delegators get: 100\*80% - Commission = 76 HEART

Then, in accordance with their stake in the validator's staking pool, each delegator can claim their share of the 76 HEART. Keep in mind that block provisions are not subject to the validator's commission. Keep in mind that the same technique is used to distribute block rewards, which are paid in HEART.

How are fees distributed?

Fees are distributed similarly, with an added bonus for the block proposer who includes more than the minimum required precommits in the block it proposes.

When a validator is selected to propose the next block, it must include at least ⅔ precommits for the previous block in the form of validator signatures. However, there is an incentive to include more than ⅔ precommits, as the proposer receives a linear bonus ranging from 1% for including ⅔rd precommits (the minimum for the block to be valid) to 5% for including 100% precommits. The proposer should aim to include as many signatures as possible without waiting too long, as other validators may timeout and move on to the next proposer. This mechanism encourages validators to find a balance between maximizing signatures and minimizing wait time, promoting non-empty block proposals, improved networking between validators, and mitigating censorship.

Let's use a concrete example to illustrate the concept. Assume there are 10 validators with equal stake, each applying a 5% commission and having 20% self-bonded HEART. A successful block collects a total of 1005 HEART in fees. If the proposer included 100% of the signatures in its block, it would receive the full 5% bonus.

Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block it proposes if it includes more than the strict minimum of required precommits. We have to solve this simple equation to find the reward $R$ for each validator:

$$9R ~ + ~ R ~ + ~ 5\%(R) ~ = ~ 1005 ~ \Leftrightarrow ~ R ~ = ~ 1005 ~/ ~10.05 ~ = ~ 100$$

• For the proposer validator:

    - The pool obtains $R ~ + ~ 5\%(R)$: 105 HEART
    - Commission: $105 ~ *~ 80\% ~* ~ 5\%$ = 4.2 HEART
    - Validator's reward: $105 ~ * ~ 20\% ~ + ~ Commission$ = 25.2 heart
    - Delegators' rewards: $105 ~ * ~ 80\% ~ - ~ Commission$ = 79.8 HEART (each delegator will be able to claim its portion)

(in proportion to their stake)

- The pool obtains $R$: 100 HEART
- Commission: $100 ~ *~ 80\% ~* ~ 5\%$ = 4 HEART
- Validator's reward: $100 ~ * ~ 20\% ~ + ~ Commission$ = 24 HEART
- Delegators' rewards: $100 ~ * ~ 80\% ~ - ~ Commission$ = 76 HEART (each delegator will be able to claim its portion)

(in proportion to their stake)

What are the slashing conditions?

To ensure the integrity of the network, validators who engage in misbehavior will have their bonded stake, along with their delegators' stake, slashed. The severity of the punishment depends on the type of offense. There are three primary faults that can result in the slashing of funds for a validator and its delegators:

• Double-signing: If a validator signs two blocks at the same height on different chains that share a common ancestor, they will be penalized 5.00% of their total stake.

• Downtime: Missing more than 95% of the last 5,000 blocks will result in a 0% penalty (for now, and this can be modified via governance).

• Unavailability: If a validator's signature is not included in the last X blocks, the validator will be penalized proportionally to X. If X exceeds a certain limit Y, the validator will be unbonded.

Are there any best practice guides on preventing double-signing?

Check out this page.

Do validators need to self-bond HEART?

Validators' total stake is the sum of their self-bonded stake and their delegated stake, so a validator can offset a low self-bonded stake by attracting more delegators. This highlights the importance of reputation for validators.

Although there's no requirement for validators to self-bond HEART, delegators prefer validators to have self-bonded HEART in their staking pool, or "skin-in-the-game".

To provide some assurance to delegators, validators can signal a minimum self-bonded HEART amount. If a validator's self-bond falls below the predefined limit, the validator and its delegators will unbond.

How to prevent concentration of stake in the hands of a few top validators?

The community is expected to act in a rational and self-preserving manner. In Bitcoin, when a mining pool amasses too much mining power, the community tends to redirect their contributions to other pools. Humans.ai will initially rely on this same dynamic. To further enhance this process, additional mechanisms will be implemented in the future:

• Penalty-free re-delegation: Enabling delegators to effortlessly switch between validators, reducing the stickiness of validators.
• UI warning: Wallets can display warnings to users who intend to delegate to a validator with a significant staking share, cautioning them against over-concentration.

Technical Requirements

What are hardware requirements?

The provision of one or more data center sites with redundant power, networking, firewalls, HSMs, and servers should be expected by validators.

We anticipate that initial hardware requirements will be modest, but that they may increase as network usage grows. The most effective approach to find out more is to take part in the testnet.

What are software requirements?

Validators ought to create solutions for management, monitoring, and alerting in addition to operating a Humans.ai node.

What are bandwidth requirements?

Compared to chains like Ethereum or Bitcoin, Humans.ai has a very high throughput capacity.

In light of this, we advise that the data center nodes only link up with reliable full nodes in the cloud or other validators who are acquainted socially. By doing this, the data center node is freed from the responsibility of preventing denial-of-service assaults.

In the end, as the network is used more frequently, one can realistically anticipate daily bandwidth of several terabytes.

What does running a validator imply in terms of logistics?

A validator business will require the work of multiple highly qualified workers as well as ongoing operational care. Compared to, say, running a bitcoin miner, this will need a lot more work.

How to handle key management?

Validators should expect to run an HSM that supports ed25519 keys. Here are potential options:

• YubiHSM 2
• Ledger Nano S
• Ledger BOLOS SGX enclave
• Thales nShield support
• Strangelove Horcrux
• Terndermint KMS

The Humans.ai team does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management.

What can validators expect in terms of operations?

The secret to avoiding sudden unbonding or getting slashed is to run a competent operation. This entails having the ability to respond to attacks and outages as well as to keep your data center secure and isolated.

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 Denial-of-Service attacks?

Attackers can disable a server's ability to connect to the internet by flooding it with internet traffic at a certain IP address. This is known as a denial-of-service attack.

An attacker traverses the network in an effort to identify the validator nodes' IP addresses so they can be made unreachable by flooding them with traffic.

Validators are advised to carefully design their network topology in a so-called sentry node architecture to reduce these hazards.

Only full-nodes that validator nodes trust—those that they manage themselves or that they know socially—should be connected. A data center is often where a validator node operates. Major cloud providers' networks are directly connected by the majority of data centers. These links can be used by the validator to connect to cloud-based sentry nodes. This places the responsibility for mitigating denial-of-service assaults directly on the sentry nodes of the validator, and it might be necessary to spin up or activate new sentry nodes in order to do so. Validators will entirely mitigate these dangers.

For more on sentry node architecture, see this.