What if post-quantum Ethereum doesn’t need signatures at all?
TL;DR: Current PQC migration plans assume we must verify post-quantum signatures — either on-chain (kilobytes per tx) or inside ZK circuits (millions of constraints). We present an alternative: prove authorization semantics directly in ZK, without any signature object. Result: 4,024 R1CS constraints, 128-byte proofs, 52 ms proving time. The construction is proof-system agnostic (Groth16, PLONK, STARKs all work) and deployable today as an AA validator module — no protocol changes required.
Motivation: The PQC data wall
The community has been actively exploring PQC migration paths (13) and the core tension is well-known:
| Scheme | Sig Size | Public Key | Total per TX |
|---|---|---|---|
| ML-DSA-44 (Level 2) | 2,420 B | 1,312 B | 3,732 B |
| ML-DSA-65 (Level 3) | 3,309 B | 1,952 B | 5,261 B |
| ML-DSA-87 (Level 5) | 4,627 B | 2,592 B | 7,219 B |
| SLH-DSA-128f | 17,088 B | 32 B | 17,120 B |
| FN-DSA-512 | ~666 B | 897 B | 1,563 B |
| Ed25519 (classical) | 64 B | 32 B | 96 B |
That’s a 30-60x increase in authorization data per transaction. In rollup architectures where calldata/blob space is explicitly priced, this is a first-order scalability problem.
The “obvious” solution and why it’s expensive
The natural response is: verify PQ signatures inside ZK circuits, post only the succinct proof on-chain.
The problem: lattice-based signature verification requires NTTs over degree-256 polynomial rings in \mathbb{Z}_q (q = 2^{23} - 2^{13} + 1), emulated over a ~254-bit proof-system field. Structural lower bounds:
| In-circuit verification | R1CS constraints | Dominant cost |
|---|---|---|
| ML-DSA-44 verify | ≥ 2M | 4×4 NTTs + non-native mod. arith. |
| ML-DSA-65 verify | ≥ 4M | 6×5 NTTs + non-native mod. arith. |
| FN-DSA-512 verify | ≥ 1M | FFT + Gram-Schmidt + mod. arith. |
| SLH-DSA verify | ≥ 5M | WOTS+ chains + Merkle trees |
| ECDSA verify (classical) | ~1.5M | scalar mul. + mod. inverse |
Even with optimized gadgets, we’re looking at millions of constraints just to prove “this signature is valid.”
Key observation: authorization ≠ signatures
Here’s the thing: at the consensus layer, blockchains don’t actually require verification of a specific signature object. What consensus requires is assurance that a transaction was authorized by the correct entity.
Signatures are an implementation artifact for expressing authorization — not authorization itself. We’ve been conflating the two.
ZK-ACE: identity-centric authorization
We present ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities), which takes this observation to its logical conclusion:
Don’t verify signatures in ZK. Don’t compress signatures. Eliminate signature objects from the authorization path entirely.
Instead, the chain stores a compact identity commitment (32 bytes):
$$ID_{com} = H(REV | salt | domain)$$
where REV is a 256-bit identity root derived from a deterministic identity derivation primitive (DIDP). Each transaction carries a ZK proof attesting:
- (C1) Commitment consistency: Prover knows a preimage of ID_{com}
- (C2) Derivation correctness: A target-binding hash is consistent with deterministic key derivation under the identity root
- (C3) Authorization binding: The identity root has authorized this specific TxHash
- (C4) Anti-replay: Nonce commitment or nullifier is correctly derived
- (C5) Domain separation: All bindings use the declared chain/domain tag
The entire circuit is 5 Poseidon hash invocations + equality constraints. No lattice arithmetic. No signature verification logic. No non-native field emulation.
Benchmarks (reference implementation)
Implementation: arkworks + Groth16 over BN254, Poseidon (t=3, \alpha=17, 8 full + 57 partial rounds).
Circuit size:
| Constraint | Inputs | Hash calls | R1CS |
|---|---|---|---|
| (C1) Commitment consistency | 3 | 1 | 805 |
| (C2) Derivation correctness | 4+1 | 2 | 1,200 |
| (C3) Authorization binding | 7 | 1 | 1,615 |
| (C4) Replay prevention | 2 | 1 | 400 |
| (C5) Domain sep. + enforce_equal | — | — | 4 |
| Total | 5 | 4,024 |
Both replay modes (nonce-registry and nullifier-set) produce identical constraint counts.
Performance (single-threaded, Apple M3 Pro, Criterion.rs, 100 samples):
| Operation | Median | 95% CI |
|---|---|---|
| Trusted setup (one-time) | 45.6 ms | [45.4, 45.8] ms |
| Prove (per transaction) | 52.3 ms | [51.5, 53.4] ms |
| Verify (per transaction) | 604 μs | [600, 608] μs |
Proof size:
| Encoding | Proof | Public inputs | Total auth data |
|---|---|---|---|
| Compressed Groth16 | 128 B | 160 B (5 × 32 B) | 288 B |
Compression vs. PQ signatures:
| Scheme | PQ sig+pk | ZK-ACE | Reduction |
|---|---|---|---|
| ML-DSA-44 (Level 2) | 3,732 B | 288 B | 13x (92.3%) |
| ML-DSA-65 (Level 3) | 5,261 B | 288 B | 18x (94.5%) |
| ML-DSA-87 (Level 5) | 7,219 B | 288 B | 25x (96.0%) |
| SLH-DSA-128f | 17,120 B | 288 B | 59x (98.3%) |
Constraint comparison (the core result):
| Approach | R1CS constraints |
|---|---|
| ZK-ACE (this work) | 4,024 |
| In-circuit ML-DSA-44 verify | ≥ 2,000,000 |
| In-circuit ECDSA verify | ~1,500,000 |
That’s a ~500x constraint reduction — not from optimizing signature verification, but from not doing it at all.
Deployment: AA validator module
ZK-ACE is designed as an ERC-4337 validator module. In an AA wallet:
- The account validation logic invokes ZK-ACE verification instead of checking a classical or PQ signature
- Proof generation happens client-side (~52 ms)
- The bundler transports proof + public inputs (untrusted, learns nothing)
- On-chain verification costs ~604 μs per proof
This means no protocol-level changes are required. ZK-ACE can be deployed on existing infrastructure.
Proof-system agnostic by design
An important design property: ZK-ACE is a protocol-level authorization model, not a proof-system-specific construction. The five constraints (C1)–(C5) are stated over abstract hash evaluations and equality checks. They can be instantiated with:
| Proof system | Setup | Proof size | Trade-off |
|---|---|---|---|
| Groth16 (reference impl.) | Trusted (per-circuit) | 128 B | Smallest proof, fastest verify |
| PLONK / KZG | Universal (one-time) | ~400–600 B | No per-circuit setup |
| STARKs / FRI | Transparent (none) | ~40–100 KB | No trusted setup, plausibly PQ-secure |
| Bulletproofs / IPA | Transparent | ~700 B | No setup, larger verify cost |
The benchmarks above use Groth16 because it gives the tightest numbers, but the protocol doesn’t depend on it. In particular, a STARK instantiation would make the entire authorization pipeline plausibly post-quantum at the proof layer as well — no trusted setup, no pairing assumptions, hash-based soundness only. The identity commitments are proof-system-agnostic (they’re just hash outputs), so migrating from one proof system to another does not require identity rotation or re-registration.
The security reductions in the paper are stated generically in terms of knowledge-soundness advantage \text{Adv}^{ks} and are compatible with any backend satisfying completeness, knowledge soundness, zero-knowledge, and public-input binding.
Assumed primitive: DIDP
ZK-ACE assumes a Deterministic Identity Derivation Primitive (DIDP) as a black box — any framework providing:
- Deterministic key derivation from a high-entropy root
- Context isolation across derivation paths
- Identity-root recovery hardness
This is not tied to any specific construction. A simple HKDF(root, context) satisfies the interface. We provide ACE-GF as an instantiation; any KDF with domain separation works.
Security
Four game-based security definitions with reduction-based proofs under standard assumptions:
- Authorization soundness → reduces to knowledge soundness + collision resistance + DIDP recovery hardness
- Replay resistance → reduces to authorization soundness + verifier enforcement
- Substitution resistance → reduces to public-input binding of the proof system
- Cross-domain separation → reduces to collision resistance + public-input binding
Full proofs in the paper.
What this is NOT
To be explicit:
- Not ZK-verification of PQ signatures (we don’t verify any signature inside the circuit)
- Not signature compression (we eliminate signatures, not shrink them)
- Not a new signature scheme
- Not dependent on any specific identity framework
It’s a change in what we prove: from “this signature is valid” to “this identity authorized this transaction.”
Relation to existing discussions
This work connects to the ongoing PQC migration discourse:
- So you wanna Post-Quantum Ethereum transaction signature identified the AA path for PQC
- The road to Post-Quantum Ethereum transaction is paved with AA demonstrated Falcon verification via AA
- Poqeth benchmarked PQ signature verification on-chain
These approaches all preserve the signature-centric model. ZK-ACE asks: what if we don’t?
Paper: ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems
Reference implementation: github.com/ya-xyz/zk-ace
I co-founded a brand new, post-quantum L1 project and after reading this thread we’ve totally decided to follow this pattern.