StaFi Hub Validator

StaFi Hub Validator Guides

Install

Go 1.18+ is required for building and installing the StaFiHub software.

Install go by following the official docs.

Remember to set your $GOPATH, $GOBIN, and $PATH environment variables, for example:

mkdir -p $HOME/go/bin
echo "export GOPATH=$HOME/go" >> ~/.bashrc
source ~/.bashrc
echo "export GOBIN=$GOPATH/bin" >> ~/.bashrc
source ~/.bashrc
echo "export PATH=$PATH:$GOBIN" >> ~/.bashrc
source ~/.bashrc

Verify that go has been installed successfully

go version

Install stafihubd

After setting up go correctly, you should be able to compile and run stafihubd.

Make sure that your server can access to google.com because our project depends on some libraries provided by google. (If you are not able to access google.com, you can also try to add a proxy: export GOPROXY=https://goproxy.io (opens in a new tab))

git clone https://github.com/stafihub/stafihub
cd stafihub
git checkout <version>
make install```
 
If your environment variables have set up correctly, you should not get any errors by running the above commands. Now check your `stafihubd` version.
 
```shell copy
stafihubd version
make install```
 
## Join The Mainnet
 
### Hardware Requirements
 
Minimal
- 4GB RAM
600GB SSD
2 vCPU
 
Recommended
- 8GB RAM
- 1T SSD
- 4 vCPU
 
### Installation Steps
 
Install dependencies:
 
```shell copy
cd $HOME
sudo apt update
sudo apt install make clang pkg-config libssl-dev build-essential git jq ncdu bsdmainutils -y < "/dev/null"

Install Go:

cd $HOME
wget -O go1.20.3.linux-amd64.tar.gz https://go.dev/dl/go1.20.3.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.20.3.linux-amd64.tar.gz && rm go1.20.3.linux-amd64.tar.gz
echo 'export GOROOT=/usr/local/go' >> $HOME/.bashrc
echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc
echo 'export GO111MODULE=on' >> $HOME/.bashrc
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> $HOME/.bashrc && . $HOME/.bashrc
go version

Clone git repository

git clone --branch <latest-release-tag> https://github.com/stafihub/stafihub

Install

cd $HOME/stafihub && make install

Download genesis (replace YOUR_NODE_NAME):

stafihubd init YOUR_NODE_NAME --chain-id stafihub-1
wget -O $HOME/.stafihub/config/genesis.json "https://github.com/stafihub/network/raw/main/mainnets/stafihub-1(dragonberry)/genesis.json"
stafihubd tendermint unsafe-reset-all --home ~/.stafihub

Configure your node

sed -i.bak -e "s/^minimum-gas-prices *=.*/minimum-gas-prices = \"0.01ufis\"/" $HOME/.stafihub/config/app.toml
sed -i '/\[grpc\]/{:a;n;/enabled/s/false/true/;Ta};/\[api\]/{:a;n;/enable/s/false/true/;Ta;}' $HOME/.stafihub/config/app.toml
peers="[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656"
sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$peers\"/" $HOME/.stafihub/config/config.toml

Start the node in the background

stafihubd start

Or install service to run the node

echo "[Unit]
Description=StaFiHub Node
After=network.target
 
[Service]
User=$USER
Type=simple
ExecStart=$(which stafihubd) start
Restart=on-failure
LimitNOFILE=65535
 
[Install]
WantedBy=multi-user.target" > $HOME/stafihubd.service
sudo mv $HOME/stafihubd.service /etc/systemd/system
sudo tee <<EOF >/dev/null /etc/systemd/journald.conf
Storage=persistent
EOF
sudo systemctl restart systemd-journald
sudo systemctl daemon-reload
sudo systemctl enable stafihubd
sudo systemctl restart stafihubd

Check your node logs

journalctl -u stafihubd -f

Generate keys

stafihubd keys add YOUR_WALLET_NAME --keyring-backend file

You can recover your keys with --recover flag if you have mnemonic

Explorer

Explorer available here (opens in a new tab).

Become a Validator

How to become a validator

Any participant in the network can signal that they want 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)
  • Initial commission rate: The commission rate on block rewards and fees charged to delegators.
  • Maximum commission: The maximum commission rate which this validator can charge. This parameter cannot be changed after create-validator is processed.
  • Commission max change rate: The maximum daily increase of the validator commission. This parameter cannot be changed after create-validator is processed.
  • Minimum self-delegation: Minimum amount of FIS the validator needs to have bonded at all time. If the validator's self-delegated stake falls below this limit, their entire staking pool will unbond.

Once a validator is created, FIS holders can delegate FIS to them, effectively adding stake to their pool. The total stake of an address is the combination of FIS bonded by delegators and FIS self-bonded by the entity which designated themselves.

Out of all validator candidates that signaled themselves, the 21 with the most total stake are the ones who are designated as validators. They become validators if a validator's total stake falls below the top 21 then that validator loses their validator privileges: they don't participate in consensus and generate rewards any more. Over time, the maximum number of validators may be increased via on-chain governance proposal.

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 be 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 StaFiHub 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. Being the pillars of the system, they are required to vote on every proposal. It is especially important since delegators who do not vote will inherit the vote of their validator.

What does staking imply?

Staking FIS 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, FIS undergo a 3 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. If a validator misbehaves, a certain portion of their total stake is slashed. This means that every delegator that bonded FIS to this validator gets penalized in proportion to their bonded stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.

Can a validator run away with their delegators' FIS?

By delegating to a validator, a user delegates voting power. The more voting power a validator have, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators' FIS. 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 FIS?

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 FIS) of the validator. For example, if the total bonded stake across all validators is 100 FIS and a validator's total stake is 10 FIS, then this validator will proposer ~10% of the blocks.

Will validators of the StaFiHub ever be required to validate other zones in the Cosmos ecosystem?

Yes, they will. If governance decides so, validators of the StaFiHub may be required to validate additional zones in the Cosmos ecosystem.

Incentives

What is the incentive to stake?

Each member of a validator's staking pool earns different types of revenue:

  • Block rewards: Native tokens of applications run by validators (e.g. FIS on the StaFiHub) are inflated to produce block provisions. These provisions exist to incentivize FIS holders to bond their stake, as non-bonded FIS will be diluted over time.
  • Transaction fees: The StaFiHub maintains a whitelist of token that are accepted as fee payment. The initial fee token is the FIS.

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 the incentive to run a validator ?

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 are validators commission?

Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate and maximum commission. The StaFiHub enforces the parameter that each validator sets. Only the commission rate can change after the validator is created.

How are block rewards distributed?

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains FIS with each reward, all validators will maintain equal weight over time.

Let us take an example where we have 10 validators with equal voting power and a commission rate of 1%. Let us also assume that the reward for a block is 1000 FIS and that each validator has 20% of self-bonded FIS. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator's pool has 100 FIS. These 100 FIS will be distributed according to each participant's stake:

  • Commission: 100*80%*1% = 0.8 FIS
  • Validator gets: 100\*20% + Commission = 20.8 FIS
  • All delegators get: 100\*80% - Commission = 79.2 FIS

Then, each delegator can claim their part of the 79.2 FIS in proportion to their stake in the validator's staking pool.

How are fees distributed?

Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if they include more than the strict minimum of required precommits.

When a validator is selected to propose the next block, they must include at least 2/3 precommits of the previous block. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course 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 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 to mitigate censorship.

Let's take a concrete example to illustrate the aforementioned concept. In this example, there are 10 validators with equal stake. Each of them applies a 1% commission rate and has 20% of self-delegated FIS. Now comes a successful block that collects a total of 1025.51020408 FIS in fees.

First, a 2% tax is applied. The corresponding FIS go to the reserve pool. Reserve pool's funds can be allocated through governance to fund bounties and upgrades.

  • 2% * 1025.51020408 = 20.51020408 FIS go to the reserve pool.

1005 FIS now remain. 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 R for each validator: 9R + R + R5% = 1005 ⇔ R = 1005/10.05 = 100

  • For the proposer validator:
    • The pool obtains R + R * 5%: 105 FIS
    • Commission: 105 * 80% * 1% = 0.84 Fis
    • Validator's reward: 105 * 20% + Commission = 21.84 FIS
    • Delegators' rewards: 105 * 80% - Commission = 83.16 FIS (each delegator will be able to claim its portion of these rewards in proportion to their stake)
  • For each non-proposer validator:
    • The pool obtains R: 100 FIS
    • Commission: 100 * 80% * 1% = 0.8 Fis
    • Validator's reward: 100 * 20% + Commission = 20.8 FIS
    • Delegators' rewards: 100 * 80% - Commission = 79.2 FIS (each delegator will be able to claim their portion of these rewards in proportion to their stake)

What are the slashing conditions?

If a validator misbehaves, their delegated stake will be partially slashed. There are currently two faults that can result in slashing of funds for a validator and their 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 by 5% on chain A.
  • Downtime: If a validator misses more than 95% of the last 10.000 blocks, they will get slashed by 0.01%.

Do validators need to self-delegate FIS?

Yes, they do need to self-delegate at least 1 FIS. Even though there is no obligation for validators to self-delegate more than 1 FIS, delegators should want their validator to have more self-delegated FIS 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-delegated FIS. If a validator's self-delegation goes below the limit that it predefined, this validator and all of its delegators will unbond.

How to prevent concentration of stake 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. The StaFiHub will rely on the same effect initially. Other mechanisms are in place 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 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 StaFiHub node, validators should develop monitoring, alerting and management solutions.

What are bandwidth requirements?

The Cosmos network has the capacity for very high throughput relative to chains like 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, multigigabyte 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 Tendermint 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 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 disconnect 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 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 attacked 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.

StaFi Chain NominatorEVM LSD Integration