Running a Node

A dregg node participates in federation consensus, verifies STARK proofs, tracks nullifiers, and serves the HTTP/WebSocket API. It stores 32-byte commitments -- not cell contents.

Starting the Node

# Build from source
cargo build -p dregg-node --release

# Initialize data directory and generate keypair
dregg-node init --data-dir ~/.dregg

# Run with defaults (solo mode, localhost only)
dregg-node run

Full options for dregg-node run:

dregg-node run \
  --port 8420 \
  --bind 127.0.0.1 \
  --gossip-port 9420 \
  --data-dir ~/.dregg \
  --federation-peers "peer1:9420,peer2:9420" \
  --federation-mode full \
  --consensus blocklace \
  --checkpoint-interval 1000

Multi-Group Participation

A node can participate in multiple reference groups simultaneously. Each group has its own membership set and tau ordering. Cross-group communication uses interest-based dissemination with cryptographic cross-references on the shared DAG.

dregg-node run --groups <group-id-hex-1>,<group-id-hex-2>

Group IDs are 64-character hex strings. When specified, the node joins each group's Constitutional Consensus process and contributes blocks to each group's portion of the blocklace.

Relay Operation

Relay operators host inboxes for offline message delivery (store-and-forward). This is a separate service from the main node:

dregg-node relay \
  --port 3100 \
  --bond 10000 \
  --max-capacity 100000 \
  --gc-interval 300 \
  --message-ttl 1000 \
  --max-delivery-latency 50

• Bond -- computrons staked as operator collateral.
• GC interval -- seconds between garbage collection sweeps.
• Message TTL -- blocks before undelivered messages are pruned.
• Max delivery latency -- SLA in blocks; exceeding this slashes bond.

Relay operators earn fees for hosting inboxes. Subscribers pay deposits proportional to inbox size.

Monitoring and Health Checks

The node exposes several monitoring endpoints:

# Health check (HTTP)
curl http://127.0.0.1:8420/status

# Node status via CLI
dregg node status

# System health (cclerk, federation, storage)
dregg doctor

Key things to monitor:

• Sync state -- is the node caught up to the frontier? Check block height vs peers.
• Peer count -- are gossip connections healthy? Federation mode needs 2f+1.
• Nullifier set size -- growing unboundedly indicates pruning is needed.
• Checkpoint lag -- are checkpoints being produced on schedule?
• Proof verification time -- if degrading, check CPU/memory.

The node emits structured tracing via tracing. Set RUST_LOG=dregg_node=info for production, =debug for troubleshooting.

Genesis State and Deployment

For new networks, generate genesis configuration:

dregg-node genesis \
  --validators 4 \
  --epoch-length 1000 \
  --checkpoint-interval 100 \
  --output ./devnet-config

This produces keypairs and a genesis.json for each validator. Distribute keys securely and start all nodes with matching genesis state.

Federation Modes

• solo -- single-node devnet. Processes turns immediately, no gossip, tentative receipts. Auto-upgrades to full when peers appear.
• full -- BFT quorum. Requires peer connections. Uses blocklace consensus with tau ordering (3-round finality).

Storage Management

By default the node runs in archival mode (keeps all history). Enable pruning to bound storage growth:

dregg-node run --enable-pruning --checkpoint-interval 1000

With pruning enabled, blocks below the latest checkpoint are removed. New nodes can fast-sync from the latest checkpoint instead of replaying the full history.