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
- Fullnodes
Each Aptos node comprises several logical components:
- REST API service
- Mempool
- Consensus (disabled in fullnodes)
- Execution
- Virtual Machine
- Storage
- State synchronizer
The Aptos-core software can be configured to run as a validator node or as a fullnode.
Aptos validator network on Explorer. Counts change as operators join and leave; view the live set.
Overview
Section titled “Overview”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.
The Aptos blockchain uses a Byzantine Fault Tolerance (BFT) consensus protocol for validator nodes to agree on the ledger of finalized transactions and their execution results. Validator nodes process these transactions and include them in their local copy of the blockchain database. This means that up-to-date validator nodes always maintain a copy of the current state of the blockchain, locally.
Validator nodes communicate directly with other validator nodes over a private network. Fullnodes are an external validation and/or dissemination resource for the finalized transaction history. They receive transactions from peers and may re-execute them locally (the same way a validator executes transactions). Fullnodes store the results of re-executed transactions to local storage. In doing so, they can challenge any foul-play by validators and provide evidence if there is any attempt to re-write or modify the blockchain history. This helps to mitigate against validator corruption and/or collusion.
Validator node components
Section titled “Validator node components”
Mempool
Section titled “Mempool”Mempool is a component within each node that holds an in-memory buffer of transactions that have been submitted to the blockchain, but not yet agreed upon or executed. Fullnodes forward user transactions into this buffer over the REST API.
Mempool verifies signatures, balances, and replay protection (sequence number or orderless nonce) to reject invalid traffic and to limit denial-of-service attacks. After a transaction passes those checks, Quorum Store disseminates it in batches to the validator set. That decouples data availability from the leader’s metadata proposal.
When a validator becomes the consensus leader, it proposes a block that orders certified batches rather than flooding raw transactions through the proposal. Each validator executes that block and votes on the result.
Consensus
Section titled “Consensus”Consensus is the component that is responsible for ordering blocks of transactions and agreeing on the results of execution by participating in the consensus protocol with other validator nodes in the network.
Execution
Section titled “Execution”Execution is the component that coordinates the execution of a block of transactions and maintains a transient state. Consensus votes on this transient state. Execution maintains an in-memory representation of the execution results until consensus commits the block to the distributed database. Execution uses the virtual machine to execute transactions. Execution acts as the glue layer between the inputs of the system (represented by transactions), storage (providing a persistency layer), and the virtual machine (for execution).
Virtual machine (VM)
Section titled “Virtual machine (VM)”The virtual machine (VM) is used to run the Move program within each transaction and determine execution results. A node’s mempool uses the VM to perform verification checks on transactions, while execution uses the VM to execute transactions.
Storage
Section titled “Storage”The storage component is used to persist agreed upon blocks of transactions and their execution results to the local database.
State synchronizer
Section titled “State synchronizer”Nodes use their state synchronizer component to “catch up” to the latest state of the blockchain and stay up-to-date.