Proof-Carrying Arithmetic for Quantum ECDLP: A Certificate Format for Public Reversible Blocks

1. Introduction

Quantum resource estimates for the elliptic-curve discrete logarithm problem (ECDLP) have become more than asymptotic complexity statements. They now influence cryptographic migration planning, blockchain security analysis, and the design of fault-tolerant quantum architectures. Recent work gives resource claims at a level of specificity where the relevant quantities are no longer only “polynomial time” versus “exponential time”, but concrete logical-qubit counts, Toffoli counts, CNOT counts, circuit-depth tradeoffs, physical-qubit assumptions, and architecture-dependent runtime estimates. For example, Babbush et al. give new resource estimates for attacking ECDLP over secp256k1, while Luo et al. give an explicit public reversible modular-inversion construction designed to reduce the logical-qubit footprint of prime-field ECDLP circuits [1,2].

This creates a verification problem. Different quantum-ECDLP papers disclose different kinds of evidence for their resource claims. Some publish detailed circuit constructions and allow direct recomputation of resource counts. Others, for responsible-disclosure reasons, may withhold sensitive circuit details while providing cryptographic evidence that certain resource claims are valid. Both models are valuable, but they leave a gap: public reversible arithmetic blocks should have a lightweight, reusable, and independently checkable certificate format. Such a format should not require every paper to build a full zero-knowledge proof system, but it should still make claims about arithmetic correctness and resource counts reproducible.

This paper proposes such a format for public reversible arithmetic blocks used in quantum ECDLP resource estimation. The first target is modular inversion over prime fields, a central operation in affine-coordinate elliptic-curve arithmetic. For a prime p, the relevant transformation is

$$|x\rangle |0\rangle ⟼|x\rangle |x^{-1}modp\rangle ,x\in {\mathbb{F}}_p^{\times }.$$

A certificate for such a block records a circuit commitment, gate basis, resource counts, input-output specification, deterministic test-generation rule, correctness transcript, and optional proof artifact. The goal is not to introduce a new quantum attack, nor to verify private circuits from prior work. The goal is to make public reversible arithmetic claims more reproducible, comparable, and auditable.

1.1. Motivation: Resource Estimates as Security Claims

A quantum attack on ECDLP is not characterized by a single resource number. Logical qubit counts determine the size of the fault-tolerant computation, while Toffoli or T-gate counts often dominate runtime and magic-state production. CNOT counts, depth, active volume, connectivity, and physical error-correction assumptions further affect whether a resource estimate is operationally relevant. Babbush et al. emphasize this point in the cryptocurrency setting by distinguishing between on-spend, at-rest, and on-setup attacks, where the required execution time changes the operational meaning of a resource estimate [1]. A resource estimate is therefore not merely a complexity-theoretic statement; it is also a security-relevant claim.

At the same time, resource estimates are difficult to compare. One construction may optimize logical qubits, another may optimize Toffoli count, and another may make architecture-specific assumptions. Some estimates count full scalar multiplication or point addition, while others isolate subroutines such as modular inversion. This makes it difficult to determine whether two estimates are directly comparable or whether they are optimizing different parts of the circuit stack.

For public arithmetic subroutines, this difficulty can be reduced by attaching a standard certificate to the circuit or circuit family. Such a certificate should bind the claim to a concrete circuit description or circuit generator, state the arithmetic function being computed, record the gate basis and resource counts, and provide deterministic correctness tests. The certificate does not replace a formal proof of correctness, but it gives readers and implementers a common object to inspect, reproduce, and compare.

1.2. Two Disclosure Models in Recent Quantum-ECDLP Work

Recent quantum-ECDLP work illustrates two complementary disclosure models. Babbush et al. give improved resource estimates for secp256k1 but intentionally withhold sensitive circuit details. To substantiate the estimates, they provide a zero-knowledge proof framework: their public statement commits to circuit hashes, resource thresholds, and randomized correctness checks while avoiding disclosure of the full circuit implementation [1]. This model is appropriate when full disclosure could provide an actionable cryptanalytic blueprint.

Luo et al. take a different approach. They publish an explicit, reversible modular-inversion construction based on the extended Euclidean algorithm. Their design uses length registers and location-controlled arithmetic to reduce the space required by modular inversion, obtaining $3n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$ logical qubits for inversion and $5n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$ logical qubits for the resulting prime-field ECDLP algorithm [2]. They also identify gate-count optimization, circuit-depth optimization, and architecture-aware implementation as natural future directions. This model is appropriate when the arithmetic block is public and the community benefits from recomputation and independent implementation.

The present paper addresses the space between these models. We do not attempt to replace zero-knowledge attestation for withheld circuits. Instead, we define a certificate layer for public reversible arithmetic blocks. This layer is useful when a circuit is meant to be public, but its resource claims should still be machine-checkable, reproducible, and comparable across papers.

1.3. Our Contribution

The contribution of this paper is a verification framework for public reversible arithmetic blocks used in quantum-ECDLP resource estimates. The framework is deliberately lightweight: it can be used without a zero-knowledge proof system, while still allowing such a proof artifact to be attached later.

Concretely, we make the following contributions.

(i)

We define a resource certificate object for public reversible arithmetic blocks. The certificate records a circuit commitment, gate basis, arithmetic parameters, resource counts, input-output specification, deterministic tests, transcript data, and optional proof artifact.

(ii)

We give a deterministic hash-derived test-generation method for arithmetic circuits. This prevents test vectors from being handpicked and makes correctness transcripts reproducible.

(iii)

We prove a basic soundness bound for randomized testing certificates: if a deterministic circuit is incorrect on an $\epsilon$-fraction of its domain, then the probability that it passes N independently sampled tests is at most ${(1-\epsilon )}^N$, under the stated random-oracle model for hash-derived tests.

(iv)

We specialize the framework to modular inversion over prime fields. For this case, correctness is checked by verifying $xy\equiv 1(modp)$ for claimed input-output pairs $(x,y)\in {\mathbb{F}}_p^{\times }\times {\mathbb{F}}_p^{\times }$.

(v)

We outline a prototype verifier and certificate schema suitable for an open repository. The prototype is intended to support small exhaustive tests, larger deterministic randomized tests, and resource-count metadata checks.

(vi)

We compare three disclosure models: full circuit disclosure, withheld circuit with zero-knowledge attestation, and public circuit with a reusable certificate. The proposed certificate model is complementary to both existing models.

The intended benefit is practical. A certificate gives readers a concrete object to verify, implementers a reproducible test target, and authors a standard way to state public arithmetic-block claims. For quantum-ECDLP resource estimation, this can make public subroutine claims easier to audit without requiring disclosure of sensitive full attack circuits.

1.4. Scope and Non-Goals

This paper has a narrow scope. We do not introduce a new quantum algorithm for ECDLP. We do not publish attack circuits. We do not reconstruct, verify, or audit withheld circuits from prior work. We do not claim to certify a complete Shor-style ECDLP pipeline. The object of study is the public reversible arithmetic block, with modular inversion over ${\mathbb{F}}_p$ as the first case study.

A certificate is only as meaningful as its circuit representation, gate-basis conventions, resource-counting rules, and correctness model. Randomized tests give probabilistic evidence unless they are exhaustive or embedded in a formal proof system. Accordingly, the certificate format is designed to support several levels of assurance: metadata and resource-count certificates, deterministic randomized tests, exhaustive checks for toy domains, formal verification, and optional zero-knowledge or succinct proof artifacts.

The broader purpose is to support a culture of proof-carrying quantum arithmetic: public arithmetic claims should be accompanied by enough structured data to make them reproducible, comparable, and independently auditable.

1.4.0.1. Code availability.

The prototype verifier, certificate schema, example certificates, and generated reports are available at

https://github.com/fearlessronin/qecdlp-cert.

The repository contains the toy certificates and report-generation scripts used for the examples in Section 7.

2. Background on Quantum ECDLP Arithmetic

This section fixes the arithmetic and resource-estimation notation used in the certificate framework. We do not review Shor’s algorithm in full. Instead, we recall the specific elliptic-curve arithmetic blocks whose resource claims a certificate should make reproducible.

2.1. ECDLP and Coherent Group Arithmetic

Let $E/{\mathbb{F}}_p$ be an elliptic curve over a prime field, and let $P\in E\left({\mathbb{F}}_p\right)$ generate a cyclic subgroup of order r. Given $Q\in \langle P\rangle$, the elliptic-curve discrete logarithm problem (ECDLP) is to recover the unique scalar

$$m\in \{0,\dots ,r-1\}\mathrm{such}\mathrm{that}Q=\left[m\right]P.$$

Classically, generic attacks such as Pollard’s rho require square-root group operations in the subgroup size. Shor’s algorithm changes the asymptotic picture by reducing the discrete-logarithm problem in a finite abelian group to coherent group evaluation followed by Fourier sampling [3,4].

For elliptic curves, the dominant quantum subroutine is coherent evaluation of linear combinations of public curve points, typically of the form

$$(k,\ell )⟼\left[k\right]P+[\ell ]Q.$$

A quantum circuit for this map is built from controlled elliptic-curve point additions and the underlying reversible finite-field arithmetic. Consequently, quantum ECDLP resource estimates are ultimately estimates for reversible arithmetic blocks: modular addition, subtraction, negation, multiplication, squaring, inversion, point addition, and their controlled variants [5,6].

This observation motivates the certificate viewpoint used in this paper. A complete ECDLP circuit may be sensitive or too large to inspect manually, but many of its arithmetic subroutines are public and independently testable. A resource certificate for such a subroutine should specify both the arithmetic function being computed and the resources required by a particular reversible realization of that function.

2.2. Affine Point Addition and Modular Inversion

In affine Weierstrass coordinates, point addition involves a slope computation. For distinct affine points

$$P_1=(x_1,y_1),P_2=(x_2,y_2),$$

with $P_2\ne \pm P_1$, one computes

$$\lambda ={\displaystyle \frac{y_2-y_1}{x_2-x_1}},x_3={\lambda }^2-x_1-x_2,y_3=\lambda (x_1-x_3)-y_1,$$

so that $P_1+P_2=(x_3,y_3)$. For point doubling, the slope is

$$\lambda ={\displaystyle \frac{3x_1^2+a}{2y_1}}.$$

Thus affine point addition requires modular inversion in ${\mathbb{F}}_p$, in addition to modular multiplication, squaring, addition, and subtraction.

The inversion operation is a major driver of the space cost in affine-coordinate quantum ECDLP circuits. Luo et al. focus precisely on this point: they construct an explicit reversible modular-inversion block using the extended Euclidean algorithm, length registers, and location-controlled arithmetic [2]. Their inversion block computes

$$|x\rangle |0\rangle ⟼|x\rangle |x^{-1}modp\rangle ,x\in {\mathbb{F}}_p^{\times },$$

using

$$3n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$$

logical qubits for an n-bit prime p. When inserted into their affine ECDLP construction, the resulting algorithm uses

$$5n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$$

logical qubits. They report 1333 logical qubits for a 256-bit prime-field curve and give asymptotic inversion costs of approximately

$$204n^2{log}_{2}n+O\left(n^2\right)$$

Toffoli gates and

$$102n^2{log}_{2}n+O\left(n^2\right)$$

CNOT gates [2].

The present paper uses modular inversion as the first certification target because its input-output relation is simple, its circuit cost is significant, and a public construction already exists. In contrast to full point addition, where correctness must account for multiple exceptional cases, modular inversion over ${\mathbb{F}}_p^{\times }$ can be tested by the single relation

$$xy\equiv 1(modp).$$

2.3. Resource Metrics

A resource certificate must state which resources are being counted. In this paper we use the following basic metrics.

Logical qubits. 

The number of logical qubits required by the reversible arithmetic block, including input, output, control, and work registers.

Ancilla or work qubits. 

The subset of logical qubits used as temporary storage. A certificate should specify whether these qubits are clean, dirty, borrowed, or required to be returned to $|0\rangle$.

Toffoli count. 

The number of Toffoli-type non-Clifford gates, or the specified equivalent count in the chosen gate basis. Since Toffoli or T-type resources often dominate fault-tolerant runtime, this is one of the central resource metrics in ECDLP estimates.

CNOT count. 

The number of CNOT gates or controlled-X operations after compilation to the stated reversible gate basis.

Depth. 

The circuit depth under a specified scheduling convention. When relevant, this may be refined to Toffoli depth, active depth, or architecture-aware depth.

Architecture-aware metrics. 

Some estimates also depend on routing, connectivity, surface-code layout, reaction time, active volume, or physical-qubit assumptions. These metrics are not part of the minimal certificate in this paper, but the format is designed to allow such fields.

Different quantum-ECDLP estimates optimize different objectives. For example, one circuit may reduce logical qubits at the cost of more gates, while another may reduce Toffoli count at the cost of additional workspace. Babbush et al. make this tradeoff explicit by reporting low-qubit and low-gate variants for their secp256k1 resource estimates, and by distinguishing the relevance of those estimates for different operational attack modes [1]. Luo et al. focus instead on reducing the width of the modular-inversion block, while noting that their non-standard components may admit further gate-count and depth optimization [2].

For this reason, a certificate should not collapse all costs into a single number. It should record the individual resource coordinates that allow readers to compare circuits under their own cost model.

2.4. Disclosure Models and Verification Pressure

Quantum-ECDLP resource estimates now sit at the intersection of algorithm design, cryptographic migration, and responsible disclosure. A fully disclosed circuit enables direct recomputation of resource counts, but may be inappropriate for a complete attack circuit if the details are considered sensitive. A withheld circuit can avoid disclosing an actionable blueprint, but then the community needs another way to assess the credibility of the claimed resources.

Babbush et al. address this issue by using a zero-knowledge attestation model: they commit to circuit hashes and give proof statements for circuits satisfying specified resource thresholds and correctness tests, while withholding the underlying circuit details [1]. Their approach is appropriate for sensitive full-circuit claims. Public arithmetic blocks, however, can be handled differently. When the circuit or circuit generator is public, the natural object is a structured certificate containing the circuit commitment, the arithmetic specification, the resource counts, deterministic tests, and a correctness transcript.

This paper develops that public-circuit certificate model. It is intended to complement, not replace, zero-knowledge attestation. For withheld circuits, a proof artifact may be necessary. For public reversible arithmetic blocks, a lightweight certificate can already make claims easier to inspect, reproduce, and compare. The certificate format introduced below is designed for this second setting.

3. Certificate Objects for Reversible Arithmetic Blocks

This section defines the certificate object used throughout the paper. The definition is intentionally independent of any particular implementation language, proof system, or circuit compiler. Its purpose is to bind together four kinds of information that are often separated in quantum-ECDLP resource estimates: the public arithmetic function, the circuit representation, the claimed resources, and the correctness evidence.

The certificate model is motivated by two recent disclosure patterns. In the withheld-circuit setting, Babbush et al. use cryptographic attestation to support resource claims without exposing the full circuit details [1]. In the public-circuit setting, Luo et al. publish explicit reversible arithmetic constructions, including a space-efficient modular inversion block, together with qubit and gate estimates [2]. Our certificate object is designed for the second setting: public reversible arithmetic blocks whose correctness and resource metadata should be reproducible and auditable.

3.1. Reversible Arithmetic Blocks

Definition 3.1 

(Reversible arithmetic block). A reversible arithmetic block is a finite reversible circuit C, expressed in a fixed gate basis, together with an input-output specification

$$F_C:D⟶R$$

for a finite arithmetic domain D and range R. The circuit may use work registers provided that its output convention and clean-up convention are specified.

In this paper the main example is modular inversion over a prime field:

$$F_C\left(x\right)=x^{-1}modp,x\in {\mathbb{F}}_p^{\times }.$$

A reversible implementation may store the input x, write the output $x^{-1}modp$, and use additional work registers during the computation. The certificate must state whether those work registers are required to return to a fixed clean state. This convention matters because two circuits can implement the same arithmetic map on visible registers while differing in how they treat ancillas.

A reversible arithmetic block may be specified in several ways. It may be given as a literal gate list, an intermediate representation, a circuit generator, or a family of circuits indexed by arithmetic parameters such as the bit length n and modulus p. For a public block, the representation should be hashable. If the circuit is generated rather than listed explicitly, the certificate should bind to the generator version, input parameters, and compilation conventions. This prevents resource claims from floating free of the actual object being counted.

The minimal gate basis used in the prototype repository is

$$\{\mathrm{NOT},\mathrm{CNOT},\mathrm{TOFFOLI},\mathrm{SWAP}\}.$$

This is not intended to be the only possible basis. Quantum resource papers often translate reversible classical circuits into Clifford+T, Toffoli networks, or architecture-dependent instruction sets. The certificate therefore records the basis explicitly rather than assuming a universal counting convention.

3.2. Resource Certificate Schema

Definition 3.2 

(Resource certificate). A resource certificate for a reversible arithmetic block C is a tuple

$$\begin{array}{cc}\hfill \mathcal{R}\left(C\right)=(& Hash\left(C\right),\mathsf{basis},\mathsf{params},q\left(C\right),a\left(C\right),\hfill \\ & Toff\left(C\right),CNOT\left(C\right),depth\left(C\right),\mathsf{IO}\left(C\right),\hfill \\ & \mathsf{Tests}\left(C\right),\mathsf{Transcript}\left(C\right),\pi ).\hfill \end{array}$$

where $Hash\left(C\right)$ commits to the circuit representation, $\mathsf{basis}$ specifies the allowed gates, $\mathsf{params}$ records arithmetic parameters, $q\left(C\right)$ and $a\left(C\right)$ record logical and auxiliary qubits, $Toff\left(C\right)$, $CNOT\left(C\right)$, and $depth\left(C\right)$ record resource counts, $\mathsf{IO}\left(C\right)$ specifies the claimed arithmetic function, $\mathsf{Tests}\left(C\right)$ specifies deterministic test generation, $\mathsf{Transcript}\left(C\right)$ records test outcomes, and π is an optional formal or zero-knowledge proof artifact.

In the prototype implementation, the depth field is instantiated only as serial depth; architecture-aware depth, Toffoli depth, and T-depth are reserved for future certificate levels. The tuple notation is abstract. In the prototype implementation this data is represented as a JSON certificate with the following required fields:

$$\begin{array}{c}\mathtt{certificate}\_\mathtt{version},\mathtt{certificate}\_\mathtt{id},\mathtt{circuit}\_\mathtt{hash},\mathtt{gate}\_\mathtt{basis},\\ \mathtt{arithmetic}\_\mathtt{function},\mathtt{arithmetic}\_\mathtt{parameters},\mathtt{resource}\_\mathtt{counts},\mathtt{io}\_\mathtt{spec},\\ \mathtt{test}\_\mathtt{generation},\mathtt{correctness}\_\mathtt{transcript},\mathtt{transcript}\_\mathtt{hash},\mathtt{proof}\_\mathtt{artifact}.\end{array}$$

For public gate-list circuits, the certificate may also include a public_circuit field binding the certificate to a circuit file, circuit identifier, and circuit hash. The verifier recomputes the hash and gate counts from the public circuit file and compares them against the certificate metadata.

The certificate separates arithmetic correctness from resource counting. For modular inversion, the arithmetic check is

$$xy\equiv 1(modp).$$

The resource check is instead a claim about the circuit representation: number of logical qubits, number of work qubits, Toffoli count, CNOT count, and depth under a stated scheduling convention. A certificate can pass the arithmetic transcript check while still failing the resource-count check if the public circuit file does not match the claimed metadata. This separation is useful because resource estimates are often compared across papers even when the underlying arithmetic function is the same.

The optional proof artifact $\pi$ may be empty. In a lightweight certificate, $\pi$ can be recorded as $\mathtt{type}=\mathtt{none}$. In a stronger certificate, $\pi$ may point to a formal verification object, a succinct proof, or a zero-knowledge proof. This is compatible with the attestation direction taken by Babbush et al., where proof artifacts are used to substantiate circuit claims without revealing the full circuit [1]. The present paper does not require such a proof artifact for the public modular-inversion case.

3.3. Certificate Levels

Different use cases require different levels of assurance. We therefore organize certificates into levels. The levels are cumulative: higher levels include the data and checks of lower levels.

Level 0. 

Hash, arithmetic parameters, gate basis, and resource counts. This level records what is being claimed but does not by itself test arithmetic correctness.

Level 1. 

Level 0 plus deterministic randomized tests. Test inputs are generated from a hash-derived seed, and the certificate records a correctness transcript. For modular inversion, each transcript row is checked by verifying $xy\equiv 1(modp)$.

Level 2. 

Level 1 plus exhaustive correctness over toy-size domains. This is feasible for small primes and is useful for debugging the verifier and circuit representation.

Level 3. 

Level 2 plus formal verification of arithmetic correctness. At this level, the certificate is supported by a machine-checkable proof that the circuit realizes the specified arithmetic function.

Level 4. 

Level 3, or a Level 1-style claim, embedded into a succinct or zero-knowledge proof system. This level is appropriate when one wants an independently checkable proof artifact, possibly without revealing all circuit details.

The repository accompanying this paper currently implements the lower levels. It validates certificate structure, recomputes transcript hashes, generates deterministic modular-inversion tests, verifies modular-inversion transcripts, and checks resource counts against public toy gate lists. These lower levels are already enough to make public arithmetic-block claims more reproducible. Higher levels, including formal verification and zero-knowledge proof integration, are left for future work.

This hierarchy also clarifies the role of randomized testing. A Level 1 certificate is not a formal proof of universal correctness. It is a reproducible audit object. Its strength depends on the test-generation model, number of tests, and the assumed distribution of faults. Section 4 gives the basic soundness statement used for this testing layer.

3.4. Relationship to Withheld-Circuit Attestation

The certificate model in this paper is complementary to withheld-circuit attestation. When a full ECDLP circuit is considered sensitive, publishing the circuit may be inappropriate. In that setting, a zero-knowledge or succinct proof can substantiate selected resource and correctness claims without disclosing the circuit. This is the disclosure posture adopted by Babbush et al. for their improved secp256k1 resource estimates [1].

Public arithmetic blocks are different. If a modular inversion circuit, multiplication circuit, or point-addition block is intended to be public, then the community should be able to recompute and audit its claims. A public resource certificate is a lightweight way to make that possible. It binds the circuit or circuit generator to its arithmetic specification, resource counts, and test transcript. It does not hide the circuit. It makes the public claim easier to check.

Thus there are three distinct disclosure modes:

$$\begin{array}{ccc}\mathrm{full}\mathrm{disclosure}\hfill & :\hfill & \mathrm{circuit}\mathrm{details}\mathrm{are}\mathrm{public}\mathrm{and}\mathrm{claims}\mathrm{are}\mathrm{recomputed};\hfill \\ \mathrm{withheld}\mathrm{circuit}\mathrm{with}\mathrm{proof}\hfill & :\hfill & \mathrm{claims}\mathrm{are}\mathrm{attested}\mathrm{without}\mathrm{revealing}\mathrm{the}\mathrm{circuit};\hfill \\ \mathrm{public}\mathrm{circuit}\mathrm{with}\mathrm{certificate}\hfill & :\hfill & \mathrm{public}\mathrm{arithmetic}\mathrm{blocks}\mathrm{carry}\mathrm{structured}\mathrm{audit}\mathrm{data}.\hfill \end{array}$$

The third mode is the focus of this paper. It is designed for reusable arithmetic subroutines such as modular inversion, not for disclosing complete cryptanalytic pipelines.

4. Deterministic Test Generation and Soundness

The certificate model records not only resource metadata, but also a reproducible correctness transcript. For public reversible arithmetic blocks, the tests should not be handpicked. They should be derived deterministically from the circuit commitment and the arithmetic parameters, so that any reader can regenerate the same test set and verify the same transcript.

This section formalizes that testing layer. The model follows the same general logic as Fiat–Shamir-style public randomness: a binding commitment to the object being checked is used to derive apparently random challenges [7]. In the implementation accompanying this paper, the challenge stream is generated using SHAKE256, an extendable-output function specified in the SHA-3 standard [8]. The same general approach appears in Babbush et al., where deterministic randomized testing is used as part of a zero-knowledge attestation framework for ECDLP resource claims [1]. Here we use the idea in a lighter setting: public arithmetic blocks with public certificates.

4.1. Hash-Derived Tests

Let C be a public reversible arithmetic circuit or circuit family. The certificate contains a commitment

$$h_C=Hash\left(C\right),$$

where C may denote either a literal gate list or a hashable circuit generator together with its parameters. For a finite arithmetic domain D, a label $\mathsf{label}$, and arithmetic parameters $\mathsf{params}$, we derive test inputs from

$$\mathsf{seed}=H(h_C\parallel \mathsf{params}\parallel \mathsf{label}),$$

where H is modeled as a hash or extendable-output function. The resulting byte stream is parsed into candidate inputs and reduced or rejected until the desired number of valid test points is obtained.

For modular inversion over a prime field, the domain is

$$D={\mathbb{F}}_p^{\times }.$$

Thus test generation must avoid $x=0$. In the repository implementation, test values are derived from a SHAKE256 stream seeded by the circuit hash, the modulus p, and a label identifying the test family. The generated values are then placed in the interval

$$1\le x\le p-1.$$

The certificate records the test-generation rule, the number of tests, the correctness transcript, and a transcript hash. For a transcript

$$\mathsf{Transcript}\left(C\right)={\left\{(x_i,y_i,{\mathsf{passed}}_i)\right\}}_{i=1}^N,$$

the modular inversion check is

$$x_i{y}_i\equiv 1(modp).$$

The transcript hash binds the certificate to these concrete test outcomes.

The benefit of this construction is reproducibility. A verifier does not need to trust that the author selected representative inputs. Given the same circuit commitment and parameters, the verifier regenerates the same test inputs, checks the transcript, and recomputes the transcript hash. This gives a lightweight audit layer for public reversible arithmetic claims.

4.2. Randomized Testing Soundness

The following elementary bound records what randomized testing can certify. It does not say that a circuit is correct on all inputs; it says that a circuit which is wrong on a noticeable fraction of inputs is unlikely to pass many independent random tests.

Proposition 4.1 

(Soundness of hash-derived randomized testing). Let D be a finite domain and let C be a deterministic circuit claiming to compute a function $f:D\to R$. Suppose that C disagrees with f on at least an ε-fraction of inputs in D. If N independent test inputs are sampled uniformly from D, then the probability that C passes all N tests is at most

$${(1-\epsilon )}^N.$$

In the random-oracle model, the same bound applies to test inputs generated from an extendable-output function seeded by a binding commitment to C.

Proof. 

Let

$$B=\{x\in D:C(x)\ne f(x\left)\right\}$$

be the bad set. By hypothesis,

$$\left|B\right|\ge \epsilon \left|D\right|.$$

A uniformly sampled test input lands outside B with probability at most $1-\epsilon$. Since the N test inputs are independent, the probability that all N tests avoid B is at most

$${(1-\epsilon )}^N.$$

Thus the probability that an $\epsilon$-bad circuit passes all N tests is at most ${(1-\epsilon )}^N$. If the test inputs are generated by an extendable-output function modeled as a random oracle and seeded by a binding commitment to C, then the generated tests are modeled as independent random samples from D, giving the same bound.    □

For example, if a circuit is wrong on at least $1\%$ of inputs, then $N=9024$ independent tests give the bound

$${\left(0.99\right)}^{9024}<2^{-130}.$$

This is the same kind of estimate used in recent zero-knowledge resource attestation for ECDLP circuits [1]. In the present paper, the same calculation is used only for public arithmetic blocks and public correctness transcripts.

4.3. What Testing Does and Does Not Prove

Randomized testing is an audit layer, not a formal proof of universal correctness. A Level 1 certificate, in the terminology of Section 3.3, gives reproducible evidence that a public circuit passes a deterministic test suite. It does not prove that the circuit computes the specified function on every input. A malicious or buggy circuit could still pass the tests if its error set is small or if the testing model fails to sample from the relevant region of the domain.

There are three stronger alternatives. First, for toy domains one may perform exhaustive testing. This gives a Level 2 certificate and proves correctness on the tested finite domain by direct enumeration. Second, one may attach a formal proof that the circuit realizes the specified arithmetic function. This gives a Level 3 certificate. Third, one may embed the correctness and resource-count claim into a succinct or zero-knowledge proof system, giving a Level 4 certificate. The zero-knowledge attestation framework of Babbush et al. is an example of this stronger proof-oriented direction for withheld circuit claims [1].

The purpose of the testing layer in this paper is more modest. It provides a standard, reproducible way to attach correctness evidence to public reversible arithmetic blocks. For modular inversion, the verifier checks the relation $xy\equiv 1(modp)$, recomputes the transcript hash, and confirms that the test inputs were generated from the claimed circuit commitment. This is enough to make small public arithmetic claims independently auditable, while leaving full formal verification and zero-knowledge proof integration as future extensions.

5. Certificate Specialization: Modular Inversion over Prime Fields

We now specialize the certificate model to the first arithmetic block supported by the prototype verifier: modular inversion over a prime field. This choice is deliberate. In affine-coordinate elliptic-curve arithmetic, point addition and point doubling require a field inversion to compute the slope. Luo et al. identify this operation as a dominant contributor to the logical-qubit footprint of prime-field quantum ECDLP circuits and give an explicit reversible implementation based on the extended Euclidean algorithm [2]. Modular inversion is therefore a natural first case for public arithmetic-block certification.

The specialization in this section has two goals. First, it gives a concrete input-output relation against which correctness transcripts can be checked. Second, it identifies the resource and representation fields that a certificate should record when the arithmetic block is a public reversible modular-inversion circuit.

5.1. Arithmetic Specification

Let p be a prime. We work over the multiplicative group

$${\mathbb{F}}_p^{\times }={\mathbb{F}}_p\setminus \left\{0\right\}.$$

The modular inversion function is the map

$$x⟼x^{-1}modp,$$

defined uniquely by the relation

$$x{x}^{-1}\equiv 1(modp).$$

In this paper we exclude $x=0$ from the input domain. This avoids the need for an exceptional-output convention or validity flag in the first certificate format. Future certificate versions may include a flagged total function on all of ${\mathbb{F}}_p$, but the clean domain ${\mathbb{F}}_p^{\times }$ is sufficient for the prototype.

Definition 5.1 

(Prime-field modular inversion block). For a prime p, the modular inversion function is

$${Inv}_p:{\mathbb{F}}_p^{\times }⟶{\mathbb{F}}_p^{\times },x⟼x^{-1}modp.$$

A reversible modular inversion block realizes the transformation

$$|x\rangle |0\rangle |w_0\rangle ⟼|x\rangle |x^{-1}modp\rangle |w_0\rangle$$

for all $x\in {\mathbb{F}}_p^{\times }$, with work registers returned to their initial state.

The final condition on the work registers is part of the arithmetic specification. A circuit that leaves garbage entangled with the output is not the same reversible block as one that cleans its workspace. In a larger quantum ECDLP circuit, uncleared work registers can affect composability, qubit counts, and uncomputation. Therefore the certificate must record whether the implementation claims clean work registers, borrowed workspace, or another convention.

5.2. Correctness Checks

For modular inversion, correctness is easy to test. A transcript row consists of an input x, a claimed output y, and a pass/fail flag. The verifier checks that

$$1\le x\le p-1,1\le y\le p-1,$$

and

$$xy\equiv 1(modp).$$

If the certificate binds to a public gate-list circuit and the circuit simulator is used, the verifier may also check the visible output bits and any declared clean-work convention. The current prototype supports this style for small toy reversible circuits and uses arithmetic transcript checks for modular inversion.

This is simpler than verifying full elliptic-curve point addition. Point addition in affine coordinates must handle several cases: ordinary addition, doubling, the point at infinity, and exceptional cases such as adding inverse points. Modular inversion over ${\mathbb{F}}_p^{\times }$ has only one arithmetic relation:

$$xy\equiv 1(modp).$$

For this reason, modular inversion is a suitable first target for a public certificate standard.

The prototype repository supports two verification modes for modular inversion. For toy-size domains, one may use exhaustive testing over all $x\in {\mathbb{F}}_p^{\times }$. For larger domains, the verifier uses the hash-derived deterministic testing procedure of Section 4. In both cases, the transcript is serialized canonically and hashed. The certificate is accepted only if the transcript hash agrees with the transcript actually checked by the verifier.

5.3. Resource Fields for Modular Inversion Certificates

A modular inversion certificate should record enough information to make the resource claim reproducible. At minimum, the arithmetic parameters should include the modulus p, the bit length $n=\lceil {log}_{2}p\rceil$, and the domain convention $x\in {\mathbb{F}}_p^{\times }$. The input-output specification should state the input register, output register, and correctness relation.

For a gate-level or generator-level certificate, the resource metadata should include the fields in Table 1.

If the circuit follows a Luo-style extended Euclidean structure, the certificate should also record the conventions for length registers and location-controlled arithmetic. Luo et al. use these ingredients to store intermediate variables compactly and obtain their low-space modular inversion estimate [2]. A certificate for such a circuit should therefore bind not only the total qubit count, but also the register-layout and generator conventions that make the count meaningful.

The current prototype implements a first version of this idea. It validates the certificate schema, checks the modular inversion transcript, verifies transcript hashes, and, when a public toy circuit is supplied, recomputes the circuit hash and resource counts from the gate list. The toy gate-list examples are not claimed to be Luo-style inversion circuits. They demonstrate the certificate mechanism: a public circuit can be bound to a hash, resource metadata can be recomputed, and the correctness transcript can be verified independently.

5.4. Relation to Luo-Style EEA Inversion

Luo et al. provide the motivating public arithmetic block for this case study. Their modular inversion construction starts from the extended Euclidean algorithm, uses register sharing, length registers, and location-controlled arithmetic, and achieves

$$3n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$$

logical qubits for modular inversion. In their full prime-field ECDLP estimate, the qubit count becomes

$$5n+4\lfloor {log}_{2}n\rfloor +O\left(1\right),$$

with 1333 logical qubits reported for a 256-bit prime-field curve [2]. They also report explicit asymptotic gate estimates for modular inversion and identify further gate-count, circuit-depth, and architecture-aware optimization as natural future work [2].

The certificate framework in this paper is designed to support public blocks of that kind. It does not require us to reproduce the full Luo construction in the first version. Instead, it fixes the certificate fields, test-generation rule, transcript hash, and resource-count verification procedure that a public Luo-style circuit or circuit generator could instantiate. Thus the prototype serves as a proof of concept for public arithmetic-block certification, while the larger goal is to support increasingly realistic modular arithmetic blocks used inside quantum ECDLP resource estimates.

This separation is important. The paper does not claim a new low-qubit ECDLP algorithm and does not improve Luo et al.’s inversion circuit. Its contribution is a verification layer: given a public reversible arithmetic block, the certificate records what function it claims to compute, how it was tested, what resources it claims, and how those claims can be independently checked.

6. Prototype Verifier

The prototype verifier accompanying this paper is intentionally small. It is not a full implementation of the reversible extended-Euclidean modular inversion circuit of Luo et al. [2], nor does it attempt to verify the withheld circuits or zero-knowledge attestation artifacts of Babbush et al. [1]. Instead, it implements the certificate pipeline developed in the previous sections: schema validation, deterministic test generation, transcript hashing, public circuit hashing, resource-count checking, and toy reversible-circuit simulation. This provides a concrete artifact showing how public arithmetic-block claims can be made reproducible.

The current implementation supports two kinds of examples. First, it verifies modular-inversion certificates at the transcript level, checking relations of the form $xy\equiv 1(modp)$. Second, it verifies small public reversible Boolean and toy arithmetic circuits by recomputing their circuit hashes, resource counts, and exhaustive truth-table transcripts. These examples are deliberately small, but they exercise the same certificate fields that would be used for larger public arithmetic blocks.

6.1. Circuit Representation

The prototype uses a simple JSON gate-list representation for public reversible circuits. A circuit file records a circuit identifier, version, description, gate basis, qubit count, and an ordered list of gates. Each gate object records its type and the relevant target and control qubits. The current toy implementation supports the reversible gate types

$$\mathrm{NOT},\mathrm{CNOT},\mathrm{TOFFOLI},\mathrm{SWAP}.$$

This basis is sufficient for small reversible Boolean examples and for testing the certificate machinery. It is not intended to be the final basis for large-scale quantum ECDLP arithmetic. Larger circuits may use Toffoli networks, Clifford+T decompositions, architecture-specific layouts, or circuit generators rather than explicit gate lists; these are standard choices in fault-tolerant quantum circuit accounting and reversible computation [9,10].

A public circuit certificate binds to the gate list by hashing its canonical JSON representation. This ensures that resource counts are attached to a specific public object rather than to an informal description. If the circuit is produced by a generator rather than written as a literal gate list, the same principle applies: the certificate should bind to the generator version, arithmetic parameters, compilation settings, and gate basis. This is important because resource estimates for quantum ECDLP depend strongly on representation choices, as shown by earlier point-addition and ECDLP resource estimates [5,6] and by the low-space affine-coordinate modular-inversion approach of Luo et al. [2].

The toy gate-list representation is also classically simulable on computational basis inputs. The verifier uses this only for small public examples. It does not simulate quantum superposition, and it is not meant to evaluate a full quantum ECDLP circuit. Its purpose is to verify that a small reversible gate list implements the claimed Boolean or toy arithmetic transformation on all inputs.

6.2. Gate and Qubit Counting

For public gate-list circuits, the verifier recomputes elementary resource metadata directly from the circuit file. The current implementation records the following fields.

Logical qubits. 

The declared circuit qubit count.

Total gates. 

The length of the gate list.

NOT count. 

The number of $\mathrm{NOT}$ gates.

CNOT count. 

The number of $\mathrm{CNOT}$ gates.

Toffoli count. 

The number of $\mathrm{TOFFOLI}$ gates.

SWAP count. 

The number of $\mathrm{SWAP}$ gates.

Serial depth. 

The number of gates under the prototype serial scheduling convention.

The verifier also checks that all gate references are within the declared qubit range. This prevents a certificate from claiming a resource count for a malformed or ill-specified circuit.

The phrase “serial depth” is intentional. In the prototype, this number is equal to the total number of gates because the toy verifier uses a fully serial scheduling convention. It is not a parallel circuit depth, not a Toffoli depth, not a T-depth, and not an architecture-aware depth metric. For real quantum ECDLP arithmetic, depth depends on scheduling, parallelism, connectivity, gate basis, routing, error-correction model, and whether one counts Toffoli depth, T-depth, active depth, or architecture-aware volume. Babbush et al. explicitly distinguish logical resource counts from architecture-dependent runtime estimates and emphasize the operational difference between fast-clock and slow-clock fault-tolerant architectures [1]. For this reason, the present certificate format records the depth convention rather than treating any one depth metric as universal.

In the current examples, gate-count verification is used to demonstrate the certificate pipeline. The toy circuits are not cryptographic circuits. They show that a public circuit can be hashed, parsed, checked for well-formedness, counted, and compared against certificate metadata. Future implementations should replace the prototype’s serial-depth field with richer scheduling and architecture-aware metrics when the circuit representation supports them.

6.3. Test Generator

For modular inversion certificates, test inputs are generated deterministically from the certificate data. The prototype uses a SHAKE256-derived stream seeded by the circuit hash, modulus, and a test label. SHAKE256 is an extendable-output function standardized as part of SHA-3 [11]. Candidate values are mapped into the valid domain

$$1\le x\le p-1,$$

so that the inversion function is defined. The verifier regenerates the same test inputs and compares them against the inputs recorded in the certificate transcript.

This test-generation rule has two benefits. First, it prevents an author from choosing favorable test inputs after seeing the behavior of the circuit. Second, it makes the transcript reproducible: any reader with the certificate can regenerate the same tests, recompute the same transcript hash, and check the same relations. This mirrors the deterministic challenge-generation philosophy used in Fiat–Shamir-style protocols [7]. It is also consistent with the deterministic randomized testing used by Babbush et al. as part of their zero-knowledge attestation framework for ECDLP resource claims [1].

For toy reversible Boolean circuits, the prototype uses exhaustive truth-table testing instead of randomized testing. The CNOT-copy circuit, Toffoli-AND circuit, SWAP circuit, and small reversible addition circuit are checked on every computational-basis input. These exhaustive examples correspond to Level 2 certificates in the hierarchy of Section 3.3.

6.4. Verifier

The verifier performs four independent checks.

First, it validates the certificate against the JSON schema. This check ensures that the required fields are present: certificate version, certificate identifier, circuit hash, gate basis, arithmetic function, arithmetic parameters, resource counts, input-output specification, test-generation data, correctness transcript, transcript hash, and proof-artifact metadata.

Second, it checks the correctness transcript. For modular inversion, this means verifying every recorded pair $(x,y)$ by checking

$$xy\equiv 1(modp).$$

For randomized modular-inversion certificates, the verifier also regenerates the hash-derived test inputs and confirms that the transcript uses the expected test set. For exhaustive toy circuits, the verifier simulates the public gate list on all computational-basis inputs and compares the outputs against the claimed Boolean or arithmetic function.

Third, it recomputes the transcript hash using a canonical JSON serialization of the transcript. The certificate is rejected if the recomputed hash does not match the recorded hash. This binds the certificate to the exact transcript that was checked.

Fourth, if a public circuit file is supplied, the verifier recomputes the circuit hash and resource counts from the gate list. It then compares the recomputed logical-qubit count, Toffoli count, CNOT count, and serial depth against the certificate metadata. The certificate is accepted only when the public circuit and the certificate agree.

In command-line form, the verifier supports checks such as

$$\mathtt{python}-\mathtt{mverifier}.\mathtt{certificateexamples}/\mathtt{inv}\_\mathtt{8}\mathtt{bit}.\mathtt{json}$$

for transcript-only modular-inversion certificates, and

$$\mathtt{python}-\mathtt{mverifier}.\mathtt{certificateexamples}/\mathtt{inv}\_\mathtt{8}\mathtt{bit}\_\mathtt{with}\_\mathtt{circuit}.\mathtt{json}$$

$$--\mathtt{circuitcircuits}/\mathtt{toy}\_\mathtt{modinv}\_\mathtt{stub}\_\mathtt{8}\mathtt{bit}.\mathtt{json}$$

for certificates that also bind to a public circuit file. The circuit in this example is a toy stub; it is not a real modular-inversion circuit. Its purpose is to test hash and resource-count verification.

6.5. Certificate Artifact

The prototype uses JSON certificates. A typical certificate records the following data.

certificate_id.

A stable identifier for the certificate.

circuit_hash.

A hash commitment to the circuit or circuit family.

gate_basis.

The reversible gate basis used for counting.

arithmetic_function.

The arithmetic function being certified, for example modular inversion.

arithmetic_parameters.

The modulus, bit length, and field convention.

resource_counts.

Qubits, gate counts, and serial depth.

io_spec.

The input-output convention and correctness relation.

test_generation.

The hash-derived or exhaustive test specification.

correctness_transcript.

The test inputs, outputs, and pass flags.

transcript_hash.

A hash of the canonical transcript.

proof_artifact.

Optional proof metadata.

The current repository includes several example certificates. The modular inversion examples examples/inv8bit.json and examples/inv16bit.json check deterministic transcript verification for small prime fields. The example examples/inv8bitwithcircuit.json additionally binds the certificate to a public toy gate-list file and verifies the circuit hash and resource counts. The toy circuit certificates for CNOT-copy, Toffoli-AND, SWAP, and reversible modular addition demonstrate exhaustive truth-table certification for small reversible blocks.

The repository also generates summary reports in Markdown and CSV format. These reports record the certificate identifier, arithmetic function, modulus or bit length when applicable, test count, transcript-hash status, public-circuit status, resource-count status, proof-artifact type, and final verification status. These reports are not part of the mathematical certificate definition; they are convenience artifacts for readers and implementers.

The prototype therefore realizes the lower levels of the certificate hierarchy: schema validation, deterministic tests, transcript hashing, public-circuit binding, resource-count verification, serial-depth reporting under a declared toy scheduling convention, and exhaustive truth-table checks for toy circuits. Formal proof objects and zero-knowledge proof artifacts are left for future work. This division matches the purpose of the paper: to define and demonstrate a lightweight certificate layer for public reversible arithmetic blocks, not to replace full formal verification or withheld-circuit attestation. The latter setting is represented by zero-knowledge resource attestation as in Babbush et al. [1]; the former is represented by public arithmetic-block constructions such as the modular-inversion work of Luo et al. [2].

7. Experiments and Case Studies

This section records the prototype experiments supported by the accompanying repository. The experiments are intentionally modest. They are designed to exercise the certificate pipeline, not to reproduce a full quantum ECDLP resource estimate. In particular, the current prototype does not implement the space-efficient reversible extended-Euclidean modular inversion circuit of Luo et al. [2], and it does not verify the withheld circuits or zero-knowledge proof artifacts of Babbush et al. [1]. The purpose is instead to show that public arithmetic-block claims can be bound to concrete certificates, deterministic tests, transcript hashes, public circuit hashes, and resource-count metadata.

The repository currently generates two classes of reports. The certificate report files1 summarize schema validation, transcript verification, public-circuit hash verification, resource-count verification, proof-artifact type, and final status. The toy-circuit report files2 summarize public toy reversible circuits and their truth-table simulations. The tables below record the intended interpretation of those artifacts.

7.1. Toy Exhaustive Tests

The first class of experiments uses exhaustive truth-table testing for small reversible Boolean and arithmetic circuits. These examples are not cryptographic circuits. They are included to validate the certificate pipeline in a setting where correctness can be checked on every input.

The current toy circuits include a CNOT-copy block, a Toffoli-AND block, a SWAP block, and a small reversible addition block. Each circuit is given as a public gate list. The verifier recomputes its circuit hash, recomputes elementary resource counts, simulates the circuit on every computational-basis input, and compares the resulting truth table with the claimed function. These examples therefore instantiate Level 2 certificates in the hierarchy of Section 3.3.

Table 2. Exhaustive toy-circuit certificate examples generated by the prototype. These examples validate the certificate pipeline on small reversible Boolean and arithmetic maps; they are not cryptographic circuits.

Certificate	Function	Tests	Circuit check	Status
CNOT-copy	toy_cnot_copy	exhaustive	hash and resource counts verified	pass
Toffoli-AND	toy_toffoli_and	exhaustive	hash and resource counts verified	pass
SWAP	toy_swap	exhaustive	hash and resource counts verified	pass
Addition mod $2^n$	toy_add_mod_2n	exhaustive	hash and resource counts verified	pass

Table 2. Exhaustive toy-circuit certificate examples generated by the prototype. These examples validate the certificate pipeline on small reversible Boolean and arithmetic maps; they are not cryptographic circuits.

Certificate	Function	Tests	Circuit check	Status
CNOT-copy	toy_cnot_copy	exhaustive	hash and resource counts verified	pass
Toffoli-AND	toy_toffoli_and	exhaustive	hash and resource counts verified	pass
SWAP	toy_swap	exhaustive	hash and resource counts verified	pass
Addition mod $2^n$	toy_add_mod_2n	exhaustive	hash and resource counts verified	pass

The reversible addition example is the most arithmetic of the current toy blocks. It implements a small reversible map of the form

$$(a,b)⟼(a,b+amod{2}^n)$$

for a toy value of n. It is not a modular addition circuit modulo an arbitrary prime, and it is not part of a full ECDLP circuit. Its purpose is to show that the certificate format can bind a public arithmetic gate list to an exhaustively checked input-output relation.

7.2. Deterministic Randomized Tests

The second class of experiments uses deterministic randomized tests for modular inversion certificates. For these examples, the verifier derives test inputs from a SHAKE256 stream seeded by the circuit hash, modulus, and test label. SHAKE256 is an extendable-output function standardized in FIPS 202 [11]. The generated inputs lie in

$${\mathbb{F}}_p^{\times }=\{1,\dots ,p-1\},$$

and the verifier checks each transcript row by testing

$$xy\equiv 1(modp).$$

The repository currently includes two transcript-only modular inversion certificates and one modular inversion certificate that also binds to a public toy gate list. The latter example checks circuit hash and resource-count metadata in addition to the modular inversion transcript.

Table 3. Deterministic randomized modular-inversion certificate examples. The verifier regenerates hash-derived tests, checks $xy\equiv 1(modp)$, and verifies the transcript hash. The third example additionally checks a public toy circuit hash and resource-count metadata.

Certificate	p	Tests	Transcript	Public circuit	Status
inv_8bit	251	32	hash verified	not attached	pass
inv_16bit	65521	64	hash verified	not attached	pass
inv_8bit_with_circuit	251	32	hash verified	hash/counts verified	pass

Table 3. Deterministic randomized modular-inversion certificate examples. The verifier regenerates hash-derived tests, checks $xy\equiv 1(modp)$, and verifies the transcript hash. The third example additionally checks a public toy circuit hash and resource-count metadata.

Certificate	p	Tests	Transcript	Public circuit	Status
inv_8bit	251	32	hash verified	not attached	pass
inv_16bit	65521	64	hash verified	not attached	pass
inv_8bit_with_circuit	251	32	hash verified	hash/counts verified	pass

These tests demonstrate deterministic transcript verification. They should not be read as evidence for the correctness of a large modular inversion circuit. The circuit attached to inv_8bit_with_circuit.json is a toy stub used to test hash and resource-count plumbing. The larger goal is to support the same certificate pattern for public modular inversion circuits such as the extended-Euclidean constructions studied by Luo et al. [2].

The soundness interpretation is the one stated in Proposition 4.1. If a deterministic circuit is wrong on an $\epsilon$-fraction of the test domain, then N independent random tests miss all bad inputs with probability at most ${(1-\epsilon )}^N$. This probabilistic interpretation is useful for large domains, while exhaustive testing remains preferable whenever the domain is small enough.

7.3. Resource-Count Reproduction

The prototype verifies resource metadata in a limited but concrete sense. For a public gate-list circuit, the verifier recomputes the circuit hash and basic gate counts from the gate list. It then compares those values against the certificate fields shown in Table 4. The current serial-depth convention is intentionally simple: it records the number of gates under a fully serial schedule. This is not a parallel depth, Toffoli-depth, T-depth, or architecture-aware depth metric.

This resource-count check is not yet a reproduction of the asymptotic formulas reported by Luo et al. [2]. In particular, the prototype does not implement the full location-controlled arithmetic and length-register structure used to obtain the reported low-space modular inversion bound

$$3n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$$

or the full ECDLP bound

$$5n+4\lfloor {log}_{2}n\rfloor +O\left(1\right).$$

It also does not reproduce the withheld low-qubit or low-gate secp256k1 circuits attested by Babbush et al. [1].

The point of the prototype is narrower: a certificate can bind a public circuit file to its claimed resource counts, and the verifier can reject mismatches. This is the first step toward certifying larger public arithmetic blocks. A future version should replace toy circuits with public reversible modular arithmetic generators and then compare the recomputed counts to stated theoretical formulas.

7.4. Certificate-Size and Verifier-Runtime Measurements

The repository also records certificate-level metadata useful for reproducibility: certificate status, number of tests, transcript-hash status, public-circuit status, and resource-count status. These measurements are not performance benchmarks for quantum circuits. They are measurements of the certificate workflow itself.

The current report generator does not yet record precise file-size and verifier runtime columns. Table 5 records the intended measurement fields for the next version of the prototype. These quantities will become more important when the verifier is applied to larger generated arithmetic circuits.

The experimental conclusion is modest but useful. The prototype demonstrates an end-to-end certificate workflow for public reversible arithmetic blocks. It validates schema structure, deterministic test generation, transcript hashing, public circuit hashing, resource-count verification, exhaustive toy simulation, and summary report generation. This is the functionality needed for the next stage, where the toy circuits can be replaced by public reversible modular arithmetic blocks closer to those used in quantum ECDLP resource estimates.

8. Comparison with Existing Disclosure Models

This section compares the certificate model proposed in this paper with two disclosure practices already present in quantum-ECDLP resource estimation. The first is full technical disclosure, where circuits or circuit constructions are public and resource claims can be recomputed. The second is withheld-circuit attestation, where sensitive circuit details are not disclosed but selected claims are supported by a proof artifact. The model proposed here occupies a third position: the circuit or circuit family is public, but the resource and correctness claims are packaged in a structured, machine-checkable certificate.

8.1. Open Circuits and Recomputation

Open technical disclosure is the most direct reproducibility model. A paper publishes the arithmetic construction, circuit design, resource-count method, and sufficient implementation detail for readers to recompute or reimplement the claims. Luo et al. follow this model for their reversible modular inversion construction: they describe an extended-Euclidean modular inversion circuit, state its logical-qubit and gate-count estimates, and identify the resulting full-ECDLP qubit estimate obtained by inserting the inversion block into affine point addition [2].

The advantage of open disclosure is clarity. Readers can inspect the arithmetic design and attempt independent implementations. The limitation is that even public descriptions can be difficult to compare across papers. Resource counts depend on gate basis, register conventions, allowed ancillas, scheduling conventions, and compilation assumptions. A public circuit description therefore benefits from a structured metadata layer. The certificate format proposed here adds such a layer: it binds the public arithmetic block to a circuit hash, arithmetic parameters, resource counts, deterministic tests, and transcript hash.

Thus our certificate model does not replace open disclosure. It strengthens it. For public arithmetic blocks, recomputation remains possible, but the certificate makes the object being recomputed more precise.

8.2. Withheld Circuits and Zero-Knowledge Attestation

A different disclosure model is appropriate when revealing a complete circuit may expose sensitive cryptanalytic details. Babbush et al. explicitly adopt this posture for improved secp256k1 quantum-ECDLP resource estimates: they report resource thresholds while withholding circuit details, and they use a zero-knowledge attestation framework to support the claimed resource bounds [1]. Their appendix describes proof statements, circuit commitments, randomized correctness testing, and proof artifacts for low-qubit and low-gate variants of the claimed computation [1]. The general cryptographic methodology is consistent with the Fiat–Shamir paradigm for deriving public challenges from commitments [7], and with succinct proof-system technology such as Groth16 [12].

This withheld-circuit model serves a different purpose from ours. It is appropriate for sensitive full attack circuits, where complete disclosure may be undesirable. The present paper does not attempt to verify the withheld circuits of Babbush et al. [1]. Nor does it claim that lightweight certificates are a substitute for zero-knowledge attestation in sensitive settings.

Instead, we treat withheld-circuit attestation as a complementary model. If the object is private, a proof artifact may be necessary. If the object is public, a structured certificate may be sufficient to make the claim reproducible and comparable.

8.3. Public Arithmetic Blocks with Proof-Carrying Certificates

The certificate model proposed here is designed for public reversible arithmetic blocks. Examples include modular inversion, modular multiplication, controlled addition, point addition, and architecture-specific compiled versions of those subroutines. These blocks may be too small or too public to justify a full zero-knowledge attestation pipeline, but still complex enough that informal resource claims are difficult to audit.

A proof-carrying arithmetic certificate records the circuit commitment, gate basis, resource counts, input-output specification, deterministic test rule, correctness transcript, and optional proof artifact. For public circuits, the verifier can recompute the circuit hash and resource counts. For arithmetic transcripts, it can regenerate hash-derived tests and recompute transcript hashes. For small examples, it can exhaustively simulate the truth table. This provides a low-overhead reproducibility layer between ordinary prose descriptions and full proof systems.

The intended use is incremental. A Level 0 certificate records metadata and resource claims. A Level 1 certificate adds deterministic randomized tests. A Level 2 certificate adds exhaustive correctness for toy domains. Higher levels may add formal verification or succinct proof artifacts. This makes the model compatible with both public-circuit reproducibility and future proof-based extensions.

8.4. Summary Table

Table 6 summarizes the three disclosure models. The table is not meant to rank them. Each model is appropriate in a different setting. Full disclosure is strongest when public recomputation is desired and safe. Withheld-circuit attestation is strongest when the full circuit is sensitive. Public arithmetic certificates are intended for public subroutines whose correctness and resource claims should be independently auditable.

The certificate model should therefore be read as a middle disclosure layer. It does not offer the secrecy properties of zero-knowledge attestation, and it does not replace detailed circuit descriptions. Its purpose is narrower: to give public arithmetic blocks a standard, reproducible, and machine-checkable resource-certificate format.

Remark 8.1 

(A broader proof-carrying arithmetic perspective). The certificate model in this paper is specialized to public reversible arithmetic blocks used in quantum ECDLP resource estimation. Nevertheless, the underlying principle is broader: computational arithmetic claims should be attached to explicit objects, reproducible checks, and independently verifiable data. In the present setting, the objects are circuits, resource counts, test transcripts, and circuit commitments. In arithmetic geometry, analogous reproducibility questions arise for descent computations, Selmer representatives, local conditions, boundary maps, and liftability obstructions.

For example, Creutz’s second p-descent framework computes whether a class at one level of the Shafarevich–Tate group lifts to the next, equivalently whether there exists a class D with $pD=C$ for a given obstruction class C [13]. Dogra’s work on 2-descent for Bloch–Kato Selmer groups computes explicit boundary maps associated to torsion exact sequences such as

$$0⟶J\left[2\right]⟶J\left[4\right]⟶J\left[2\right]⟶0,$$

which act as liftability obstructions in a Selmer-theoretic setting [14]. These examples are not used in the present paper, and we make no BSD-type claim here. They simply illustrate that the same proof-carrying philosophy—explicit objects, checkable relations, and reproducible verification data—may be useful beyond quantum-circuit resource certification.

9. Limitations

The certificate framework developed in this paper is a reproducibility framework for public reversible arithmetic blocks. It is not a new quantum algorithm for ECDLP, does not improve the asymptotic complexity of Shor’s algorithm [3], and does not reproduce a complete ECDLP circuit of the kind studied in prior quantum resource estimates [4,5,6].

The framework also does not reconstruct, verify, or audit withheld circuits from prior work. In particular, it is complementary to the zero-knowledge attestation approach of Babbush et al. [1], rather than a verification of their private circuits.

The prototype certifies arithmetic-block metadata and transcripts, not a full Shor-style ECDLP pipeline. Its modular-inversion case study is motivated by the public construction of Luo et al. [2], but the implementation does not reproduce their full extended-Euclidean circuit, length-register machinery, or location-controlled arithmetic blocks.

Randomized testing is probabilistic. The bound in Section 4 shows that an $\epsilon$-bad circuit passes N independent tests with probability at most ${(1-\epsilon )}^N$, but universal correctness requires exhaustive testing, formal verification, or a proof artifact.

Finally, resource certificates depend on conventions: gate basis, register layout, ancilla policy, scheduling convention, and architecture model all affect the meaning of a resource count. The current implementation is therefore a proof of concept using toy circuits, intended to fix a concrete certificate workflow before scaling to larger public arithmetic circuits.

10. Future Work

Several extensions follow naturally from the certificate framework. First, the format should be instantiated on a public Luo-style modular inversion circuit or faithful circuit generator. Luo et al. give a reversible extended-Euclidean modular-inversion construction with $3n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$ logical qubits for modular inversion and $5n+4\lfloor {log}_{2}n\rfloor +O\left(1\right)$ logical qubits for prime-field ECDLP [2]; a natural next step is to bind such a construction to a certificate recording its circuit hash, resource counts, test transcript, and convention choices.

Second, one can add proof artifacts. The present paper allows $\pi =⌀$, but a stronger certificate could embed the modular-inversion claim into a succinct or zero-knowledge proof system, in the spirit of the attestation model used by Babbush et al. for withheld ECDLP resource claims [1]. For public arithmetic blocks, such a prototype would not need to hide the circuit; it would instead demonstrate succinct verification of correctness and resource claims.

Third, the format should be extended from modular inversion to elliptic-curve point addition. This is a richer target because affine formulas involve ordinary addition, doubling, exceptional cases, and the point at infinity. A point-addition certificate should therefore record domain conventions, exceptional-case handling, register layout, and correctness tests for all relevant branches, bringing the framework closer to complete ECDLP resource estimates [5,6].

Fourth, future certificates should support architecture-aware metrics beyond the prototype’s serial-depth convention: Toffoli depth, T-depth, active volume, routing overhead, two-dimensional layout constraints, surface-code assumptions, and physical-qubit estimates. Such fields would make certificates more useful for comparing logical arithmetic blocks under different fault-tolerant architectures.

Fifth, certificates can support circuit optimization. Luo et al. identify non-standard components such as length-register and location-controlled operations as targets for further gate-count and depth optimization [2]. A certificate can make each proposed improvement auditable by binding the optimized block to a circuit hash, resource counts, and correctness transcript.

Finally, Remark 8.1 points to an independent arithmetic-geometric spin-off. Creutz’s second p-descent computes liftability data in the Shafarevich–Tate group [13], while Dogra’s work computes boundary maps for torsion exact sequences in Bloch–Kato Selmer settings [14]. A separate project could develop certificate objects for such computations; this lies outside the quantum-ECDLP application but reflects the same proof-carrying arithmetic philosophy.

11. Conclusions

Quantum ECDLP resource estimates are increasingly consequential, but their verification practices are not yet uniform. Public arithmetic constructions, such as the reversible modular-inversion work of Luo et al. [2], support recomputation and independent implementation. Withheld-circuit approaches, such as the zero-knowledge attestation model of Babbush et al. [1], support selected claims without revealing sensitive circuit details. This paper proposed a third, complementary model: public arithmetic blocks equipped with structured, reproducible resource certificates.

The certificate model binds a circuit commitment, gate basis, arithmetic parameters, resource counts, input-output specification, deterministic tests, correctness transcript, and optional proof artifact. We specialized the framework to modular inversion over prime fields, proved a basic soundness bound for hash-derived randomized testing, and described a prototype verifier that checks schema validity, transcript hashes, public circuit hashes, resource metadata, and exhaustive truth tables for toy examples.

The contribution is not a new ECDLP attack and not a new low-qubit or low-gate resource record. It is a reproducibility layer for proof-carrying quantum arithmetic. Modular inversion is the first case study because it is central to affine-coordinate quantum ECDLP arithmetic and already has a public low-space construction [2]. The next step is to replace toy examples with public modular arithmetic generators, then with modular-inversion and point-addition blocks closer to those used in quantum ECDLP estimates. In that form, resource certificates can make public quantum-ECDLP arithmetic claims easier to compare, reproduce, and audit.