DEV Community: Cleiton Augusto Correa Bezerra

We Benchmarked 4 Rust Quantum Simulators. Three Agreed. One Didn't.

Cleiton Augusto Correa Bezerra — Sun, 05 Jul 2026 11:42:18 +0000

We built CleitonForge — a neutral benchmarking layer for quantum simulation written in Rust. The idea is simple: take the same quantum circuit, run it through multiple simulators using an identical canonical IR, and compare. No favorites. No built-in assumptions about which framework is correct.

We plugged in four backends: our own native statevector, quantrs2, roqoqo, and q1tsim. On Bell states, Grover search, QFT, and Bernstein-Vazirani — all four agreed to machine precision. Then we ran QAOA.

Native vs quantrs2 fidelity: 0.00000000.

Not a rounding error. Not a bug in our code. A fundamental sign disagreement in how one framework defines the Rz gate — invisible in standard benchmarks, catastrophic in parameterized quantum algorithms.

The finding: two definitions of the same gate

The Rz(λ) gate is one of the most common in quantum computing. IBM, Qiskit, OpenQASM, and virtually every textbook define it as:

IBM / Qiskit convention — used by: native · roqoqo · q1tsim

Rz(λ) = ⎡ e^{−iλ/2}    0        ⎤
         ⎣    0       e^{+iλ/2}  ⎦

Opposite sign convention — used by: quantrs2-core

Rz(λ) = ⎡ e^{+iλ/2}    0        ⎤
         ⎣    0       e^{−iλ/2}  ⎦

The difference is a global sign flip in the exponent. For λ = 0, both give the identity — you can't tell them apart. For λ = π/4 (as in QAOA's cost layer), the two matrices produce orthogonal quantum states. Fidelity: exactly zero.

The evidence

We ran every backend through the same QAOA MaxCut circuit (2 qubits, γ = −3π/4, β = −π/8) and measured cross-backend fidelity:

Pair	Fidelity	Verdict
native ↔ roqoqo	1.00000000	✅ agree
native ↔ q1tsim	1.00000000	✅ agree
roqoqo ↔ q1tsim	1.00000000	✅ agree
native ↔ quantrs2	0.00000000	❌ differ
roqoqo ↔ quantrs2	0.00000000	❌ differ
q1tsim ↔ quantrs2	0.00000000	❌ differ

Why Quantum Volume doesn't catch it

We also ran the IBM Quantum Volume benchmark — Haar-random SU(4) circuits, 100 trials per width. All four backends returned identical HOG fractions to 4 decimal places:

Width n	QV	native	quantrs2	roqoqo	q1tsim
n = 2	—	0.5355	0.5355	0.5355	0.5355
n = 3	8	0.7340 ✅	0.7340 ✅	0.7340 ✅	0.7340 ✅
n = 4	16	0.7991 ✅	0.7991 ✅	0.7991 ✅	0.7991 ✅
n = 5	32	0.8459 ✅	0.8459 ✅	0.8459 ✅	0.8459 ✅

This is not a contradiction — it's the key insight. Quantum Volume uses random angles. When λ is drawn from a uniform distribution over [0, 2π), the sign flip averages out across the ensemble. The divergence only surfaces with specific, purposeful angles — exactly the kind used in QAOA, VQE, and other variational algorithms.

The implication: Standard Clifford benchmarks and random circuit tests are blind to this class of convention disagreement. You need a benchmark that exercises parameterized gates at specific angles — which is exactly what QAOA does, and exactly what CleitonForge's benchmark suite runs automatically across all backends.

The architecture that found it

CleitonForge is not a simulator. It's a neutral benchmarking layer that sits between circuits and simulators. Every backend receives the same canonical intermediate representation — a flat list of typed operations with no framework-specific encoding — and returns a statevector.

// Same circuit, four backends, zero code duplication
let circuit = parse_qasm2(qaoa_source)?;

let backends: &[(&str, &dyn SimulationBackend)] = &[
    ("native",   &NativeStateVectorBackend),
    ("quantrs2", &QuantRS2Backend),
    ("roqoqo",   &RoqoqoBackend),
    ("q1tsim",   &Q1tSimBackend),
];

for (name, backend) in backends {
    let result = backend.run(&circuit, /*shots=*/0, seed)?;
    measure_fidelity(&reference_sv, &result.statevector);
}

The canonical IR means backends never see each other's types. roqoqo's gate structs, q1tsim's matrix API, and quantrs2's internal representation are all adapted at the backend boundary. This is also why the Rz divergence is detectable: the input angle λ is the same floating-point value for all backends. The difference is entirely in how each framework's gate definition applies it.

Beyond the finding: what we built along the way

Exact noisy simulation

We implemented a density matrix backend — exact noisy simulation via ρ ∈ ℂ^(4ⁿ), no Monte Carlo variance. Four Kraus noise channels (depolarizing, amplitude damping, bit-flip, phase-flip) applied after each gate. At 12 qubits you get the exact probability distribution from a single simulation run.

import cforge

c = cforge.Circuit(2)
c.h(0); c.cx(0, 1)

# IBM Nairobi calibration: avg SX err 0.03%, avg CX err 0.64%
r = cforge.run(c, backend="density-matrix",
               depolarizing_1q=0.000315,
               depolarizing_2q=0.00638)

print(r.top_states(4))
# [('00', 0.487), ('11', 0.487), ('01', 0.013), ('10', 0.013)]

Real hardware calibration

We ship a parser for IBM's public calibration JSON format — T1/T2 times, per-qubit SX error rates, per-pair CX error rates — and convert it directly to a NoisyConfig. IBM Nairobi numbers are included as a reference snapshot.

Python bindings

Everything above is available from Python via pip install cleitonforge. The bindings expose all backends, noise channels, and the QASM parser. Built with PyO3 and maturin; Linux/macOS/Windows wheels on PyPI.

Performance (release build)

Benchmark	Qubits	Gates	Time (ms)
Bell state	2	2	0.6
GHZ state	3	3	0.4
QFT	3	8	0.4
Bernstein-Vazirani	3	8	0.3
Grover search	3	43	0.3

What we are — and what we're not

The temptation when you find a convention divergence is to build your own simulator and do it "right." We're not doing that.

Our moat is neutrality. The moment CleitonForge ships its own simulator, it becomes a competitor to the projects it benchmarks — and loses the only thing that makes its findings credible: no skin in the game. roqoqo cannot tell you "our Rz convention matches IBM and quantrs2's doesn't," because they're a party to the comparison. We can.

What does make sense: a convention normalization transpiler — a layer that detects which Rz convention a circuit assumes and corrects it for the target backend. That's an extension of the benchmarking mission, not a departure from it.

What's next

Open source: Convention normalization transpiler — detect and correct Rz sign on any circuit. Planned as part of cforge-parser.

arXiv: Preprint: "Neutral cross-framework benchmarking reveals Rz sign convention divergence in quantum simulation backends." Formally citable.

Enterprise SaaS: cforge-enterprise: per-device calibration tables, Zero-Noise Extrapolation, convention-aware circuit routing. API for teams running multi-backend quantum workloads.

Tooling: Jupyter notebook companion, QASM linter that flags convention-sensitive gates, dashboard for multi-hardware fidelity tracking.

The SaaS angle is straightforward: quantum teams running the same algorithm on different hardware providers need consistency guarantees that no single provider can offer. CleitonForge is the neutral layer that can.

Try it yourself

pip install cleitonforge

# or from source — reproduce the exact findings:
cargo run --release --example benchmark_suite -p cforge-cli
cargo run --release --example quantum_volume -p cforge-cli

GitHub: github.com/cleitonaugusto/cleitonforge

I built a neutral benchmarking layer for quantum simulators in Rust — and it revealed a silent disagreement between two backends

Cleiton Augusto Correa Bezerra — Sat, 04 Jul 2026 18:26:18 +0000

placeholder

Nonce Design for Safety-Critical Systems: Lessons from a Post-Quantum MAVLink Protocol

Cleiton Augusto Correa Bezerra — Tue, 23 Jun 2026 02:39:57 +0000

Replay attacks on drone command links are not theoretical. A ground station sends ARM at timestamp T. An adversary records the packet. Thirty seconds later they retransmit it verbatim. If the drone accepts it, you have a serious problem — and in a jammed or contested environment, the attacker can do this silently.

The standard defense is a monotonically increasing nonce: every packet carries a counter, and the receiver only accepts packets with counters strictly greater than the last accepted value. Simple in concept. The implementation details are where things get interesting.

This post walks through the nonce design in CleitonQ, a post-quantum authentication layer for MAVLink v2, and the three decisions that are non-obvious but matter for security.

The Problem: Concurrent Control Loops

A drone's onboard software runs several concurrent threads: a 100 Hz telemetry loop, a command processor, and potentially a mesh relay. All of them sign outbound packets. All of them need nonces.

The naive implementation is a shared u64 behind a Mutex. It works. It's also a footgun: if two threads call next_nonce() simultaneously without proper synchronization, they can read the same value, both increment to the same next value, and emit duplicate nonces. The receiver sees the duplicate and treats it as a replay — silently dropping a legitimate command.

In a flight-critical system, a dropped command is not an acceptable error mode.

The second naive implementation is fetch_add on an AtomicU64:

// Tempting, but has a subtle problem
fn next(&self) -> u64 {
    self.0.fetch_add(1, Ordering::Relaxed)
}

This fixes the race. But it wraps silently at u64::MAX. After 18.4 quintillion packets — unlikely in practice, but not impossible over the lifetime of a long-running system — nonce 0 becomes valid again. An adversary who stored a packet from the beginning of time can now replay it.

Decision 1: Saturate, Don't Wrap

CleitonQ's AtomicNonce::next() uses a compare-and-exchange loop that saturates at u64::MAX instead of wrapping:

pub fn next(&self) -> u64 {
    let mut current = self.0.load(Ordering::Relaxed);
    loop {
        if current == u64::MAX {
            return u64::MAX;  // channel is exhausted, not rolled over
        }
        match self.0.compare_exchange(
            current, current + 1,
            Ordering::Relaxed, Ordering::Relaxed,
        ) {
            Ok(_) => return current,
            Err(observed) => current = observed,
        }
    }
}

When the counter saturates, the receiver rejects u64::MAX as a replay (it was already accepted). The channel stops working. That is the correct behavior: a locked channel surfaces as an observable failure — an operator sees it, investigates, and re-establishes the session. A silently rolled-over channel surfaces as an intermittent security hole that nobody notices until it's too late.

Fail loudly rather than fail silently. In safety-critical systems, this principle is not optional.

The CAS loop also handles the race correctly: if two threads read the same current, one wins the exchange and the other retries with the updated value. No duplicates, no locks.

Decision 2: Memory Ordering Is Not Symmetric

The sender (AtomicNonce) and the receiver (NonceTracker) have different memory ordering requirements, and they are not interchangeable.

AtomicNonce::next() uses Relaxed for both the load and the CAS. This is intentional. The only property needed is that each call returns a unique, strictly increasing value. There is no requirement that the nonce emission happens-before anything else in the caller's memory. The packet containing the nonce will be serialized and sent over the network — the network ordering establishes the happens-before relationship with the receiver. Using SeqCst here would be correct but unnecessary, adding synchronization overhead on every outbound packet in a 100 Hz loop.

NonceTracker::accept() is different:

pub fn accept(&self, nonce: u64) -> bool {
    let mut current = self.0.load(Ordering::Acquire);
    loop {
        if nonce <= current {
            return false;
        }
        match self.0.compare_exchange(
            current, nonce,
            Ordering::AcqRel, Ordering::Acquire,
        ) {
            Ok(_) => return true,
            Err(observed) => current = observed,
        }
    }
}

The receiver uses Acquire on the load and AcqRel on the successful exchange. This establishes a happens-before edge: any thread that subsequently reads the tracker's value with Acquire sees all writes that preceded the accepted nonce. In practice this means: the authentication check that accepted a packet happens-before any processing of that packet's payload. If two threads race to accept the same nonce, exactly one wins the CAS — the other sees nonce <= current on retry and returns false.

Using Relaxed on the receiver would be wrong. It would allow a theoretical reordering where a thread begins processing a payload before the nonce check completes — which, in a language with a memory model that permits this, is a real vulnerability class.

Decision 3: Process Restarts Without Persistent State

What happens when the companion computer reboots mid-flight? The AtomicU64 in RAM is gone. If the new process starts from 0, every nonce it emits is below the receiver's last_accepted — the channel is dead until a new session is established.

One answer is NVRAM persistence: write the nonce to flash periodically, read it on boot. This works but adds I/O latency on the critical path and creates a new failure mode: flash write corruption during power loss.

AtomicNonce::from_time() takes a different approach:

pub fn from_time() -> Self {
    let nanos = std::time::SystemTime::now()
        .duration_since(std::time::UNIX_EPOCH)
        .unwrap_or_default()
        .as_nanos();
    Self::new(u64::try_from(nanos).unwrap_or(u64::MAX))
}

Seeding from nanoseconds since the Unix epoch means a restarted process almost certainly starts with nonces higher than anything emitted before the restart. A 10-second reboot adds 10 billion nonces of headroom. A 1-millisecond glitch adds 1 million. The wall clock is the implicit persistent store.

This relies on the system clock being monotonic across reboots — which is true on any platform with a battery-backed RTC and NTP. On systems without one (some deeply embedded targets), from_time() is unavailable and the application must manage initial nonce values explicitly.

The deeper architectural answer is that CleitonQ's session boundary makes this largely moot: a reboot forces a new ML-KEM session, which establishes a new session key. Since nonces are checked within a session (HMAC tags include the session key), cross-session replay is impossible regardless of nonce values.

The Embedded Target

Not all targets have 64-bit atomics. Cortex-M4 (the processor in most Pixhawk flight controllers) does not. For these, CleitonQ provides SimpleNonce and SimpleNonceTracker:

pub struct SimpleNonce(u64);

impl SimpleNonce {
    pub fn next_nonce(&mut self) -> u64 {
        let v = self.0;
        self.0 = self.0.wrapping_add(1);
        v
    }
}

These are not thread-safe — the &mut self receiver makes that explicit at the type level. On a single-threaded embedded executor, this is correct and zero-overhead. On a multi-threaded target with 64-bit atomics, the compiler will refuse to compile the single-threaded variant in a shared context.

The platform split is expressed via #[cfg(target_has_atomic = "64")], not runtime checks — it's a compile-time guarantee, not a runtime assertion.

Testing the Properties

Three properties need tests, not documentation.

Uniqueness under concurrency — 8 threads each calling next() 1000 times should produce 8000 distinct nonces:

let n = Arc::new(AtomicNonce::new(0));
let threads: Vec<_> = (0..8)
    .map(|_| {
        let n = Arc::clone(&n);
        thread::spawn(move || (0..1000).map(|_| n.next()).collect::<Vec<_>>())
    })
    .collect();

let mut all = HashSet::new();
for t in threads {
    for nonce in t.join().unwrap() {
        assert!(all.insert(nonce), "duplicate nonce — race in AtomicNonce::next");
    }
}
assert_eq!(all.len(), 8000);

Replay rejection — the tracker must reject exact replays and regressions:

let t = NonceTracker::new(0);
assert!(t.accept(5));
assert!(!t.accept(5));   // exact replay
assert!(!t.accept(3));   // regression
assert!(t.accept(6));    // forward progress

No double-accept under concurrency — 4 threads racing to accept nonces 1..=500 should produce exactly 500 total acceptances:

let tracker = Arc::new(NonceTracker::new(0));
// 4 threads, each tries to accept all 500 nonces
let total_accepted: usize = threads.into_iter()
    .map(|t| t.join().unwrap())
    .sum();
assert_eq!(total_accepted, 500);
assert_eq!(tracker.last_accepted(), 500);

These tests run on every CI push, including on a Neoverse-N2 ARM64 runner that mirrors the hardware profile of production companion computers.

The Broader Point

Nonce design looks simple until you consider the combination of concurrent writers, concurrent readers, process restarts, and an adversary who stores packets indefinitely. Each of those constraints pushes the design in a different direction. Getting all four right simultaneously requires explicit reasoning about each decision — not just picking the first implementation that passes the unit tests.

The three decisions above — saturating arithmetic, asymmetric memory ordering, and clock-seeded initialization — are each defensible in isolation. Together they form a design that fails loudly, maintains happens-before guarantees where they matter, and survives the most common production failure mode (process restart) without persistent state.

CleitonQ is open source under MIT OR Apache-2.0. The full nonce implementation, with all tests, is in src/nonce.rs.

CleitonQ is a post-quantum authentication layer for MAVLink v2, combining ML-KEM-1024 (FIPS 203) for session establishment and ML-DSA-87 (FIPS 204) for command signing. A formal security model in ProVerif 2.05 verifies session key secrecy (Q1) and command authenticity (Q2) against a Dolev-Yao attacker. Paper on Zenodo.

Implementing Adaptive Backpressure in Rust with FlowGuard

Cleiton Augusto Correa Bezerra — Sat, 27 Dec 2025 15:43:34 +0000

Implementing Adaptive Backpressure in Rust with FlowGuard
Hey fellow Rustaceans! 👋

I recently open-sourced FlowGuard, a library for adaptive concurrency control and backpressure in Rust services. In this post, I'll share why static rate limiting fails and how FlowGuard solves it with TCP Vegas congestion control.

🤔 The Problem with Static Limits
We've all done this:

rust
// "Maximum 100 concurrent connections"
let max_connections = 100;
But static limits are a trap:

Set too high? Your system crashes before reaching the limit

Set too low? You waste resources and refuse legitimate traffic

Guessing game? You're always tuning based on hunches

🚀 The Solution: Dynamic Backpressure
Instead of guessing, what if your system could self-adjust based on real-time performance? That's where FlowGuard comes in.

Introducing FlowGuard
FlowGuard implements the TCP Vegas congestion control algorithm to dynamically adjust concurrency limits based on actual system latency.

🎯 How It Works
rust
use flow_guard::{FlowGuard, VegasStrategy};
use std::sync::Arc;

[tokio::main]

async fn main() {
// Start with 10 concurrent operations
let strategy = Arc::new(VegasStrategy::new(10));
let guard = FlowGuard::new(Arc::clone(&strategy));

println!("Initial limit: {}", guard.current_limit());

// Execute tasks with adaptive backpressure
let result = guard.run(async {
    // Your database query, API call, etc.
    tokio::time::sleep(std::time::Duration::from_millis(100)).await;
    Ok::<_, &str>("Success!")
}).await;

println!("Final limit: {}", guard.current_limit()); // Adjusted!

}
✨ Key Features

Real-time Adjustment rust // Watch limits adjust dynamically println!("Current limit: {}", guard.current_limit()); println!("Available permits: {}", guard.available_permits());
Vegas Algorithm Based on the difference between expected and actual throughput:

✅ Increases limit when system has spare capacity

✅ Decreases limit when latency indicates congestion

✅ Self-tuning - no manual configuration needed

Web Framework Integration rust // Axum 0.8 middleware let strategy = VegasStrategy::new(50); let flow_layer = FlowGuardLayer::new(strategy);

let app = Router::new()
.route("/api/data", get(handler))
.layer(flow_layer);
📦 Getting Started
Add to your Cargo.toml:

toml
[dependencies]
flow-guard = "0.2.1"

With Axum/Tower support

flow-guard = { version = "0.2.1", features = ["axum", "tower"] }
🔧 Under the Hood
FlowGuard replaces tokio::sync::Semaphore with a custom DynamicSemaphore that can adjust its limit up and down in real-time:

rust
pub struct DynamicSemaphore {
max_permits: AtomicUsize,
available_permits: AtomicUsize,
notify: Notify,
}

impl DynamicSemaphore {
pub fn set_limit(&self, new_limit: usize) {
// Adjusts permits dynamically based on Vegas calculations
}
}
🎯 Use Cases

Database Protection rust // Prevent database overload let db_guard = FlowGuard::new(VegasStrategy::new(20));

async fn query_database() -> Result {
db_guard.run(|| async {
// Your database query here
database.query("SELECT * FROM users").await
}).await``
}

API Rate Limiting rust // Adaptive rate limiting for external APIs let api_guard = FlowGuard::new(VegasStrategy::new(5));

async fn call_external_api() -> Result {
api_guard.run(|| async {
client.get("https://api.example.com/data").await
}).await
}

Microservices rust // Protect services from cascading failures let service_guard = FlowGuard::new(VegasStrategy::new(100)); 📊 Benchmarks In testing, FlowGuard showed:

5 → 12 limit adjustment under optimal conditions

Sub-millisecond overhead per request

Zero allocation in hot path

Thread-safe with atomic operations

🚀 Try It Yourself
bash

Clone and run examples

git clone https://github.com/cleitonaugusto/flow-guard
cd flow-guard
cargo run --example basic_usage
🔗 Resources
GitHub: https://github.com/cleitonaugusto/flow-guard

Crates.io: https://crates.io/crates/flow-guard

Documentation: https://docs.rs/flow-guard/0.2.1/

Examples: basic_usage.rs, server_demo.rs

💭 Why I Built This
After seeing too many services crash from static limits or waste resources with conservative settings, I wanted a solution that adapts to actual system performance. The TCP Vegas algorithm has been battle-tested for decades in networking - why not apply it to service concurrency?

🤝 Contributing & Feedback
FlowGuard is open source under MIT license. I'd love your:

Feedback on the API design

Use cases from your projects

Contributions to the codebase

Ideas for improvements

What adaptive concurrency patterns have you used in your Rust projects? Share in the comments!