QUANTARA • QUANTUM-RESISTANT L1
Benchmarks guide for Quantara Devnet-0
How to run safe, repeatable benchmarks against Quantara — from local micro-benches to Devnet-0 load tests and dashboard-driven analysis.
Docs • Performance
Benchmarks guide for Quantara Devnet-0
This guide explains how we think about performance on Quantara, how to run safe benchmarks against Devnet-0, and how to share results that actually help us improve the network.
Devnet-0 is where we push the protocol and the node to their limits before we expose a wider public testnet. Benchmarks are how we learn where things break — and how much headroom we have before they do.
This page focuses on the operator-facing view: how to run repeatable tests, what to look for in dashboards, and how to avoid stressing the network in ways that don't teach us anything.
For details of specific test plans and numbers, pair this guide with the Devnet-0 overview, Status updates, and any performance notes in the Release artifacts doc.
Devnet-0 is not a stress-spam arena. Always coordinate heavy tests with the Quantara team and other validators so we can capture metrics and avoid misleading results.
Devnet-0 performance snapshot
Last updated: 2025-11-23 22:00 UTC. Target block time, weights tuning, and benchmark campaigns will evolve as we refine Devnet-0. Check /status for current performance focus.
1 • What we measure
Core performance signals on Quantara
Blockchains are complex systems. These are the top-level numbers we care about when we say “performance.”
1.1 — Block production
- • Time between blocks vs. target (e.g., 6s).
- • Empty vs. full block ratios.
- • Outliers where blocks take significantly longer.
1.2 — Finality & forks
- • Time from inclusion to GRANDPA finality.
- • Reorg depth and frequency under load.
- • Any evidence of equivocation or stalled voting.
1.3 — Throughput & latency
- • Transactions per second (ingest and finalized).
- • RPC latency for common calls.
- • Queue depth and time-to-inclusion for user TXs.
1.4 — Resource usage
- • CPU, RAM, and disk I/O at validators and RPCs.
- • Network bandwidth and peer counts.
- • DB size growth over time.
2 • Benchmark types
Three layers of benchmarking
Most performance work fits into three buckets: micro-benchmarks, node-level load tests, and full-network exercises.
2.1 — Micro-benchmarks (local)
- • Measure individual primitives, pallets, or runtime calls.
- • Run locally or in CI, no network required.
- • Used to derive weight constants and regression tests.
- • Good for “did we make X faster or slower?” questions.
2.2 — Node-level load tests
- • Focus on a single node or small cluster.
- • Synthetic transaction generators push specific flows.
- • Ideal for RPC tuning, database settings, and caching.
- • Can run in isolated environments without main Devnet-0.
2.3 — Full-network drills
- • Coordinated tests against the live Devnet-0 network.
- • Validate end-to-end behavior under realistic load.
- • Require scheduling and clear success criteria.
- • Best used sparingly, with full metrics capture.
3 • Local & CI
Running local and CI benchmarks
Before you ever touch Devnet-0, you can learn a lot from local and CI-driven benches.
3.1 — Local developer flow
- • Use the Quantara repo's benchmark targets & scripts.
- • Pin Rust toolchain and features to the versions we use.
- • Capture CPU model, cores, and memory in your notes.
- • Run before and after changes to confirm performance impact.
See the in-repo BENCHMARKS_GUIDE.md for exact CLI examples and environment variables.
3.2 — CI and regression checks
- • CI runs a curated subset of benchmarks on fixed hosts.
- • Results are compared to a rolling baseline.
- • Significant regressions are flagged for review.
- • As an external builder, you can mirror this pattern in your own CI for custom pallets or apps.
4 • Devnet-0 load tests
Coordinated load tests on the live network
When you’re ready to test end-to-end behavior, Devnet-0 is the place — but only with a clear plan and coordination.
4.1 — Before you start
- • Share your test plan in validator / ops channels.
- • Agree on start/stop times and target intensity.
- • Ensure monitoring and log capture are in place.
- • Confirm no conflicting maintenance or incidents.
4.2 — During the test
- • Track block time, finality, and forks in dashboards.
- • Watch CPU, RAM, disk, and network saturation.
- • Record which nodes are generating load.
- • Keep a timeline of notable events or anomalies.
4.3 — After the test
- • Capture metrics snapshots and export key graphs.
- • Summarize peak throughput and resource usage.
- • Note any limits hit (DB, network, consensus).
- • Share findings with Quantara; link to a short write-up if possible.
5 • Interpreting results
Turning raw numbers into useful insights
Good benchmark reports don’t just say “X TPS” — they explain conditions, limits, and next steps.
5.1 — What to include in a report
- • Hardware specs and node roles involved.
- • Chain spec, runtime version, and node version.
- • Traffic pattern (tx types, batch sizes, senders).
- • Key metrics: TPS, finality, resource usage, error rates.
- • Short narrative: what surprised you, good or bad.
5.2 — Common pitfalls
- • Mixing different runtime or node versions mid-test.
- • Running from a single noisy host with no baseline.
- • Ignoring DB growth or long-tail latencies.
- • Quoting TPS without clarifying finality assumptions.
The best benchmark reports are easy to reproduce and easy to compare to future runs. Treat your notes like a mini research paper, not just a screenshot of a Grafana panel.
6 • Safety & impact
Keeping Devnet-0 healthy while benchmarking
We want aggressive testing — but not chaos. A few ground rules keep Devnet-0 useful for everyone.
6.1 — Do
- • Coordinate high-intensity tests in advance.
- • Share your plan, goals, and exit criteria.
- • Capture metrics and logs from your own infra.
- • Help write up findings after major tests.
6.2 — Don’t
- • Randomly flood Devnet-0 at peak times.
- • Use private or sensitive keys in test traffic.
- • Ignore alerts or incidents triggered by your tests.
- • Publish numbers without explaining how you got them.
6.3 — When in doubt
- • Ask in validator / ops channels before a big test.
- • Treat surprising behavior as a potential Incident Response scenario.
- • Capture enough detail that we can reproduce issues later.
Next steps
From Devnet-0 benchmarks to mainnet readiness
If you can run disciplined benchmarks on Devnet-0, you’re already doing mainnet-grade performance work — just with safer stakes.
Use this guide as your high-level playbook, and lean on in-repo docs like BENCHMARKS_GUIDE.md for exact commands. As Devnet-0 evolves, we'll publish more structured benchmark campaigns, reference dashboards, and public reports.
The operators and builders who help us measure, understand, and push Quantara's limits on Devnet-0 are the ones we'll lean on most as we step into public testnet and mainnet.