# snarkOS: the node software where Aleo's encrypted state gets verified

> snarkOS is ProvableHQ's Apache-2.0 Rust decentralized operating system for zero-knowledge applications, forming the backbone of the Aleo network by verifying transactions and storing encrypted state in a publicly verifiable manner. It defines three node roles, validators bonded into consensus, ledger-keeping clients, and provers solving the Aleo puzzle, with hardware requirements measured in hundreds of gigabytes and core counts, current release v4.10.1.

**ProvableHQ/snarkOS** — A Decentralized Operating System for ZK Applications

- Repository: https://github.com/ProvableHQ/snarkOS
- Website: http://snarkos.org
- Stars: 4,530 · Forks: 2,697
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/provablehq-snarkos

## An operating system analogy that holds up

snarkOS is a decentralized operating system for zero-knowledge applications, and the analogy is structural rather than decorative, this code forms the backbone of the Aleo network, which verifies transactions and stores the encrypted state applications in a publicly verifiable manner. Applications on Aleo run as programs whose state is encrypted on the network, and snarkOS is the layer that executes the verification and maintains that state, the way an operating system schedules and accounts for processes. The implementation is Rust across a twenty member workspace, account, cli, display, node and utilities at the top, with the node crate subdivided into bft, cdn, consensus, metrics, network, rest, router, sync and tcp subcrates, and snarkVM pinned by git revision as the virtual machine executing the zero-knowledge programs themselves. The homepage at snarkos.org and the Aleo Discord and Twitter badges complete the public surface, while the repository itself stays focused on operations, build scripts, the node implementation and the tooling around them.

## Three node roles, one binary

The network's roles are defined precisely. Validators participate in consensus and must be started with an account bonded into the committee. Clients do not participate in consensus but maintain a ledger, providing information about the network and accepting solutions and transactions to communicate to peers, and for configuration management the documentation splits them into core clients connected directly to validators and outer clients connected only to other clients or provers. Provers are dedicated to solving the Aleo puzzle, participating in neither consensus nor ledger maintenance. The taxonomy matters operationally because everything downstream, hardware requirements, firewall rules, metrics exposure, is keyed to the role, and one Rust binary serves all three depending on how it is started. The core and outer client distinction exists because topology, not software, changes behavior, a core client always has a validator to answer questions, while an outer client must rely on its peers, so bandwidth and latency budgets differ even though both run the same binary.

## Hardware requirements in the hundreds of gigabytes

The requirements table is the most concrete part of the build guide. Clients want 64-bit Ubuntu 22.04, macOS Ventura or Windows 11, 24 cores with 32 preferred, 128GiB of DDR4 with 192 preferred, 2TB of NVMe on PCIe Gen 3 x4 or better with 4TB preferred, and 250Mbps symmetric upload and download. Validators escalate each row, Ubuntu only, 64 cores with 128 preferred, 256GiB with 384 preferred, 4TB with 6TB preferred, and 500Mbps symmetric. No recommendations are made for proving nodes because proving hardware may be highly variable, with the community's published resources suggested instead. Reading the table honestly, this is datacenter-class infrastructure for validators, and the numbers exist precisely so operators do not discover the shortfall at consensus time.

## Cloning mainnet, building with cargo

Installation begins with Rust, at least the version pinned in the repository's rust-toolchain file, then a clone with an explicit branch and history trim:

```
git clone --branch mainnet --single-branch https://github.com/ProvableHQ/snarkOS.git
```

followed by cd snarkOS, the Ubuntu helper script ./build_ubuntu.sh for dependencies, and the install itself:

```
cargo install --locked --path .
```

The branch flag carries the deployment decision, mainnet for production participation, while the repository's default branch is staging, where development lands first. The locked install flag pins the workspace's resolved dependency graph, and the toolchain file notes that the MSRV lives in three places, rust-toolchain, the Cargo manifest and the CircleCI config, a triple-keep-in-sync warning written into a comment. The locked flag deserves emphasis for reproducibility, the Cargo.lock beside the manifest pins the resolved graph, and without locked a fresh build could pull newer compatible versions than the ones the release was tested against, a silent drift no node operator wants mid-epoch.

## A port table that encodes the threat model

The port configuration section is a firewall policy per role, and the validator table reads as a security lesson. All roles open 4130/tcp to all sources for peer traffic. Outer clients add 3030/tcp, the REST server, to the world. Validators deny 3030 to everything, with the emphasis built into the table, this should always be disabled for validators, while opening 5000/tcp only to trusted validator IPs for BFT communication, and keeping 3000, the metrics dashboard, 9000, metrics export, and 9090, Prometheus metrics, inside an internal VPC or VPN. The distinction between client-facing and validator-facing surfaces is the whole model, a validator's consensus and telemetry endpoints must never share address space with its public peer port, and the table says so row by row.

## The open file limit, quantified

Beneath the port table sits an operating system tuning note with a number, ensure the open file limit is set to 16,384 or above, with the recommended setting echoed as shell lines, appending a username and nofile 65536 entry to /etc/security/limits.conf through tee, and a second line for the daemon scope. The requirement exists because a peer-to-peer node holds thousands of concurrent TCP connections, each a file descriptor, and a default ulimit of 1024 turns network growth into connection failures that look like bugs. That the README includes the exact commands, with the placeholder username called out for replacement, reflects how often operators hit the limit, the kind of fix that enters documentation only after breaking enough deployments.

## CUDA as a leftover, labeled honestly

The optional CUDA acceleration section is refreshingly candid. The CUDA build is optional, and the current snarkOS puzzle does not leverage CUDA acceleration, it is a leftover from a previous event, although CUDA may become relevant again with ARC-43. The feature is considered unstable and experimental with breaking changes expected, and the install for prover operators who want to experiment adds one feature flag, cargo install with the cuda feature beside the locked path install. For most operators the correct action is to skip it, and the documentation says so in effect, an unusual honesty in blockchain infrastructure where GPU features are usually marketed rather than caveated, and the ARC-43 reference marks the governance proposal that could revive the path. The section also signals how the project treats experimental paths generally, isolated behind feature flags with explicit stability labels, so the stable build path and the experimental one never blur, and an operator reading the feature flag list can see at a glance what is production and what is not.

## Workspace crates, release trains, and staging

The Cargo workspace's twenty members map the codebase's separation of concerns, account for key management, cli for the command surface, display for terminal output, node decomposed into bft with its events and storage services, consensus, cdn, metrics, network, rest, router with message types, sync with communication and locators, tcp and utilities. The snarkvm dependency pins a git revision annotated as staging plus mainnet_4_10_0, tying the virtual machine to the node release explicitly. Releases move quickly, v4.10.0 on 2026-09-15, the testnet-v4.10.1 tag a day later, and v4.10.1 on 2026-09-18, with the staging branch pushed 2026-09-25, Rust edition 2024, MSRV 1.96, and Apache-2.0 throughout, credited to The Aleo Team.

## Conclusion

Run snarkOS when participating in the Aleo network as a validator, client or prover, and size the machine honestly against its published requirements, 24 cores and 128GiB for clients, 64 cores and 256GiB for validators with Ubuntu 22.04, before committing. Skip CUDA acceleration unless experimenting, the README itself says the current puzzle does not leverage it and the feature is unstable. Before deploying a validator, apply the port firewall table exactly, keep the REST server on 3030 denied and the BFT, metrics and Prometheus ports inside a VPC or VPN, raise the open file limit to at least 16,384, and pin the branch deliberately, mainnet versus staging, since the default branch is staging.

## FAQ

### What is snarkOS?

snarkOS is a decentralized operating system for zero-knowledge applications, written in Rust under Apache-2.0, forming the backbone of the Aleo network by verifying transactions and storing encrypted application state in a publicly verifiable manner. It supports three node roles, validators in consensus, ledger-keeping clients, and provers solving the Aleo puzzle.

### What hardware does snarkOS require?

Clients need 24 cores, 128GiB of DDR4 memory, 2TB of NVMe storage and 250Mbps symmetric bandwidth, while validators need 64 cores, 256GiB, 4TB and 500Mbps, with preferred specifications higher on every row. Ubuntu 22.04 is required for validators, and no hardware recommendations are made for provers since proving hardware varies widely.

### Which ports must be open for a snarkOS validator?

Validators open 4130/tcp to all sources for peer traffic and 5000/tcp to trusted validator IPs for BFT communication, while the REST server on 3030/tcp should always be denied publicly, and the metrics dashboard on 3000, metrics export on 9000 and Prometheus metrics on 9090 should only be reachable from an internal VPC or VPN.

## Sources

- [License: Apache-2.0](https://github.com/ProvableHQ/snarkOS/blob/staging/LICENSE)
- [Project website](http://snarkos.org)
- [ProvableHQ/snarkOS on GitHub](https://github.com/ProvableHQ/snarkOS)
- [README](https://github.com/ProvableHQ/snarkOS/blob/staging/README.md)
- [Releases](https://github.com/ProvableHQ/snarkOS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/provablehq-snarkos