Witness Elimination Policy in Computation
- Witness Elimination Policy is a rule that manages witness-bearing information, ensuring data persists only while it guides computation or certifies protocol state.
- In constructive type theory, the policy preserves concrete witnesses through dependent pattern matching to enable verifiable and total computation.
- In quantum cryptography, the policy mandates deletion processes that leave no irrefutable, transferable evidence, achieving certified deniability.
A witness elimination policy is a rule for deciding when witness-bearing information must be retained, exposed, erased, or rendered simulatable. In constructive type theory and dependently typed programming, a witness is the concrete data that makes an existential or disjunctive proposition computationally usable, and elimination is constructive only when it exposes that data to guide further computation (Ishii, 2021). In quantum cryptography, the same phrase denotes a stronger operational objective: after deletion of a signature or non-interactive zero-knowledge argument, no irrefutable post-deletion witness should remain, and any residual state should be simulatable without ever receiving the deletable object (Çakan et al., 2024). Across both settings, the governing principle is that witnesses must persist exactly as long as they steer computation, justify rewrites, or certify protocol state, and no longer.
1. Constructive witnesses and proof-relevant data
Under the Curry–Howard correspondence, propositions are identified with types and proofs with programs. Under the Brouwer–Heyting–Kolmogorov interpretation cited in the programming paper, a proof is a construction carrying the information that makes the proposition true (Ishii, 2021). This makes witnesses intrinsically proof relevant.
For disjunction , the witness has a tag-and-witness structure: a witness is a pair , where indicates which branch holds and is the corresponding witness. The tag and the data matter and guide computation. For existential quantification, a proof of is precisely a witness together with a proof . In a dependently typed language, this is represented by a dependent pair, or -type, , whose first component is the concrete witness and whose second component is the evidence that the property holds for that specific witness.
This proof-relevant reading is the basis for the policy claim that constructive arguments must be guided with concrete witnesses. A plausible implication is that witness elimination is not primarily a logical simplification; it is a computational design choice about whether the information needed to select branches, maintain invariants, or perform rewrites remains available.
2. Elimination as dependent pattern matching
The logical and type-theoretic rules in the programming treatment make the elimination policy explicit. Writing for a typing judgment, existential introduction takes the form
0
1
Constructive elimination destructs the existential proof, names both the witness and its proof, and continues with a continuation that may depend on both:
2
3
The paper contrasts this with a classical 4-elimination that discards witnesses and derives 5 without naming 6 and 7; the constructive policy rejects that move because actual computation needs the witness-bearing data (Ishii, 2021).
The same structure appears at the level of 8-types. Formation, introduction, and elimination are given by the standard dependent rules. The eliminators include projections
- 9
- 0
with 1-rules 2 and 3, and also elimination by dependent pattern matching. Given 4, one may write a match on 5, and the body may depend on both 6 and 7. The 8-rule substitutes both components into the continuation.
In Agda, Idris, and Coq, the elimination pattern is exemplified by
3
This is constructive because elimination preserves both 9 and 0, allowing subsequent computation to depend on them. The policy therefore identifies dependent pattern matching as the canonical form of witness elimination: witnesses are not discarded but exposed locally at the point where they guide computation.
3. Programming policy in dependent and promoted Haskell styles
The central practical thesis is that programs and proofs must carry concrete witnesses and use them to guide decisions. In Haskell’s promoted and singleton-based style, the paper states this as an actionable policy: add witnessing arguments to type-level functions that branch by pattern matching, and emulate disjunctions of constraints using statically computable witnesses that encode which branch holds (Ishii, 2021).
The paper’s Haskell singletons API illustrates existential packaging through
4
Eliminating this witness by pattern matching is constructive because it recovers the concrete type index 1 and its singleton Sing a. The same pattern is used for demoting closed type-level functions with pattern matching. The gcd example introduces a witness that records whether m is zero:
5
Here classifyZero returns the appropriate ZeroCase witness for the remainder. The witness keeps the compiler informed of which branch is taken, enabling a total, type-safe definition. Without ZeroCase, the compiler cannot justify the relevant pattern matches at the type level, and the function cannot be demoted reliably.
The same policy governs disjunctive constraints. Since a bare constraint-level disjunction is not directly usable, the paper recommends a tagged witness with branch-specific evidence:
6
This is the BHK-style 2 pattern in programming form. Matching on the witness makes a safe field accessor possible for a union of extensible records.
Equality witnesses are treated similarly. The paper notes use of the Deferrable constraint pattern with witness manipulation and “design of the witness of type-level equalities,” using a witness type
7
Pattern matching on EqW provides constructive elimination: only in the Refl branch does one gain the coercion between the two types. This makes equality witnesses indispensable in code paths that depend on runtime plugin decisions.
The best-practice formulation is explicit. Witnesses should be kept as long as they guide computation or ensure invariants. The paper lists indexes in length-indexed structures, proofs of non-emptiness for safe head and tail, equality witnesses for type-level rewrites and coercions, tags and proofs for disjunctions among constraints, and witnesses that make recursive type-level functions total as canonical retained witnesses.
4. Proof relevance, erasure, and failure modes
The policy is not “never erase,” but “erase only when irrelevance is justified.” In the proof-relevant account used by the programming paper, tags and witnesses are data that matter and are used to guide computation. In Haskell singletons there is no Prop universe, so witnesses live in Type and are used via pattern matching to bring information into scope, for example by obtaining Known a through withKnown (Ishii, 2021).
The paper then distinguishes systems with explicit proof irrelevance or erasure mechanisms. In Coq, proofs in Prop are proof-irrelevant and erased at runtime. A policy consistent with the paper is to put non-computational proofs in Prop to enable erasure, while keeping computationally relevant witnesses in Type so they remain available to programs. In Agda and Idris, irrelevant arguments or erasure pragmas allow proofs to be dropped from runtime while still being used during typechecking. The guiding criterion is unchanged: do not erase witnesses that guide branches, index shapes, or provide equalities necessary for computation.
The paper identifies several dangers of premature witness elimination. Loss of guidance makes branches uncheckable, leading to stuck type families or ambiguous constraints. Partiality can arise because, without a guiding witness, a function that is intended to be total may become partial at the term level. Non-constructive reasoning can derive existence without a construction, but then there is no data to compute with.
These failure modes are illustrated by explicit refactorings. A type-level gcd that branches on whether m = 0 becomes unworkable if the branch witness is not threaded through the recursion; the refactoring is to introduce ZeroCase m. A field accessor over a union of extensible records becomes unsound or untypeable without a tag-and-witness structure; the refactoring is to define a disjunction witness 3 that captures which side holds and the corresponding field proof. In plugin pipelines, coercion becomes impossible to justify if equality witnesses are erased before the point of rewrite; the refactoring is to retain an EqW witness until the coercion site.
A plausible synthesis is that the programming notion of witness elimination is local and typed: elimination should expose witnesses where they are used, repackage invariants when they must persist, and erase only when later eliminations are provably unnecessary.
5. Certified deniability as post-deletion witness elimination
In the quantum cryptographic setting, witness elimination takes a different but structurally related form. Certified deletion ensures that a deleted object can no longer be reused in its original protocol, but it does not prevent retention of irrefutable third-party evidence that the object once existed. Certified deniability is the stronger, simulation-based notion: after deletion, anything retained could have been learned anyway without ever receiving the deletable object, so deletion leaves no trace behind (Çakan et al., 2024).
The formalization is given in the Quantum Random Oracle Model. Let 4 be a signature or NIZK scheme, let 5 be a QPT environment or adversary, let 6 be a QPT simulator, and let a single global random oracle 7 be sampled once-and-for-all. In WorldReal, the adversary receives the deletable object, executes Delete, and outputs a residual state 8. In WorldSim, the adversary never receives the object, interacts only with the simulator, and outputs 9. Certified deniability requires
0
where
1
The associated advantage formulation is also given:
2
For signatures, the real experiment Sig-CDen gives the adversary vk, quantum signing oracle access, and one special “free deleteable” signature on 3 that is not logged in the list 4; if deletion verification accepts, the output is 5, otherwise 6. The ideal experiment gives the simulator access to vk, the oracle description, and an ordinary signing oracle that may not sign 7. Definition 8 states the resulting computational indistinguishability condition. For NIZKs, the real experiment NIZK-CDen gives the adversary a proof 8 and deletion key on statement 9 with witness 0; if deletion verification accepts, the residual state is output, otherwise 1. Definition 10 states the corresponding indistinguishability condition against a simulator that never sees the witness.
The key conceptual move is that witness elimination is no longer simply the local exposure of a constructive witness. It is the destruction of transferable evidence. The paper’s statement is exact: after successful deletion, it is not possible to delete a signature or NIZK and later provide convincing evidence that it used to exist.
6. Quantum constructions, deletion procedures, and limits
The certified-deniable constructions rely on “Fiat–Shamir in superposition” with subspace or coset states. For NIZKs, the construction FS-CDeny begins with a sigma protocol 2 for an NP language 3 with perfect completeness, quantum proof of knowledge, and HVZK secure at level 4. Let 5, let 6 be a random subspace of dimension 7, let 8 be a random offset, and define the coset state
9 (Çakan et al., 2024).
Prove(x,w) samples 0 and 1, prepares a register 2, initializes transcript registers to 3, samples 4, and applies an isometry that coherently maps each basis state 5 to a Fiat–Shamir transcript using randomness 6. Verify coherently recomputes the Fiat–Shamir challenge and checks Verify_Σ across the superposition, then measures to accept or reject. Delete returns the whole quantum register. DelVer parses the deletion key 7, coherently uncomputes the transcripts back to 8, and measures 9 with the projector-valued measurement
0, accepting iff the outcome is 1.
Certified-deniable signatures instantiate the same mechanism over the language 2 for a one-way function 3. KeyGen(1^\lambda) picks sk = w and sets pk = vk = f(w). Sign(sk,m) executes the NIZK prover on statement vk with witness sk, using the Fiat–Shamir prefix 4; Verify, Delete, and DelVer are inherited from the NIZK construction. The paper states that, assuming one-way functions, there exists a signature scheme in the QROM with correctness, EUF-CMA security, and certified deniability.
The intuition for evidence elimination is that the deletion certificate is the entire quantum state, and passing deletion verification implies that the receiver has “forgotten” all specific 5 values in the superposition. Any attempt to keep classical information about even one such 6 breaks the ability to reproduce the exact coset state and causes DelVer to fail. The simulator uses “forgetful local programming,” reprogramming the random oracle only at hidden inputs containing 7; because a receiver who passes deletion cannot later reveal any such 8, a third party cannot catch the simulator’s reprogramming.
The paper attributes the bypass of classical impossibility to uniquely quantum effects: no-cloning and destructive projection, forgetful local programming, 9-twirl or coset indistinguishability, and direct-product hardness on subspace states. It also states a black-box barrier in the plain model: no black-box proof in the plain model can achieve certified deniability for signatures or NIZKs, so the constructions crucially depend on the QROM.
The resulting cryptographic witness elimination policy is operational. Creation produces a deletable quantum signature or proof together with a deletion key. Controlled dissemination delivers only the quantum object and public inputs, not the deletion key. Storage must preserve coherence, since extracting classical information from the coset register will later cause deletion verification to fail. The deletion procedure is “return the object,” and the authority runs DelVer; if accept, the system records “deleted” without storing any artifact tied to specific 0 values. The paper adds implementation notes about parity-check representations for subspaces, deterministic transcript generation from 1, trusted authority-side verification, and masking of timing or I/O that correlates with specific 2 values.
A plausible implication is that the two literatures describe complementary extremes of witness handling. In dependent programming, witnesses are retained because computation needs them; in certified deniability, witnesses are eliminated because post-deletion transferability must be impossible. In both cases, however, the policy is governed by the same criterion: witness-bearing information must remain available exactly while it has computational or security relevance, and its removal is justified only when that relevance has ended.