Node Types & Requirements
Relix relies on a network of independently operated nodes. Each node type has a clear role in the protocol and slightly different expectations in terms of hardware, connectivity, and operational discipline.
This section describes the main node categories on Relix and outlines baseline requirements for running them during the testnet phase.
1. Node roles in the Relix network
Relix distinguishes between several logical roles:
Validator nodes Participate in Proof of Stake, propose and validate blocks, and help secure the chain.
Full nodes Maintain a complete, verified copy of the blockchain and state, relaying blocks and transactions across the network.
RPC / gateway nodes Full nodes with additional infrastructure for serving traffic from wallets, dApps, and backend services via JSON-RPC.
Archive nodes (optional, advanced) Retain full historical state and are used for deep analytics, historical queries, and certain classes of debugging.
In small deployments, one physical server may act as both a validator and an RPC endpoint. For production-grade setups, it is strongly recommended to separate these concerns.
2. Validator nodes
Purpose
Validator nodes are at the heart of Relix’s Proof of Stake design. They:
Propose new blocks when selected by the consensus engine
Validate and sign blocks proposed by other validators
Contribute to finality and overall network security
Because they hold stake and participate in consensus, validator nodes must be treated as critical infrastructure.
Operational expectations
High uptime and stable connectivity
Timely software updates when protocol releases are announced
Secure key management and minimal attack surface
Indicative hardware (testnet / early mainnet)
These figures are guidelines, not strict limits. Operators can scale up as usage grows.
CPU:
Minimum: 2–4 vCPUs
Recommended: 4–8 vCPUs for comfortable headroom
RAM:
Minimum: 8 GB
Recommended: 16 GB or more for busy environments
Storage:
SSD storage (NVMe preferred)
Starting from ~500 GB for testnet, with space to grow as chain history accumulates
IOPS matter more than raw capacity; avoid slow HDDs
Network:
Stable, low-latency connection
Minimum: 50–100 Mbps symmetric
Public IP or properly configured port forwarding
Operating system:
64-bit Linux distribution (Ubuntu, Debian or equivalent)
Hardened and regularly patched
For production, operators often place validator nodes behind sentry nodes or firewalls, isolating the validator from direct public traffic and reducing exposure to attacks.
3. Full nodes
Purpose
Full nodes are the backbone of the protocol. They:
Download, verify, and store every block
Reconstruct the full state from genesis
Relay transactions and blocks to peers
Serve data to wallets, dApps, and other infrastructure components
Full nodes do not need to stake RLX or sign blocks, but they strictly enforce protocol rules and help keep the network decentralized.
Typical use cases
Internal infrastructure for development teams
Data providers for analytics and monitoring
Reliable peers for validators and RPC gateways
Indicative hardware
Full nodes have similar requirements to validators, but without the additional constraints around key security.
CPU: 2–4 vCPUs (more for high-traffic setups)
RAM: 8–16 GB
Storage:
SSD, starting around 500 GB for testnet
Plan for steady growth as the chain matures
Network:
Consistent connectivity with sufficient upstream bandwidth
Ability to maintain peer connections over time
Running one or more full nodes under your control is strongly recommended if your application depends heavily on Relix. It reduces reliance on public RPC endpoints and gives you better visibility into network behavior.
4. RPC / gateway nodes
Purpose
RPC nodes expose the Relix JSON-RPC interface to external clients:
Wallets (MetaMask, Rabby, OKX Wallet, etc.)
Frontend dApps
Backend services and indexers
They are often full nodes with:
Additional CPU and memory to handle concurrent requests
Reverse proxies, rate limiting, TLS termination, and logging
Monitoring and alerting for performance and availability
Typical requirements
For a public-facing RPC endpoint, plan for higher load:
CPU: 4–8 vCPUs or more, depending on expected traffic
RAM: 16–32 GB for comfort under peak usage
Storage: SSD, same order of magnitude as full nodes, with room for growth
Network: High-throughput, low-latency link with sufficient bandwidth and no aggressive throttling
You may also want:
Load balancers in front of multiple RPC nodes
Separate internal and external endpoints (for example, one for indexers, one for public dApps)
Logging and metrics (Prometheus, Grafana, or similar) to track request volume and error rates
For many teams, the initial setup is a single full node serving RPC to internal services, with the option to expand as the project scales.
5. Archive nodes (optional)
Purpose
Archive nodes keep:
The full history of the chain
Historical state for every block, not just the latest snapshot
This is useful when you need to:
Reconstruct precise balances and contract storage at arbitrary past blocks
Perform deep analytics across long time ranges
Support tools that rely on full historical state introspection
Requirements
Archive nodes place a heavier load on storage:
Storage:
Large SSD volumes, potentially several TB over time
Fast disks for queries and indexing
CPU / RAM:
Similar or higher than RPC nodes, depending on usage
Additional memory for heavy analytical queries
Archive nodes are not required for normal participation in the network. Most operators will only run them if they have a specific need for historical data.
6. General recommendations
Regardless of node type, a few practices apply across the board:
Use SSDs, not spinning disks The performance impact of slow storage can be dramatic for blockchain workloads.
Monitor everything Track CPU, RAM, disk usage, peer count, block height, and sync status. Alert on anomalies.
Plan for updates Stay informed about Relix releases and network announcements so you can upgrade nodes in an orderly way.
Isolate critical keys For validator nodes, keep signing keys separate from user access and general-purpose services.
Test on non-critical infrastructure first Apply new releases to a non-validator full node before touching production validators, whenever possible.
As Relix evolves from testnet into full production, these requirements and best practices will be refined. Operators should treat the values here as a starting point and adjust based on real-world usage, performance profiles, and their own risk appetite.
Last updated