Running a validator node

Validator nodes secure Tempo by validating blocks and transactions, then using Threshold Simplex to reach consensus. They distribute signing shares among themselves to collectively sign block approvals and finalizations.

Cryptographic key hierarchy

All validators have two kinds of keys:

signing key - this is an ED25519 keypair used to identify your validator amongst others
signing share - this is a share of a BLS12-381 keypair used to sign block notarizations and finalizations

The signing key is static and can only be rotated by removing and re-creating a validator on-chain. The signing share is dynamic and is updated periodically on each DKG ceremony. Once updated, it will be saved to disk. Currently, the DKG ceremony is scheduled to run on-chain every ~3 hours.

Generating a signing key

You can generate an ED25519 keypair using the following command:

tempo consensus generate-private-key --output <path>

Once the private key is generated, you can calculate/verify the public key by running:

tempo consensus calculate-public-key --private-key <path>

The public key should match the output of the generate-private-key command.

Running the validator

The process for running a validator node is very similar to running a full node.

You should start by downloading the latest snapshot using tempo download --chain <moderato|mainnet|devnet>. Downloading the snapshot allows your validator to start participating in consensus much faster. Once you've downloaded the snapshot and have been whitelisted on-chain, you can proceed to run the validator node as such:

tempo node --datadir <datadir> \
    --chain moderato \
    --port 30303 \
    --discovery.addr 0.0.0.0 \
    --discovery.port 30303 \
    --consensus.signing-key <path> \
    --consensus.fee-recipient <validator_wallet_address> \
    --telemetry-url <TELEMETRY_URL>

Optional flags

Flag	Description
`--telemetry-url <URL>`	Unified metrics and logs export. Pushes both reth and consensus metrics with a `consensus_id` label for node identification. We ask all validators to configure this so we can support troubleshooting.
`--consensus.datadir <PATH>`	Store consensus data on a separate volume (e.g., AWS EBS) while keeping execution state on high-performance local disks. Migrate by copying `<datadir>/consensus` to the new location.

The notable difference between RPC nodes and validator nodes is the omission of the --follow argument and the addition of the --consensus.signing-key and --consensus.fee-recipient arguments. The fee recipient is the address that will receive transaction fees in your validators' proposed blocks.

Once your node is up, it may not start syncing immediately. This is because your node might not be part of the active set. In most cases, your validator will enter the active set in under 6 hours after the on-chain addition of the validator identity.

Troubleshooting

Checking if your node is proposing blocks

Once your node is proposing blocks, it will start emitting logs like these:

INFO handle_propose{epoch=18 view=387213 parent.view=387212 parent.digest=0x43885416b4a7ae7550c615ad4dc702045cd26540b78fa2bd75abdcbfbef02d9d}: tempo_commonware_node::consensus::application::actor: constructed proposal proposal.digest=0x6baa8fa813beea491cf598024d8b31cb2927e7ba1b92a29899a795dbafd682c6 proposal.height=5733680

If you do not see logs like these:

please check that your validator is part of the active set, and is both a player and a dealer
please check that your node is synced up to the latest block height.
please check that your outgoing IP address matches the one whitelisted on the validator smart contract:

tempo consensus validators-info --rpc-url <YOUR_RPC_URL>