Setup a validator node on f(x)Core Testnet
Introduction
To ensure network stability, we have been running f(x)Core with the Foundation’s hosted validator nodes for almost three months. Now, we are finally opening up to the public to set up validator nodes on f(x)Core. This Hash Out will guide you through the setup on a Testnet. Mainnet setup will be exactly the same with the exception that it will only be available to the public in a month’s time. That’s enough time for you to get your feet wet by setting up on Testnet. We will be conducting a video session for Mainnet setup to ensure a seamless process, please stay tuned to our Twitter account for the exact date.
With a whole suite of products and services to be launched on the f(x)Core blockchain, I believe you are just as excited as I am in becoming one of the f(x)Core validators! We want to make the entire process really easy and seamless so we have compiled everything into this article just for you.
Here’s a breakdown of some key points from our own experience and a re-visit of some basic concepts of how block creation and consensus work. Before diving into the validator setup requirements, let’s review the roles and some important information about participating in the f(x)Core governance. We also want to stress that when participating in any decentralized project, YOU HAVE TO DO YOUR DUE DILIGENCE! It is not a risk-free activity.
Tips: You don’t need exceptionally good hardware to set up a f(x)Core validator node. You might even be able to run it from the comforts of your home if you have free 500GB of storage. And, of course, $FX is required.
Step by step setup manual
If you want to go directly into the setup manual, here are the steps to set up an f(x)Core validator. Each step has the link to the full documentation to guide you through with screenshots.
In order for you to fully setup a Testnet validator, you’ll have to go through all three steps below. You may also refer to this link for the complete setup documentation.
Step 1: Install f(x)Core .
Step 2: Setup a full Node.
Step 3: Deploy validator (Testnet).
General tips and tricks
- Even though it is system agnostic, Ubuntu 20.04 LTS would be preferred.
- While installing f(x)Core, ensure that you install GO version 1.16 or later.
- When setting up a full-node, the docker way would be the preferred choice.
- Once the node is set up and syncing, it will take a few hours so you may resume your Axie Infinity gameplay.
- When you bind your currency holding account with that of your node consensus account, ensure that you self-delegate an amount that is less than the maximum amount in your currency holding account. (FX is paid to create that transaction).
- Monitor your disk usage.
What is a validator?
The role of a validator is to run a full-node and participate in consensus by broadcasting votes. Validators commit new blocks in the blockchain and receive rewards in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake (if that is unclear, we’ll explain it later…patience my young Padawan).
What is a full-node?
A full-node is a program that fully validates transactions and blocks of a blockchain. It also maintains historical information about the state of the blockchain, unlike a light-node that only processes block headers and a small subset of transactions. Setting up a full-node is a prerequisite to becoming a validator.
What is a delegator?
Delegators are FX holders who want to participate in protocol governance, but don’t want to carry the burden of becoming a validator. In which case they can delegate FX to a validator and obtain a slice of their revenue (as well as risks). If a validator misbehaves or is dishonest, their delegators will have a portion of their delegated stake slashed. Therefore it is important to wait for it…DO YOUR DUE DILIGENCE on validators and also spread your stake across multiple validators. THIS IS NOT AS ACTIVE AS VALIDATOR BUT NEITHER IS THIS A FULLY PASSIVE ROLE!
What is validation?
f(x)Core uses a delegated Proof of Stake (DPoS) protocol. This means that anyone who owns FX can delegate some or all of their FX to a validator, resulting in the validator “gaining weight” on the network. The “heavier” the validator is, the higher the probability of being assigned as a leader for more slots, as well as earning more rewards for voting.
Useful tips: When delegating your FX, you retain full control which means you can choose to undelegate and withdraw at any point in time, regardless of the validator’s performance or status. However, once you’ve unstaked from one validator, there will be a 21 day lockout period where you will be unable to delegate to any other validator. This is to create stability in the network and prevent people from gaming the system.
Before delegating / staking your FX to participate in the f(x)Core governance, please make sure you understand how this works and budget your FX holdings well.
The flow of participating in governance
How are block rewards distributed?
Block rewards are distributed proportionally to all validators relative to their voting power. Even though each validator gains FX from each reward, all validators will maintain their original weight over time unless new FX is staked into the network.
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 FX and that each validator has 20% of self-bonded FX (remaining 80% are delegated FX). These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator’s pool has 100 FX. These 100 FX will be distributed according to each participant’s stake:
- Commission:
100*80%*1% = 0.8 FX - Validator gets:
100*20% + Commission = 20.8 FX - All delegators get:
100*80% - Commission = 79.2 FX
Then, each delegator can claim their part of the 79.2 FX 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 required minimum number of pre-commits.
When a validator is selected to propose the next block, they must include at least 2/3 pre-commits of the previous block. However, there is an incentive to include more than 2/3 pre-commits in the form of a bonus. The bonus ranges from 1% if the proposer includes 2/3rd pre-commits (minimum for block validity) to 5% (growing linearly) if the proposer includes 100% pre-commits.
The proposer should strike a balance between waiting for more signatures and risk losing out on proposing the next block entirely. 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 FX. Now comes a successful block that collects a total of 1025.51020408 FX in fees.
First, a 2% tax is applied. The corresponding FX go to the reserve pool. Reserve pool’s funds can be allocated through governance to fund bounties and upgrades.
2% * 1025.51020408 = 20.51020408FX go to the reserve pool.
1005 FX 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:
9*R + R + R*5% = 1005 ⇔ R = 1005/10.05 = 100
- For the proposer validator:
- The pool obtains
R + R * 5%: 105 FX - Commission:
105 * 80% * 1%= 0.84 FX - Validator’s reward:
105 * 20% + Commission= 21.84 FX - Delegators’ rewards:
105 * 80% - Commission= 83.16 FX (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 FX
- Commission:
100 * 80% * 1%= 0.8 FX - Validator’s reward:
100 * 20% + Commission= 20.8 FX - Delegators’ rewards:
100 * 80% - Commission= 79.2 FX (each delegator will be able to claim their portion of these rewards in proportion to their stake)
Now moving on to the most important segment…drumroll please…
What are the Hardware Requirements to set up a f(x)Core validator node?
We recommend the following for running f(x)Core:
- 2 or more CPU cores
- At least 500G of disk storage
- At least 4G of memory
- At least 10mbps network bandwidth
Unlike other blockchain validators, the specs you require are actually quite low.
Ideally you would need an SSD drive and the only thing that stands in your way from setting up a validator on a laptop versus setting it up on a server is the 500GB of disk storage. That being said, as the network usage increases, so will the hardware requirements.
What are bandwidth requirements?
f(x)Core 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 they know socially. Once again DO YOUR DUE DILIGENCE!
How to handle key management?
Validators should expect to run an Hardware Security Module (HSM) that supports ed25519 keys. Here are potential options:
- YubiHSM 2
- Ledger Nano S
- Ledger BOLOS SGX enclave
- Thales nShield support
The team does not recommend one solution over the other. The validator is encouraged to bolster efforts to improve HSMs and the security of key management.
Other tips
Running an effective operation is not any easy task. The key is to avoid attacks and outages and maintain security and isolation. Performing regular software upgrades, bug fixes, having protection against denial-of-service attacks are just some of the additional aspects to look out for.
Costs
In addition to the hardware and network costs, in Testnet validators need to self-delegate a minimum of 100 FX. For Mainnet, we encourage 100,000 FX or more.
There is no obligation for validators to self-delegate more than 100FX. However, delegators can set a minimum requirement for their validators to self-delegate more than the required FX. If a validator’s self-delegation dips below the predetermined limit, all the delegators will unbind from this validator. This ensures that validators will have more skin in the game.
Create your own Testnet Validator
You can now setup your validator node on the Testnet for a trial run. The requirements and the steps for Mainnet are exactly the same, except that for setting up a Testnet validator, you will have to mint some worthless FX testnet tokens through the faucet.
As mentioned above, these are the steps to set up an f(x)Core validator. Each step has the link to the full documentation to guide you through with screenshots. Installation f(x)Core, Node setup, How to deploy a validator node on the f(x)Core Mainnet. You can refer to this link for the complete setup documentation.
Until now, there’s quite a bit to digest (that’s still an understatement), including setting up instructions on our Gitbook. If you still find this overbearing, we will have a video session on how to setup on Mainnet in a months time.
Finally…
As a closing note, we thank you for all the support. Make sure to follow us on Twitter, Facebook, Reddit for our updates. If you are interested in sharing ideas and participating in building the Function X ecosystem to make it better, join our official Function X Forum.