ZK in agents: verification, integration and fail-closed reception

Understand how a delegation proof is verified independently (including by an on-chain verifier on a public test network), how the proof lane integrates with a deterministic authorization runtime without becoming a silent authority, how the fail-closed reception path decides per message, and how concurrency and replay prevention are made correct under load.

Track

Research

Module

5 · Research case studies

Prerequisites

ZK in agents: credentials, chains and the delegation circuit · Digital signatures · Delegation chains

The circuit is not the enforcement path. The architecture runs two lanes that evaluate the same authorization check and meet at a single point. The ENFORCEMENT lane evaluates the check over real signatures with the chain in the clear; every runtime decision — message reception, the court judge — happens here. The DEMONSTRABILITY lane produces the zero-knowledge proof and is invoked only on request.

The two are alternatives, not conjuncts: no operation requires both a cleartext note and a proof. This separation is deliberate and it bounds a property (P5, covered in the results lesson): because no enforcement decision is ever taken on the circuit, the system never accepts what it cannot check. The proof lane can only ever fail to convince a third party of something still live; it can never cause acceptance of something the enforcement lane would reject.

Verification is a pure function of the artefact and the public parameters, so it replicates without coordination: more than one verifier replica can run, each needing no shared state. What is deployed on-chain is the VERIFIER, not the circuit. The circuit executes off-chain; the deployed artefact is a small contract generated from the circuit’s verification key that never inspects the chain — it evaluates a single fixed-cost equation independent of chain depth.

The paper reports a verifier deployed on a public TEST network, exercisable read-only by any reader without an account and without contacting the authors: a valid delegation proof returns true, and the same proof with an altered public signal returns false. This is the one component a reviewer can confirm without trusting the paper.

The layer plugs into a host runtime whose authorization is deterministic (a policy decision point, called a “court” of judges in the source). The delegation layer contributes one judge: it asserts that an agent is demonstrably authorized by a verifiable chain. By default this judge is ADVISORY — it audits and emits a trace but never alters the verdict. A blocking mode, where it can veto, is opt-in.

Enforcement operates on messages, not bare chains. A topic fixes a trusted root and a required action. A message carries a note: the signed payload plus the chain that authorizes its sender to publish on that topic. Reception is closed by default — an agent processes a message if and only if all ten checks pass, in order, with no alternate path and no caller-side shortcut.

1. 1A1 — a note is present.
2. 2A2 — it names this topic.
3. 3A3 — the payload signature verifies.
4. 4A4 — the chain’s root is the topic’s trusted root.
5. 5A5 — the payload signer is the chain’s leaf subject.
6. 6A6 — the chain passes V1–V5.
7. 7A7 — the leaf scope covers the required action.
8. 8A8 — no hop in the chain is revoked.
9. 9A9 — the payload timestamp is within the freshness window.
10. 10A10 — the payload digest has not been seen before.

Requirement R5 is a throughput requirement in a concurrent setting. Agents do not communicate directly or share mutable state, so the interesting concurrency is not between agents but between OPERATIONS of the same kind: many receptions at once, many proofs at once, many audit writes at once. Verification is embarrassingly parallel; proof generation is independent per chain; audit writes are detached. One operation is different: the replay guard.

Check A10 — "digest not seen before" — is a read-modify-write on shared state on the critical path of every accepted message. The paper implements it as a uniqueness-constrained insertion rather than a check-then-write: the constraint violation IS the duplicate detection. This is what makes the at-most-once property (P3) hold under concurrency, because a plain read-then-write admits an interleaving where two copies of one message both observe an empty set and both proceed.

• ▸The seen-set retention must exceed the freshness window plus clock skew, or a replayed message can reappear after its record is gone. This relation is checked at start-up; the service refuses to start if it does not hold, and a caller-supplied freshness bound is capped at a configured maximum rather than trusted.
• ▸Verification replicas need no coordination, but the replay guard does: correctness depends on a single logical seen-set, so replicas must SHARE the store, not keep local copies.
• ▸If the seen-set store is unreachable, the guard must FAIL CLOSED (reject) — a guard that silently falls back to local memory does not merely lose durability, it loses the property. (The source found this exact bug while writing; see the results lesson.)

A small set of attesting agents — roles such as authority, prover, verifier, witness and relayer — inherit from the runtime’s agent machinery but take NO decision in any application domain. They issue, sign, observe and check, and sit entirely on the deterministic side of the system. That is the property that separates them from ordinary cognitive agents: they are instruments, not decision-makers.

Non-repudiation of individual artefacts does not stop a registry from showing different histories to different auditors. The transparency mechanism (goal G5) addresses this: the registry publishes chained epoch roots; independent witnesses observe and sign what they see; and divergence between two observed views of one epoch becomes detectable. Signatures give attribution, the circuit gives disclosure-free demonstration, and epochs give consistency of the record over time — three different properties from three different mechanisms, not one mechanism doing all three.

Expected direction: Verification is a pure function of the artefact and public parameters, so replicas need no shared state and scale freely. The replay guard’s correctness depends on a single logical seen-set; local per-replica sets admit interleavings where the same message is accepted by two replicas (the at-most-once property is lost, not just durability). So replicas must share the store, and when it is unreachable the guard must fail closed — reject — rather than fall back to local memory.

Why is the delegation judge advisory by default rather than blocking?

Because an accountability layer that can veto silently is itself an authority that would need its own accountability; staying advisory keeps it observable (it audits and traces) without becoming a hidden decision-maker. Blocking mode is opt-in.

What makes the fail-closed reception gate a real control rather than just a list of checks?

The biconditional invariant — a message is processed if and only if all ten checks pass — together with the absence of any bypassing path or caller-side shortcut. A check that can be routed around is not a control.

Why is the replay check implemented as a uniqueness-constrained insertion instead of a check-then-write?

Because check-then-write admits a concurrent interleaving where two copies of one message both see an empty seen-set and proceed; making the insertion’s uniqueness-constraint violation the duplicate detection makes at-most-once hold under concurrency.

Is the reported ~2.10×10⁵ gas an on-chain verification cost measured on the public network?

No — it is measured under a local virtual machine. The public-network interaction was a read-only call that reports no gas; the separate larger gas figure on the network is contract creation, not verification.