ZK-ACE: Zero-Knowledge Authorization

• ZK-ACE is a cryptographic protocol that uses zero-knowledge proofs to enable privacy-preserving and succinct authorization across blockchain and e-voting applications.
• It incorporates a deterministic identity derivation primitive and rigorous circuit constraints to ensure authorization soundness, replay resistance, and cross-domain separation.
• The protocol reduces on-chain data overhead compared to post-quantum signatures and leverages batch aggregation and recursive proofs for scalable system integration.

ZK-ACE refers to a set of cryptographic protocols that employ zero-knowledge proofs as a core mechanism for privacy-preserving, sound, and succinct authorization. ZK-ACE appears in two prominent research lines: first, as an identity-centric zero-knowledge authorization scheme for post-quantum blockchain environments; and second, as a component in advanced voting protocols enforcing auditability and privacy. The constant within both settings is the explicit use of zero-knowledge statements to prove properties (authorization or ballot well-formedness) without revealing secret witnesses, thereby achieving succinctness, strong security properties, and privacy (Wang, 9 Mar 2026, Rojjha et al., 20 Apr 2026).

1. Identity-Centric Zero-Knowledge Authorization on Blockchain

In blockchain contexts, ZK-ACE is introduced as an alternative to the signature-centric authorization paradigm. Standard deployment of post-quantum (PQ) signature schemes, such as ML-DSA or SLH-DSA, results in large signature artifacts (e.g., 2.4 KB per ML-DSA Level-2 signature), sharply increasing on-chain storage and transaction throughput costs. Even embedding PQ signature verification in zero-knowledge (so-called “ZK-compressed signatures”) simply transfers the verification bottleneck to the prover, as lattice-based signature checks translate to millions of gates in the circuit [(Wang, 9 Mar 2026), Section 1.2].

ZK-ACE shifts the focus: instead of transmission and verification of explicit signature objects, the protocol requires only a succinct zero-knowledge proof that an entity with a committed identity correctly authorized a transaction, according to a deterministic predicate. This approach exploits the fact that consensus protocols fundamentally require a cryptographic guarantee of authorization, not the digital signature artifact per se.

2. Protocol Structure and Core Components

Deterministic Identity Derivation Primitive (DIDP)

At the foundation of ZK-ACE is the DIDP, a primitive with two key interfaces [(Wang, 9 Mar 2026), Section 3.2]:

• Unseal: $$REV \leftarrow \mathsf{Unseal}(\mathsf{params}, SA, Cred)$$
• Derive: $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$, with context $$Ctx=(\mathsf{AlgID}, \mathsf{Domain}, \mathsf{Index})$$

The DIDP must have identity-root recovery hardness, preventing adversaries from recovering the root identity $REV$ given only access to hash oracles related to $REV$ and to derived keys. The concrete security definition is formalized as: $$\Pr\left[\mathcal{A} \text{ wins } \mathsf{Game}^{\mathsf{rec\text{-}didp}}_{\mathcal{A}}(\lambda)\right] \leq \mathsf{negl}(\lambda)$$ where the adversary has specified oracle access [(Wang, 9 Mar 2026), Section 3.3].

On-Chain Commitments and Replay State

The primary on-chain anchor is a compact identity commitment, formed as: $ID_{com} = H(REV\Vert salt \Vert domain)$ where $salt$ is randomly chosen per identity [(Wang, 9 Mar 2026), Eq. 4.1]. Per-transaction replay prevention relies on either a nonce commitment or a nullifier, supporting two distinct replay-prevention models (see Section 5).

Authorization Proofs and Circuit Constraints

Authorization is carried by a non-interactive zero-knowledge proof showing that the prover knows $(REV, salt, Ctx, ...)$ linking a transaction to $ID_{com}$ and a fresh replay state, satisfying a set of five core circuit constraints (C1–C5) [(Wang, 9 Mar 2026), Section 7.2]:

Constraint	Description
C1	$\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$0
C2	$\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$1
C3	$\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$2
C4-nonce / C4-null	$\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$3 hash of $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$4 with nonce (or of $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$5 with domain) – replay
C5	$\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$6

Circuit instantiations use Poseidon (e.g., $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$7) and require approximately 1,100–1,400 R1CS constraints per proof [(Wang, 9 Mar 2026), Table 7.1].

3. Game-Based Security Definitions

ZK-ACE formalizes and proves four core security properties, each via a standard cryptographic game [(Wang, 9 Mar 2026), Section 5]:

• Authorization Soundness: Ensures adversaries cannot forge valid proofs authorizing transactions under untouched $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$8 (Definition 5.1).
• Replay Resistance: Prevents malicious actors from resubmitting the same proof for multiple acceptances (Definition 5.2).
• Substitution Resistance: Forbids proof reuse with altered public inputs (Definition 5.3).
• Cross-Domain Separation: Blocks cross-domain proof replay using the same identity root (Definition 5.4).

Reductions establish these properties under knowledge soundness of the ZK system, collision resistance of $\mathsf{Key}\leftarrow \mathsf{Derive}(REV,Ctx)$9, and DIDP recovery hardness, with explicit inequalities bounding adversary advantage. For example, for authorization soundness (Theorem 5.2): $$Ctx=(\mathsf{AlgID}, \mathsf{Domain}, \mathsf{Index})$$0

4. Replay Prevention Schemes

ZK-ACE supports two canonical replay-prevention models [(Wang, 9 Mar 2026), Section 6.4]:

• Nonce Registry: On-chain, per-identity state enforces monotonically increasing nonces (constraint C4-nonce). This approach naturally supports account abstraction and reveals transaction ordering.
• Nullifier Set: On-chain global set accumulating nullifiers derived from $$Ctx=(\mathsf{AlgID}, \mathsf{Domain}, \mathsf{Index})$$1 and domain (constraint C4-null), yielding better unlinkability at the cost of global state growth.

Verifiers are responsible for enforcing freshness of replay state in either mode (Algorithm 4.1).

5. Data Efficiency, Batch Aggregation, and Recursive Proofs

The ZK-ACE approach achieves an order-of-magnitude reduction in on-chain authorization data compared to PQ signature models. For a single transaction authorization [(Wang, 9 Mar 2026), Table 10.1]:

• PQ Signature: 3.7–7.2 KB per transaction (signature + pubkey amortization)
• ZK-ACE: 320–448 B (including Groth16 proof, commitment, and public inputs)

Batch aggregation schemes allow multiple independent ZK-ACE proofs (possibly from distinct identities) to be amortized, either via SNARK multi-proof composition or through recursive proof constructions. Recursive composition enables $$Ctx=(\mathsf{AlgID}, \mathsf{Domain}, \mathsf{Index})$$2 authorizations to be proven by a single, constant-size SNARK, which is particularly suited for rollup-based architectures.

6. Deployment Architectures and System Integration

ZK-ACE is compatible with modern account abstraction frameworks (e.g., as an ERC-4337 validator). User wallets generate ZK-ACE proofs off-chain; validation logic simply invokes the proof verifier on-chain [(Wang, 9 Mar 2026), Section 9.2]. Rollup protocols can aggregate or recurse many ZK-ACE proofs before posting state roots, thereby minimizing calldata.

The system is agnostic to SNARK type (Groth16, PLONK, STARKs, Bulletproofs), with the only constraint that the hash function in circuit matches that in DIDP derivation. Circuit-native hashes such as Poseidon are preferred for proof efficiency, but commitments themselves remain proof-system independent.

7. ZK-ACE in Privacy-Preserving Voting

In advanced e-voting, ZK-ACE (also referred to as “ACE with explicit zero-knowledge”) forms the cryptographic backbone for protocols achieving end-to-end verifiability, tally-hiding aggregation, and receipt-freeness [(Rojjha et al., 20 Apr 2026), Sections 1–5]. Here, Pedersen vector commitments encode votes, and zero-knowledge proofs replace explicit ballot receipts:

• Each voter commits to a split-share encoding of their ballot.
• Audit-or-Cast cut-and-choose enforces cast-as-intended security: voters challenge talliers with either “audit” or “cast” rounds, extracting SNARK proofs of correct rerandomization.
• Publicly verifiable non-interactive ZK proofs (NIZK/SNARKs) certify each step (ballot formation, tallier-side rerandomization, tally decommitment).
• Security definitions ensure end-to-end verifiability (accountability), public and internal tally-hiding, and information-theoretic receipt-freeness under standard cryptographic assumptions.

These protocols demonstrate ZK-ACE’s versatility beyond blockchain authorization, supporting privacy and integrity in distributed trust settings.

---

References:

• "ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems" (Wang, 9 Mar 2026)
• "Audit-or-Cast: Enforcing Honest Elections with Privacy-Preserving Public Verification" (Rojjha et al., 20 Apr 2026)