Node Requirements

To ensure that your validator and validator fullnode (VFN) operate smoothly, both nodes should meet the requirements specified in this document.

When running an Aptos validator and VFN, we strongly recommend that the nodes run on two separate and independent machines. These machines should be well-provisioned, meet the requirements outlined below and be isolated from each other. Maintaining resource isolation between the validator and the VFN is important for security and to ensure that the nodes do not encounter performance degradation, instability or failures when under load.

For running an Aptos validator and VFN in mainnet, we recommend that your hardware be performant enough to maintain ~30,000 transactions per second (TPS). There are two ways to evaluate if your hardware meets this requirement:

1. Use the reference specs provided below.
2. Run the performance benchmarking tool provided by Aptos.

Note that both the validator and VFN require sufficient hardware separately (i.e., two separate machines that satisfy the requirements outlined below).

Specifications for Running an Aptos Validator and VFN on Mainnet

Example Machine Types on Various Clouds

If you’d prefer to evaluate your hardware for sufficient performance, you can use the performance benchmarking tool. First, clone the aptos-core repository and install the required dependencies (see the Cloning aptos-core section). Then, execute the following commands to run the benchmark:

TABULATE_INSTALL=lib-only pip install tabulate

./testsuite/performance_benchmark.sh --short

Once the benchmark finishes, it will print out a table, with a column "t/s", which shows the TPS achieved by your hardware. The evaluation criteria is encoded in the tool, and the tool will display a warning if your hardware does not meet the requirements.

Local SSD vs. network storage

Cloud deployments require choosing between local storage or network storage, such as, AWS EBS and GCP PD. Loosely speaking, a local SSD often provides lower latency and cost, especially relative to IOPS (input/output operations per second), while network storage requires CPU support to scale IOPS. However, network storage provides better support for backups and offers improved reliability for nodes that stop or fail, thus enabling higher availability. The choice between local SSD and network storage depends on your specific requirements and constraints.

Hardware requirements for Aptos nodes depend on: (i) the transaction workload being executed; and (ii) the size of the database on each machine. The current hardware requirements have been set using an estimated transaction workload (e.g., 30,000 TPS) and an estimated database growth rate for 2024. These may be subject to change. It is also worth noting that transaction workloads can change frequently, and thus it is necessary to provision your hardware to meet the requirements of the most demanding transaction workloads. This will ensure that your nodes can perform well under load and remain stable.

Generally, the size of the database on each machine is a function of the ledger history (i.e., the number of transactions in the blockchain history) and the number of on-chain states (e.g., accounts and resources). Both the ledger history and the number of on-chain states depend on several additional factors, including the age of the blockchain, the average transaction rate over time, and the configuration of the ledger database pruner. At the time of writing, we estimate that testnet and mainnet require several 100’s of GB of storage.

Note that because archival nodes store the entire history of the blockchain, the database size on archival nodes will continue to grow unbounded. As a result, we cannot provide a recommendation for archival node storage sizes.

When you are running a validator and a VFN, you are required to open network ports on your nodes to allow other nodes (i.e., peers) to connect to you. There are different Aptos network types, and each network type uses a different port (see below).

There are three types of Aptos networks:

1. Validator network: Validators connect to each other over this network. Validator fullnodes (VFNs) and public fullnodes (PFNs) do not use this network.
2. VFN network: The validator fullnode (VFN) network allows a validator and VFN pair to connect to each other. This network is private between the validator and the VFN.
3. Public network: The public network allows VFNs and public fullnodes (PFNs) to connect to other VFNs and PFNs. This allows public node operators to access the blockchain.

Your node can be configured so that each of these networks can operate using a different port on your node. You can configure the port settings using the node configuration YAML file. Here is an example configuration file for a VFN node that configures the VFN network to use port 6181 and the public network to use port 6182.

The recommendations described below assume the default port settings used by validators, VFNs and PFNs. If you have changed the default port settings in your configuration file, then you should adjust the recommendations accordingly.

Assuming default ports are used, the following should be configured for validator nodes:

• Open the following TCP ports:
  • 6180 - Validator network: Open this port publicly to enable the validator to connect to other validators in the network.
  • 6181 – VFN network: Open this port privately to only be accessible by your VFN.
• Close the following TCP ports:
  • 6182 – Public network: Close this port to prevent PFN connections.
  • 9101 – Inspection service: Close this port to prevent unauthorized metric inspection.
  • 9102 – Admin service: Close this port to prevent unauthorized admin service interaction.
  • 80/8080 REST API: Close this port to prevent unauthorized REST API access.

Assuming default ports are used, the following should be configured for VFN nodes:

• Open the following TCP ports:
  • 6181 – VFN network: Open this port privately to only be accessible by your validator.
  • 6182 – Public network: Open this port publicly to enable PFNs to connect to your VFN.
• Close the following TCP ports:
  • 9101 – Inspection service: Close this port to prevent unauthorized metric inspection.
  • 9102 – Admin service: Close this port to prevent unauthorized admin service interaction.
  • 80/8080 REST API: Close this port to prevent unauthorized REST API access.

It is highly recommended to enable system clock synchronization using a Network Time Protocol (NTP) service. Accurate timekeeping ensures that nodes participate in consensus promptly and remain synchronized with the rest of the network. Failure to maintain consistent system time may cause nodes to lag behind and validators may even fail to propose blocks.