Ciphernode Requirements

This page lists what a host needs to run a ciphernode. It is for operators who plan a new node or size a server. Some limits are enforced by the node code, and this page says so. Other numbers are guidance from earlier deployments, and the node does not check them. At the end, you can choose a host and open the correct ports.

Hardware

A ciphernode runs threshold cryptography and makes zero-knowledge proofs. The work uses a lot of CPU and memory during DKG and proof generation. Memory is the only hardware value that the node checks.

How the node sizes its prover work

The node runs CPU-heavy jobs (zero-knowledge proofs and threshold BFV work) in a shared pool. The number of concurrent jobs is the smallest of three values:

• The requested value, node.multithread_concurrent_jobs (default 2).
• The number of logical CPUs minus node.multithread_reserve_threads (default 2).
• The memory limit: one job for each 13 GiB after a 4 GiB reserve for the node and the host.

On Linux, the node reads the host memory (MemTotal in /proc/meminfo) and the cgroup memory limit, and it uses the smaller value. A container memory limit is a cgroup limit. When the result is lower than the requested value, the node logs Reduced compute concurrency to fit detected CPU and memory limits.

When the memory limit is too small for one job, startup stops with this error:

the detected memory limit cannot safely run one prover job in addition to the node; increase the host or cgroup memory limit

The node never admits more jobs than the memory limit allows, also when you set a higher multithread_concurrent_jobs. You can set the value in the configuration file or with the E3_NODE__MULTITHREAD_CONCURRENT_JOBS environment variable.

When a proof job fails

The node retries a failed proof job or key-share job. The wait between attempts is 5 s, 15 s, 60 s, and then 300 s for each later attempt. From the second attempt, proof jobs run Barretenberg in low-memory mode (--slow_low_memory). The node stops the retries when the E3 reaches a terminal stage. The warning Compute worker failed; automatic recovery remains active does not mean that the E3 failed.

Operating systems and platforms

Each release publishes two interfold binaries and one Docker image. Other platforms must build the CLI from source.

The memory check reads Linux interfaces. On macOS, the node does not detect a memory limit, so the check does not stop startup. To build from source, use the Rust toolchain in rust-toolchain.toml (Rust 1.91.1). The DAppNode package is built for linux/amd64.

Network ports

The DAppNode Mainnet package uses UDP port 37173 for QUIC, and the Sepolia package uses 37174. Cloud firewalls (for example, AWS security groups or GCP firewall rules) must allow inbound UDP on the QUIC port. Behind NAT, forward the same UDP port to the host.

The node accepts at most 8 inbound connections from one IP address (for IPv6, from one /56 prefix). You do not need a firewall rule for this. If you add a per-source limit on the QUIC port, set it to 8 or more, because several nodes can share one address. A firewall counts UDP flows, and one flow can carry more than one QUIC connection, so a firewall limit does not replace the node's limit.

The node finds its first peers through a DNS bootstrap address for its network: /dnsaddr/bootstrap.interfold.network on mainnet and /dnsaddr/bootstrap-sepolia.interfold.network on Sepolia. See Run a Ciphernode to set peers.

Network bandwidth

The node does not check its bandwidth. Upload bandwidth is the limit. When the node is in a committee, it sends a threshold share of approximately 1.8 MB to each other member during the DKG. The node uploads one share at a time. Each upload sends the share to up to 20 peers at the same time, and each transfer has 60 seconds to complete.

Other traffic on the same connection decreases the upload that the node can use. Examples are backups, file synchronization, video calls, and a second node.

For each E3 where the node is in the committee, the node sends approximately 1 GB when it first sends its shares, and it receives approximately the same quantity. Until the committee public key is published, the node sends each of its documents again approximately every 30 minutes. A node that is not in the committee also sends data, because it keeps copies of the shares of other nodes and sends them to peers that ask for them.

The values come from a test of the v0.19.0 network code: 30 nodes on one host, with documents of the size that the secure parameters make. The test did not limit download bandwidth.

RPC endpoints

A ciphernode needs two endpoints for each chain:

• An Ethereum endpoint with a WebSocket URL (ws:// or wss://). The node subscribes to contract logs with eth_subscribe. The endpoint must keep the log history from the contract deploy blocks.
• An Avail HTTP endpoint (http:// or https://) for data availability. The node refuses to start when a chain has no data_availability entry.

An endpoint that dropped old logs can return an empty result without an error. Test your Ethereum endpoint on RPC Endpoints before the first sync.

Disk and storage

The node keeps its state in a .interfold directory next to its configuration file. Run interfold config get db_file to print the exact path.

<name> is the node profile name. The default profile is _default. The data_dir and config_dir keys move the data and key directories.

Disk use grows with the E3 history that the node keeps. Events up to 32 MiB stay inside the event log. A larger local event, for example a proof work plan, goes to a separate file in event-blobs-v1. Each blob file is limited to 512 MiB. The node checks the length and SHA-256 hash of each blob when it reads it.

At startup, the node deletes only blob files that no committed event references. Blob files that the event log references stay on disk, also after their E3 completes.

The disk values in the hardware table are first allocations, not retention estimates. Monitor free space and growth for each E3, and expand the volume before it is full. Back up the complete .interfold directory as one unit. Use SSD storage, because slow disk access can make the node miss protocol windows. Migrate a Node explains how to move this directory.

Software

This page covers ciphernodes only. For a development environment, see Installation. For compute provider hosts, see Compute Provider.

Check resource use

The node dashboard shows node health. On a Linux host, these commands show the system resources:

# Memory
free -h
 
# CPU and memory for each process
htop
 
# Free disk space
df -h
 
# The QUIC listener (UDP). Replace 9091 if you changed node.quic_port.
ss -ulnp | grep 9091

Next steps