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.
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.
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.
The authentication smart contract provides a message to be signed by the node's staking private key. This message contains:
The node operator then uses the private key to sign the message, and submits the following information to the smart contract:
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:
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.
Join us on social media to keep up with news & development. Have questions? Hop into our Discord & we'll be happy to answer them.
