FAQ
Some validator frequently asked questions
What is a Vince Chain validator?
Vince Chain runs on top of the CometBFT consensus engine—a fork of Tendermint Core. Validators are responsible for committing new blocks on Vince Chain to enable it to run successfully. Before validators can successfully commit new blocks, they must participate in the consensus protocol by broadcasting votes containing cryptographic signatures signed by the respective validators using their private keys.
What is staking?
Vince Chain, being a Proof-of-Stake (PoS) blockchain, relies on staking to maintain the integrity and liquidity flow in the blockchain. Users can delegate validators (100 max.) through staking. The voting power of the validator is determined by the number of tokens staked. Also, the rewards from the staked token depend on the amount staked. The validator can bond tokens directly or indirectly through delegators who hold VCE.
Who can become a validator on Vince Chain?
Anyone can become a validator on Vince Chain provided you meet the requirement which includes having VCE, running nodes with the standard hardware/device, etc. You can declare your intention to the network by sending a create-validator transaction. From there, you may become a validator.
Becoming a validator is competitive and comes with responsibility and sacrifice. To stand a chance, it is recommended you have at least 1,000,000 VCE to improve your weight or voting power and successfully run nodes if you succeed. Also, operating outside the network's code of conduct could attract penalties, including "jail" and token (VCE) slashing.
What is a full node?
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.
Anyone can run a full node without being a validator.
Who is a delegator?
A delegator is a VCE holder who may not wish to run validator nodes or operations themselves. Delegators delegate their resources to a validator to run validator operations on their behalf, and in return, earn a portion of the revenue from transaction fees.
Delegators are crucial to the success of the network and are responsible for choosing its validators. They are the watchdogs and form the governance members and community behind the network. Meanwhile, being a delegator is not a passive role.
There are pros and cons to becoming a delegator. You share the responsibility of the validator as a delegator. Should the validator misbehave, the penalty will be shared between you and the validator, the same way the revenue will be shared between both parties. That is why we recommend due diligence when choosing a validator. You may also want to diversify validators to be on the safer side.
How to become a validator?
Before you can be approved as a validator, you must follow the due process, which involves registering a validator profile. The candidate must broadcast a create-validator transaction, in which they must submit the following information:
Validator's Public Key. A validator can have different accounts for validating and holding liquid funds. However, the public keys must have a principal private key with which the validator can sign prevotes and precommits.
Validator's Address. The
vincechainvaloper1- address. This is the address used to identify a validator publicly. The private key associated with this address is used to bond, unbond, and claim rewards.Validator's name. Also called the
monikerValidator's website. This is optional.
Validator's description. This parameter is optional too.
Initial commission. The block provisions, block rewards, and fees charged to delegators.
Maximum commission. The maximum commission the validator can charge.
Commission change rate. The maximum daily increase of the validator commission.
Minimum self-bond amount. The minimum amount of VCE a validator must bond always. Should the validator's self-bonded stake fall below this limit, its entire staking pool will be unbonded.
Initial self-bond amount. The initial amount of VCE the validator wishes to self-bond.
The command below contains the information the validator must submit to become a validator:
DANGER! Using a test keyring backend to create your mainnet validator keys could lead to loss of funds. This makes your funds remotely accessible via the
eth_sendTransactionJSON-RPC endpoint.
VCE holders can delegate VCE to the validator once it is registered and approved, by adding stakes to its pool. The total stake of a validator is proportional to the sum of the VCE self-bonded by the validator's operator and the VCE bonded by external delegators.
Only the top 100 validators with the most stake are considered "active validators," becoming bonded validators. If ever a validator's total stake dips below the top 100, 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.
Validator keys and states
What are the different keys types?
There are primarily two types of keys:
Tendermint Key. This key is used to sign block hashes. It is associated with a public key
vincechainvalconspub. The Tendermint key is generated when the node is created with vinced init. Example:vincechainvalconspub1zcjduc3qcyj09qc03elte23zwshdx92jm6ce88fgc90rtqhjx8v0608qh5ssp0w94cApplication 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
vincechainpub-and an addressvincechain-. Both are derived from account keys generated byvinced keys.
A validator's operator key is directly linked to an application key but uses reserved prefixes solely for this purpose: vincechainvaloper and vincechainvaloperpub.
What are the different validator states?
Three states exist after a validator has been created with a create-validator transaction:
Bonded: In this state, the validator is active and participates in consensus protocols. The validator is also earning rewards and can be penalized for misbehavior.
Unbonding: This is a transition state from bonded to unbonded. In this state, the validator is not active and does not participate in consensus. The validator is also not earning rewards, but can still be penalized for misbehavior. If the validator does not send a
rebond transactionwhile in the unbonding state, it will take three weeks for the state transition to complete.Unbonded: In this state, the validator is not active, and, therefore not signing blocks. Unbonded validators cannot be penalized and do not earn any rewards from their operation. It is still possible to delegate VCE to this validator. Undelegating from an unbonded validator is immediate. Delegators have the same state as their validator.
You may not necessarily bond delegations. For instance, VCE can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid.
What is self-bond?
Self-bond refers to the amount of VCE stake a validator delegates to itself. You can increase your self-bond by delegating more VCE to your validator account.
Is there a minimum amount of VCE that must be staked to be an active (bonded) validator?
There is no minimum. The higher the stake to a delegate, the higher its chances of becoming an active validator. The top 100 validators with the highest total stake (where total stake = self-bonded stake + delegators stake) are the active validators.
How will delegators choose their 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 VCE. Number of VCE a validator self-bonded to its staking pool. A validator with a higher amount of self-bonded VCE has more skin in the game, making it more liable for its actions.
Amount of delegated VCE. Total number of VCE 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 VCE grows. Bigger validators also increase the centralization of the network.
Commission rate. The commission applied to 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 a reputation one way or another to attract delegators. For example, it would be good practice for validators to have their setup audited by third parties.
Note: The Vince Chain team will not approve or conduct any audit itself.
Do validators need to be publicly identified?
No, they don't. Delegators may have different approaches to validating the credibility of validators after due diligence. Validators may choose to register a website for their services, however, it is not compulsory to do so. That said, 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.
What are the responsibilities of a validator?
Validators have three main responsibilities:
Ability to constantly run the correct version of the software. validators need to make sure that their servers are always online and that their private keys are not compromised.
Provide feedback on the correct deployment of community pool funds. The Vince Chain protocol includes a governance system for proposals to the facilitate adoption of its currencies; validators are expected to hold budget executors to account to provide transparency and efficient use of funds.
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.
What is the reason behind staking?
You can think of staking as a safety deposit for validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, VCE undergoes a three weeks unbonding period during which they could be slashed for potential misbehaviors committed by the validator before the unbonding process starts.
Validators, 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 VCE 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' VCE?
By delegating VCE 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' VCE. 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 a case, each delegator's stake will be partially slashed in proportion to their relative stake.
How often is a validator chosen to propose the next block?
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 VCE, and a validator's total stake is 10 VCE, then this validator will be chosen 10% of the time as the proposer. To understand more about the proposer selection process, see Tendermint BFT consensus docs.
What is a staking incentive?
Each member of a validator's staking pool earns different types of revenue:
Block rewards: Native tokens of applications run by validators (e.g. VCE on Vince Chain) are inflated to produce block provisions. These provisions exist to incentivize VCE holders to bond their stake, as non-bonded VCE will be diluted over time.
Transaction fees: Vince Chain maintains a whitelist of tokens that are accepted as fee payments. The initial fee token is the Vince. This total revenue is divided among validators' staking pools according to each validator's weight. Then, within each validator's staking pool, the revenue is divided among delegators in proportion to each delegator's stake. A commission on delegators' revenue is applied by the validator before it is distributed.
What is a validator incentive?
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 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. Vince Chain enforces the parameter that each validator sets. These parameters can only be defined when initially declaring candidacy, and may only be constrained further after being declared.
How are block rewards distributed?
Block rewards (provisions) are distributed proportionally to all validators relative to their total stake (voting power). This means that even though each validator gains VCE with each provision, all validators will still maintain equal weight.
For example:
Assuming we have 10 validators with equal staking power and a commission rate of 1%. Let us also assume that the provision for a block is 1000 VCE and that each validator has 20% of self-bonded VCE. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator's pool has 100 VCE. These 100 VCE will be distributed according to each participant's stake:
Commission: 100*80%*1% = 0.8 VCE
Validator gets: 100*20% + Commission = 20.8 VCE
All delegators get: 100*80% - Commission = 79.2 VCE
Then, each delegator can claim part of the 79.2 VCE in proportion to its stake in the validator's staking pool. Note that the validator's commission is not applied to block provisions. Note that block rewards (paid in VCE) are distributed according to the same mechanism.
How are transaction fees distributed?
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.
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 in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes ⅔rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits.
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 wait 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 mitigate censorship.
Let's take a concrete example to illustrate the aforementioned concept:
In this example, there are 10 validators with equal stakes. Each of them applies a 1% commission and has 20% of self-bonded VCE. Now comes a successful block that collects a total of 1005 VCE in fees. Let's assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%.
We have to solve this simple equation to find the reward RR for each validator:
9R ~ + ~ R ~ + ~ 5%(R) ~ = ~ 1005 ~ \Left right arrow ~ R ~ = ~ 1005 ~/ ~10.05 ~ = ~ 1009R + R + 5%(R)= 1005 ⇔ R = 1005/10.05 = 100
For the proposer validator:
The pool obtains R ~ + ~ 5%(R)R + 5%(R): 105 VCE
Commission: 105 ~ ~ 80% ~ ~ 1%105 ∗ 80% ∗ 1% = 0.84 VCE
Validator's reward: 105 ~ * ~ 20% ~ + ~ Commission 105 ∗ 20% + Commission = 21.84 VCE
Delegators' rewards: 105 ~ * ~ 80% ~ - ~ Commission 105 ∗ 80% − Commission = 83.16 VCE (each delegator will be able to claim its portion of these rewards in proportion to their stake)
The pool obtains RR: 100 VCE
Commission: 100 ~ ~ 80% ~ ~ 1% 100 ∗ 80% ∗ 1% = 0.8 VCE
Validator's reward: 100 ~ * ~ 20% ~ + ~ Commission 100 ∗ 20% + Commission = 20.8 VCE
Delegators' rewards: 100 ~ * ~ 80% ~ - ~ Commission 100 ∗ 80% − Commission = 79.2 VCE (each delegator will be able to claim its portion of these rewards in proportion to their stake)
What are the slashing conditions?
If a validator misbehaves, its bonded stake, along with its delegators' stake and will be slashed. The severity of the punishment depends on the type of fault. There are 3 main faults that can result in the slashing of funds for a validator and its 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 on chain A.
Downtime: If a validator misses more than 95% of the last 10.000 blocks, they will get slashed by 0.01%.
Unavailability: If a validator's signature has not been included in the last X blocks, the validator will get slashed by a marginal amount proportional to X. If X is above a certain limit Y, then the validator will get unbonded.
Non-voting: If a validator did not vote on a proposal, its stake could receive a minor slash.
Even if a validator does not intentionally misbehave, it can still be slashed if its node crashes, loses connectivity, gets DDoSed, or if its private key is compromised.
Do validators need to self-bond VCE?
No, they do not. A validator's total stake is equal to the sum of its own self-bonded stake and of its delegated stake. This means that a validator can compensate for its low amount of self-bonded stake by attracting more delegators. This is why reputation is very important for validators.
Even though there is no obligation for validators to self-bond VCE, delegators should want their validator to have self-bonded VCE in their staking pool. In other words, validators should have skin in the game.
In order for delegators to have some guarantee about how much skin-in-the-game their validator has, the latter can signal a minimum amount of self-bonded VCE. If a validator's self-bond goes below the limit that is predefined, this validator and all of its delegators will unbond.
Can you prevent the number of stakes in the hands of a few top validators?
For now, the community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool. Vince Chain will rely on the same effect initially. In the future, other mechanisms will be deployed to smoothen this process as much as possible:
Penalty-free re-delegation: This is to allow delegators to easily switch from one validator to another, in order to reduce validator stickiness.
UI warning: Wallets can implement warnings that will be displayed to users if they want to delegate to a validator that already has a significant amount of staking power.
Technical Requirements: What are hardware requirements? Validators should expect to provide 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 a Vince Chain node, validators should develop monitoring, alerting, and management solutions.
What are bandwidth requirements?
Vince Chain 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 DoS 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.
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 n Shield support
Strangelove Horocrux
The Vince Chain 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?
Running an effective operation is the key to avoiding unexpectedly unbonding or being slashed. This includes being able to respond to attacks, and outages, as well as to maintain security and isolation in your data center.
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?
Denial-of-service (DoS) 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 disconnects 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 to 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 to 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 attack 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 the part of validators will completely mitigate these threats.
Last updated