Home Docs Blog Contact

Naming Validators

August 22nd, 2023

As we move into the era of elastic subnets, validator naming will become important. This document highlights the methods we are using for providing names to valdiators.

How do we think about & identify validators?

Anyone can run an Avalanche node using the avalanchego binary. When you run a node, it pulls the state of the Avalanche system & can be used as an RPC for issuing transactions. However, it cannot participate in consensus until you stake AVAX tokens & turn it into a validator. 

Avalanche nodes are identified by their NodeID. Within the AvalancheGo config directory, there is a staking directory (normally ~/.avalanchego/staking) containing an RSA-4096 keypair (staker.crt and staker.key). The NodeID can be derived from staker.crt, the public certificate, and the private key can be used to authenticate ownership of the node.

Staking tokens & creating a validator is completed on the P-Chain by a P-Chain address. This P-Chain address is the source of the staked tokens & the beneficiary of the staking rewards. We will refer to the owner of this P-Chain address as the beneficiary from now on.

Importantly, we have a sort of dual ownership of a node in some cases, as the node operator is not necessarily the same actor as the beneficiary.

How does Avvy Domains authenticate validators?

Our current method is to use the RSA-4096 keypair to authenticate ownership of the NodeID itself. The owner of this keypair ultimately controls the node's communication on the Avalanche network, despite not necessarily having control over the staking capital.

To authenticate ownership of a node, the node owner must provide their public staking certificate and a signature created using their staking private key to the smart contract responsible for reverse-resolving NodeIDs. We use the public staking certificate + signature to verify the user is indeed authorized to act on behalf of the provided NodeID. More in-depth technical details are provided below.

The downside of this approach is that node service providers do not necessarily give their clients access to the staking keypair. In the future, we may have to collaborate with node service providers to get access to this data, or collaborate with the AvalancheGo team to find another way to authenticate node ownership via the RPC.

Technical Details on Authentication for Reverse Resolving NodeIDs

The authentication smart contract provides a message to be signed by the node's staking private key. This message contains:

  • The domain name we want the NodeID to reverse resolve to
  • A timestamp
  • The version of the authentication contract

The node operator then uses the private key to sign the message, and submits the following information to the smart contract:

  • The public staking certificate
  • The domain name we wish to reverse resolve to (i.e. mynode.avax)
  • The timestamp
  • The message signature

The smart contract uses the public staking certificate to extract the NodeID as well as the RSA modulus & exponent.

A number of checks are performed by the smart contract:

  • We verify the wallet submitting the transaction is authorized to write to the provided domain name
  • We use the RSA modulus & exponent extracted from the public certificate to verify that the signature is valid
  • We use the timestamp to ensure that the signature is not more than 15 minutes old or 15 minutes in the future.
  • We verify the domain in the signature matches the domain we are writing to
  • We confirm that the NodeID we are setting the reverse record for matches the NodeID derived from the public certificate

Signed messages are locked to a timestamp which is only valid for a 15 minute window, this version of the authentication smart contract, a NodeID, and a domain name. Even if a message is intercepted, the transaction would need to be signed & submitted by someone authorized to act on the domain name. The signature can only for this version of the authentication smart contract. These signatures can be used multiple times during the 15 minute window, and nodes can potentially be tricked into signing a message in the future. However even in the case of the malicious signature, a malicious scenario would require the domain to be transferred to a new, malicious owner, and that new malicious owner somehow have access to a signature that was created for future use.



We make use of two libraries to perform the verification.

  1. We use base58-solidity to provide the Base58 encoding as part of the process of reducing staking certificates into NodeIDs.
  2. We use SolRsaVerify to verifying the RSA signatures.


Join Our Community

Join us on social media to keep up with news & development. Have questions? Hop into our Discord & we'll be happy to answer them.

Twitter  x  Telegram  x  Discord