Become a Validator

Validators perform the critical function of proposing and validating transactions on the Provenance Blockchain network. A strong network of validators ensures Provenance Blockchain security is maintained. Validators stake Hash to become part of the active validators on the network and are a foundational element for Hash holders that want to delegate their stake and share in rewards produced by the network's fee distribution framework.

Quick Start

This quick start assumes that you have already completed the necessary steps to join a full node to the Provenance Blockchain network and are ready to designate the node as a validator.

warning

To configure a validator you need to acquire Hash to grant the newly created validator voting power on the network.

Finding Node Public Key

Each node has a public key that identifies it to other participants on the network. To configure the full node created in Join Provenance Blockchain Testnet, find the public key that identifies the node. Tendermint, the underlying consensus algorithm, provides a simple way to display the key for use.

provenanced --testnet tendermint show-validator

Staking Hash to Become a Validator

The following command has a lot of detail that should be closely reviewed.

Parameter	Description
chain-id	the name of the network you're connecting to
home	home directory containing the blockchain data for the node - this was set to $PIO_HOME in the Joining Testnet section
moniker	the name of your validator that should be shown to other participants on the network
pubkey	Public key determined using the tendermint show-validator command
amount	amount of Hash to delegate as voting power on the network
from	account that holds the Hash to be delegated
fees	amount of nhash to pay in fees
commission-rate	commission rate charged by the validator
commission-max-rate	max commission rate charged by the validator
commission-max-change-rate	max change in commission rate allowed
min-self-delegation	minimum amount of Hash the validator will delegate while the node is operating
broadcast-mode	wait until the block containing the transaction is committed

provenanced --testnet \
   --keyring-dir <location_of_keyring> \
   --chain-id <chain_id> \
   --home <location_of_blockchain> \
tx staking create-validator \
   --moniker arbiter34.com \
   --pubkey <public_key> \
   --amount 9000000000nhash \
   --from stakeholder0
   --fees 5000nhash \
   --commission-rate=1.0 \
   --commission-max-rate=1.0 \
   --commission-max-change-rate=1.0 \
   --min-self-delegation 1 \
   --broadcast-mode block

Security

Validators are the most important nodes in the network. They require a level of security that ensures they are highly available and protected at every level. The following reviews the recommended network architecture to ensure the Provenance Blockchain network validators are protected. This is patterned after the official Tendermint Documentation.

Network Architecture

A multi-tier network architecture is recommended to secure validators. Each tier of the network increases restrictions on network access.

Tiers

Tier	Description
Public Sentry	Public Sentry nodes are available to the world and provide a proxy for the network.
Private Sentry	Private Sentry nodes provide an interconnect layer that can be used to provide more direct integration with large foundational Provenance Blockchain systems.
Validator	The core of the Provenance Blockchain that should be isolated from all public-facing networks.
KMS	Key Management Service - A remote signing platform that secures access to encryption keys.

The Recommended Network Architecture diagram is the architecture to follow when building out Provenance Blockchain nodes and validators. This may be done in a cloud environment (e.g. AWS, GCP, or Azure), within an on-premise data center, or a combination of both. The idea of this infrastructure will be further detailed below but conceptually it is required to protect the validator by leveraging multiple layers of network security.

Network Security (Firewall)

The Provenance Blockchain network leverages two different ports (P2P and RPC) by default and should be considered when opening necessary firewall rules.

P2P

The persistent peer port (P2P) uses TCP port 26656 and is required for nodes to connect to the network and to each other. As such, firewall rules should be created that limit access to this port.

RPC

The RPC port is the application port that uses TCP port 26657. This port should only be made available to trusted sources. If more public access such as querying the status of the network of specific API endpoints is needed, use NGINX's reverse-proxy to limit that access.

It is recommended that each of these nodes be placed in specific zones or private networks and leverage network firewalls to limit access. For example, the Public Sentry nodes should leverage a public IP and access to these nodes will be open to the public. Private Sentry nodes should leverage private IPs or whitelist access with public IPs from the public sentry nodes. Validators should always leverage private IP addresses to ensure they are protected.

Configuration

The validator node requires the highest level of security as it contains the key that will be authorized to sign blocks on the Provenance Blockchain network. If a bad actor gets this key, they could connect to the chain and impersonate that same validator, thereby causing a double signing incident which would result in a validator being jailed and slashed. For this reason, access to this node should be limited to those who absolutely require access. All access should be monitored and recorded via a monitoring solution.

The following configuration parameters are found in the config.toml file.

Configuration	Setting
pex	false This turns the peer exchange reactor on or off for a node.
persistent-peers	private sentry node ids a comma separated list of nodeID@ip:port values that define a list of peers that are expected to be online at all times
private-peer-ids	none Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
unconditional-peer-ids	private sentry node ids List of node IDs, to which a connection will be (re)established ignoring any existing limits
addr-book-strict	false By default nodes with a routable address will be considered for connection. If this setting is turned off (false), non-routable IP addresses, like addresses in a private network can be added to the address book.

Key Management - HSM

There are multiple solutions available that could be used to provide this network security. One solution readily available is Tendermint KMS which is actively maintained and supports multiple Hardware Security Modules.

The validator consensus key used to sign blocks on the Provenance Blockchain network must be protected. By default, this key is in plain text on the node and anyone with access would be able to obtain it. A remote signer KMS combined with an HSM to ensure the absolute security of the validator key should be leveraged. Due to the strong recommendation of leveraging an HSM, this solution should be built on-site in a Secured Data Center. This would include leveraging network firewalls, secured servers, network switches, and limited access to these devices by necessary personnel.

Recommended Hardware Configuration

info

CPU/Memory/Storage is determined by how Provenance Blockchain will be used and how the node is configured (type) and data retention periods. These are general use numbers and may be adjusted based on the desired performance.

Node Type	CPU	Memory	Storage
Validator	4 CPU	32GB	500GB