Sui validator hardware is not Ethereum validator hardware. The consensus mechanism is different, the execution model is different, the state shape is different, and the network latency profile is fundamentally different. Operators who size a Sui validator using Ethereum reference numbers — 16 cores, 64 GB RAM, 4 TB SSD — will run into capacity walls within months. This article is the consolidated picture of what a Sui validator actually requires today, anchored on Mysten Labs' upstream guidance, our own production experience operating the chain since mainnet, and the things that are not in any documentation but show up six months into running the workload.
Two preliminary clarifications. First, all numbers below describe a Sui mainnet validator on the active set — not a full-node operator, not a public RPC operator, not a testnet validator. The active-validator role is the most demanding configuration. Public-RPC operators have a related but distinct sizing exercise (we describe ours at /docs#rpc-sui). Second, the Sui validator workload changes meaningfully across protocol upgrades; the numbers below reflect the state of the protocol as of mid-2026, post-protocol-version 70-something. Sui ships fast; expect to re-evaluate annually.
What makes Sui different
Three architectural choices in Sui drive hardware requirements that diverge from EVM-family chains. The first is Narwhal-Bullshark consensus. Narwhal is a DAG-based mempool that decouples transaction dissemination from ordering; Bullshark is the BFT consensus that finalises a total order over the DAG. The combination produces high throughput and sub-second finality, but it places consistent CPU pressure on the validator host — workers, primaries, and the consensus committee all run concurrent goroutines, and the throughput profile is closer to a database server than to a single-process blockchain client.
The second is parallel execution via the object model. Move transactions in Sui declare which objects they read and write; the scheduler executes non-conflicting transactions in parallel, exploiting the full multi-core CPU on the validator host. This is the architectural reason Sui scales horizontally on a single machine where EVM chains scale only via L2s. The operational consequence is that core count matters more on Sui than on Ethereum — 8 cores on Ethereum will keep up; 8 cores on Sui will leave performance on the table.
The third is state growth shape. Sui state is object-centric; the live object set grows with usage, and dynamic fields under shared objects can grow without bound if a popular application uses them aggressively. Pruning is aggressive but not free, and snapshot strategy is a real operational concern rather than a nice-to-have. Plan for state larger than your initial sizing within 12-18 months.
Baseline specs: the institutional floor
Mysten Labs publishes hardware guidance for validators at docs.sui.io/guides/operator/validator-config. The institutional floor we deploy in production today goes somewhat above the published minimum, because the published minimum is exactly that — a minimum, with no headroom for traffic spikes, protocol upgrades, or the gradual state growth that the operator will face in year two.
- CPU: 24 modern cores minimum, 32 cores recommended. AMD EPYC 9354 (32 cores, 64 threads) or EPYC 7543 (32 cores) are the right shelf. Per-core clock speed matters less than on Ethereum because the parallel execution exploits core count; that said, avoid older or lower-clocked SKUs — the Move VM hot path benefits from modern IPC. - RAM: 128 GB minimum, 256 GB recommended, ECC required. Sui is materially more RAM-hungry than EVM chains. The mempool, the consensus committee state, the in-memory object cache, and the JSON-RPC server collectively can consume 80-120 GB during periods of high load. 64 GB is the published minimum but will produce OOM events on a busy mainnet validator within the first few protocol upgrades. - Storage: 4 TB NVMe enterprise SSD as the absolute floor, 8 TB recommended for 2026 deployments with explicit headroom for state growth into 2027. Samsung PM9A3, Solidigm D7-P5520, or Micron 7450 Pro. ZFS or XFS with snapshot capability; the snapshot capability matters because Sui state snapshots are a real recovery primitive. - Network: 1 Gbps symmetric minimum, with low and consistent latency to other validators in the active set. Monthly bandwidth budget 10-20 TB at current mainnet activity, with explicit room to grow. Public IPv4; IPv6 optional but increasingly relevant. - Disk IOPS: random-read IOPS matters more on Sui than on Ethereum because of the object-model access pattern. Enterprise NVMe with 600k+ random-read IOPS is the right target; consumer NVMe with 400k IOPS will work until it does not. - Power: redundant PSU. UPS-backed. Generator-backed datacenter.
Consensus footprint: Narwhal and Bullshark
The Sui validator binary runs several long-lived processes that cooperate to produce consensus. The Narwhal primary handles block production and mempool dissemination; Narwhal workers handle batched transaction ingest; Bullshark runs over the Narwhal DAG to commit total order. Each of these is CPU-bound during peak load, and the validator host has to be sized so that no one of them starves the others under contention.
In production, we observe Narwhal workers consuming 4-8 cores under typical mainnet load, the Narwhal primary consuming 2-4 cores, and Bullshark consensus consuming 4-6 cores. The execution layer running Move transactions in parallel can consume the remaining cores opportunistically — the parallelism in the execution layer is what makes the 32-core deployment substantially faster than the 16-core minimum, because the execution layer scales close to linearly with available cores when the workload contains non-conflicting transactions.
Memory footprint follows the same shape. The mempool can hold tens of thousands of pending transactions during peak load; the consensus committee state is non-trivial; the object cache (which is the single most important performance optimisation for the execution layer) wants as much RAM as the operator is willing to give it. We allocate ~80 GB of the 256 GB host to the validator process and the object cache; the remainder is OS, filesystem cache, monitoring, and explicit headroom for the JSON-RPC server during traffic spikes.
Network: latency to peers is a first-class concern
Sui is a BFT consensus protocol. Block production requires a quorum of validators to communicate within the consensus round-trip window. The network path between validators is therefore directly in the critical path of validator performance — high or jittery latency to peers produces measurable degradation in the validator's vote credit and, if persistent, eventually triggers the peer-reporting mechanism that reduces the validator's reward share.
The practical implication is that Sui validators benefit materially from being hosted on networks with direct peering to other validators and with low-jitter international transit. For 01node, this is one of the structural arguments for our own ASN — AS41536 with direct peering to Tier 1 carriers gives us a consistently lower and less variable network path to other validators in Europe and to the Asian validators that dominate the Sui active set than any cloud-region deployment would provide.
Public-facing traffic — RPC requests, peer-discovery messages from full nodes, JSON-RPC clients — should not share the network path with consensus traffic. We separate them at the firewall layer and prioritise consensus traffic at the QoS layer. This is not an optimisation; it is a precondition for stable consensus performance during periods of high public RPC load.
RPC overhead: GraphQL and gRPC on top of the validator
01node operates public Sui RPC endpoints — GraphQL at sui.01.ro/graphql and gRPC at sui.01.ro:443. The RPC workload is operationally separate from the validator workload in our deployment, but worth describing because operators evaluating Sui infrastructure costs need to understand the full picture if they intend to offer RPC alongside validation.
GraphQL adds significant CPU pressure during query bursts — the resolver pipeline is heavier than gRPC, and complex queries against large object sets can produce single-request CPU spikes that, on a validator-co-located deployment, would compete with consensus for cores. gRPC is materially lighter — binary protobuf serialisation, streaming subscriptions for checkpoint data, and a more predictable per-request CPU profile. Operators planning to expose both interfaces should size for the GraphQL footprint and treat the gRPC footprint as a small additional load.
We do not co-locate validator and public RPC on the same host. The validator runs on hardware sized for the validator workload as described above; the public RPC runs on a separate set of full-node hosts with their own resource budget. This separation is what makes it operationally honest to claim 99.99% consensus performance on the validator side and >50ms RPC latency on the RPC side simultaneously.
Snapshot strategy: a real operational primitive
Sui state can be restored from snapshots, and snapshot management is part of a credible Sui operations runbook. Without snapshots, a validator that suffers corrupt state has to re-sync from genesis — a multi-day operation that costs the operator both validator performance penalties and lost reward income during the sync window.
We take snapshots every 4 hours, retain 72 hours of rolling history, and ship daily snapshots to a separate datacenter for off-host recovery. The snapshot mechanism uses Sui's native checkpoint format; storage cost is significant (~50-80 GB per snapshot at current state size, growing through 2026) but the operational value during a state-corruption event is the difference between a 30-minute restore and a multi-day re-sync.
On the storage side, this requires planning for the snapshot footprint in addition to the live state footprint. The 8 TB recommendation above accounts for live state, snapshot retention, and the operational headroom that any production deployment needs.
What we run at 01node
On the Sui validator host today: AMD EPYC 9354 (32 cores, 64 threads). 256 GB ECC DDR5 — well above the published minimum, because Sui rewards memory headroom in ways that show up in vote credit performance and stability under load. 4× 4 TB enterprise NVMe in a ZFS RAIDZ2 configuration, with snapshot retention on a separate NVMe partition. Redundant PSU. Two Tier III TIA-942 datacenters in Bucharest, physically separate, on different power grids, with diverse upstream transit.
AS41536 with our own BGP policy, direct Tier 1 peering, 20+ Gbps of upstream transit. 140 Gbps of upstream DDoS mitigation. Public RPC (GraphQL + gRPC) runs on separate full-node hosts within the same datacenter footprint but with independent resource budget — the architecture is documented at /docs#rpc-sui.
Our validator is verifiable on Suiscan, and SUI holders can delegate to us directly from explorer.sui.io. The chain identifier returned by our node is the canonical Sui mainnet identifier 4btiuiMPvEENsttpZC7CZ53DruC3MAgfznDbASZ7DR6S; the full set of on-chain receipts for our operator credentials is at /operator-credentials.
Common mistakes that show up in year two
Under-sizing RAM is the most common one. Sui mainnet operators who deployed at the published minimum 64 GB in 2024 began experiencing OOM events through 2025 as state grew and the in-memory object cache had less room. The validator does not gracefully degrade under memory pressure; it eventually OOMs, restarts, misses checkpoints, and accumulates peer-reporting penalties before the on-call engineer responds. 128 GB is the floor we would deploy today; 256 GB removes the concern entirely for the next 18-24 months of state growth.
Consumer NVMe is the second. The random-read access pattern that Sui's object model produces is brutal on consumer drives — they keep up for 6-12 months and then random-read latency rises noticeably as the drive's internal mapping degrades. The validator's vote credit performance drops 1-3 percentage points before the operator notices. Enterprise NVMe (PM9A3, D7-P5520, 7450 Pro) does not have this profile.
Cloud-hosted Sui validators are the third, and the failure mode is specific: cloud network latency variance is high enough that Sui validators co-located in the same cloud region produce visibly worse consensus performance than bare-metal validators with direct peering. We have seen this in the public mainnet performance data, and it is the structural reason no major Sui validator in the European active set runs on AWS or GCP today.
Skipping snapshot management is the fourth. Operators deploying Sui without a snapshot strategy will eventually hit a state-corruption event — kernel bug, filesystem issue, sudden power loss without proper UPS — and discover that re-syncing from genesis takes days during which the validator misses checkpoints and accumulates penalties. The recovery cost of skipping snapshots is much higher than the storage cost of keeping them.
Treating the network as an afterthought is the fifth. Sui's BFT consensus depends on low-latency communication between validators; an operator who deploys on residential Gigabit fibre with best-effort routing will produce visibly worse vote credit performance than an operator on dedicated peering. The validator works; it just does not perform at the level institutional delegators expect.
How 01node is positioned
We have operated a Sui validator since mainnet launch with consistent active-set participation and a zero-slashing-equivalent record across the lifecycle of our delegation. The hardware is documented above; the public RPC architecture is at /docs#rpc-sui; the validator address and on-chain receipts are at /operator-credentials. Our Sui-specific commentary and ecosystem coverage — Suilend, the Facebook-to-Sui retrospective, the institutional thesis — is in the blog index under the Sui tag.
For Sui delegators evaluating us against another operator, the comparison should turn on what we actually produce — vote credit consistency, RPC availability, peer-reporting score, network latency to other validators in the active set — rather than on marketing claims. We are happy to share production metrics in a technical call. For Mysten Labs, institutional delegators, and ecosystem partners interested in the deeper architecture, the trust pack at /trust-pack.pdf consolidates the public evidence; the unredacted version is delivered under NDA on request to [email protected].