config-hardware
Hardware requirements for Arbitrum chains
Arbitrum chains, including Arbitrum One, Nova, and customizable Arbitrum L2/L3 chains, have varying hardware needs depending on the node type. Requirements are generally modest compared to Ethereum L1 nodes, with a focus on accessibility for decentralized participation. The specs are for nodes handling limited RPC requests; scale up for high traffic. Full nodes form the base, with validators and sequencers building on them. Archive nodes require more storage for historical data.
Key considerations:
- OS: Linux or macOS recommended; Docker is commonly used for setups.
- Bandwidth: At least 100 Mbps for syncing and RPC; higher for sequencers to minimize latency.
- Storage: NVMe SSD preferred for speed; data grows over time (e.g., Arbitrum One chain data ~1TB+).
- Scaling: Increase CPU/RAM for multiple RPC requests or during disputes (e.g., BoLD challenges). Use cloud providers like AWS t3.xlarge for baseline.
- Arbitrum chain-specific: Storage requirements are similar. If running AnyTrust, you will need to run your own DAS or use a third-party DA service provider.
- General Tip: Start with minimums and monitor; overprovision for reliability. No internet access needed post-sync, but initial sync requires a stable connection.
Full node (base for most setups)
Runs the chain state, serves RPCs, and syncs data. Non-archive by default.
| Component | Minimum | Recommended | Notes |
|---|---|---|---|
| CPU | 4 cores (multi-core processor) | 8+ cores (e.g., Intel i7 or AMD Ryzen 7) | Single-core performance key; upgrade if node lags. For limited RPC. |
| RAM | 16 GB | 32 GB+ | Scale with RPC load; more for simultaneous requests. |
| Storage | 1 TB NVMe SSD | 2 TB+ | Depends on chain traffic; Arbitrum One ~1TB, grows ~100GB/month. |
| Bandwidth | 100 Mbps | 1 Gbps | For initial sync (days to weeks). |
Validator node
Monitors assertions and challenges fraud. Runs on top of a full node with staker software enabled. BoLD upgrade makes it more efficient, assuming one honest party.
| Component | Minimum | Recommended | Notes |
|---|---|---|---|
| CPU | 4 cores | 8 cores | Needs fast computation for disputes; BoLD reduces multi-challenge load. |
| RAM | 8 GB | 16-32 GB | Similar to full node; more if running defensive mode. |
| Storage | 1 TB NVMe SSD | 2 TB+ | Includes chain data |
| Bandwidth | 100 Mbps | 500 Mbps+ | For monitoring and bonding (e.g., 3,600 ETH equivalent stake). |
| Other | Bonding funds; WASM support | VPS/cloud for uptime | Permissioned for low-TVL chains; permissionless needs higher bonds/resources. |
Sequencer node
Orders transactions, posts batches. Centralized in main chains (run by Offchain Labs), but customizable for Arbitrum chains (e.g., via RaaS like Gelato/Caldera). Focus on low latency; hardware similar to full node but optimized for throughput.
| Component | Minimum | Recommended | Notes |
|---|---|---|---|
| CPU | 4-8 cores | 16+ cores | High clock speed for tx processing; latency-sensitive. |
| RAM | 16 GB | 32-64 GB | Handles mempool and batching; more for high TPS Arbitrum chains. |
| Storage | 1 TB NVMe SSD | 2 TB+ | For logs and state; fast I/O critical. |
| Bandwidth | 1 Gbps | 10 Gbps+ | Low-latency network; private mempool integration. |
| Other | Docker/Nitro stack | Dedicated server/cloud | In Arbitrum chains using AnyTrust, lower due to DAC; self-host or RaaS for control. |
Archive node
Optional for full history querying; builds on full node.
| Component | Minimum | Recommended | Notes |
|---|---|---|---|
| CPU | 4 cores | 8+ cores | Similar to full, but more for pruning disabled. |
| RAM | 16 GB | 32 GB+ | - |
| Storage | 2 TB SSD | 4 TB+ | Historical data balloons size (e.g., 2-5x full node). |
Decisions to Make:
- Node Type: Full for basic, validator for security contribution, sequencer for Arbitrum chain sovereignty.
- Chain Mode: Storage requirements are similar for Rollup or AnyTrust.
- Hosting: Self-host (control, cost) vs. RaaS/cloud (ease, fees). Start local, scale to VPS.
- BoLD Enablement: For validators, reduces hardware during disputes but requires an upgrade.
- Monitoring: Use tools like Prometheus; budget for growth (e.g., +20% resources yearly).
- When to Upgrade: If CPU >80% or sync lags, add resources. Test on Sepolia.
Consult official docs for updates; requirements evolve with traffic.