Validator FAQ
This content is not yet presented under its final version. Mechanisms and values are susceptible to change.
General concepts
What is a validator?
The OKTC is based on Tendermint, which relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator’s 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’s staking?
The OKTC blockchain utilises a public Proof-Of-Stake (PoS) mechanism. The weight of each validator is determined by the amount of tokens staked (OKT) and bonded as collateral. These OKTs can be self-delegated directly by the validator or delegated to them by other OKT holders.
Any user in the system can declare their intention to become a validator by sending a create-validator transaction. From there, they can become validator candidates.
The weight (i.e. voting power) of a validator determines whether or not they are active validators. Initially, only the top 21 validators with the largest voting power will be active validators.
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-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node 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 no downtime.
Of course, it is possible and encouraged for users to run full-nodes even if they do not plan to become validators.
Becoming a validator
How to become a validator?
Any participant in the network can signal their willingness to become a validator by sending a create-validator transaction, where they must fill out the following parameters:
- Validator’s
PubKey: The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.
- Validator’s Address: Application level address. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance.
- Validator’s name (moniker)
- Validator’s website (Optional)
- Validator’s description (Optional)
Once a validator is created, OKT holders can delegate OKTs to them, effectively adding stake to their pool. The total stake of an address is the combination of OKTs bonded by delegators and OKTs self-bonded by the entity that designated themselves.
Out of all validator candidates that signaled themselves, the 21 with the highest stake are the ones who are designated as validators. If a validator’s total stake falls below the top 21 then that validator loses the validator privileges: therefore they can’t participate in consensus and generate rewards any more.
Testnet
How can I join the testnet?
The testnet is a great environment to test your validator setup before launch.
We view testnet participation as a great way to signal to the community that you are ready and able to operate a validator. You can find all relevant information about the testnet here and here.
What are the different types of keys?
In short, there are two types of keys:
- Tendermint Key: This is a unique key used to sign consensus votes.
- It is associated with a public key
okchainvalconspub (Get this value with exchaind tendermint show-validator)
- It is generated when the node is created with exchaind init.
- Application key: This key is created from
exchaincli and used to sign transactions. Application keys are associated with a public key prefixed by okchainpub and an address prefixed by oktc. Both are derived from account keys generated by exchaincli keys add.
Note: A validator’s operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: okchainvaloper and okchainvaloperpub.
What are the different states a validator can be in?
After a validator is created with a create-validator transaction, they can be in three states:
- bonded: The validator is active and participates in the consensus. The validator is earning rewards and can potentially be slashed in case of misbehaviour.
- jailed: The validator misbehaved and is in jail, i.e. suspended. If the jailing is caused by having been offline for too long, the validator can send an
unjail transaction in order to re-obtain his validator full rights. If the jailing is due to a double signing, the validator cannot unjail himself.
- unbonded: The validator is not active, and therefore cannot sign blocks. Validator cannot be slashed, and does not earn any reward. It is still possible to delegate OKTs to this validator. Un-delegating from an
unbonded validator is immediate.
Is there a minimum amount of okts that must be delegated to become an active (bonded) validator?
The minimum is 10000 okt.
How will delegators choose their validators?
Delegators are free to choose validators according to their own subjective criteria. Some of the criterias we consider significant are:
- Amount of delegated OKTs: Total number of OKTs delegated to a validator. A high voting power shows that the community trusts this validator, but it also means that this validator may be a bigger target for hackers. Bigger validators also decrease the decentralisation of the network.
- 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 may have been compromised.
Apart from these criteria, there will be a possibility for validators to add a website address to complete and enhance their resume. Validators will need to build reputation one way or another in order 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 OKTC team will not approve or conduct any audit themselves. For more on due diligence, see this blog post.
Responsibilities
Do validators need to be publicly identified?
No, they do not. Each delegator will value validators based on their own criteria. Validators will be able 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 operating the validator and their resume, while others might prefer anonymous validators with positive track records.
What are the responsibilities of a validator?
Validators have two 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.
- Actively participate in governance: Validators are required to vote on every proposal.
Additionally, validators are expected to be active members of the community. They should always remain up-to-date with the current state of the ecosystem so that they can easily adapt to any change.
What does ‘participate in governance’ entail?
Validators and delegators on the OKTC can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, or make a decision on any given matter.
Validators play a special role in the governance system. hey are for instance required to vote on every proposal which is especially important since delegators who do not vote will inherit the vote of their validator.
What does staking imply?
Staking OKTs 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, OKTs undergo a 2 weeks unbonding period during which they are liable to being slashed for potential misbehaviors committed by the validator before the unbonding process started.
Validators, and by association delegators, receive block rewards, fees, and have the right to participate in governance.
Can a validator run away with their delegators’ OKTs?
By delegating to a validator, a user delegates voting power. The more voting power a validator has, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators’ OKTs. 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.
How often will a validator be chosen to propose the next block? Does it go up with the quantity of bonded OKTs?
The validator that is selected to propose the next block is called proposer. Each proposer is selected deterministically, and the frequency of being chosen is proportional to the voting power (i.e. amount of bonded OKTs) of the validator. For example, if the total bonded stake across all validators is 100 OKTs and a validator’s total stake is 10 OKTs, then this validator will propose ~10% of the blocks.
Incentives
For more information on incentives, see Staking Rewards Algorithm.
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 a OKTC node, validators should develop monitoring, alerting and management solutions.
What are bandwidth requirements?
The OKTC network has the capacity for very high throughput compared to Ethereum or Bitcoin.
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 heavily used, multi-gigabyte per day bandwidth is very realistic.
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 nShield support
The OKTC 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, 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 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 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 that part of validators will completely mitigate these threats.
For more on sentry node architecture, see this.
