Under-constrained circuits

Ordinary code describes steps. A circuit describes conditions that must hold, and the proving system searches for values satisfying all of them. The output is a proof that such values exist, and the verifier checks the proof rather than re-running anything.

That inversion is where the difficulty lives. In ordinary code, forgetting a check means a bad input reaches the next line and something downstream usually misbehaves. In a circuit, forgetting a constraint means the set of acceptable values is larger than intended, and every value in that larger set produces a proof the verifier will accept as valid.

In plain terms: the bug is not something the system does wrong. It is something the system was never told to forbid.

The verifier is correct. The proof is genuine. The mathematics holds.

What has happened is that the statement being proved is weaker than the one the designers believed they had written. The circuit proves that the constraints were satisfied, and if those constraints do not pin down the behaviour, the proof carries less meaning than the system relies on.

There is no revert, no failed transaction and no anomalous event. A system accepting these proofs sees a stream of valid operations. Monitoring built on failure signals sees nothing at all, because nothing fails.

In plain terms: a proof verifying is not the same as a proof being about what you think it is about. Everything downstream treats those as identical.

Unconstrained intermediate signals. A value computed during the circuit but never tied to anything the constraints check. The prover may assign it freely, and a free variable in the middle of a computation usually means the output can be steered.

Missing range checks. Field arithmetic wraps at the field modulus rather than overflowing as integers do. A value intended to be a small number, unconstrained, may be enormous, and a sum that should be impossible becomes arithmetically fine inside the field.

Under-constrained division and inverses. Division is expressed as multiplication by an inverse, and the inverse has to be constrained to actually be one. Without that, a prover can supply a value that satisfies the stated relation while meaning something else entirely.

Non-deterministic witnesses. Where more than one witness satisfies the constraints for a given public input, the prover chooses which, and the choice may be the difference between an honest operation and a double spend.

In plain terms: each of these is a question the circuit forgot to ask, and the prover is the party that benefits from it never being asked.

Two properties, and they fail in opposite directions. The distinction decides which bugs you find in testing and which you find in production.

Completeness means every honest operation can produce a proof. A completeness failure blocks legitimate users, surfaces during integration, and gets fixed before launch because it is loud.

Soundness means no dishonest operation can produce one. A soundness failure admits operations that should have been impossible, and it produces no complaint from anyone — the party exploiting it is satisfied, and nobody else can tell.

In plain terms: a completeness bug announces itself and a soundness bug does not. Testing finds the first reliably and the second only if someone deliberately looks for it, which is the entire argument for a review by someone who reads the constraints rather than the behaviour.

A circuit sits inside a system, and the surrounding pieces carry their own assumptions.

The trusted setup, where the scheme requires one, generates parameters whose secret inputs must be destroyed. If any participant retained theirs, they can forge proofs indefinitely and the forgery is undetectable. A ceremony is sound if at least one participant was honest, which is why they are run with many participants and published in detail — a setup nobody can verify is a soundness assumption resting on a promise.

The verifier contract is ordinary on-chain code with ordinary risks: a verifying key that can be replaced by a privileged role, a public-input encoding that differs from what the circuit expects, a proof accepted without checking which circuit it belongs to.

Nullifiers and replay. A system proving a thing happened once needs a value preventing the same proof being used twice, and that value has to be bound to the right inputs and recorded in a way an upgrade cannot reset.

And randomness. Where a protocol depends on an unpredictable value, its source is a trust assumption of the same weight as any oracle.

Three structural reasons, and none of them is opportunistic pricing.

The reviewer pool is small. Reading constraint systems is a different skill from reading Solidity, closer to applied cryptography than to software engineering, and the number of people who can do it competently is a fraction of the number who can review a contract.

The tooling is young. Contract review has a decade of static analysers, fuzzers and invariant frameworks behind it. Circuit tooling is improving quickly and still leans far harder on a person reasoning about what the constraints permit.

And the failure mode resists testing. A soundness bug does not appear in a test suite unless someone constructs the malicious witness that exploits it, which requires already suspecting it exists.

In plain terms: if you are quoted the same figure for a circuit as for an equivalent contract, that is worth a question.

Five questions. Your circuit engineers will have views on all of them.

Which signals are computed but not constrained, and what would a prover gain by choosing them freely?

Where do we assume a value is small, and is that assumption expressed as a range check or only in our heads?

Is every witness for a given public input unique, and if not, what does the choice change?

If the scheme needed a trusted setup, whose ceremony was it, how many participants, and is the transcript published?

Can the verifying key be replaced, and by whom? That is an access-control question wearing cryptographic clothes.