27. Node Operation & Validator Requirements
27.1 Node Software
A Quantos node is a single Rust binary (quantos, entry point src/main.rs) configurable as a full validator or a non-validating full node. It bundles the consensus engine, QuantosVM, the DAG-native ingress pipeline (TxIngressBuffer + VertexBuilder), the storage layer, the P2P stack, and the JSON-RPC server. Containerised deployment is provided via the repository Dockerfile and docker-compose.yml, with monitoring wiring under quantos/monitoring/.
27.2 Hardware Profile
A high-performance benchmark profile may use hardware such as the following. These are not minimum validator requirements and do not establish throughput:
| Resource | Recommended |
|---|---|
| CPU | 64 cores (parallel signature verification + parallel execution) |
| Storage | NVMe SSD (RocksDB write-heavy workload) |
| Network | 10 Gbps NIC (post-quantum signature bandwidth is the dominant consumer) |
| Memory | Sized to hold the hot working set and ingress buffer |
CPU, storage and network requirements depend on ML-DSA-65 signature overhead, ML-KEM operations, validator count, workload, storage mode, message propagation and enabled modules. Hardware sizing must be measured for the chosen configuration.
27.3 Configuration
Node behaviour is set through NodeConfig (in config.rs) and network config files (quantos/config/, quantos/networks/). Key parameters and their reference defaults in NodeConfig:
db_path = "./data/quantumdag"
p2p_port = 30303
rpc_port = 8545
num_committees = 1000
validators_per_committee = 21
num_shards = 1000
committee_rotation_ms = 100
checkpoint_interval = 1000 # vertices per checkpoint
max_dag_parents = 8
min_dag_parents = 2
These are NodeConfig defaults; testnet deployments may differ. For example, the current testnet VPS runs with num_shards = 4 (visible in the node health check: "num_shards": 4). Distinct network definitions (local devnet, testnet) live under networks/, fixing the genesis validator set, chain id, and economic constants for each environment.
27.4 JSON-RPC Interface
Operators and applications interact with a node through the qnt_* JSON-RPC namespace (src/rpc/). The full method set in the code:
Ethereum-compatible
| Method | Purpose |
|---|---|
qnt_getBalance | Account balance |
qnt_getTransactionCount | Account nonce |
qnt_sendRawTransaction | Submit a signed transaction |
qnt_getTransactionByHash | Look up a transaction |
qnt_getTransactionReceipt | Transaction receipt |
qnt_blockNumber | Latest block height |
qnt_chainId | Chain identifier |
qnt_call | Read-only execution |
qnt_estimateGas | Gas estimation |
qnt_getCode | Account code |
qnt_getStorageAt | Storage slot |
Quantos-specific
| Method | Purpose |
|---|---|
qnt_deployContract | Deploy a contract |
qnt_getContractMetadata | Contract metadata |
qnt_verifyContract | Verify a contract |
qnt_getSlot / qnt_getFinalizedSlot | Consensus slot state |
qnt_getMetrics | Node and performance metrics |
qnt_getShardInfo | Shard information |
Account
| Method | Purpose |
|---|---|
qnt_getAccount | Full account record |
qnt_getStateRoot | State root |
Network & node
| Method | Purpose |
|---|---|
qnt_nodeInfo | Node information |
qnt_health | Health check |
qnt_syncing | Sync status |
qnt_peerCount / qnt_getPeers | Peer information |
Validators
| Method | Purpose |
|---|---|
qnt_getValidators | Active validator set |
qnt_getValidatorByAddress | Validator by address |
qnt_getValidatorStats | Validator statistics |
qnt_getEpochRewards | Epoch rewards |
Ingress buffer (formerly mempool)
| Method | Purpose |
|---|---|
qnt_pendingTransactions | Pending transactions |
qnt_txPoolStatus | Ingress buffer status |
DAG
| Method | Purpose |
|---|---|
qnt_getVertexByHash | Vertex by hash |
qnt_getDagTips | DAG tips |
Batch
| Method | Purpose |
|---|---|
qnt_sendRawTransactionBatch | Submit a batch of signed transactions |
The full method set must be verified against the active RPC server and network configuration before being treated as a stable public API.
27.5 Observability
A node exposes metrics (via qnt_getMetrics and the monitoring stack) covering throughput, consensus latency, finalized slot, ingress buffer depth, peer count and diversity, and rebalancing activity. The Explorer API additionally exposes GET /v1/metrics and GET /v1/health (see §25.5). These feed the sustainability and security signals described elsewhere (rent coverage, eclipse-resistance peer diversity, time-drift alerts), so operators can observe the network's health rather than infer it.
27.6 Benchmarking
The repository includes benchmark programs, but benchmark names, coverage and results must be checked against the exact source commit. A publication-ready report must include hardware, topology, validator count, transaction mix, cross-shard ratio, conflicts, failed admissions, resource use and finality latency.