Skip to content
LogoLogo

Running a validator node

Validator nodes are responsible for securing the network by validating blocks and the transactions within them. Tempo uses Threshold Simplex to achieve consensus between validators.

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 ~48 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 and then running the validator node as such:

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

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 48-72 hours after the on-chain addition of the validator identity.

FAQ

What happens if we lose our validator's signing share?

Your validator won't be able to propose / sign blocks until it receives a new signing share (~48-72 hours, depending on the stage in the current epoch).

What happens if we lose our validator's signing key?

Your validator will need to rotate its identity by deactivating the current validator identity on-chain and creating a new one.

What happens if we run a validator with the same identity on two different instances?

Only the whitelisted IP address will be able to connect to other validators, meaning that the validator on the second instance will be ignored.

What happens if we lose our node's data, e.g. the consensus database?

You will be able to resync from genesis to the latest block height. We're currently implementing the ability for validators to sync from an execution database snapshot (e.g. by downloading a snapshot by running tempo download).

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 node is synced up to the latest block height. Additionally, please check that your outgoing IP address matches the one whitelisted on the validator smart contract:

cast call 0xCccCcCCC00000000000000000000000000000000 "getValidators()((bytes32, bool, uint64, address, string, string)[])" --json

Checking that your node has successfully participated in a DKG ceremony

A successful DKG ceremony is necessary for your validator to receive a signing share. You can check that you've participated in a successful DKG ceremony by looking at

curl localhost:8002/metrics | grep consensus_engine_dkg_manager_ceremony_successes_total
consensus_engine_dkg_manager_ceremony_successes_total 1

The consensus_engine_dkg_manager_ceremony_successes_total metric should be greater than 0. If the metric is 0, it doesn't necessarily means that your node has observed a failed DKG ceremony. You can get the total number of DKG ceremony failures by looking at this metric:

curl localhost:8002/metrics | grep consensus_engine_dkg_manager_ceremony_failures_total
consensus_engine_dkg_manager_ceremony_failures_total 0

If the number is greater than 0, it means that your node has observed a failed DKG ceremony.