Deprecate VFNs

AIP-139 deprecates Validator Full Nodes (VFNs) by allowing validators to accept direct connections from Public Full Nodes (PFNs). This removes the need for operators to run a separate VFN alongside their validator.

提示

Devnet and Testnet
VFN removal has already occurred on Devnet and Testnet. The instructions in this document apply only to Mainnet VFN deprecation and removal.

Summary

This guide provides step-by-step instructions for Mainnet validator operators to shut down their VFNs and configure their validators to accept PFN connections. To achieve this, you will need to perform the following tasks:

1. Prerequisite: Ensure you are running aptos-node v1.45.x or later.
2. Configure the validator to accept inbound PFN connections.
3. Important: Wait for confirmation from Aptos Labs before shutting down your VFN. Announcements will be made across release groups.
4. Shut down your VFN.

Follow the instructions in each step carefully, and reach out to the Aptos Labs team if you have any questions or need assistance.

Prerequisites

Before proceeding, verify that you are running aptos-node v1.45.x or later. Older releases do not support direct validator-to-PFN connections.

You can check your node version by running:

aptos-node --version

If you are on an older release, upgrade before continuing.

Step 1: Configure PFN connections

Configure your validator to accept inbound PFN connections. This requires your validator to be listening for PFN connections on an open port.

There are three options:

1. (Recommended) Use the default port (6182) to accept PFN connections.
2. Use a custom port to accept PFN connections.
3. (Discouraged) Reject PFN connections.

提示

Accept PFN connections
We strongly encourage operators to accept PFN connections (option 1 or 2 above). Accepting PFN connections is necessary for network health and ecosystem connectivity. If validators reject PFN connections, this may impact the ability of PFNs to sync and serve data.

Option 1: Use the default port

By default, the validator binary will start listening for PFN connections on port 6182 (without any config changes). If you are happy with this port, no additional steps are required. Simply ensure port 6182 is open in your firewall, and your validator will be able to accept inbound PFN connections.

Option 2: Use a custom port

If you want to use a different port for PFN connections, you can configure the validator to listen on that port instead. To do this, add a full_node_networks section to your validator config with the desired port:

validator.yaml

full_node_networks:
  - network_id: "public"
    discovery_method: "none"     # Prevents unnecessary outbound connections to other PFNs.
    max_outbound_connections: 0  # Prevents unnecessary outbound connections to other PFNs.
    listen_address: "/ip4/0.0.0.0/tcp/<your-port>"
    identity:
      type: from_file
      path: /path/to/validator-identity.yaml  # Path to the validator identity file

Replace <your-port> with the port you want to use (e.g., 7777), and ensure the port is open in your firewall. Set the identity field to the validator’s network identity by pointing to the validator-identity.yaml file.

After updating the config and restarting the validator, you must also update the on-chain fullnode_network_addresses to point to your validator’s host and the new port. To do this, update your operator config file (e.g., operator.yaml) with these three fields:

operator.yaml

full_node_network_public_key: "<validator-network-public-key>"
full_node_host:
  host: <validator-host>
  port: <your-port>

Replace <validator-network-public-key> with the public key from your validator-identity.yaml file, <validator-host> with your validator’s public IP or hostname, and <your-port> with the port configured above. Then run:

aptos node update-validator-network-addresses \
  --pool-address <owner-address> \
  --operator-config-file ~/path/to/operator.yaml

Replace <owner-address> with your validator pool address. For more details on using update-validator-network-addresses (including how to locate your pool address and operator config), see Connect to the Aptos Network.

提示

Wait for the next epoch
On-chain network address updates take effect at the start of the next epoch. PFNs will not be able to discover the new address until then.

Verify your on-chain registration

After the next epoch begins, confirm that the correct addresses are registered on-chain by running:

aptos node show-validator-config \
  --pool-address <owner-address> \
  --profile <your-profile>

The output includes fullnode_network_addresses, which should reflect your validator’s host and the custom port you configured. For example:

{
  "fullnode_network_addresses,": "/ip4/<validator-host>/tcp/<your-port>/noise-ik/<validator-network-public-key>/handshake/0"
}

If the value has not updated yet, wait for the next epoch and run the command again.

Option 3: Reject PFN connections

警告

Not Recommended
Rejecting PFN connections can be harmful to the network, and degrade ecosystem health. Only use this option if you have a strong operational reason to do so.

If you do not want the validator to accept any PFN connections, set enable_validator_pfn_connections to false in the base section of your validator node config:

validator.yaml

base:
  enable_validator_pfn_connections: false

When this configuration is used, the node will no longer listen for or accept connections from PFNs.

Step 2: Shut down your VFN

危险

Do not proceed until confirmed by Aptos Labs
VFN removal will be rolled out across release groups. Only shut down your VFN after Aptos Labs confirms it is safe to do so. If you have any doubt, contact the team before proceeding.

Once you have received confirmation, you can take the VFN offline safely. You do not need to leave the validator set to shut down the VFN. Only the validator needs to remain online.

提示

Backup your VFN data
As a precaution, we recommend backing up the VFN keys, identity files, and configuration files before shutting down your VFN.

To stop the VFN, use the appropriate method for your deployment, for example:

• Source code: Kill the aptos-node process running the VFN.
• Docker: Run docker compose down --volumes in the VFN directory.
• Terraform: Run terraform destroy targeting the VFN resources.

Protecting your validator

With the VFN removed, your validator will be more exposed to the public internet. This increases the attack surface for network-level attacks, such as DDoS. If you don’t already have protections in place, we strongly recommend implementing appropriate safeguards (see the recommendations below).

警告

Protecting your validator
The recommendations below reflect common practices already used by operators. However, this is not an exhaustive list; operators should evaluate their own risk tolerance and operational requirements.

Firewall

At minimum, we recommend locking down all ports on the validator host except those required for node operation, e.g.:

• Consensus port (default 6180): Required for validator to validator traffic.
• PFN port (default 6182): Required for PFN traffic.

All other ports should be blocked by your firewall, including the REST API port, and metrics port. If you need to expose these ports for monitoring, restrict access to trusted IPs or internal networks only.

Popular tools include ufw and firewalld. Apply the principle of least privilege: deny by default and allow only what is explicitly required.

Load balancer & reverse proxy

Running a load balancer, or reverse proxy in front of open validator ports adds a layer of indirection that allows traffic shaping, rate limiting, and health checks without exposing the node directly. HAProxy is a commonly used option; example configs can be found in the aptos-core repository.

DDoS protection

DDoS protection can also be quite useful. Some operators already use a combination of network-level protections and DNS-level protections, e.g., Cloudflare Spectrum, AWS Shield, GCP Cloud Armor Network Edge, and upstream provider mitigations, including network-level DDoS scrubbing.

Summary checklist

Defense	Minimum recommendation
Firewall	Block all ports except those required (deny by default).
Load balancer & reverse proxy	Place HAProxy (or equivalent) in front of the validator.
DDoS protection	Enable DDOS protection (Cloudflare Spectrum, AWS Shield, or similar).