DEV Community: Cleiton Augusto Correa Bezerra

The test asserted exactly what could not fail

Cleiton Augusto Correa Bezerra — Tue, 18 Aug 2026 00:05:54 +0000

Over the last month I found correctness bugs in three different quantum
software projects. All three had tests covering the broken code. All three
tests passed.

That is not a story about quantum computing. It is a story about a way of
writing assertions that feels like testing and is not, and I keep running into
it, so I want to write it down.

The shape of it

Here is the one that made it click. It is from a compiler framework that exports
quantum circuits to OpenQASM:

assert!(qasm.contains("OPENQASM 3.0;"));
assert!(qasm.contains("qubit[2] q;"));
assert!(qasm.contains("h q["));
assert!(qasm.contains("cx q["));

Look at the third line. It checks that an h gate was emitted. It stops the
string one character before the qubit index.

The exporter was putting every gate on the wrong qubit. It derived the index
from a counter that went up once per gate instead of reading the operands, so
the Nth gate landed on qubit N. Three gates on one qubit came out on three
different qubits.

That test passes on the broken output. It would pass on almost any output. It
is not testing the export, it is testing that the function returned a string
with some letters in it.

The same shape, twice more

In another project, a Rust simulator, the Rz gate had a sign error: Rz(theta)
was implemented with the sign of theta flipped, so Rz(pi/2) gave you S dagger
where it should give you S.

The test:

assert_eq!(magnitudes(result), expected_magnitudes);

Magnitudes. The bug was in the phase. A sign flip does not move a magnitude, so
the test could not see it, and it had been passing since the code was written.

Back in the first project, a different test, this time for a pass that rewrites
gates into a hardware native set:

assert!(names.contains(&"quantum.rz".to_string()));
assert!(names.contains(&"quantum.sx".to_string()));
assert!(names.contains(&"quantum.cx".to_string()));

The pass is supposed to replace a gate with an equivalent sequence. This checks
that the new sequence showed up. It never checks that the old gate went away.

It did not go away. The pass inserted the replacement and left the original in
place, so the circuit ended up doing both. A T gate became an S gate. That one
had been shipping in a release.

Three ways to write a test that cannot fail

Once you have seen them together the pattern is easy to name.

Asserting a magnitude when the defect is a sign. The assertion projects away the
exact dimension the bug lives in.

Cutting the string before the field that breaks. contains("h q[") is one
character short of useful, and the missing character is the whole subject of the
function under test.

Asserting presence when the defect is absence. A correct rewrite is two claims:
the new thing appears, and the old thing is gone. Checking only the first half
lets every "forgot to delete" bug through.

There is a fourth one I found in the same file, and it is the pure form:

let _ = (result, rz_before);

That is the last line of a test called test_rz_stays_untouched. It computes the
before state, runs the pass, and then discards both values. It asserts nothing.
It passes unconditionally. Line coverage counts it as covered.

What I do about it now

I have one question I ask, and it is boring, and it works:

What change to the code under test would make this assertion fail?

If I cannot answer quickly and concretely, the assertion is decoration. For the
export test the honest answer was "almost nothing", since any output with an h
somewhere passes. For the magnitudes test the answer was "any change that
affects magnitude", which excludes the entire class of bug that was actually
there.

The other thing I do now is run the test against the broken code on purpose.
When I sent a patch for the sign error I described above, I flipped the sign
back before opening the pull request, watched my new test fail, and then flipped
it again. Two minutes. It is the only way to know the test has any power, and
you can only really do it while the bug is still in front of you.

That is also the honest reason these tests exist in the first place. Nobody sets
out to write a test that cannot fail. You write it after the code already works,
so it passes on the first run, and a test that passes on the first run never
shows you what it would have caught.

Why this bites harder in numerical code

In ordinary application code a wrong result usually turns into something visibly
wrong: a crash, an exception, a null, a screen full of garbage.

In numerical and quantum code, a wrong result is a perfectly well formed number.
An amplitude with a flipped sign is still a valid amplitude. A circuit on the
wrong qubits is still a valid circuit, and the file it exports still parses.
There is no shape you can check for that says "this is broken", which is exactly
why weak assertions survive here: nothing downstream complains about them either.

So the burden falls entirely on the assertion. If the assertion looks away, the
bug ships, and it ships quietly.

The reports

If you want the details, they are public:

Qiskit, sign of the dividend in a Rust transpiler pass, fixed in 2.5.1:
https://github.com/Qiskit/qiskit/issues/16594

Lift, the export and decomposition bugs above:
https://github.com/rustnew/Lift/issues/2
https://github.com/rustnew/Lift/issues/3

The tool I use to find them is a differential fuzzer, which is a longer post:
https://github.com/cleitonaugusto/CleitonForge

Three gates that should have left one behind

Cleiton Augusto Correa Bezerra — Tue, 18 Aug 2026 00:04:04 +0000

I have been building a linter for quantum chemistry setups, nqf-lint. Some of it
is easy. Some of it fights back, mostly the borrow checker. I spend my nights in
there, and around it I keep studying the algorithms I like, VQE and QAOA.

At some point I stopped trusting the simulators underneath all of it. They
looked too tidy. Every run handed me a clean number and never complained about
anything. Nothing that never complains is that correct.

So I wrote a small fuzzer that throws random circuits at them and checks if they
disagree with each other. The first time it stopped and told me two backends did
not match, I was not excited. I assumed the bug was mine.

The bug

It was small enough to hold in your head. Three gates, one qubit.

from qiskit import QuantumCircuit
from qiskit.transpiler import PassManager
from qiskit.transpiler.passes import CommutativeCancellation

qc = QuantumCircuit(1)
qc.sxdg(0)
qc.sxdg(0)
qc.sx(0)

out = PassManager([CommutativeCancellation()]).run(qc)
print(out.count_ops())

On paper those three add up to a quarter turn in the negative direction. One
gate should come out the other side. What comes out is an empty circuit.

OrderedDict()

No error. No warning. Nothing in the logs. The rotation is just gone, and if
you measure that qubit you get a different answer than the one your circuit
says you should get. Nothing tells you why, because as far as the compiler is
concerned nothing went wrong.

I ran it again. I was sure I had typed the command wrong.

If you want to see it yourself, you need pip install qiskit==2.5.0. It is fixed
in 2.5.1, which is the whole point of the rest of this post.

Where I went wrong

So I opened an issue. And I did not stop at "here is a circuit that comes out
wrong". I had read the code, or I thought I had, so I told them why.

What I wrote was this:

Looks like the cause is in the pass itself: _x_rotations includes sx and
sxdg (line 69 of commutative_cancellation.py) and two sxdg get treated as
an inverse pair.

I put "looks like" in front of it. That does not count for much. When you name a
file and a line number, you are not hedging anymore, you are making a claim.

I had come at the problem from several directions by then. There was one
explanation left that I had not tested yet, and that was enough for me. That is
where the certainty came from.

I was wrong. And I was wrong in a worse way than being off by a line.

The answer came the same day, from Jake Lishman, one of the core maintainers:

Thanks for the report, we can get this fixed. The actual root cause is
quite different (all this code is in Rust), and commutative cancellation
is calculating the necessary rotation angle correctly, it just fails to
correctly synthesise that into gates when the combined X rotation is a
negative odd multiple of pi/2 and sx appears to be a supported gate.

Read that first parenthesis again. All this code is in Rust.

I had pointed at a Python file. The logic I was describing does not live in
Python at all, and the part I said was broken was working correctly. The pass
computes the angle right. It fails when it turns that angle back into gates.

So I was not slightly off. I was reading a different file than the one that
runs.

Measuring instead of arguing

Here is the part I want to be honest about, because it is the only part I would
do the same way again.

I did not argue. I wrote this:

Thanks for the quick triage, and for correcting me on the cause. I was
reading the Python and guessed wrong.

And then I went to measure, because that was the only thing I had that was
worth anything. If I could not explain the bug, I could at least map it.

I swept the combined rotation across every multiple of pi/2 from -8 to 8,
forcing exact angles with pairs of rx gates, and checked each result against
the exact operator. It came back with something neither of us had said: it is
not only the odd multiples. There were even multiples failing too.

Then I found something worse, and it was in my own report. I had written that
the bug needed a gate on another qubit sitting between the two sxdg. That was
wrong. It happens on a single qubit, alone, with nothing else in the circuit:

qc = QuantumCircuit(1)
qc.sxdg(0); qc.sxdg(0); qc.sx(0)

I posted that correction against myself before anyone asked for it.

Somewhere in there I stopped trying to be right and started trying to be
useful, and the second one turned out to be much easier.

The line

With the map in hand, the line was not hard to find:

let num_sx = (total_angle / FRAC_PI_2).round();
for _ in 0..(num_sx as i64) % 4 {
    dag.insert_1q_on_incoming_qubit((StandardGate::SX, &[]), cancel_set[0]);
}

In Rust, % keeps the sign of the dividend. So -1 % 4 is -1, not 3. That makes
the loop 0..-1, which is an empty range, so no sx is emitted and the rotation
is dropped on the floor. rem_euclid(4) gives 0..3 for either sign.

I posted it. Jake replied:

Yes, there's a PR (two, actually) linked above your comment that changes
that line.

He had already opened it. My comment was not the fix, and I want to be clear
about that because the timeline is public and anyone can check it. We landed on
the same one line change from different directions, and he got there first.

It was still the best day I have had in a long time.

What I take from it

The habit I actually changed is smaller than a lesson. When I want to write "the
cause is X", I now go and make X happen on purpose first. If I cannot make it
happen, I do not know it yet, and I write what I measured instead.

It sounds obvious written down. It was not obvious at the time, because being
almost sure feels exactly like being sure.

I used it again this week, on someone else's compiler. I thought I had found a
sign error in a gate decomposition, and instead of writing that down I put the
old sign back, ran the test I had just written, and watched it fail. Then I put
the new sign in and watched it pass. Two minutes. That is the whole habit.

Links

Issue: https://github.com/Qiskit/qiskit/issues/16594
Fixed in Qiskit 2.5.1, PR #16599.
The fuzzer: https://github.com/cleitonaugusto/CleitonForge

A conformant DICOM de-identifier silently strips your image's signature

Cleiton Augusto Correa Bezerra — Wed, 12 Aug 2026 14:24:06 +0000

If you sign DICOM objects and then de-identify them, the signature is gone on the other side. Nobody re-signs it, nobody logs it, and the receiver has no way to tell the image was ever signed. I measured this, and it's quieter than I expected.

Here's the setup. DICOM has a digital signature mechanism in PS3.15: a Digital Signatures Sequence that attests where an object came from and that it hasn't been altered. De-identification is the step you run before images leave your four walls, for research, for AI training, for a data-sharing deal. It rewrites the object to strip patient identifiers.

I built a small Secondary Capture image, signed content the de-identifier doesn't touch (the pixel data, the dimensions, the modality), and ran it through a real de-identifier. Then I checked whether the signature survived.

tool	Digital Signatures Sequence after de-id
dcm4che `deidentify` (PS3.15 Basic Profile)	removed
dicognito	kept

dcm4che's deidentify, which implements the PS3.15 Basic Confidentiality Profile, removed the Digital Signatures Sequence outright. It blanked the patient name and ID, as it should. But it left the signed image content untouched, which means the signature it deleted would still have verified. It didn't re-sign. It even left an orphaned MAC Parameters Sequence pointing at a signature that no longer exists.

dicognito, a lighter anonymizer that only targets specific identifiers, left the signature in place.

So two conformant tools disagree on whether your image keeps its provenance, and you find out which one you have by running it, not by reading the spec.

This isn't a bug

The part that caught me is that dcm4che is right. PS3.15 says to remove the Digital Signatures Sequence during de-identification, because the Certificate of Signer can itself carry identifying information. And it says, in as many words, that re-signing by the de-identifier is not required. So the standard's own recipe deletes the origin proof and leaves restoring it optional. The tool is doing exactly what it's told.

There's no attacker anywhere in this. A legitimate sender signs, a legitimate pipeline de-identifies, and the proof is gone. That's why it's easy to miss. Nothing in the flow looks wrong.

Where it bites, and where it doesn't

If you don't sign your DICOM objects, none of this touches you today, and most shops don't sign. I'll say that plainly, because the opposite would be scaremongering. But the moment you do sign, for provenance, for integrity, for a data-authenticity claim in a regulatory file, a downstream de-identification step quietly undoes it. And de-identification is exactly where your AI training and validation data comes from. An image that entered your training set can't be traced back to the device that produced it.

Under FDA Section 524B this reads as a data-integrity control gap for your Security Risk Management, not a product vulnerability. It's the kind of thing a threat model should name, then either accept with eyes open or fix.

The fix is boring. Re-sign after de-identification. The standard lets you, it just doesn't make you. Where you can't, carry provenance in a record the de-identifier preserves, and have downstream consumers treat a missing signature as unverified rather than as absent.

Run it yourself

Sign a DICOM object, then:

# de-identify with a PS3.15-conformant tool
docker run --rm -v "$PWD":/w -w /w dcm4che/dcm4che-tools \
    deidentify /w/signed.dcm /w/out.dcm

# did the signature survive?
python -c "import pydicom; d=pydicom.dcmread('out.dcm'); \
    print('signature present:', 0xFFFAFFFA in [e.tag for e in d])"

If the Digital Signatures Sequence is gone and nothing re-signed the object, this applies to you.

The bigger pattern

This is one instance of something I've been measuring across protocols: authentication or integrity material that a conformant intermediary drops when it parses a message and rebuilds it, with no attacker at the moment of removal. MAVLink relays, SOME/IP gateways, gRPC-JSON transcoders, and now DICOM de-identification. Same shape, different boundary.

The full threat-catalogue entry, written to paste into a 524B risk file, with the exact test: https://github.com/cleitonaugusto/CleitonQ/blob/main/docs/dicom-provenance-threat-entry.md

The class write-up across the other protocols, including the results that argue against the thesis: https://doi.org/10.5281/zenodo.21840073

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!