Validator Node

A validator node is essential for securing the network by validating transactions and blocks, and participating in the consensus process. Deploying validator nodes enables participation in the consensus mechanism and allows for the collection of rewards provided by the network to those who help secure it.

Validator nodes perform the following tasks:

• Validation: Ensure the validity of transactions.
• Consensus: Reach agreement with other validators on the transactions to be added to the blockchain.
• Block Addition: Bundle the agreed-upon transactions into a block and append it to the blockchain.

On Flare, data protocols such as the Flare Time Series Oracle and Flare Data Connector are enshrined into the network. This requires validators to perform additional tasks to secure the network and earn rewards.

Flare Staking Phases

Deployment will occur in three phases, during which:

1. Infrastructure entities will be progressively on-boarded to ensure the network remains operational.
2. Current FTSO data providers must build a minimum stake to function as validators.
3. Existing validators need to enhance their capabilities to become data providers.

Each phase will gradually relinquish control, allowing the network to validate independently of the Flare Foundation.

Launch (Jul 2022)

At network launch, 20 validators had their node IDs hard-coded into the client software, preventing other validators from participating. The Flare Foundation managed these nodes and gradually reassigned 16 of them to 4 external entities to increase decentralization. These entities, known as professional validators, are experienced infrastructure providers managing blockchain nodes. During this period, FTSO data providers operated entirely independently of validators.

Phase 1 (July 2023)

A network fork enabled Avalanche's proof-of-stake mechanism, opening validation to everyone. Simultaneously, all stakes from the original validators expired. The Flare Foundation loaned all the stakes for the initial validators, maintaining the distribution of validation power while testing proof-of-stake. After some FTSO data providers completed a KYC process, the Flare Foundation loaned them funds to deploy validation nodes and act as validators.

Since staking occurs on the P-chain, staked tokens cannot access rewards managed by smart contracts on the C-chain. To address this, a communication mechanism between the two chains is being developed. All staking rewards are manually calculated offchain and then distributed onchain. These calculations will initially be private for fine-tuning and will become public in Phase 2 for verification.

Phase 2 (Oct 2023, current)

Once FTSO data providers have gathered enough stake to ensure the network's continued operation, all stakes loaned by the Flare Foundation to the launch validators will be withdrawn. Professional validators are expected to cease operations unless they provide their own stake. The Flare Foundation might delegate stake to KYC-verified FTSO data providers to help initiate the system. This process, known as stake boosting, will run for a limited time. Staked funds can earn FlareDrops and participate in governance but not earn FTSO delegation rewards.

Staking rewards will:

• Consider validator uptime and staked amount, which is publicly monitored.
• Require that the validator is also an FTSO data provider consistently rewarded for accurate prices.
• Be manually calculated offchain using a public script and then distributed onchain.

Phase 3

Once secure communication between the P- and C-chains is established, staking rewards will be managed entirely onchain. The goal is for funds staked on the P-chain to have the same rights as wrapped FLR on the C-chain, enabling them to earn FTSO rewards, FlareDrops, and participate in governance.

Summary of Phases

	Launch	Phase 1	Phase 2*	Phase 3
Validation open to everybody	❌	✅	✅	✅
Validators must provide own stake	❌	❌	✅	✅
Validators must be data providers to earn rewards	❌	❌	✅	✅
Locked stake can earn staking rewards	❌	❌	✅	✅
Staking rewards are handled onchain	❌	❌	❌	✅
Same rights for staked and wrapped tokens	❌	❌	❌	✅

*Current Phase

Hardware requirements

Validator nodes have the same hardware requirements as RPC nodes. Refer to the Hardware requirements section of the RPC node guide for more information.

Prerequisites

Ensure you have the following tools installed:

• Go
• GCC
• jq

MacOS

brew install go gcc jq

Ubuntu

apt install golang gcc jq

Arch

pacman -S go gcc jq

Configure the node

warning

Validator security impacts the security of the entire network. To configure your node for security:

• Don't allow port 9650 to be reached externally.
• Don't allow password authentication over SSH.
• Don't run any non-validator services on the same IP.

In addition to the above, the following security measures are recommended for further hardening:

• Do firewall the machine. Only the ports required for validator operation should be open (i.e. only the staking port, which defaults to 9651).

• Don't allow any ICMP traffic.

• Don't allow the node to accept RPC API requests, only use it as a validator. Deploy a separate RPC node for tasks requiring RPC API access.

• Don't enable the more than the minimum set of EVM APIs when configuring your node.

Sample JSON configuration for validator nodes.

config.json

{
  "snowman-api-enabled": false,
  "coreth-admin-api-enabled": false,
  "coreth-admin-api-dir": "",
  "eth-apis": ["web3"],
  "continuous-profiler-dir": "",
  "continuous-profiler-frequency": 900000000000,
  "continuous-profiler-max-files": 5,
  "rpc-gas-cap": 50000000,
  "rpc-tx-fee-cap": 100,
  "preimages-enabled": false,
  "pruning-enabled": true,
  "snapshot-async": true,
  "snapshot-verification-enabled": false,
  "metrics-enabled": true,
  "metrics-expensive-enabled": false,
  "local-txs-enabled": false,
  "api-max-duration": 30000000000,
  "ws-cpu-refill-rate": 0,
  "ws-cpu-max-stored": 0,
  "api-max-blocks-per-request": 30,
  "allow-unfinalized-queries": false,
  "allow-unprotected-txs": false,
  "keystore-directory": "",
  "keystore-external-signer": "",
  "keystore-insecure-unlock-allowed": false,
  "remote-tx-gossip-only-enabled": false,
  "tx-regossip-frequency": 60000000000,
  "tx-regossip-max-size": 15,
  "log-level": "info",
  "offline-pruning-enabled": false,
  "offline-pruning-bloom-filter-size": 512,
  "offline-pruning-data-directory": ""
}

Run the node

Start your node by following the Run the node section of the RPC node guide.

info

If you have a pre-registered validator key, you just need to add these parameters to the launch command:

--staking-tls-cert-file=<NODE_CRT_PATH> --staking-tls-key-file=<NODE_KEY_PATH>