Aptos

Protocol URL

Aptos Foundation: https://aptosfoundation.org/get-started

Aptos Labs: https://aptoslabs.com/

Node Operators: https://aptos.dev/nodes/nodes-landing/

Architecture

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

https://aptos.dev/nodes/validator-node/operator/node-requirements#hardware-requirements

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:

https://aptos.dev/concepts/validator-nodes

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:

https://aptos.dev/concepts/fullnodes

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

https://aptos.dev/nodes/validator-node/operator/node-requirements#network-types

Tesnet Validators

i) Validator Files:

docker-compose.yaml

Git repo: aptos-core

Git branch: testnet on https://github.com/aptos-labs/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

Git branch: testnet on https://github.com/aptos-labs/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

Git branch: testnet on https://github.com/aptos-labs/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

Git branch: testnet on https://github.com/aptos-labs/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

https://aptos.dev/nodes/node-files-all-networks/node-files-testnet

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.

https://aptos.dev/guides/state-sync/#executing-all-transactions

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.

https://aptos.dev/guides/state-sync/#applying-all-transaction-outputs

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.

https://aptos.dev/guides/state-sync/#intelligent-syncing

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.

https://aptos.dev/guides/state-sync/#fast-syncing

Aptos Explorers

Tesnet:

Aptos Explorer

Explore transactions, accounts, events, nodes, gas fees and other network activity within the Aptos Network.

https://explorer.aptoslabs.com/?network=testnet

Mainnet:

Aptos Explorer

Explore transactions, accounts, events, nodes, gas fees and other network activity within the Aptos Network.

https://explorer.aptoslabs.com/?network=mainnet

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: