logo

Protocol URL

Architecture

Image without caption

Hardware Requirements (Tesnet & Mainnet)

  • CPU: 32 cores, 2.8GHz, or faster, AMD Milan EPYC or Intel(R) Xeon(R) Platinum
  • Memory: 64GB RAM.
  • Storage: 2T SSD with at least 60K IOPS and 200MiB/s bandwidth.
    • Start with 700GB if you can upgrade storage
  • Networking bandwidth: 1Gbps
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.
Example machine types that meet the reference specs (on various clouds):
Source:
Node Requirements | Aptos Docs
To ensure that your validator and validator fullnode (VFN) operate smoothly, both nodes should meet the
Node Requirements | Aptos Docs

Node Types

  • Validator Nodes
When a transaction is submitted to the Aptos blockchain, validator nodes run a distributed consensus protocol, execute the transaction, and store the transaction and the execution results on the blockchain. Validator nodes decide which transactions will be added to the blockchain and in which order. Source:
Validator Nodes Overview | Aptos Docs
An Aptos node is an entity of the Aptos ecosystem that tracks the state of the Aptos blockchain. Clients interact with the blockchain via Aptos nodes. There are two types of nodes:
Validator Nodes Overview | Aptos Docs
  • Full Nodes
Fullnodes can be run by anyone. Fullnodes verify blockchain history by either re-executing all transactions in the history of the Aptos blockchain or replaying each transaction's output. Fullnodes replicate the entire state of the blockchain by synchronizing with upstream participants, e.g., other fullnodes or validator nodes. To verify blockchain state, fullnodes receive the set of transactions and the accumulator hash root of the ledger signed by the validators. In addition, fullnodes accept transactions submitted by Aptos clients and forward them directly (or indirectly) to validator nodes. While fullnodes and validators share the same code, fullnodes do not participate in consensus. Source:
Fullnodes Overview | Aptos Docs
An Aptos node is an entity of the Aptos ecosystem that tracks the state of the Aptos blockchain. Clients interact with the blockchain via Aptos nodes. There are two types of nodes:
Fullnodes Overview | Aptos Docs

Network Types

  • Validator network: Validators connect to each other over this network. Validator fullnodes (VFNs) and public fullnodes (PFNs) do not use this network.
  • 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.
  • 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.
Source:
Node Requirements | Aptos Docs
To ensure that your validator and validator fullnode (VFN) operate smoothly, both nodes should meet the
Node Requirements | Aptos Docs

Tesnet Validators

i) Validator Files:
docker-compose.yaml
  • Git repo: aptos-core
  • Command to download:
    • shell
      wget -O docker-compose.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/docker-compose.yaml
validator.yaml
  • Git repo: aptos-core
  • Command to download:
    • shell
      wget -O validator.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/validator.yaml
ii) VFN (Validator Full Node) or PFN (Public Full Node) files:
docker-compose-fullnode.yaml
  • Git repo: aptos-core
  • Command to download:
    • shell
      wget -O docker-compose-fullnode.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/docker-compose-fullnode.yaml
fullnode.yaml
  • Git repo: aptos-core
  • Command to download:
    • shell
      wget -O fullnode.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/fullnode.yaml
Source:
Files For Testnet | Aptos Docs
When deploying an Aptos node in testnet, you may need to download the files listed on this page. The files are
Files For Testnet | Aptos Docs

Security

Each of the different state sync syncing modes perform data integrity verifications to ensure that the data being synced to the node has been correctly produced and signed by the validators. This occurs slightly differently for each syncing mode:
  • Executing transactions: Executing transactions from genesis is the most secure syncing mode. It will verify that all transactions since the beginning of time were correctly agreed upon by consensus and that all transactions were correctly executed by the validators. All resulting blockchain state will thus be re-verified by the syncing node.
Source:
State Synchronization | Aptos Docs
Nodes in an Aptos network (e.g., validators, VFNs and PFNs) must always be synchronized to the latest blockchain state.
State Synchronization | Aptos Docs
  • Applying transaction outputs: Applying transaction outputs from genesis is faster than executing all transactions, but it requires that the syncing node trusts the validators to have executed the transactions correctly. However, all other blockchain state is still manually re-verified, e.g., consensus messages, the transaction history and the state hashes are still verified.
Source:
State Synchronization | Aptos Docs
Nodes in an Aptos network (e.g., validators, VFNs and PFNs) must always be synchronized to the latest blockchain state.
State Synchronization | Aptos Docs
  • Intelligent syncing: Intelligent syncing will either execute or apply the transaction outputs depending on whichever is faster, per data chunk. Thus, the security implications of using this mode are identical to those of applying transaction outputs.
Source:
State Synchronization | Aptos Docs
Nodes in an Aptos network (e.g., validators, VFNs and PFNs) must always be synchronized to the latest blockchain state.
State Synchronization | Aptos Docs
  • Fast syncing: Fast syncing skips the transaction history and downloads the latest blockchain state before continuously syncing. To do this, it requires that the syncing node trust the validators to have correctly agreed upon all transactions in the transaction history as well as trust that all transactions were correctly executed by the validators. However, all other blockchain state is still manually re-verified, e.g., epoch changes and the resulting blockchain states.
Source:
State Synchronization | Aptos Docs
Nodes in an Aptos network (e.g., validators, VFNs and PFNs) must always be synchronized to the latest blockchain state.
State Synchronization | Aptos Docs

Aptos Explorers

  • Tesnet:
Aptos Explorer
Explore transactions, accounts, events, nodes, gas fees and other network activity within the Aptos Network.
  • Mainnet:
Aptos Explorer
Explore transactions, accounts, events, nodes, gas fees and other network activity within the Aptos Network.

Port Settings

Port #
Firewall/adapter
Purpose
Comments
6182
open
Aptos Public network
PFN
9101
closed
Aptos Inspection service
PFN
9102
closed
Aptos Admin service
PFN
80/8080
closed
Aptos REST API
PFN
The inspection service port (9101), admin service port (9102) and the REST API port (80 or 8080) are likely useful for your internal network, e.g., application development and debugging. However, the inspection service port and the admin service port should never be exposed publicly as they can be easily abused. Similarly, if you choose to expose the REST API endpoint publicly, you should deploy an additional authentication or rate-limiting mechanism to prevent abuse.

GitHub repository

  • Aptos core: