Validator FAQ
Check the FAQ for running a validator on Bitnet.
Last updated
Check the FAQ for running a validator on Bitnet.
Last updated
General Concepts
Bitnet is powered by Core, which relies on a set of validators to secure the network. Validators 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 also participate in on-protocol treasury governance by voting on governance proposals. A validator's voting influence is weighted according to their total stake.
Bitnet is a public Proof-of-Stake (PoS) blockchain, meaning that validator's weight is determined by the amount of staking tokens (BNC) bonded as collateral. These staking tokens can be staked directly by the validator or delegated to them by BNC holders.
Any user in the system can declare its intention to become a validator by sending a create-validator transaction. From there, they become validators.
The weight (i.e., total stake or voting power) of a validator determines whether or not it is an active validator, and also how frequently this node will have to propose a block and how much revenue it will obtain. Initially, only the top 150 validators with the most weight will be active validators. If validators double-sign or are frequently offline, they risk their staked tokens (including BNC delegated by users) being "slashed" by the protocol to penalize negligence and misbehavior.
A full node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light client node that only processes block headers and a small subset of transactions. Running a full node requires more resources than a light client but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and without downtime.
Of course, it is possible and encouraged for any user to run full nodes even if they do not plan to be validators.
Delegators are BNC holders who cannot, or do not want to run validator operations themselves. Users can delegate BNC to a validator and obtain a part of its revenue in exchange (for more detail on how revenue is distributed, see What is the incentive to stake? and What is a validator's commission? sections below).
Because they share revenue with their validators, delegators also share responsibility. Should a validator misbehave, each of its delegators will be partially slashed in proportion to their stake. This is why delegators should perform due-diligence on validators before delegating, as well as diversifying by spreading their stake over multiple validators.
Delegators play a critical role in the system, as they are responsible for choosing validators. Be aware that being a delegator is not a passive role. Delegators are obligated to remain vigilant and actively monitor the actions of their validators, switching should they fail to act responsibly.
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:
Validator's PubKey: Validator operators can have different accounts for validating and holding liquid funds. The PubKey submitted must be associated with the private key with which the validator intends to sign prevotes and precommits.
Validator's Address: bitnetvaloper1- address. This is the address used to identify your validator publicly. The private key associated with this address is used to bond, unbond, and claim 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 this validator will be allowed to charge.
Commission change rate: The maximum daily increase of the validator commission.
Minimum self-bond amount: Minimum amount of BNC the validator needs to 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: Initial amount of BNC the validator wants to self-bond.
bitnetd tx staking create-validator
--pubkey bitnetvalconspub1zcjduepqs5s0vddx5m65h5ntjzwd0x8g3245rgrytpds4ds7vdtlwx06mcesmnkzly
--amount "2abitnet"
--from tmp
--commission-rate="0.20"
--commission-max-rate="1.00"
--commission-max-change-rate="0.01"
--min-self-delegation "1"
--moniker "validator"
--chain-id "bitnet_9000-4"
--gas auto
--node tcp://127.0.0.1:2664DANGER
Once a validator is created and registered, BNC holders can delegate BNC to it, effectively adding stake to its pool. The total stake of a validator is the sum of the BNC self-bonded by the validator's operator and the BNC bonded by external delegators.
Only the top 150 validators with the most stake are considered the active validators, becoming bonded validators. If ever a validator's total stake dips below the top 150, the validator loses its validator privileges (meaning that it won't generate rewards) and no longer serves as part of the active set (i.e doesn't participate in consensus), entering unbonding mode and eventually becomes unbonded
In short, there are two types of keys:
Tendermint Key: This is a unique key used to sign block hashes. It is associated with a public key bitnetvalconspub.
- Generated when the node is created with `bitnetd init`.
- Get this value with `bitnetd tendermint show-validator`e.g. bitnetvalconspub1zcjduc3qcyj09qc03elte23zwshdx92jm6ce88fgc90rtqhjx8v0608qh5ssp0w94c
Application keys: These keys are created from the application and used to sign transactions. As a validator, you will probably use one key to sign staking-related transactions, and another key to sign oracle-related transactions. Application keys are associated with a public key bitnetpub- and an address bitnet-. Both are derived from account keys generated by bitentd keys add.
DANGER
A validator's operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: bitnetvaloper and bitnetvaloperpub
After a validator is created with a create-validator transaction, it can be in three states:
bonded: Validator is in the active set and participates in consensus. Validator is earning rewards and can be slashed for misbehaviour.
unbonding: Validator is not in the active set and does not participate in consensus. Validator is not earning rewards, but can still be slashed for misbehaviour. This is a transition state from bonded to unbonded. If validator does not send a rebond transaction while in unbonding mode, it will take two weeks for the state transition to complete.
unbonded: Validator is not in the active set, and therefore not signing blocks. Unbonded validators cannot be slashed, but do not earn any rewards from their operation. It is still possible to delegate BNC to this validator. Un-delegating from an unbonded validator is immediate.
Delegators have the same state as their validator.
DANGER
Delegations are not necessarily bonded. BITNET can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid.
The validator operator's "self-bond" refers to the amount of BITNET stake delegated to itself. You can increase your self-bond by delegating more BITNET to your validator account.
There is no minimum. The top 150 validators with the highest total stake (where total stake = self-bonded stake + delegators stake) are the active validators.
Delegators are free to choose validators according to their own subjective criteria. That said, criteria anticipated to be important include:
Amount of self-bonded BNC: Number of BNC a validator self-bonded to its staking pool. A validator with higher amount of self-bonded BNC has more skin in the game, making it more liable for its actions.
Amount of delegated BNC: Total number of BNC delegated to a validator. A high stake shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Validators are expected to become less and less attractive as their amount of delegated BNC grows. Bigger validators also increase the centralization of the network.
Commission rate: Commission applied on revenue by validators before it is distributed to their delegators
Track record: Delegators will likely look at the track record of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime and how often the node was compromised.
Apart from these criteria, there will be a possibility for validators to signal a website address to complete their resume. Validators will need to build reputation one way or another to attract delegators. For example, it would be a good practice for validators to have their setup audited by third parties. Note though that the Bitnet team will not approve or conduct any audit itself.
No, they do not. Each delegator will value validators based on their own criteria. Validators will be able(and are advised) to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team running the validator and their resume, while others might prefer anonymous validators with positive track records. Most likely both identified and anonymous validators will coexist in the validator set.
Validators have three main responsibilities:
Be able to constantly run a correct version of the software: validators need to make sure that their servers are always online and their private keys are not compromised.
Provide oversight and feedback on correct deployment of community pool funds: the Bitnet protocol includes the governance system for proposals to facilitate the adoption of its currencies. Validators are expected to hold budget executors to account to provide transparency and efficient use of funds.
Additionally, validators are expected to be active members of the community. They should always be up-to-date with the current state of the ecosystem so that they can easily adapt to any change.
Staking BNC can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, the deposit undergoes a two week unbonding period during which they are liable to being slashed for potential misbehavior committed by the validator before the unbonding process started.
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 BNC to this validator gets penalized in proportion to its stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.
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' BNC. By no means can a validator run away with its delegator's funds.
Even though delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. In such case, each delegators' stake will be partially slashed in proportion to their relative stake.
The validator that is selected to mine the next block is called the proposer, the "leader" in the consensus for the round. Each proposer is selected deterministically, and the frequency of being chosen is equal to the relative total stake (where total stake = self-bonded stake + delegators stake) of the validator. For example, if the total bonded stake across all validators is 100 BNC, and a validator's total stake is 10 BNC, then this validator will be chosen 10% of the time as the proposer.
To understand more about the proposer selection process in Tendermint BFT consensus, read more in their official docs.
Never create your mainnet validator keys using a 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:
If you want to obtain coins for the testnet, you can do so by using the .