Authenticator FAQ

Review frequently asked questions about running validators on DST.

General concepts

What is a validator?

DST is powered by [Tendermint](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html) Core, which relies on a set of validators to secure the network.

Validators run a full node and participate in consensus by broadcasting votes containing cryptographic signatures signed by their private keys. Validators submit new blocks in the blockchain and earn income in exchange for their work.

They also participate in financial governance within the protocol by voting on governance proposals. Validators' voting influence is weighted by their total stake.

What is "staking"?

DST is a public proof-of-stake (PoS) blockchain, which means validators are weighted based on the amount of Mortgage Tokens (NXN) held as collateral. These staked tokens can be directly staked by validators or delegated to them by NXN holders.

Any user in the system can declare their intent to become a validator by sending a create-validator transaction. From there, they become validators. A validator's weight (i.e. total stake or voting power) determines whether it is an active validator, and also determines how often the node proposes blocks and how much it will earn.

Initially, only the top 150 validators with the highest weight will be active validators. If validators double-sign or are often offline, they risk staked tokens (including user-delegated NXN) being “slashed” by the protocol to punish negligence and misconduct.

What is a full node?

A full node is a program that fully verifies the transactions and blocks of a blockchain. It differs from light client nodes that only process block headers and a small set of transactions. Running a full node requires more resources than a light client, but it is required to be a validator.

In practice, running a full node simply means running an uncompromised and up-to-date version of the software, with low network latency and no downtime. Of course, any user can and is encouraged to run a full node, even if they don't intend to become a validator.

What is pos commission?

Delegators are NXN holders who cannot or do not want to run validator operations themselves. . Users can delegate NXN to validators and receive a portion of their revenue in exchange (for more details on how revenue is distributed, see What is the motivation for staking? and What is Validation below? server commissions? section).

Because they share revenue with their validators, delegators also share responsibility. If a validator misbehaves, each of its delegators will be partially slashed in proportion to their stake. This is why delegators should do due diligence on validators before delegating and diversify by spreading their stake across multiple validators.

Delegators play a key role in the system as they are responsible for selecting validators. Note that being a principal is not a passive role. Delegators are obliged to be vigilant and actively monitor the behavior of their validators and switch if they fail to act responsibly.

Become a validator

How to become a validator?

Any participant in the network can indicate their intention to become a validator by creating a validator and registering their validator profile. To do this, candidates broadcast 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 liquidity.

prevotes

precommits

Validator's Address: dstvaloper1- address. This is the address used to publicly identify your validator. The private key associated with this address is used for binding, unbinding and claiming rewards.
Validator's name (also known as nickname)
Validator's website(optional)
Validator's description (optional)
Initial commission rate: Block rewards and fees charged to delegators.
Maximum commission: The maximum commission rate this validator will be allowed to charge.
Commission change rate: Maximum daily increase in validator commission.
Minimum self-bond amount: The minimum amount of NXN that the validator needs to always bond with. If a validator's self-staking stake falls below this limit, its entire staking pool will be unstaked.
Initial self-bond amount: The initial NXN amount that the validator wants to self-bond.

stcd tx staking create-validator
--pubkey dstvalconspub1zcjduepqs5s0vddx5m65h5ntjzwd0x8g3245rgrytpds4ds7vdtlwx06mcesmnkzly
--amount "2fm"
--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 "fm_9000-4"
--gas auto
--node tcp://127.0.0.1:26647

🚨 Dangerous:
DO NOT use test as the keyring backend to create your mainnet validator keys. Doing so can result in the loss of funds, as your funds can be accessed remotely via the eth_sendTransaction JSON-RPC endpoint.

Once a validator is created and registered, NXN holders can delegate NXN to it, effectively adding stake to their pool. The total pledge amount of the validator is the sum of the NXN staked by the validator operator itself and the NXN staked by the external delegator.

Only the top 150 validators holding the most stake are considered active and become Bind authenticator. If the validator's total stake falls below the top 150, the validator will lose its validator privileges (meaning it will not generate rewards) and will no longer be part of the active set (i.e. not participate in consensus), enter to unbind mode and eventually becomes Unbind.

Authenticator key and state

What are the different types of keys?

In short, there are two types of keys:

Tendermint key: This is the unique key used to sign the block hash. It is associated with the public key dstvalconspub.
- Generated when a node is created with stcd init.
- Use stcd tendermint show-validator to get this value, for example dstvalconspub1zcjduc3qcyj09qc03elte23zwshdx92jm6ce88fgc90rtqhjx8v0608qh5ssp0w94c
Application Keys: These keys are created from the application and are used to sign transactions. As a validator, you might use one key to sign staking-related transactions and another key to sign oracle-related transactions. The application key is associated with the public key dstpub- and the address dst-. Both are derived from account keys generated by stcd keys add.

⚠️Note: The validator's operator key is bound directly to the application key, but the reserved prefixes are used only for this purpose: dstvaloper and dstvaloperpub

What are the different states that a validator can be in?

Once a validator is created using the create-validator transaction, it can be in three states:

bonded: The validator is in the active set and participating in consensus. Validators are being rewarded and can be slashed for misbehavior.
unbonding: The validator is not in the active set and does not participate in the consensus.
Validators are not rewarded, but can still be slashed for misbehavior. This is the transition state from bound to unbound. If a validator does not send a rebond transaction in unbond mode, it takes two weeks to complete the state transition.
unbonded: The validator is not in the active set and therefore does not sign blocks.
Unbonded validators cannot be slashed, but do not receive any rewards for their actions. NXN can still be delegated to this validator.
Unbonding from an unbonded validator is immediate. Delegators have the same state as their validators.

⚠️Note: A delegate is not necessarily bound. NXN can be delegated and bound, delegated and unbound, delegated and unbound, or liquid.

What is a "self-mortgage"? How do I increase my "self-mortgage"?

A validator operator's self-staking refers to the amount of NXN pledged to itself. You can increase your self-staking by delegating more NXN to your validator account.

Is there a testnet faucet?

If you want to get testnet coins, you can use water-tap

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

There is no minimum. The top 150 validators with the highest total stake (where total stake = self-bonded stake + delegators stake) are active validators.

How will delegators choose their validators?

Delegators are free to choose validators based on their own subjective criteria. That said, criteria expected to be important include:

Number of self-bonded NXN: The number of NXN the validator has self-bonded to its staking pool. Validators with more self-bonded NXN have more skin in the game, making them more responsible for their actions.
Number of NXN Delegated: The total number of NXN delegated to the validator. A high stake indicates that the community trusts the validator, but also means that the validator is a bigger target for hackers. As the number of delegated NXN grows, validators are expected to become less and less attractive. Larger validators also increase the centralization of the network.
Commission Rate: The commission that validators apply to earnings before distributing them to their delegators
Track History: Delegators may view the track records of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime, and how often nodes are compromised.

In addition to these criteria, validators can also provide a website address to complete their resume. Validators need to build a reputation somehow to attract delegators. For example, it is good practice for validators to have their settings audited by a third party. Note, however, that the DST community does not self-approve or conduct any moderation.

Responsibilities

Do verifiers need to disclose their identities?

No they don't. Each delegator will evaluate validators according to their own criteria. Validators will be able to (and be advised to) register a website address when they nominate themselves so they can advertise their operations as they see fit. Some delegators may prefer a website that clearly shows the team running the validator and their bio, while others may prefer an anonymous validator with a good track record. Authenticators and anonymous verifiers will most likely co-exist in the validator set.

What is the role of a validator?

Validators have three main responsibilities:

Be able to consistently run the correct version of the software: Validators need to ensure that their servers are always online and their private keys are not compromised.
Provide oversight and feedback on the proper deployment of community pool funds: The Daodst Protocol includes a proposal governance system to facilitate the adoption of its currency. Validators are expected to hold budget implementers accountable for providing transparency and efficient use of funds.

Additionally, validators should be active members of the community. They should always be aware of the current state of the ecosystem so they can easily adapt to any changes.

What does staking mean?

Staking NXN can be regarded as a security deposit for verification activities. When a validator or delegator wants to get back some or all of their stake, they send an unbond transaction. Deposits then go through a *two-week unbonding period* during which they may be slashed for potential misconduct by validators before the unbonding process begins.

Can a validator run away with a delegator's NXN?

By delegating to a validator, a user delegates a stake. The more collateral a validator has, the more weight it has in the consensus and process. This does not mean that validators can take custody of their delegators' NXN. Verifiers must never run away with delegator funds. Even if delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. In this case, each settlor's stake will be partially cut in proportion to their relative stake.

How often will a validator be elected to propose the next block? Will it increase with the number of staked NXN

The verifier selected to mine the next block is called the proposer, which is the `leader`"` in this round of consensus. Each proposer is deterministically selected and is selected by The selected frequency is equal to the validator's relative total stake (where total stake = self-mortgaged stake + delegator's stake). For example, if the total stake of all validators is 100 NXN, and the total stake of a validator is 10 NXN, then that validator will have a 10% chance of being elected as a proposer. To learn more about the proposer selection process in the Tendermint BFT consensus, read more (https://docs.tendermint.com/master/spec/consensus/proposer-selection.html)

Incentives

What is the motivation for staking?

Each member of a validator stake pool receives a different type of income:

Block Reward: The native token of the application run by the validator (e.g. NXN on Daodst) is inflated to generate block terms. These terms exist to incentivize NXN holders to bind their stake, as unbound NXN will Diluted over time.

Transaction Fees: Daodst maintains a whitelist of tokens that are accepted as payment for fees. The initial fee token is `dst`.

This total revenue is distributed to validators' stake pools according to each validator's weight. Then, in each The validator’s staking pool revenue is distributed to delegators in proportion to each delegator’s stake. commission The delegator's income is applied by the validators before being distributed.

What is the motivation for running the validator?

Validators earn more than their delegators due to commissions. Validators also play an important role in governance. If a delegator does not vote, they will inherit their voting rights validator. This gives validators primary responsibility in the ecosystem.

What is a validator commission?

The revenue received by the validator pool is distributed between the validator and its delegators. Validators can apply A commission allocated to a portion of the principal's income. This commission is set as a percentage. Each validator is free to set its initial commission, maximum daily commission change rate, and maximum commission. Daodst enforces parameters set by each validator. These parameters can only be defined when initially declaring Candidature, and can be further restricted only if declared.

How are collective provisions assigned?

Block terms (rewards) are distributed among all validators proportional to their total stake (voting power). This means that even though each validator earns NXN per supply, all validators will remain equal weight.

Let's take an example where we have 10 validators with the same stake and 1% commission rate. let us also Suppose the supply of a block is 1000 NXN, and each validator has 20% self-mortgaged NXN. these tokens Do not go directly to the proposer. Instead, they are evenly distributed among validators. So now each validator's pool There are 100 NXNs. The 100 NXN will be distributed according to each participant's stake:

Commission: `100*80%*1% = 0.8 NXN`
Validator gets: `100\*20% + commission = 20.8 NXN`
All principals get: `100\*80% - commission = 79.2 NXN`

Each delegator can then claim a portion of the 79.2 NXN in proportion to their stake in the validator's stake pool. Note that validator commissions do not apply to block terms. Note that block rewards are distributed according to the same mechanism.

How will costs be allocated?

Fees are distributed in a similar manner, except block proposers get a block fee bonus Suggest if it contains more than the strict minimum required precommit.

When a validator is chosen to propose the next block, it must include at least ⅔ precommits of the previous block The form of the verifier's signature. However, there is an incentive to include more than ⅔ of pre-commits bonus. Rewards are linear: if a proposer includes ⅔rd precommits (the minimum for a block), the reward ranges from 1% valid) to 5%, if the proposer includes 100% pre-commit. Of course suitors can't wait too long or whatever A validator may timeout and move on to the next proposer. Therefore, validators must find a balance between The wait time for getting the most signatures and the risk of losing the proposed next block. The mechanism is designed to Incentivizes non-empty block proposals, better networking among validators, and mitigation of censorship.

Let us take a concrete example to illustrate the above concept. In this example, there are 10 validators equal interest. They charge 1% commission each and have a 20% self-insured NXN. Now comes a successful block A total of 1005 dst will be charged. Suppose the proposer includes 100% of the signatures in its proposal clogged. Get a full 5% bonus.

We have to solve this simple equation to find the reward for each validator:

$$9R ~ + ~ R ~ + ~ 5\%(R) ~ = ~ 1005 ~ \left and right arrows ~ R ~ = ~ 1005 ~/ ~10.05 ~ = ~ 100$$

For proposer validators:

Pool gets $R ~ + ~ 5\%(R)$: 105 DST
Commission: $105 ~ *~ 80\% ~* ~ 1\%$ = 0.84 DST
Validator reward: $105 ~ * ~ 20\% ~ + ~ commission = 21.84 DST
Delegator Rewards: $105 ~ * ~ 80\% ~ - ~ Commission = 83.16 DST (each delegator can claim his own portion These rewards are proportional to their stake)
Pool gets $R$: 100 DST
Commission: $100 ~ *~ 80\% ~* ~ 1\%$ = 0.8 DST
Validator reward: $100 ~ * ~ 20\% ~ + ~ commission = 20.8 DST
Delegator Rewards: $100 ~ * ~ 80\% ~ - ~ Commission = 79.2 DST (each delegator can claim his own portion These rewards are proportional to their stake)

What are the cut conditions?

If a validator misbehaves, its pledged stake and its delegator's stake will be slashed. the severity of Penalties depend on the type of error. There are 3 major bugs that could result in a validator's funds being slashed and its principals:

Double Signature: If someone on chain A reports that the validator signed two blocks at the same height on chain A and Chain B, if chain A and chain B share a common ancestor, then this validator will be slashed on chain A. punish Double sign is 10.00% of the total shares.

Downtime: If validators miss more than 50% of the last 90.000 blocks, they will be slashed by 0.50%.
Unavailability: If the validator's signature is not included in the last X blocks, the validator will get is cut by a marginal quantity proportional to X. If X is above some limit Y, the validator will unbind.

Note that even if a validator does not misbehave intentionally, it will still be slashed if its node crashes, loses Connectivity, get DDoSed, or have their private key compromised.

Do validators need to self-bind NXN?

No they don't. A validator's total stake is equal to the sum of its own collateral stake and its delegated stake. This means that validators can compensate their small self-staking stake by attracting more delegators. This is Why reputation is very important for validators.

Even though validators are not obliged to bind NXN themselves, delegators should expect their validators to have Self-bond NXN in their staking pool. In other words, validators should participate.

To give delegators some assurance about how much stake their validators have, the latter can signal Minimal amount of self-bonded NXN. If the validator's self-constraint is lower than its predefined limit, then this The validator and all its delegators will be unbound.

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

For now, the community should act in a smart and self-protective manner. When bitcoin mining pools become too The community usually stops contributing much mining power to the pool. Daodst will initially rely on the same effect. In the future, other mechanisms will be deployed to smooth this process as much as possible:

Penalty-free re-delegation: This is to allow delegators to easily switch from one validator to another so that To reduce the stickiness of the verifier.

UI warning: Wallets can implement warnings that will be shown to users if they want to delegate to a validator Already owns a substantial mortgage.

skills requirement

What are the hardware requirements?

Validators should expect redundant power, network, firewall, HSMs and servers.

We anticipate that modest hardware specifications will be required initially, and that they may increase as the network grows Use increased. Participating in the testnet is the best way to learn more.

What are the software requirements?

In addition to running Daodst nodes, validators should also develop monitoring, alerting, and management solutions.

What are the bandwidth requirements?

Daodst has very high throughput compared to chains like Ethereum or Bitcoin.

Therefore, we recommend that data center nodes only connect to trusted full nodes or other validators in the cloud Get to know each other socially. This offloads data center nodes from mitigating denial-of-service attacks.

Eventually, as the network is used more and more, one can actually expect bandwidth on the order of several gigabytes per day.

What does it mean to run a validator?

A successful validator operation will require the effort and ongoing operation of multiple highly skilled personnel attention. This is much more complicated than running a bitcoin miner, for example.

How is key management handled?

Validators should expect to run HSMs that support ed25519 keys

The Daodst team does not recommend one solution over another. Encourage the community to step up efforts to Improved security for HSMs and key management.

What can validators expect in terms of operations?

Running efficient operations is key to avoiding accidental unbundling or hacking. This includes being able to Respond to attacks, outages, and maintain data center security and isolation.

What are the maintenance requirements?

Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. inevitably there will be Problems early in the network boot phase require a high level of vigilance.

How do validators protect themselves from denial of service attacks?

A denial of service attack occurs when an attacker sends a large amount of Internet traffic to an IP address to prevent server access On an IP address connected to the Internet.

The attacker scans the network, trying to learn the IP addresses of various validator nodes and disconnect them from Communicate by flooding them with traffic.

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

Validator nodes should only connect to full nodes they trust because they operate themselves or are run by others Validators they know socially. Validator nodes typically run in data centers. Most data centers provide direct Links to the network of major cloud providers. Validators can use these links to connect to Sentinel nodes in the cloud. This shifts the burden of denial of service from the validator's node directly to its sentinel nodes, and may require new Start or activate Sentinel nodes to mitigate attacks on existing nodes.

Sentinel nodes can quickly start or change their IP address. Because the link to the Sentinel node is private IPspace, Internet-based attacks cannot directly interfere with them. This will ensure validators block proposals and votes Always let it reach the rest of the network.

It is expected that good operating procedures by this subset of validators will fully mitigate these threats.