zkComposer: Decomposing Proof Construction to Scale zkML Pawan Kumar Sanjaya∗ , Christina Giannoula†§ , Valdy Oktavian∗ , Mehdi Saeedi‡ , Gabor Sines‡ , Gururaj Saileshwar∗ , Nandita Vijaykumar∗ ∗ University of Toronto, Canada † Max Planck Institute for Software Systems (MPI-SWS), Germany
arXiv:2607.08095v1 [cs.CR] 9 Jul 2026
‡ Advanced Micro Devices (AMD)
Abstract—Zero-knowledge machine learning (zkML) enables a server to perform verifiable inference while keeping model parameters private from the client. However, existing zkML systems incur prohibitive proof-generation costs. We observe that proof generation exhibits limited parallelism; that is, prover time does not decrease significantly as the number of threads increases. This limitation is because existing systems rely on monolithic proof computation, constructing a single proof for the entire machine learning model. We introduce zkComposer, a modular proof-construction framework that unlocks an additional dimension of parallelism, in addition to the parallelism in existing proof kernels. zkComposer decomposes the zkML proof of correct inference into independent sub-proofs, each covering a subset of the computation for inference, e.g., each independent sub-proof can cover a subset of contiguous layers in the ML model. Adjacent sub-proofs are cryptographically linked through shared commitments to the activations from the boundary layer. zkComposer provides the same guarantees as the monolithic proof without requiring additional linking proofs or changes to the underlying cryptographic primitives. We implement zkComposer and evaluate it on three CNNs and GPT-2. We show that, on CNN workloads, zkComposer reduces prover time and response time by up to 3.25× relative to zkCNN [1]. On GPT-2, zkComposer reduces these times by up to 4.83× relative to zkGPT [2], when partitioning along the model layers. When partitioning across both model layers and input sequences in GPT-2, we show that zkComposer reduces prover time and response time by up to 6.84× relative to zkGPT [2].
1. Introduction Machine learning (ML) inference systems are increasingly deployed in high-stakes domains including personalized recommendations [3], fraud detection [4], insurance § Work partially conducted while the author was at the University of Toronto. © 2026 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo, Radeon, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
claim processing [5], and healthcare diagnostics [6]. In such settings, it is often critical that a response is generated by a specific model. Such a model may have been verified to satisfy formal properties such as fairness [7], or certified to meet a required quality of output. These guarantees do not hold if a different model is substituted. However, it is difficult to ensure that the service providers who host and deploy these models actually use the specified model [8]. For example, a provider could substitute a cheaper model in place of the one specified by the user. Revealing the model weights would let users rerun the inference and validate the response. However, weights are trade secrets, requiring significant financial resources to train (e.g., $40M for GPT4 [9]) and cannot be revealed [1], [2], [10]. Thus there is a need for a mechanism that lets users verify that a response was generated by the specified model, without knowing the model weights. Recent advances in cryptography, particularly zeroknowledge proofs (ZKPs) [11], [12], [13], offer a practical mechanism to enforce these guarantees. A ZKP allows a prover to convince a verifier that a given computation was executed correctly without revealing any private inputs, intermediate values, or other sensitive information beyond what is implied by the output alone [14]. When used to verify the model used in ML, such systems are commonly referred to as zkML [1], [10], [15], [16], [17], [18]. Figure 1 illustrates a typical zkML inference protocol in the serverclient setting [1], [2], [10], [19], [20]. The client submits a query q to the server. The server runs inference with the model specified by the client using its secret model parameters θ to obtain the response r. It then returns r and a proof π . The client verifies π to confirm that r is the correct output of the specified model on the input q , without learning anything about the model parameters θ. As in prior works [1], [2], [10], [16], [19], we assume that the model architecture itself is public, i.e., known by the client. To generate the proof, the server and the client first encode the ML operations (e.g., matrix multiplications, activations) as arithmetic constraints called the circuit C . The inference server demonstrates that the response r satisfies C , implying correct execution of the specified model on q . Here, the server is the prover and the client is the verifier. The model parameters θ are secret and known only to the
Service Provider (Prover) Inference
q
Client (Verifier)
r
q Inference Query
C,θ Proof q Generation r
Prove(q,r,C)
π
r
Verify Proof q rCπ
π
Verify
Prover time (s)
Figure 1: Overview of a zkML system: service provider generates a proof for inference. Seq. len. 64
1200
Seq. len. 128
Seq. len. 256
900 600 300 124 8 16
32
64
128
192
Number of threads
Figure 2: Prover time of zkGPT [2] does not decrease proportionally as the thread count increases.
server, i.e., they must not be inferred by the client. Thus, the prover generates a commitment to the model parameters and intermediate activations using a cryptographic commitment scheme. The commitment scheme enables the verifier to check that the underlying values satisfy C while keeping those values hidden. In this way, zkML supports ML services where trust is grounded in cryptographic guarantees rather than blind faith in the service provider. Computing this cryptographic proof is substantially more expensive than ordinary inference. For example, our measurements show that zkGPT [2] requires 147.7s to generate a proof for 64 tokens on a 192-core machine with 755 GB of RAM, while generating the corresponding model response on the same machine takes only 94.55ms. This proofgeneration overhead severely degrades user experience in any deployed zkML system. Recent systems reduce this cost via ML- and cryptography-aware optimizations. Quantization [21], lookup-table approximations of non-linear functions [2], [19], and efficient cryptographic representations of common ML kernels [1], [2], [22] lower the proving cost of each arithmetic operation. Leading frameworks such as zkGPT [2] also use circuit squashing, which combines the computations of many model layers into a single circuit layer and reduces the overall circuit depth. Despite these advances, real-world zkML deployments still incur substantial proof-generation times. Existing zkML systems [1], [2], [10], [16], [19], [23] generate a single monolithic proof using an optimized arithmetic circuit for the entire model. This design exposes only intra-proof parallelism: multiple threads can execute the sumcheck protocol or compute commitments concurrently, but this parallelism saturates quickly. Figure 2 shows the prover time of zkGPT [2] when using different thread counts on a machine with 192 cores for several sequence lengths. Prover time stops decreasing beyond 16 threads because
the workload is memory-bound, and additional threads stall on accesses to a large working set in main memory. The total memory footprint of the prover also grows with the size of the inference computation. For example, increasing the sequence length in zkGPT from 64 to 256 raises peak memory consumption of the prover from 240.5 GB to 532.4 GB. This restricts the models and input sizes for which proofs can be computed on memory-constrained accelerators and GPUs. Goal. Our goal is twofold: 1) reduce zkML proof-generation latency, and 2) reduce the peak memory required for proof generation when using large input sizes, so that zkML can run on memory-constrained accelerators and GPUs. We propose zkComposer, a new construction that, to our knowledge, is the first to expose parallelism across independent sub-proofs in zkML frameworks. This reduces proofgeneration time by complementing the parallelism exploited by prior work [1], [2]. In zkComposer, we divide the inference computation along two dimensions: model layers and the input sequence. We refer to each resulting sub-computation as a partition. When partitioning along the model layers, each partition contains the operations of a contiguous subset of layers. When partitioning along the input sequence, each partition contains the operations that compute the activations for a contiguous subset of input positions. Then, instead of generating a single proof for the entire model, we generate a separate proof for each partition. Thus, the circuit for each partition represents a subset of the operations required to compute the response. For example, when partitioning along the model layers, each sub-proof proves that the input was transformed using a subset of contiguous model layers. Within each partition, i.e., within each sub-proof, zkComposer retains an execution structure similar to that of prior works [1], [2] and can still benefit from existing circuit-level optimizations such as circuit squashing. Across partitions, however, zkComposer exposes sub-proof-level parallelism that is not available in a monolithic proof: different partitions can be proved concurrently. This can reduce end-to-end proof-generation time if all the sub-proofs together provide the same security guarantees as the monolithic proof. Thus, zkComposer reduces proof-generation latency by proving partitions in parallel. Additionally, because each partition represents only a subset of the computation relative to the monolithic proof, each sub-proof requires less memory. The smaller memory footprint of each sub-proof also enables proof generation on memory-constrained accelerators and GPUs when each sub-proof is executed in sequence. Challenges. Splitting proofs into multiple sub-proofs while providing the same security guarantees as existing zkML frameworks introduces two key challenges: (1) The integrity of the inference computation must be preserved across partition boundaries, i.e., the proof must demonstrate that the output activations produced by partition i (ordered from output to input) are equal to the input activations in partition i − 1; (2) The zero-knowledge property must be preserved, i.e., the verifier must learn nothing about intermediate activations at partition boundaries beyond what is implied by the final
output and model architecture. To ensure the correctness of the computation across partition boundaries, we generate a single cryptographic commitment for the output activations of each partition and reuse this commitment in both sub-proofs of adjacent partitions. Since a commitment cryptographically binds to a unique value, this reuse creates a guarantee: the boundary activations used in both sub-proofs are identical. Specifically, the output activations produced in partition i’s proof are provably equal to the input activations used in partition i − 1’s proof. To preserve zero knowledge, the commitments are masked with fresh random values. Here, the number of openings for each commitment across all sub-proofs is determined by the model architecture. Since the model architecture is public and known to both the prover and the verifier, the number of openings for each commitment is known at deployment. Thus, the prover uses this information to select a sufficient number of variables in the masking polynomial to mask all openings. This ensures that sharing commitments between sub-proofs reveals no additional information about model weights. Our implementation of zkComposer organizes proof generation into two phases: a sequential commitment phase followed by a fully parallel proof phase. In the commitment phase, the prover generates (masked) commitments to the boundary values of each partition. Once all boundary commitments are computed, the sub-proofs become entirely independent. As a result, the prover can generate all subproofs concurrently on separate processing cores. zkComposer can be implemented using the protocols of modern GKR-based zkML frameworks [1], [2], [16], [19], and can be trivially extended to others [10], [23]. We implement zkComposer using the arithmetization and polynomial commitment schemes from prior works, zkCNN [1] and zkGPT [2]. We compare our implementation with the respective baselines (zkCNN and zkGPT) by running them with the same hardware resources. For three CNNs, zkComposer reduces prover time by up to 3.25× relative to zkCNN with negligible impact on verifier time. Similarly, for GPT2, zkComposer achieves up to a 6.84× prover-time speedup relative to zkGPT. zkComposer also scales better with the number of available cores: its speedup over zkGPT increases from 2.87× at 16 cores to 4.83× at 192 cores with 12 partitions. Beyond exposing parallelism, this decomposition also reduces the prover’s peak memory: generating subproofs sequentially keeps only one partition in memory at a time, yielding up to 8.1× lower peak memory on GPT-2 (§6.3.3). Contributions. We make the following contributions: 1) We introduce zkComposer, a modular proof construction for zkML inference that replaces the traditional monolithic proof with multiple independent sub-proofs. By partitioning the inference computation, zkComposer exposes proof-level parallelism that is unavailable in prior zkML frameworks, while remaining compatible with existing circuit-level optimizations. 2) We design zkComposer such that it provides the same security guarantees as a monolithic proof. zkComposer
uses shared commitments to enforce equality of activations across partition boundaries. It masks these commitments to preserve zero knowledge. We prove that zkComposer preserves the guarantees of the underlying zkML proof system without requiring any changes to its cryptographic primitives. 3) We implement zkComposer on top of zkCNN [1] and zkGPT [2] and evaluate it on three CNN models and GPT-2 [24]. zkComposer reduces prover time by up to 3.25× for CNNs and up to 6.84× for GPT-2 when computing the proofs in parallel. zkComposer also reduces peak prover memory by up to 8.1× in sequential subproof generation. These results show that partitioned proof generation can improve zkML latency and enable proving on more memory-constrained hardware.
2. Background 2.1. Expressing ML Operators in ZkML ZkML inference systems (Figure 1) enable a service provider to prove to a client that a response r to query q was computed using a specified ML model with weights θ. The service provider acts as the prover (P ) and the client as the verifier (V ). The inference computation is represented as a layered arithmetic circuit C consisting of d layers, indexed from 0 (output layer) to d (input layer). Each layer comprises gates that perform arithmetic operations on the output values from the layer i + 1 or the input layer d. Typically, each ML layer is represented as one or more layers in C . To generate the proof, P demonstrates knowledge of a private witness w = {adv, θ} (advice values and model weights) such that the public instance x = (q, r) satisfies the circuit constraints, i.e., C evaluates to 1 on input x and witness w. The advice values are used to compute non-linear activation operations such as ReLU [2] and max pooling [1]. Public values q and r are known to both parties, while only P knows the private witness. This proof convinces V that r is indeed the correct output obtained by evaluating the specified model on input q . In modern zkML systems [1], [2], [10], [19], the values (q, r, adv, θ, . . .) are represented over a prime field (Fp ), i.e., integers (0, . . . , p−1) with addition and multiplication modulo p. These values are encoded into low-degree polynomials (represented as f (.), g(.)) over the field, so the circuit (C ) can be viewed as a collection of polynomial constraints that the instance and witness polynomials must satisfy. zkML systems must support two distinct classes of operations [2]. (1) Linear kernels (e.g., matrix multiplication and convolution) are represented directly by low-degree polynomial relations linking their input and output polynomials. P proves that these relations hold. (2) Non-linear activations are typically handled by adding auxiliary witnesses (advice values) and lookup-style constraints: P proves that evaluations of the corresponding witness polynomials lie in a public table and that these values are consistent with the arithmetic constraints for the operation. For example, ReLU
can be enforced using auxiliary boolean/range witnesses that certify the sign/range of the input and a simple arithmetic relation tying the output to the input. Notation. We use f (·), h(·) for polynomials, x, y, z to denote vectors of variables, and g, r, u, v for vectors of values. Subscript notation (xi ) denotes the i-th element of the vector. We use the standard notation for bitstrings {0, 1}∗ , and fields Fp with order p. For a d-variate polynomial f (x1 , · · · , xd ), degi (f ) is the degree of f in xi . A polynomial is multilinear if degi (f ) ≤ 1 for all i ∈ [d]. All adversaries are Probabilistic Polynomial-Time (PPT), unless stated otherwise.
At the beginning of the GKR protocol, P sends the claimed output value Ṽ0 to V . V then selects a random field element g (0) ∈ Fp , evaluates Ṽ0 (g (0) ), and sends g (0) to the prover. Then, P and V reduce the claim about Ṽ0 to a claim about Ṽ1 using Eq. (1). This process continues layer by layer until V obtains a claim about the input layer (Ṽd ). Each reduction step is performed using the interactive sumcheck protocol recursively on Eq. (1) [25]. The final claim on the input layer is verified by giving V oracle access to Ṽd . V can query an oracle, a black-box function (see §2.3.1) that knows the polynomial Ṽd . If the value from the oracle query matches the final claim, V is convinced that the computation was performed correctly.
2.2. GKR Protocol 2.3. Interactive Sumcheck Protocol The GKR protocol [25], [26] is used by P to show that the evaluation of an inference computation represented by a layered arithmetic circuit (C ) is correct. Modern zkML systems [1], [2], [19] use GKR to prove ML computations. Using existing convention [1], [12], Si is the number of gates at layer i and si = log2 Si . Each gate at layer i is uniquely identified by a Boolean string in the hypercube {0, 1}si . Ṽi encodes all the outputs of layer i, e.g., for a gate at index z , Ṽi (z) is the output of the corresponding gate in layer i. We use wiring predicates for the connections between the outputs of a layer i + 1 and the gates in layer i: Boolean selector functions evaluating to 1 only if there is a wire from layer i + 1 (or d) to the corresponding gate. The wiring predicate between addition gates in layer i and g i,i+1 , i.e., add g i,i+1 (z, b) = 1 values from layer i + 1 is add only if the gate at index z operates on the value at index b g i,d ,mult ] i,d,d , of layer i + 1. The other wiring predicates add ] ] multi,i+1,d , and multi,i+1 are defined analogously. Using these selectors, the value at any index z for layer i (Ṽi (z)) can be expressed as a single polynomial [1]: Ṽi (z) =
X
g i,i+1 (z, b) · Ṽi+1 (b) add
si+1
b∈{0,1}
+
X
g i,d (z, b) · Ṽi,d (b) add
b∈{0,1}sd
+
X
] i,i+1 (z, b, c) · Ṽi+1 (b) · Ṽi+1 (c) mult si+1
b,c∈{0,1}
+
X
] i,d,d (z, b, c) · (Ṽi,d (b) · Ṽi,d (c)) mult
b,c∈{0,1}sd
+
X
] i,i+1,d (z, b, c) · Ṽi+1 (b) · Ṽi,d (c), (1) mult
s
b∈{0,1} i+1 c∈{0,1}sd
where Ṽi,d is the subset of values in the input layer d that are used for computations of layer i. When evaluated on Boolean inputs, exactly one of the add or mult terms equals 1 for each gate z . This property guarantees that the sum precisely recovers the arithmetic value computed by every gate in layer i. Equivalently, verifying the correctness of layer i reduces to checking that Eq. (1) holds. GKR reduces the problem of verifying an entire layer-i computation to checking the validity of Eq. (1) at a single random point z chosen by V [25].
The sumcheck protocol [27] allows P to show that the sum of the evaluations of a polynomial h (with m variables) over binary inputs is H . Formally, it proves [27] X ? H= h(b). (2) b∈{0,1}m
It is a public-coin protocol where the random values sampled by V in each round are sent to P [27]. It proceeds in m rounds where in each round P proves that the claim made in the previous round is true using the random challenge values. In the first round, P sends a univariate polynomial [27] X q1 (z) = h(z, b2 , . . . , bm ). b2 ,...,bm ∈{0,1}
At the end of the round, V checks that H = q1 (0) + q1 (1) and sends a random value r1 ∈ F to P . The claim for the next round is set to q1 (r1 ) and the same steps are repeated for m rounds. Finally, V has a claim qm (rm ). This claim is verified by performing an oracle query for the evaluation of h at the point (r1 , . . . , rm ). V checks that this evaluation equals the claim (qm (rm )). If the equality holds, V is convinced of the original claim (Eq. (2)). When used in the GKR protocol, at the end of the sumcheck protocol on Ṽ0 , V queries P for the values of Ṽ1 at two random points u and v [25]. V evaluates the wiring predicates and computes Ṽ0 according to Eq. (1). It then verifies that this computed value matches the final claim in the sumcheck protocol. This verification step reduces the original claim for Ṽ0 to two separate claims for Ṽ1 , which are combined into a single claim via random linear combination [28]. The procedure repeats iteratively, eventually yielding a claim for Ṽd . 2.3.1. Polynomial Commitment Scheme. A Polynomial Commitment Scheme (PCS) [29], [30] emulates the oracle access in GKR using 4 algorithms (Setup, Commit, Open, and Verify). It allows P to commit (using Commit) to a polynomial f , and later can only produce evaluations of f using that commitment (using Open), i.e., it cannot change the polynomial after commitment. V learns nothing about
the polynomial (e.g., coefficients of the monomials) apart from the evaluation itself. Thus, by integrating a PCS as the oracle, P can convince V that the computation was correct. We formally define the algorithms in the PCS in §A.3. A PCS must satisfy (1) completeness: honestly generated proofs verify; (2) binding: a commitment com uniquely determines a degree-bounded polynomial f , such that every accepting opening (α, v, π) satisfies v = f (α); and (3) hiding: the commitment com does not reveal f beyond what is implied by opened evaluations. 2.3.2. Zero-Knowledge GKR. The standard GKR protocol provides soundness for the claimed computation, but it is not zero-knowledge [12]. If it is executed naively, V can learn information about the model weights θ. There are two sources of information leak when executing the GKR protocol using sumcheck style arguments for each layer. First, it is from the univariate polynomials sent during each round of the sumcheck protocol. V can learn the evaluation of each of those polynomials at a random point. These values represent linear combinations of the layer values Ṽi , which allows V to partially reconstruct some entries of the layer. This is addressed by adding a random polynomial to Eq. (1) (see §A.1). Second, at the end of the sumcheck for each layer, V learns the evaluation of Ṽi at two points. Each point corresponds to a layer output. Thus, the polynomials for each layer are replaced with their low degree extensions (LDE) as follows [12]: X V̇i (z) =Ṽi (z) + Zi (z) Ri (z1 , w), (3) where Zi (z) =
si Y
w∈{0,1}
zi (1 − zi ) and
i=1
Ri (z1 , w) =a0 + a1 z1 + a2 w + a3 z1 w + a4 z12 + a5 w2 + a6 z12 w2 .
(4)
Ri (z1 , w) has a degree 2 for a0 , . . . , a6 chosen randomly by P . Since Zi (z) = 0 for all z ∈ {0, 1}si , V̇i agrees with Ṽi over the boolean hypercube and can be substituted in Eq. 1. Each evaluation for Ṽi is now masked by an evaluation of Ri . Thus, V learns nothing about the individual values of layer polynomials from the evaluations.
2.4. GKR-based Zk-SNARKs Formally zkML proving can be represented via an indexed relation R, where the index I fixes the computation to be verified (e.g., the layered circuit for a model), instance x and witness w are the public and private values, respectively. Indexed Relation [31]: An indexed relation R is a set of triples (I, x, w) where I , x, w are the index, instance, and witness, respectively, defined as: n o R = (I, x = {q, r}, w = {adv, θ}) CI (x, w) = 1 . The indexed language (L(R)) consists of all pairs ((I, x)) for which there exists a witness (w) that satisfies the relation.
Non-Interactive protocol
Interactive Public coin protocol Commit
Layer 0 Sumcheck
m0 g0 m1 ....
Commit $
m0 g0 m1
Layer 0 Sumcheck
$
Hash
....
$ FiatShamir
Open
Hash Hash
Open Hash
Layer 1 Sumcheck
.... ....
$
Layer 1 Sumcheck
....
$ ....
Hash
Figure 3: Transforming an interactive public coin protocol into a non-interactive protocol using Fiat-Shamir heuristic. A zk-SNARK for relation R consists of three algorithms (Setup, Prove, Verify) [32]. They allow P to show that (I, x) ∈ L(R) by proving knowledge of a witness w, without revealing w to V . A zk-SNARK satisfies three security properties (formal definitions in §A.2): 1) Completeness: honestly generated proofs are always accepted by V ; 2) Soundness: false proofs cannot be accepted except with negligible probability; 3) Zero-knowledge: V learns nothing beyond validity of the statement (no information about w). In zkML systems [1], [2], [19], zk-SNARKs are typically constructed using a zero-knowledge GKR protocol within a commit-and-prove framework [33], yielding a CP-SNARKs (commit-and-prove SNARKs). P first commits (using a PCS) to the witness polynomials and then runs the zeroknowledge GKR protocol, replacing each interactive message with the corresponding committed polynomial evaluations or openings.
2.5. Fiat-Shamir For Non-interactive Protocols Fig. 3 (left) shows the interactive protocol used in zkML systems [1], [2], [19]. First, P commits to the input and masking polynomials. The commitment is sent as part of m0 to V before starting the GKR protocol. During the protocol, V samples random values (g 0 , r10 , . . . ) and sends them to P at specific points, e.g., g 0 is sent only after P transmits m0 . In typical zkML deployments, such interaction is impractical. zkML systems address this via the FiatShamir heuristic [34], converting the interactive protocol to a non-interactive one (Fig. 3, right). It replaces V ’s random sampling with a pseudo-random function, typically a hash such as SHA-3 [35]. P can thus compute the challenges (g 0 , r10 , . . . ) locally by hashing the protocol transcript up to that point, e.g., g 0 is obtained by hashing m0 . This yields a non-interactive zero-knowledge argument in the random oracle model [34] and is standard in zkML systems [1], [2], [19]. Importantly, Fiat-Shamir remains sound only when every prior prover message is included when computing the hash for each challenge [34], [36], e.g., r10 must be computed by hashing g 0 , m0 , and m1 . Thus, layer i’s proof cannot begin until all preceding layers’ proofs are computed.
3. zkComposer: Key Ideas Inference
Inputs
Proof
Outputs
Figure 4: Arithmetic circuit for zkComposer with n partitions. We accelerate zkML proof generation by exploiting the parallelism across independent sub-proofs. We divide the neural network into multiple partitions and generate a subproof for each. We describe our approach for partitioning along model layers; other schemes appear in §4.1. Each partition (indexed from output to input) consists of a subset of contiguous layers. Fig. 4 shows the arithmetic circuit of a zkML application with zkComposer, where the model is split into n partitions, Pn , · · · , P1 . Each sub-proof shows that its partition correctly transforms its input activations into output activations using its layer operations (e.g., matrix multiplication, convolution). To match the correctness guarantee of a monolithic proof, we additionally verify that the input activations of partition Pj−1 are equal to the output activations of Pj . Our setting is an instance of SNARK composition, where sub-relations are linked by enforcing a relationship between shared boundary witnesses (as in LegoSNARKs [33]). Linking sub-proofs in zkML poses two challenges. (1) Proving equality via polynomial commitments. With a separate subproof per partition, the boundary activations are private witnesses, so each sub-proof commits to its own (masked) polynomials. Partition Pj−1 ’s input activations are committed together with its model parameters as a single polynomial. Thus, composing sub-proofs requires showing that the activations in this committed input polynomial are identical to Pj ’s committed (masked) output polynomial, using only the commitments. (2) Preserving zero-knowledge at boundaries. Since intermediate activations are private witnesses, zkComposer must enforce equality of the boundary values across consecutive sub-proofs while revealing no additional information beyond what the public values imply. zkComposer addresses both challenges by linking partitions through shared (masked) commitments to output activations of the boundary layer in each partition. P creates a single PCS commitment to a partition’s output activations and reuses it in every sub-proof that consumes them as inputs. The input-layer polynomial of partition i is constructed such that its input activations are derived from (and checked against) this shared masked polynomial (see §3.1). Due to the binding property of the PCS, any correctly opened values must correspond to the same underlying boundary polynomial, thereby establishing equality of the polynomials. For zero knowledge, zkComposer masks each boundary polynomial with a fresh random polynomial (see §3.2). The number of variables in the masking polynomial
is chosen such that it masks the total number of evaluations of the corresponding polynomial across all sub-proofs. Prior proof-composition techniques [33], [37] use a separate zk-SNARK to relate two committed polynomials. LegoSNARKs [33] formalizes modular composition via CPSNARKs, providing linking gadgets that prove equality between two polynomial commitments. These gadgets assume both sub-proofs commit to the same polynomial encoding of the boundary values. In zkML systems [1], [2], [19], however, the polynomials are committed as low-degree extensions (LDEs) masked by independent random polynomials per sub-proof. Thus, the committed polynomials differ even when the underlying witness is identical, making direct use of LegoSNARK’s gadget non-trivial. Lunar [37] offers a comparable mechanism but targets univariate polynomials, whereas zkML systems [1], [2], [16], [19] typically operate over multivariate polynomials, requiring a redesign to support multivariate equality checks. Formal description of zkComposer: Recall from §2 that existing zkML systems [1], [2], [19] prove the relation: n o Rzkml = (I, x = {q, r}, w = {adv, θ}) CI (x, w) = 1 , where the index I is the circuit, the public values x consist of the query q and response r. Here, the witness w includes the model parameters θ and advice values adv. zkComposer generates proofs for partitions P1 , . . . , Pn , defined by n − 1 intermediate boundary layers b1 < · · · < bn−1 , each bj ∈ {1, . . . , d − 1}. Setting bn = d (input layer) and b0 = 0 (output layer), partition Pj consists of layers {bj−1 , . . . , bj − 1} for j ∈ {1, . . . , n} (so Pn includes the input layer and P1 the output layer). The output of layer bj−1 , denoted actbj−1 , is the output of Pj and the input to Pj−1 . For ease of exposition, we use a common indexing for the ML model and its layered arithmetic circuit, and assume each circuit layer is verified via sumcheck applied to Equation (1). In practice, some layers are instead verified via lookup protocols [1], [19] (e.g., Lasso [13]), which are themselves sumcheck-based; §4 describes zkComposer’s integration with such frameworks. The query q is a public input in Pn and the response r is the public output of P1 . The model parameters are split into θ1 , . . . , θn , each a private input to the proof of the corresponding partition, and the boundary activations are private witnesses in the two adjacent proofs. Formally, the indexed relations for the n sub-proofs are: n R1 = (I1 , x1 = {r}, w1 = {wb1 , adv1 , θ1 }) o CI1 (x1 , w1 ) = 1 , n Rj = (Ij , xj = {}, wj = {actbj−1 , wbj , advj , θj }) o CIj (xj , wj ) = 1 , for j ∈ {2, . . . , n − 1}, n Rn = (In , xn = {q}, wn = {actbn−1 , advn , θn }) o CIn (xn , wn ) = 1 .
If a prover produces accepting proofs for R1 , . . . , Rn and additionally shows wbj = actbj for all boundary layers j ∈ {1, . . . , n − 1}, this is equivalent to a proof for Rzkml [33].
3.1. Proving Equality Using Polynomial Commitments: Boundary Layer Construction To verify equality between adjacent partitions Pj and Pj+1 , we must show that the output polynomial of Pj+1 equals a portion of the input polynomial of Pj . It equals only a portion because, in GKR-based zkML, the input polynomial incorporates both activation/query values and model weights. We achieve this by constructing an input polynomial for Pj that distinctly separates these components. Let Ṽbj be the boundary polynomial for the output actbj of partition Pj+1 (where 1 ≤ j < n). For Pj , the input layer polynomial Ṽinp,j combines Pj+1 ’s output polynomial Ṽbj with the model-weight polynomial Ṽθj for Pj . We combine them using chunking [2], [38] via a selector variable in Ṽinp,j . Let kj = log2 2 · max(|actbj |, |θj |) , where (r1 , . . . , rkj −1 ) index positions in either Ṽbj or Ṽθj . The input polynomial for Pj is Ṽinp,j (r1 , . . . , rkj ) =(1 − rkj ) Ṽbj (r1 , . . . , rkj −1 ) + rkj Ṽθj (r1 , . . . , rkj −1 ),
(5)
where rkj selects which polynomial is evaluated. For each boundary layer bj , P commits once to Ṽbj in the proof for Pj+1 (where bj is the output layer) and reuses it in the proof for Pj (where bj is the input layer). P commits to Ṽθj separately in Pj ’s proof. In Pj+1 ’s proof, V queries Ṽbj directly. At the end of Pj ’s proof, when performing oracle access to Ṽinp,j , V queries Ṽbj and Ṽθj separately and computes Ṽinp,j via Eq. 5. By the binding property of the PCS, P cannot use PCS.Open on the commitment of Ṽbj to prove evaluations of two different polynomials. Consequently, the values wbj in Pj ’s proof match the activations actbj from Pj+1 ’s proof. This enforces boundary-activation equality without any additional linking proofs, while remaining fully compatible with existing zkML systems [1], [2], [19]. Shared model weights between partitions. Two partitions Pk and Pj (j < k ) may share weights when different layers reuse the same parameters. The shared values are included as input weight θ in the sub-proof for the partition that uses them first during inference, i.e., Pk . They are then encoded, together with Pk ’s output, into Pk ’s boundary polynomial. Using this boundary polynomial as input to Pj ensures both sub-proofs operate on the same weight values.
3.2. Zero-Knowledge At Partition Boundaries Using LDEs of multilinear polynomials as in Eq. (3) suffices to ensure the zero-knowledge properties of all polynomials in a sub-proof for partition Pj+1 except the output
polynomial Ṽbj . In zkComposer, V obtains oracle access to Ṽbj in at least two proofs: in Pj+1 ’s proof, to query the output of layer bj , and in Pj ’s proof, to verify the input-layer construction (Eq. 5). Thus, without proper masking, these evaluations of the boundary polynomials reveal information about the underlying activations. The number of evaluations of each boundary polynomial depends only on the model architecture and the chosen partition boundaries. P can therefore compute it in advance. For the partitioning in Fig. 4, every boundary polynomial is evaluated exactly twice for each boundary bj : once in Pj and once in Pj+1 . This count can grow with certain operations, such as skip connections. Suppose a skip connection runs from layer d − 1 to boundary bn−1 , with the two layers in different, non-contiguous partitions. Then the polynomial for layer d − 1 must be evaluated three times, once in each of the three sub-proofs that depend on it. The third evaluation occurs in the partition containing bn−1 . In general, a boundary polynomial is evaluated as many times as the number of partitions that take it as input. To preserve zero-knowledge, P selects the number of random variables in Rbj to mask all evaluations of the boundary polynomial across all sub-proofs. P then replaces each Ṽbj with its LDE. For example, when Ṽbj is evaluated twice, Rbj includes monomials over two variables (Eq. (4)). We discuss how to adapt Rb for other cases in §B.1. Thus, Eq. 5 becomes: V̇inp,j (r1 , . . . , rkj ) =(1 − rkj ) V̇bj (r1 , . . . , rkj −1 )+ rkj V̇θj (r1 , . . . , rkj −1 ),
(6)
where V̇bj and V̇θj are the LDEs of Ṽbj and Ṽθj . The LDEs agree with the original polynomials on all Boolean inputs, while masking the true values at all verifier-chosen evaluation points. This is sufficient to ensure zero-knowledge as shown in §5.
4. zkComposer: Putting It All Together Consider a model decomposed into two partitions at layer b: A (layers {0, · · · , b−1}) and B (layers {b, · · · , d}). The protocol proceeds in three phases. Boundary commitment. P executes the forward computation up to layer b to obtain the intermediate activations actb . P then constructs the LDE V̇b of the multilinear extension encoding actb and commits to it using a polynomial commitment scheme. This commitment fixes the boundary values used consistently across both sub-proofs. Proof for part A. P executes the remaining forward computation to obtain the intermediate activations and the response r. Using the committed boundary polynomial V̇b , P constructs the input polynomial for part A as in §3.1, replacing all multilinear extensions with their LDEs (§3.2). P then executes the zero-knowledge GKR protocol for layers {0, . . . , b − 1}. At the end, the commitment of V̇b is opened to prove the claim for the activations in the input of part A. This yields a zero-knowledge proof for RA , i.e.,
part A correctly computes the public response r from the committed boundary activations and private weights θA . Proof for part B . P executes the zero-knowledge GKR protocol for layers {b, . . . , d}, using the committed polynomial V̇b as the output polynomial of layer b. At the start, V selects a random evaluation point. P evaluates V̇b and opens the commitment to V̇b at that point. This evaluation is used as the claimed evaluation of layer b for the protocol. V accepts if and only if both sub-proofs verify and all commitment openings are valid. Since zkComposer modifies only the proof’s structure and not the underlying GKR or commitment mechanisms, it applies directly to existing zkML frameworks without any modification to the commitment scheme. Protocol 1 gives a formal description. The zkComposer construction extends recursively to partition a model into more than two parts. Each additional partition introduces a new boundary commitment shared by adjacent sub-proofs. This decomposition reduces the size of each sub-circuit, lowering the memory required per subproof. When sub-proofs are generated sequentially, only one partition’s witness values and prover instance must be stored at a time, reducing peak prover memory. When generated in parallel, zkComposer instead reduces end-to-end proof generation time, subject to available hardware resources. Using zkComposer with lookup-based layers. Modern zkML systems such as zkGPT [2] and zkLLM [19] use lookup arguments (e.g., Lasso [13]) to prove activation functions and normalization layers. These lookup arguments are themselves implemented using sumcheck-based protocols and polynomial commitments. zkComposer applies directly: when a partition boundary is a lookup-based layer, its boundary activations are treated in the same way as standard arithmetic layer outputs. The committed boundary polynomial encodes the activation values, while the lookup constraints are enforced entirely within the sub-proof containing the corresponding layers. zkComposer therefore requires no modification to existing lookup protocols and introduces no assumptions beyond those of existing zkML frameworks [2], [19]. zkComposer is a general construction: although primarily designed for zkML systems that use GKR, it can be used to prove arbitrary computations (§B.2) and with zkML systems that use table-based arithmetic circuits (§B.3). Using Fiat–Shamir For Non-interactive Proofs. To obtain a non-interactive protocol, we apply the Fiat–Shamir transformation (Section 2.5) to each sub-protocol in the random-oracle model. Recent work [39] shows that Fiat– Shamir security depends on the circuit implementation. In particular, the circuit depth must be less than the sum of the computational depths required to compute the hash function and the PCS. The per-partition GKR sub-protocols in zkComposer remain unchanged from the configurations analyzed in the underlying CP-SNARK constructions [1], [2], [12], which also use Fiat–Shamir compilation in the random-oracle model. We therefore assume the underlying CP-SNARKs satisfy this depth condition, i.e., they are secure in the random-oracle model.
In zkComposer, partitions are linked only through shared PCS commitments and their openings, i.e., the Fiat–Shamir transcripts for each partition are independent. Thus, the depth condition applies independently to each sub-protocol and is unaffected by the number of partitions n. If an underlying circuit does not satisfy this condition, the partitioning scheme must ensure that each partition’s depth remains below the maximum allowed for the corresponding hash function and commitment scheme used.
4.1. Partitioning The Model The choice of partition boundaries is determined by the available hardware resources (e.g., number of threads and memory) and by the structure of the proof circuit for each operation. The cost of each partition depends on the operations it contains, the associated kernel sizes, the model and input dimensions. We describe the three partitioning strategies we evaluate in §6. Partitioning along layer boundaries in GPT-2 [24]. We use the same arithmetization scheme as zkGPT [2] and place partition boundaries between the transformer decode blocks. Thus, using this strategy, we can obtain a maximum of 12 partitions (as there are 12 transformer blocks in GPT-2). We apply the circuit optimizations proposed by zkGPT [2] within each partition. Partitioning along input tokens in GPT-2 [24]. For LLMs, zkComposer can also partition along the input tokens. The key–value (KV) activations computed for a token are used to compute the attention scores of every subsequent token. We therefore commit to the intermediate KV values produced within each token partition, and subsequent partitions consume these commitments as advice in their input layer. The shared-commitment mechanism is used between partitions (§3) to ensure consistency between the advice KV values and the values produced by earlier partitions. Thus, combining the partitions along the input tokens and the layer boundaries allows additional proof computations to be run in parallel, thereby decreasing prover time. Partitioning along layer boundaries in CNNs. We use the same arithmetization as zkCNN [1] and place partition boundaries immediately after each convolution block. Here, a convolution block consists of a sequence of convolution layers followed by a max-pooling layer. Thus, we obtain a maximum of 5 partitions for the models we evaluation. The choice of partition boundaries and count K controls a memory-compute trade-off for the prover. Increasing K reduces per-partition memory and can reduce prover time when sub-proofs run in parallel, but it also introduces additional boundary commitments and reduces the number of threads available to each sub-proof. Within a single partition scheme, three failure modes can degrade performance: 1) an uneven split leaves the largest sub-proof on the critical path; 2) fine-grained partitions incur commitment and opening overhead that can offset the performance improvements from zkComposer; and 3) when the partitions are run in parallel the total memory required can be above the monolithic baseline.
Protocol 1(zkComposer). Let C be a layered arithmetic circuit with layers indexed from d (input) to 0 (output), implementing a computation with parameters θ. Let q be the public query, r the public response, and let b ∈ {1, . . . , d− 1} denote the partition point. The prover P and verifier V execute the following protocol. Setup. Public parameters pp for the PCS and the zero-knowledge GKR protocol are generated as in §2. Boundary Commitment. 1) Upon receiving q , P evaluates the circuit up P to layer b and computes the MLE Ṽb encoding actb . 2) P constructs the LDE V̇b (z) = Ṽb (z) + Z(z) w∈{0,1} Rb (z1 , w), where Z(·) and Rb (·) are defined in §2. 3) P computes comb ← PCS.Commit(pp, V̇b , rVb ) and comRb ← PCS.Commit(pp, Rb , rRb ). 4) P sends (comb , comRb ) to V . Sub-protocol A (Layers 0 to b−1). 1) P computes comθA ← PCS.Commit(pp, V̇θA , rV,θA ) and sends comθA to V . 2) P and V execute the zero-knowledge GKR protocol for layers {0, . . . , b−1} using the boundary input polynomial V̇inp,A constructed from V̇b and V̇θA (Eq. 6). $ 3) At the end of the protocol, V samples a random evaluation point g (inp,A) ← − F for the input layer of part A, and obtains the claimed value V̇inp,A g (inp,A) from the final round of the sumcheck protocol. Let 4) P opens the corresponding commitments by sending (V̇b (g (inp,A) ), πact ) ← PCS.Open(pp, V̇b , g (inp,A) , rVb ) and (V̇θA (g (inp,A) ), πθA ) ← PCS.Open(pp, V̇θA , g (inp,A) , rV,θA ). 5) V checks PCS.Verify(pp, comb , g (inp,A) , V̇b (g (inp,A) ), πact ) and PCS.Verify(pp, comθA , g (inp,A) , V̇θA (g (inp,A) ), πθA ), and aborts if either check fails. 6) V locally computes V̇inp,A g (inp,A) from V̇b (g (inp,A) ) and V̇θA (g (inp,A) ) according to Eq. 6, and checks that it matches the value obtained at the end of the sumcheck protocol. Sub-protocol B (Layers b to d). 1) P samples the random masking polynomials required for zero-knowledge in part B . This includes the masking polynomials for the MLEs of layers {d, . . . , b+1}, denoted {Rd , . . . , Rb+1 }, as well as the masking polynomials for the subsets of the input layer used by these layers, denoted {Rd−1,d , . . . , Rb,d }. P computes commitments to all these polynomials and sends the commitments to V . $ − F and sends it to P . 2) V samples a random challenge g (b) ← 3) P opens the boundary commitment by sending (V̇b (g (b) ), πb ) ← PCS.Open(pp, V̇b , g (b) , rVb ). 4) V checks PCS.Verify(pp, comb , g (b) , V̇b (g (b) ), πb ), and aborts if the check fails. 5) P and V execute a zero-knowledge sumcheck protocol to verify the following claim for layer b: X X g b,b+1 (g (b) , x) · V̇b+1 (x) + ] b,d,d (g (b) , x, y) · Ṽb,d (x) · V̇b,d (y) V̇b (g (b) ) = mult add x∈{0,1}sb+1
+
X
x,y∈{0,1}sd
g b,d (g add
(b)
, x) · V̇b,d (x) +
+
] b,b+1 (g (b) , x, y) · V̇b+1 (x) · Ṽb+1 (y) mult
x,y∈{0,1}sb+1
x∈{0,1}sd
X
X
] b,b+1,d (g (b) , x, y) · Ṽb+1 (x) · V̇b,d (y) + Zb (g (b) ) mult
x∈{0,1}sb+1 y∈{0,1}sd
X
(b) Rb g1 , w .
(7)
w∈{0,1}
6) At the conclusion of the zero-knowledge sumcheck, V obtains two claims V̇b+1 (u(b+1) ) and V̇b+1 (v (b+1) ). P opens the corresponding masking polynomial Rb at g1b , c for a verifier chosen random c, and V checks that the claimed evaluations are consistent with the value from the oracle. 7) P and V continue executing the zero-knowledge GKR protocol for layers {b+1, . . . , d}. Decision. V accepts iff both sub-protocols accept and all commitment verifications succeed.
For GPT-2, the transformer blocks are structurally identical, so any partition count yields equal-cost sub-proofs. For CNNs, where per-layer cost varies, zkComposer resolves the partitioning problem by exhaustively profiling the feasible configurations offline and selecting the one with the lowest prover time. This is a feasible approach since the profiling is only a one-time cost for deploying any given model. The same procedure applies to any new
model: choose partition boundaries aligning with the natural structural units (e.g., transformer, convolution, or residual blocks). The boundaries must be chosen such that constraintmerging optimizations (similar to zkGPT [2]) can be applied within each partition. Offline profiling can be used to choose the best configuration for deployment if the partitions are not balanced. For models with decomposable computation along the inputs (e.g., LLMs), input-dimension partitioning
adds further parallelism.
5. Security Properties Of zkComposer Here, we prove that Protocol 1 satisfies the completeness, knowledge soundness, and zero-knowledge properties of a zk-SNARK for Rzkml (formal definitions in Definition 1). Arguments for multiple partitions obtained by recursive application of zkComposer follow similarly. Intuitively, zkComposer splits the overall computation into sub-proofs and instantiates a standard zk-SNARK for each. We state the completeness and knowledge soundness theorem below, which follows directly from the underlying zk-SNARK construction and the PCS [33]. We then sketch the proof that Protocol 1 is zero-knowledge. We discuss the asymptotic complexity and the expanded proofs in §B.4. Theorem 1 (Knowledge Argument of ΠzkComposer ). Let ΠzkComposer = (Setup, Prove, Verify) be the zkComposer protocol for two partitions as shown in Protocol 1, for the indexed relation Rzkml . Let the two sub-proofs correspond to the indexed relations RA and RB , where RA proves correctness of layers {0, . . . , b − 1} and RB proves correctness of layers {b, . . . , d}. Suppose that: 1) PCS satisfies completeness and binding (Definition 2); 2) the GKR-based CP-SNARKs underlying the sub-proofs for RA and RB satisfy completeness and knowledge soundness (Definition 1). Then ΠzkComposer satisfies completeness and knowledge soundness for Rzkml . Equivalently, ΠzkComposer is a knowledge argument for Rzkml . Theorem 2 (Zero-Knowledge of zkComposer). Let zkComposer be the two-partition protocol in Protocol 1, with a single boundary layer b, and let Rzkml be the original indexed relation. Suppose that: 1) the GKR-based CP-SNARK sub-proofs for RA and RB are zero-knowledge (Definition 1), with simulator Ssc ; 2) PCS satisfies hiding (Definition 2), with simulator Spc . Then zkComposer is zero-knowledge for Rzkml . That is, there exists a PPT simulator Smod such that for every (i, x, w) ∈ Rzkml and every PPT distinguisher D, |Pr[D(π) = 1] − Pr[D(π ′ ) = 1]| ≤ negl(λ),
where pp ← Setup(1λ , i), π ← Prove(pp, i, x, w),
and π ′ ← Smod (pp, i, x).
Proof sketch. We construct a simulator Smod by combining the simulators for the two underlying components: the simulator Ssc for the GKR-based CP-SNARK transcripts and the simulator Spc for the polynomial commitments. All transcript components internal to the two subprotocols are simulated exactly as in the standard commitand-prove GKR zero-knowledge argument. Thus, by the
zero-knowledge of the sub-proofs and the hiding of the PCS, these parts are indistinguishable from a real execution [12]. In zkComposer, the two sub-protocols share the boundary polynomial V̇b . Thus, the verifier sees two evaluations of this polynomial, at query points u = g (b) and v = g (inp,A) , together with one evaluation of the boundary masking polynomial Rb (u1 , c). The boundary mask is chosen so that these three revealed values are three independent linear combinations of the random masking coefficients, i.e., the corresponding linear map has a full rank. Hence the revealed values are distributed uniformly over F3p and are statistically independent of the boundary polynomial Veb . Smod samples these three boundary-related values uniformly, uses Spc to simulate the relevant commitments and openings, and uses Ssc to simulate the GKR/sumcheck transcripts consistently with the sampled values. By a standard hybrid argument, the simulated transcript has the same distribution on the boundary messages as the real transcript. Therefore, zkComposer satisfies zero-knowledge.
6. Evaluation 6.1. Implementation Software: We evaluate zkComposer by integrating it into two modern zkML frameworks: zkCNN [1] and zkGPT [2]. zkComposer leaves the underlying arithmetization and the PCS unchanged. Accordingly, we use Hyrax [29] as the PCS for both boundary and input polynomials. The commitment kernels are accelerated via Pippenger’s algorithm [40], while the sumcheck kernels leverage multi-threaded parallelism. All field and curve operations use the mcl library [41] over the BLS12-381 [42] and BN254 [43] curves. We optimized the implementation to dynamically allocate the necessary memory for intermediate computations in the prover and release it immediately after use. Metrics. We compare the impact of zkComposer using the following metrics: prover time, peak memory, verifier time, and response time. The prover time includes the duration to commit to all witness values, e.g., model weights and activations, to generate the proof by executing the GKR protocol, and opening the respective commitments. Peak memory denotes the total memory required to store witness values and intermediate values during proof generation, e.g., tables used to compute sumcheck protocol messages via dynamic programming. The verifier time is the duration for the verifier to execute the verification algorithm. The response time is calculated as the prover time plus the transmission time for the proof over a 100 MBps network. We also report speedups by normalizing the prover/verifier/response time of zkComposer with the respective baselines. Hardware: All experiments were conducted on a system equipped with dual-socket AMD EPYC™ 9654 processors, featuring 192 cores, and 756 GB of main memory in total. In our experiments, the K sub-proofs are executed in parallel using a total of 192 threads (one thread per core), i.e., each
Model
Scheme
Proof Memory (GB) Prover Time† (s) Verifier Time (s) Size (KB) (Baseline/zkComposer) (Speedup)
AlexNet
zkCNN zkComposer (K=2) zkComposer (K=3) zkComposer (K=4) zkComposer (K=5)
24.631 (1.00×) 18.226 (1.35×) 13.534 (1.82×) 12.885 (1.91×) 9.837 (2.50×)
0.0010 0.0011 0.0008 0.0008 0.0012
273.0 376.8 575.4 726.8 734.1
4.14 (1.00×) 8.99 (0.46×) 8.58 (0.48×) 10.02 (0.41×) 11.32 (0.37×)
zkCNN zkComposer (K=2) AlexNet-Wide zkComposer (K=3) zkComposer (K=4) zkComposer (K=5)
83.852 (1.00×) 72.251 (1.16×) 53.718 (1.56×) 45.697 (1.83×) 37.416 (2.24×)
0.0015 0.0012 0.0007 0.0005 0.0007
470.0 670.3 869.9 1069.3 1268.8
16.37 (1.00×) 27.91 (0.59×) 33.75 (0.49×) 34.97 (0.47×) 39.22 (0.42×)
zkCNN zkComposer (K=2) zkComposer (K=3) zkComposer (K=4) zkComposer (K=5)
66.966 (1.00×) 42.091 (1.59×) 30.081 (2.23×) 24.289 (2.76×) 20.604 (3.25×)
0.0023 0.0024 0.0018 0.0012 0.0008
345.3 736.7 935.6 943.0 1045.9
9.59 (1.00×) 17.30 (0.55×) 19.52 (0.49×) 16.67 (0.58×) 17.08 (0.56×)
VGG16
TABLE 1: Performance of zkComposer on CNN workloads. † Response time ≈ Prover time in all cases. sub-proof uses ⌊192/K⌋ threads. Thus, zkComposer and the baseline use identical hardware resources. Although our experiments were conducted using CPUs, zkComposer can be implemented directly in GPU-based frameworks.
6.2. Performance of zkComposer on CNNs Table 1 presents the performance of zkComposer for three CNNs in comparison to the baseline (zkCNN [1]). We evaluate AlexNet [44], AlexNet-Wide [44] (with 4× the channels), and VGG16 [45]. We highlight four observations. First, zkComposer reduces prover time for all three CNN workloads. For example, in AlexNet, prover time decreases from 24.63s to 9.84s with K=5, giving a 2.50× speedup. Similarly, zkComposer achieves a 2.24× and 3.25× speedup for AlexNet-Wide and VGG16, respectively. Thus, each subproof is executed in parallel, allowing the proofs for two layers to be computed simultaneously. This reduces the total prover time required to compute the proofs, despite the additional computation required to commit to the boundary polynomials in zkComposer. This additional computation required by zkComposer is ∼ 1% of the total prover time. Second, the response-time speedup closely matches the prover-time speedup despite an increase in proof size. For example, zkComposer achieves 2.5× speedup for both prover time and response time in AlexNet, when using 5 partitions, while the proof size increases from 273KB to 734.1KB. This is because proof transmission time at 100 MBps is negligible in comparison to the prover time: even the largest proof in the table is only 1268.8KB and adds about 12ms to response time, while the prover times are several seconds. Thus, the end-to-end response time is dominated by proof generation. Third, peak memory increases for zkComposer in all three workloads. For example, for AlexNet peak memory grows from 4.14GB in the baseline to 11.32GB in zkComposer with 5 partitions. This is because, for zkComposer, we instantiate the precomputed data for commitment openings for each sub-proof. Since the sizes of CNN workloads are small, the fixed memory cost of replicating the precomputed data dominates the memory utilization. However, this increase in memory is not significant, i.e., the peak memory for all configurations in CNNs is less than 40 GB.
Scheme zkGPT zkComposer (K = 2) zkComposer (K = 3) zkComposer (K = 4) zkComposer (K = 6) zkComposer (K = 12)
† Verifier Time (s) Memory (GB) Proof (KB) Prover Time (s) (Speedup) (Baseline/zkComposer) (Speedup)
109.2 141.7 149.4 173.9 200.6 268.6
147.7 (1.00×) 96.4 (1.53×) 73.1 (2.02×) 63.0 (2.34×) 45.5 (3.25×) 30.6 (4.83×)
0.328 (1.00×) 0.295 (1.11×) 0.287 (1.15×) 0.366 (0.90×) 0.343 (0.96×) 0.273 (1.20×)
240.5 (1.00×) 257.8 (0.93×) 208.3 (1.15×) 266.4 (0.90×) 208.4 (1.15×) 211.1 (1.14×)
TABLE 2: Performance of zkComposer on GPT-2 [24] relative to zkGPT (K = 1) for a sequence length of 64. † Response time ≈ Prover time in all cases. Fourth, we observe a reduction in verifier times for zkComposer when normalised to the respective baselines (up to 1.28×, 2.89×, and 2.72× for AlexNet, AlexNetWide, and VGG16, respectively). However, the absolute differences are only on the order of milliseconds: verifier time is below 3ms for all baseline and partitioned executions. This variation is negligible compared to prover time, which ranges from tens of seconds to over a minute for the larger CNNs. We conclude that the sub-proof parallelism exposed by zkComposer reduces proof-generation latency for CNNs, with the speedup increasing as the number of partitions increases.
6.3. Performance of zkComposer on GPT-2 Table 2 presents the performance of zkComposer when partitioning along layer boundaries on GPT-2 [24] in comparison to the baseline (zkGPT [2]). Here, we use a sequence length of 64. We highlight three key observations. First, zkComposer achieves a prover-time speedup of up to 4.83× with 12 partitions, with speedup increasing as the number of partitions grows. For example, with 2 partitions, zkComposer achieves a 1.53× speedup. This improvement is because independent sub-proofs are executed in parallel, allowing proofs for multiple transformer blocks to be computed simultaneously. As a result, zkComposer reduces total prover time despite the additional cost of committing to boundary polynomials. This additional computation required by zkComposer is ∼1–3% of the total prover time. Second, verifier time and peak memory are roughly constant irrespective of the number of partitions. Verifier time remains ∼ 0.3s, although each sub-proof only proves a subset of the computations. However, each sub-proof also includes additional commitment openings for the boundary polynomials. Since the commitment openings dominate the verifier execution time, we do not see a reduction in verifier times. Peak memory ranges from 0.90× for 2 partitions to 1.2× for 12 partitions, which is comparable to the baseline. This is because zkComposer does not modify the total number of operations required to compute the proof significantly. Thus, the intermediate values required to store the witness values and compute the proofs for all partitions are similar in number to the baseline. Third, the proof size increases with the number of partitions, from 109.2KB in the baseline to 268.6KB for 12 partitions (a 2.5× increase). This is due to the additional
boundary commitments and their openings. This increase, however, does not affect response time: transmitting the largest proof takes under 3ms on a 100 MBps network, so the response time speedup matches the prover-time speedup of 4.83×. We conclude that the sub-proof parallelism exposed by zkComposer reduces proof-generation latency on GPT-2 workloads, despite the increase in proof size. Total threads (T )
Baseline (K=1) Prover (s)
zkComposer (K=12) Prover (s)
16 32 64 128 192
160.5 146.9 141.1 142.9 147.7
55.9 41.7 33.4 30.6 30.6
Speedup 2.87× 3.52× 4.22× 4.66× 4.83×
TABLE 3: Performance of zkComposer on GPT-2 with 12 partitions for various thread counts. 6.3.1. Scalability of zkComposer with increasing number of cores. Table 3 presents the performance of zkComposer when partitioning along the model layers to obtain 12 partitions on GPT-2 [24] for a sequence length of 64 for different threads T . Here, the baseline computes its single proof using all T threads, while the 12 sub-proofs of zkComposer are executed in parallel using a total of T threads, i.e., each sub-proof uses ⌊T /12⌋ threads. We observe that both the baseline and zkComposer benefit from increasing the total number of threads. The prover time for the baseline reduces from 160.5s to 147.7s, while for zkComposer it reduces from 55.9s to 30.6s, when using 16 and 192 threads, respectively. However, the speedup due to zkComposer also increases from 2.87× when using 16 threads to 4.83× when using 192 threads. This is because the baseline exploits parallelism only within the cryptographic kernels for a single proof. In contrast, zkComposer exposes an additional dimension of parallelism, across neural network layers in different partitions. Consequently, as the total number of threads increases, more threads can be assigned to each subproof, thereby reducing the prover time of each partition. Thus zkComposer yields progressively larger performance gains relative to the baseline with an increase in number of threads. 6.3.2. Performance of zkComposer with sequence partitioning. Table 4 evaluates zkComposer when we partition GPT-2 along both the model-layer dimension and the sequence dimension. We highlight three key observations. First, sequence partitioning provides an additional source of parallelism, thereby improving performance. For example, for sequence length 128, increasing from 12 layer-only partitions to 24 layer-and-sequence partitions reduces prover time from 57.0s to 55.3s, improving speedup from 3.94× to 4.06×. For sequence length 256, using 48 total partitions provides a speedup of 6.84×. This is because sequence partitioning exposes parallelism within each transformer block in
Seq. len.
Partitioning Kℓ × Ks (K )
Proof (KB)
Prover Time (s) (Speedup)
Verifier Time (s) (Speedup)
64
12 × 1 (12) 12 × 2 (24)
268.6 956.9
30.6 (4.83×) 43.3 (3.41×)
0.273 (1.20×) 1.268 (0.26×)
128
12 × 1 (12) 12 × 2 (24) 12 × 4 (48)
325.6 1009.7 1937.2
57.0 (3.94×) 55.3 (4.06×) 63.6 (3.53×)
0.287 (1.19×) 1.295 (0.26×) 1.423 (0.24×)
256
12 × 1 (12) 12 × 4 (48) 12 × 8 (96)
335.8 2059.1 3949.6
100.4 (6.03×) 88.5 (6.84×) 110.9 (5.45×)
0.350 (1.13×) 2.888 (0.14×) 2.432 (0.16×)
TABLE 4: Performance of zkComposer on GPT-2 when partitioning along both model-layer and sequence dimensions. Kℓ denotes the number of layer partitions, and Ks denotes the number of sequence partitions. Seq. len.
Baseline peak memory (GB)
zkComposer Peak memory (GB) (Baseline/zkComposer)
Prover time (s) (Slowdown)
64 128 256
240.5 269.1 532.4
31.9 (7.5×) 52.5 (5.1×) 66.0 (8.1×)
288.5 (1.95×) 479.9 (2.14×) 846.6 (1.40×)
TABLE 5: Peak prover memory and prover time slowdown for zkGPT [2] versus sequential zkComposer with 12 partitions. addition to the parallelism across blocks. As the sequence length grows, each block contains more work, so splitting the sequence lets zkComposer better utilize the available hardware. Second, sequence partitioning has diminishing returns when the partitions become too fine-grained. For example, with sequence length 64, increasing from 12 to 24 total partitions increases prover time from 30.6s to 43.3s. This is because each additional sequence partition introduces more boundary commitments, while also reducing the number of threads available to each sub-proof. Thus, sequence partitioning is most beneficial when the additional parallelism outweighs the cost of computing more sub-proofs and the additional boundary commitments. Third, proof size and verifier time increase with twodimensional partitioning. For example, at sequence length 256, using 12 layer-only partitions vs 48 layer-and-sequence partitions increases proof size from 335.8KB to 2059.1KB, and verifier time from 0.350s to 2.888s. This is because the verifier must check more sub-proofs and more boundary openings across both the layer and sequence dimensions. However, the verifier time remains small relative to prover time. Similarly, the number of additional commitments and openings required for zkComposer increases with increase in number of partitions, increasing the size of the proofs. However, the largest proof in Table 4 is under 4MB, which takes under 40ms to transmit on a 100 MBps network. Thus, the increase in proof size has a negligible impact on the prover time speedups due to zkComposer. We conclude that in zkComposer, sequence partitioning complements layer partitioning by increasing the number of available independent sub-proofs.
6.3.3. Sequential Execution and Memory Footprint. zkComposer supports a sequential execution mode, where sub-proofs are generated one at a time rather than concurrently. Table 5 presents the performance of sequential zkComposer with 12 layer partitions on GPT-2 [24] relative to the baseline (zkGPT [2]). We make two observations. First, sequential zkComposer substantially reduces peak prover memory across all sequence lengths. For example, at sequence length 64, peak memory decreases from 240.5 GB to 31.9 GB with K=12, a 7.5× reduction. zkComposer achieves similar reductions of 5.1× and 8.1× for sequence lengths 128 and 256, respectively. This is because each partition covers only a subset of the computations, and only one partition’s prover, witness, and intermediate values are stored in main memory at a time. Second, this memory reduction comes at the cost of increased prover time. For example, sequential execution is 1.95× slower than the baseline at sequence length 64. This overhead has two causes. (i) zkComposer adds commitments and openings for the boundary polynomial. (ii) The monolithic baseline merges the arithmetic circuits of all partitions into a single circuit. This merged circuit allows circuit-level optimizations across partitions, yielding fewer constraints at the cost of higher memory. Despite this time overhead, the memory reduction enables proof generation on memory-constrained accelerators such as GPUs. Each sub-proof fits within device memory (32–66 GB), while the baseline (240–532 GB) does not. A host with large main memory can support the baseline by paging from device memory to main memory, but such paging is costly. By fitting each sub-proof within device memory, zkComposer can exploit the GPU’s high memory bandwidth. This would substantially reduce per-sub-proof prover time and improve performance.
7. Limitations zkComposer’s parallelism scales with the number of partitions K . In our implementation, K is determined by the model architecture and the input size. Along the layer dimension, K is set by the model’s natural boundary points (e.g., 5 for AlexNet). Models such as LLMs expose an additional dimension along the input sequence. zkComposer therefore provides the greatest benefit for models and inputs that admit many partitions. We leave the design of additional partitioning schemes that further increase K to future work.
8. Related Work Here, we discuss prior work on improving prover performance and on modular proof frameworks. Efficient zkML implementations and Arithmetization. Many prior works [1], [2], [10], [18], [19], [46] improve zkML performance by reducing constraint counts and optimizing arithmetization for common ML operators. zkCNN [1], zkGPT [2], and others [16], [19] introduce specialized arithmetizations for ML operators that reduce proofgeneration cost, e.g., convolution operations in zkCNN.
Compiler and system-oriented frameworks [10], [22], [47], [48] such as ZEN [21] exploit high-level tensor semantics to generate specialized circuits for linear-algebra kernels. Artemis [20] proposes a CP-SNARK construction that lets the prover additionally prove the model weights match an external commitment. These works improve performance for a single proof. Our construction is complementary: it can be combined with them to improve prover performance via parallel sub-proof generation. We demonstrate this by implementing zkComposer on top of zkGPT [2] and zkCNN [1] without modifying their arithmetization or PCS. Each partition’s proof thus retains the original optimizations proposed by these works. Modularity and proof composition. A complementary line of work constructs proofs from smaller proof components. LegoSNARK [33] formalizes a modular approach for designing and composing SNARKs, assembling proofs of larger relations from proofs of simpler sub-relations. Commit-and-prove constructions such as Lunar [37] provide cryptographic mechanisms to enforce relationships (e.g., equality) between a proof’s witnesses and an externally committed witness. In principle, these constructions can combine arguments from independent proof systems. However, Lunar and LegoSNARK cannot be used directly with zkML frameworks (see §3). Further, Lunar requires P to compute a linking proof for equality between witness values in two commitments. In contrast, zkComposer’s shared commitments require no linking proof, improving performance. Prior work [49] introduces a modular framework based on verifiable evaluation (VE) for ML applications. It flexibly combines proof gadgets (protocols) to efficiently prove complex ML computations. Our construction is orthogonal: in the VE framework, proof generation remains sequential, from the outer layer to the inner layer. Integrating it with zkComposer improves prover time per sub-proof, yielding better overall performance. Accelerating prover performance using hardware. Prior work also targets performance by accelerating the dominant cryptographic kernels used by SNARK provers. GPU-based frameworks [50], [51], [52] offload expensive operations (e.g., MSM/NTT) to GPUs, and libraries such as Icicle [53] provide optimized GPU kernels for integration into SNARK stacks. Several works [54], [55], [56], [57] also propose dedicated hardware accelerators for proof generation. These approaches are complementary to zkComposer. zkComposer unlocks an additional dimension of parallelism, i.e., enabling parallel proof generation across partitions. It can be combined with kernel-level GPU optimizations or specialized accelerators to further improve zkML performance. Accelerating GKR and sumcheck protocols. Prior works such as Libra [12], divide-and-conquer sumcheck [27], SVO [58], and Virgo [26] improve GKR and sumcheck protocols by reducing the asymptotic complexity of the proving algorithm. These approaches are orthogonal to ours: they can be applied independently to each sub-proof, yielding better overall performance when combined with zkComposer. Hydra [59] parallelizes GKR-style proofs by decomposing them across GKR layers, with sub-proofs linked
via polynomial commitments. It does not guarantee zero knowledge for the resulting SNARKs, and therefore cannot be used directly for zkML. Modern zkML frameworks such as zkGPT [2] use circuit squashing, which reduces circuit depth. Squashing, however, produces layers of nonuniform width. Partitioning across these circuit layers yields sub-proofs with unequal prover times and limited parallel speedup. zkComposer instead partitions at the model level and applies circuit-level optimizations within each partition, yielding balanced sub-proofs. Some prior works [60], [61], [62], [63], [64] explore techniques for reducing the prover time or memory of the sumcheck protocol in the GKR framework for data-parallel circuits, i.e., multiple identical computations on independent data. These optimizations can improve existing zkML systems modeled as data-parallel circuits. zkComposer is orthogonal to these prior approaches. The same techniques can be applied in zkComposer for each sub-proof.
9. Conclusion We introduce zkComposer, the first modular proof framework for zkML applications. zkComposer partitions the proof computation of an ML model into multiple independent sub-proofs, each proving the correctness of a subset of the inference operations. This design enables parallel computation of sub-proofs, reducing prover time. Each subproof also requires less memory, thus, enabling proof computation on memory-constrained accelerators. zkComposer requires no changes to existing polynomial commitment schemes and delivers significant speedups over state-of-theart zkML implementations.
References [1]
T. Liu, X. Xie, and Y. Zhang, “zkCNN: Zero knowledge proofs for convolutional neural network predictions and accuracy,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’21, 2021, pp. 2968–2985. [Online]. Available: https://eprint.iacr.org/2021/673
[2]
W. Qu, Y. Sun, X. Liu, T. Lu, Y. Guo, K. Chen, and J. Zhang, “zkGPT: An efficient non-interactive zero-knowledge proof framework for LLM inference,” in 34th USENIX Security Symposium (USENIX Security 25), 2025. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity25/presentation/qu-zkgpt
[3]
S. Zhang, L. Yao, A. Sun, and Y. Tay, “Deep learning based recommender system: A survey and new perspectives,” ACM Computing Surveys, vol. 52, no. 1, pp. 1–38, 2019.
[4]
A. Abdallah, M. A. Maarof, and A. Zainal, “Fraud detection system: A survey,” Journal of Network and Computer Applications, vol. 68, pp. 90–113, 2016.
[5]
K. Kuo, “Deeptriangle: A deep learning approach to loss reserving,” Risks, vol. 7, no. 3, p. 97, 2019.
[6]
A. Esteva, A. Robicquet, B. Ramsundar, V. Kuleshov, M. DePristo, K. Chou, C. Cui, G. Corrado, S. Thrun, and J. Dean, “A guide to deep learning in healthcare,” Nature Medicine, vol. 25, no. 1, pp. 24–29, 2019.
[7]
J. Matos, B. Van Calster, L. A. Celi, P. Dhiman, J. W. Gichoya, R. D. Riley, C. Russell, S. Khalid, and G. S. Collins, “Critical appraisal of fairness metrics for artificial intelligencebased clinical prediction models: a scoping review,” The Lancet Digital Health, p. 101001, 2026. [Online]. Available: https: //www.sciencedirect.com/science/article/pii/S2589750026000245
[8]
W. Cai, T. Shi, X. Zhao, and D. Song, “Are you getting what you pay for? auditing model substitution in llm apis,” 2025. [Online]. Available: https://arxiv.org/abs/2504.04715
[9]
B. Cottier, R. Rahman, L. Fattorini, N. Maslej, T. Besiroglu, and D. Owen, “The rising costs of training frontier ai models,” 2025. [Online]. Available: https://arxiv.org/abs/2405.21015
[10] D. Kang, T. Hashimoto, I. Stoica, and Y. Sun, “ZKML: An optimizing system for ML inference in zero-knowledge proofs,” in Proceedings of the Nineteenth European Conference on Computer Systems, ser. EuroSys ’24, Apr. 2024, pp. 622–636. [11] T. Datta, B. Chen, and D. Boneh, “VerITAS: Verifying Image Transformations at Scale,” in 2025 IEEE Symposium on Security and Privacy (SP). Los Alamitos, CA, USA: IEEE Computer Society, May 2025, pp. 4606–4623. [Online]. Available: https: //doi.ieeecomputersociety.org/10.1109/SP61157.2025.00097 [12] T. Xie, J. Zhang, Y. Zhang, C. Papamanthou, and D. Song, “Libra: Succinct zero-knowledge proofs with optimal prover computation,” in Advances in Cryptology – CRYPTO 2019, ser. Lecture Notes in Computer Science, vol. 11694. Springer, 2019, pp. 733–764. [13] S. Setty, J. Thaler, and R. Wahby, “Unlocking the lookup singularity with lasso,” in Advances in Cryptology – EUROCRYPT 2024. Cham: Springer, 2024. [14] S. Goldwasser, S. Micali, and C. Rackoff, “The knowledge complexity of interactive proof systems,” SIAM Journal on Computing, vol. 18, no. 1, pp. 186–208, 1989. [15] S. Lee, H. Ko, J. Kim, and H. Oh, “vCNN: Verifiable convolutional neural network based on zk-SNARKs,” IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 4, pp. 4254–4270, 2024. [16] W. Qu, Y. Guo, Y. Ying, and J. Zhang, “VerfCNN, Optimal Complexity zkSNARK for Convolutional Neural Networks,” 2025, publication info: Published elsewhere. Minor revision. IEEE S&P 2026. [Online]. Available: https://eprint.iacr.org/2025/2020 [17] Z. Ghodsi, T. Gu, and S. Garg, “Safetynets: Verifiable execution of deep neural networks on an untrusted cloud,” in Advances in Neural Information Processing Systems, vol. 30, 2017, pp. 4672–4681. [18] K. Abbaszadeh, C. Pappas, J. Katz, and D. Papadopoulos, “Zero-knowledge proofs of training for deep neural networks,” Cryptology ePrint Archive, Paper 2024/162, 2024. [Online]. Available: https://eprint.iacr.org/2024/162 [19] H. Sun, J. Li, and H. Zhang, “zkllm: Zero knowledge proofs for large language models,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 4405–4419. [Online]. Available: https://doi.org/10.1145/3658644.3670334 [20] H. Lycklama, A. Viand, N. Avramov, N. Küchler, and A. Hithnawi, “Artemis: Efficient commit-and-prove snarks for zkml,” 2025. [Online]. Available: https://arxiv.org/abs/2409.12055 [21] B. Feng, L. Qin, Z. Zhang, Y. Ding, and S. Chu, “Zen: Efficient zero-knowledge proofs for neural networks,” Cryptology ePrint Archive, Paper 2021/087, 2021. [Online]. Available: https: //eprint.iacr.org/2021/087 [22] B. Feng, Z. Wang, Y. Wang, S. Yang, and Y. Ding, “Zeno: A typebased optimization framework for zero-knowledge neural network inference,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’24). ACM, 2024, pp. 450–464. [23] “zkonduit/ezkl,” Jan. 2026, original-date: 2022-07-05T19:54:03Z. [Online]. Available: https://github.com/zkonduit/ezkl
[24] A. Radford, J. Wu, R. Child, D. Luan, D. Amodei, and I. Sutskever, “Language models are unsupervised multitask learners,” OpenAI blog, vol. 1, no. 8, p. 9, 2019.
[40] N. Pippenger, “On the evaluation of powers and related problems,” in 17th Annual Symposium on Foundations of Computer Science (SFCS 1976). IEEE, 1976, pp. 258–263.
[25] S. Goldwasser, Y. T. Kalai, and G. N. Rothblum, “Delegating computation: Interactive proofs for muggles,” Journal of the ACM, vol. 62, no. 4, pp. 27:1–27:64, 2015.
[41] M. Shigeo, “herumi/mcl,” Dec. 2025, original-date: 2015-0505T00:18:39Z. [Online]. Available: https://github.com/herumi/mcl
[26] J. Zhang, T. Liu, W. Wang, Y. Zhang, D. Song, X. Xie, and Y. Zhang, “Doubly efficient interactive proofs for general arithmetic circuits with linear prover time,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 159–177. [Online]. Available: https://doi.org/10.1145/3460120.3484767 [27] C. Lund, L. Fortnow, H. Karloff, and N. Nisan, “Algebraic methods for interactive proof systems,” Journal of the ACM, vol. 39, no. 4, pp. 859–868, October 1992. [28] A. Chiesa, M. A. Forbes, and N. Spooner, “A zero knowledge sumcheck and its applications,” Cryptology ePrint Archive, Paper 2017/305, 2017. [Online]. Available: https://eprint.iacr.org/2017/305 [29] R. S. Wahby, I. Tzialla, abhi shelat, J. Thaler, and M. Walfish, “Doubly-efficient zksnarks without trusted setup,” in 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 926–943. [30] S. T. V. Setty, “Spartan: Efficient and general-purpose zksnarks without trusted setup,” in Advances in Cryptology – CRYPTO 2020, ser. Lecture Notes in Computer Science, vol. 12172. Springer, 2020, pp. 704–737. [31] A. Chiesa, Y. Hu, M. Maller, P. Mishra, N. Vesely, and N. Ward, “Marlin: Preprocessing zksnarks with universal and updatable srs,” in Advances in Cryptology–EUROCRYPT 2020: 39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10–14, 2020, Proceedings, Part I 39. Springer, 2020, pp. 738–768. [32] J. Groth, “On the size of pairing-based non-interactive arguments,” in Advances in Cryptology – EUROCRYPT 2016, ser. Lecture Notes in Computer Science, vol. 9666. Springer, 2016, pp. 305–326. [33] M. Campanelli, D. Fiore, and A. Querol, “Legosnark: Modular design and composition of succinct zero-knowledge proofs,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2019, pp. 2075–2092. [34] A. Fiat and A. Shamir, “How to prove yourself: Practical solutions to identification and signature problems,” in Conference on the Theory and Application of Cryptographic Techniques. Springer, 1986, pp. 186–194. [35] National Institute of Standards and Technology (US), “SHA-3 standard : permutation-based hash and extendable-output functions,” National Institute of Standards and Technology (U.S.), Tech. Rep., 2015. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.202.pdf
[42] S. Bowe, “BLS12-381: New zk-SNARK elliptic curve construction,” Zcash Blog, Mar. 2017. [Online]. Available: https://electriccoin.co/ blog/new-snark-curve/ [43] P. S. L. M. Barreto and M. Naehrig, “Pairing-friendly elliptic curves of prime order,” in Selected Areas in Cryptography, B. Preneel and S. Tavares, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2006, pp. 319–331. [44] A. Krizhevsky, I. Sutskever, and G. E. Hinton, “Imagenet classification with deep convolutional neural networks,” in Advances in Neural Information Processing Systems, vol. 25, 2012, pp. 1097–1105. [45] K. Simonyan and A. Zisserman, “Very deep convolutional networks for large-scale image recognition,” 2015. [Online]. Available: https://arxiv.org/abs/1409.1556 [46] M. Hao, H. Chen, H. Li, C. Weng, Y. Zhang, H. Yang, and T. Zhang, “Scalable zero-knowledge proofs for non-linear functions in machine learning,” in 33rd USENIX Security Symposium (USENIX Security 24). Philadelphia, PA: USENIX Association, Aug. 2024, pp. 3819–3836. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity24/presentation/hao-meng-scalable [47] B.-J. Chen, L. Tang, and D. Kang, “Zktorch: Compiling ml inference to zero-knowledge proofs via parallel proof accumulation,” 2025. [Online]. Available: https://arxiv.org/abs/2507.07031 [48] T. Xie, T. Lu, Z. Fang, S. Wang, Z. Zhang, Y. Jia, D. Song, and J. Zhang, “zkPyTorch: A Hierarchical Optimized Compiler for Zero-Knowledge Machine Learning,” 2025, publication info: Preprint. [Online]. Available: https://eprint.iacr.org/2025/535 [49] D. Balbás, D. Fiore, M. I. González Vasco, D. Robissout, and C. Soriente, “Modular sumcheck proofs with applications to machine learning and image processing,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 1437–1451. [Online]. Available: https://doi.org/10.1145/3576915.3623160 [50] W. Ma, Q. Xiong, X. Shi, X. Ma, H. Jin, H. Kuang, M. Gao, Y. Zhang, H. Shen, and W. Hu, “Gzkp: A gpu accelerated zero-knowledge proof system,” in Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ser. ASPLOS 2023. New York, NY, USA: Association for Computing Machinery, 2023, p. 340–353. [Online]. Available: https://doi.org/10.1145/3575693.3575711
[36] J. Thaler, “Proofs, arguments, and zero-knowledge,” Foundations and Trends® in Privacy and Security, vol. 4, no. 2–4, pp. 117–660, 2022. [Online]. Available: http://dx.doi.org/10.1561/3300000030
[51] M. Li, Y. Yu, B. Wang, X. Fan, and S. Deng, “ZKPoG: Accelerating WitGen-incorporated end-to-end zero-knowledge proof on GPU,” Cryptology ePrint Archive, Paper 2025/765, 2025. [Online]. Available: https://eprint.iacr.org/2025/765
[37] M. Campanelli, A. Faonio, D. Fiore, A. Querol, and H. Rodrı́guez, “Lunar: A toolbox for more efficient universal and updatable zksnarks and commit-and-prove extensions,” in Advances in Cryptology – ASIACRYPT 2021: 27th International Conference on the Theory and Application of Cryptology and Information Security, Singapore, December 6–10, 2021, Proceedings, Part III. Berlin, Heidelberg: Springer-Verlag, 2021, p. 3–33. [Online]. Available: https://doi.org/10.1007/978-3-030-92078-4 1
[52] Z. Zhang, Y. Cai, W. Yin, X. Wu, Y. Wang, L. Ju, and Z. Ji, “Pipelonk: Accelerating end-to-end zero-knowledge proof generation on gpus for plonk-based protocols,” in Proceedings of the 31st ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, ser. PPoPP ’26. New York, NY, USA: Association for Computing Machinery, 2026, p. 439–451. [Online]. Available: https://doi.org/10.1145/3774934.3786448
[38] Polyhedra Network. (n.d.) GKR input layer chunks. Polyhedra Network Documentation. [Online]. Available: https://docs.polyhedra. network/expander/prover internals/input chunks/
[53] M. Kthiri, “Benchmarking gpu acceleration for zk-snarks with icicle,” https://www.maya-zk.com/blog/gpu-acceleration, 2024, accessed: 2025-08-30.
[39] D. Khovratovich, R. D. Rothblum, and L. Soukhanov, “How to prove false statements: Practical attacks on fiat-shamir,” in Advances in Cryptology – CRYPTO 2025, Y. Tauman Kalai and S. F. Kamara, Eds. Cham: Springer Nature Switzerland, 2025, pp. 3–26.
[54] N. Samardzic, S. Langowski, S. Devadas, and D. Sanchez, “Accelerating zero-knowledge proofs through hardware-algorithm co-design,” in 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2024, pp. 366–379.
[55] A. Daftardar, S. Kumar, Y. Li, B. Reagen, and S. Garg, “Szkp: A scalable accelerator architecture for zero-knowledge proofs,” in Proceedings of the 33rd International Conference on Parallel Architectures and Compilation Techniques (PACT ’24). ACM, 2024, pp. 271–283. [56] C. Wang and M. Gao, “Unizk: Accelerating zero-knowledge proof with unified hardware and flexible kernel mapping,” in Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’25). ACM, 2025. [57] A. Daftardar, J. Mo, J. Ah-kiow, B. Bünz, R. Karri, S. Garg, and B. Reagen, “Need for zkspeed: Accelerating hyperplonk for zeroknowledge proofs,” in Proceedings of the 52nd Annual International Symposium on Computer Architecture (ISCA ’25). ACM, 2025, pp. 1986–2001. [58] S. Bagad, Q. Dao, Y. Domb, and J. Thaler, “Speeding up sum-check proving,” Cryptology ePrint Archive, Paper 2025/1117, 2025. [Online]. Available: https://eprint.iacr.org/2025/1117 [59] W. Zhang and Y. Xia, “Hydra: Succinct fully pipelineable interactive arguments of knowledge,” Cryptology ePrint Archive, Paper 2021/641, 2021. [Online]. Available: https://eprint.iacr.org/2021/641 [60] R. S. Wahby, Y. Ji, A. J. Blumberg, A. Shelat, J. Thaler, M. Walfish, and T. Wies, “Full accounting for verifiable outsourcing,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 2071–2086. [Online]. Available: https://doi.org/10.1145/3133956.3133984 [61] V. Vu, S. Setty, A. J. Blumberg, and M. Walfish, “A Hybrid Architecture for Interactive Verifiable Computation,” in 2013 IEEE Symposium on Security and Privacy. Berkeley, CA: IEEE, May 2013, pp. 223–237. [Online]. Available: http://ieeexplore.ieee.org/ document/6547112/ [62] G. Cormode, M. Mitzenmacher, and J. Thaler, “Practical verified computation with streaming interactive proofs,” in Proceedings of the 3rd Innovations in Theoretical Computer Science Conference. Cambridge Massachusetts: ACM, Jan. 2012, pp. 90–112. [Online]. Available: https://dl.acm.org/doi/10.1145/2090236.2090245 [63] C. Pappas and D. Papadopoulos, “Sparrow: Space-efficient zksnark for data-parallel circuits and applications to zero-knowledge decision trees,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 3110–3124. [Online]. Available: https://doi.org/10.1145/3658644. 3690318 [64] A. Baweja, A. Chiesa, E. Fedele, G. Fenzi, P. Mishra, T. Mopuri, and A. Zitek-Estrada, “Time-space trade-offs for sumcheck,” in Theory of Cryptography: 23rd International Conference, TCC 2025, Aarhus, Denmark, December 1–5, 2025, Proceedings, Part IV. Berlin, Heidelberg: Springer-Verlag, 2025, p. 37–70. [Online]. Available: https://doi.org/10.1007/978-3-032-12290-2 2 [65] K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” in 2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2016, pp. 770–778. [66] A. Gabizon, Z. J. Williamson, and O.-M. Ciobotaru, “Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge,” IACR Cryptol. ePrint Arch., vol. 2019, p. 953, 2019. [Online]. Available: https://api.semanticscholar.org/ CorpusID:201685538
Appendix A. Background Definitions A.1. Zero-Knowledge Sumcheck To prevent V from recovering the layer polynomial evaluations during sumcheck, P modifies the original polynomial by adding a random masking polynomial k [12],
[28]. P samples a random univariate polynomial k : Fℓ → F of degree d = deg(h). The sumcheck protocol is then run on the modified equation [12] X H + ρK = h(x) + ρ k(x) , (8) x∈{0,1}m
P
where H = x∈{0,1}m h(x) is the original claim, K = P k(x) is a single scalar sent by P , and ρ ∈ F is a m x∈{0,1} random challenge chosen by V . Since each evaluation sent during sumcheck is masked by a fresh evaluation of k , V learns nothing about the individual values of h, i.e., Ṽi in GKR.
A.2. ZK-SNARK properties Definition 1 (zk-SNARK properties). A zk-SNARK for relation R satisfies: • Completeness: For all (i, x, w) ∈ R: h i Pr Verify(pp, i, x, π) = 1 = 1 where pp ← Setup(1λ , i) and π ← Prove(pp, i, x, w). • Knowledge Soundness: For every PPT adversary A, there exists a PPT extractor E such that for all (i, x): h i Pr Verify(pp, i, x, π) = 1 ∧ (i, x, w) ∈ / R ≤ negl(λ) where pp ← Setup(1λ , i), (x, π) ← A(pp, i), and w ← E A (pp, i). • Zero-Knowledge: There exists a PPT simulator Sim such that for all (i, x, w) ∈ R and all PPT distinguishers D: Pr[D(π) = 1] − Pr[D(π ′ ) = 1] ≤ negl(λ)
where π ← Prove(pp, i, x, w) and π ′ ← Sim(pp, i, x).
A.3. Polynomial Commitment Scheme Let PD denote the class of polynomials over Fp with degree bounds D. A polynomial commitment scheme (PCS) for PD consists of the following algorithms. λ • Setup(1 , D) → pp: On input security parameter λ and class description D, the setup algorithm outputs public parameters pp. • Commit(pp, f ; r) → com: On input pp, polynomial f ∈ Ps,D , and commitment randomness r, the commitment algorithm outputs commitment com. • Open(pp, f, α; r) → (v, π): On input f ∈ PD , evalus ation point α ∈ Fpf , and commitment randomness r, the opening algorithm outputs v = f (α) and opening proof π . • Verify(pp, com, α, v, π) → {0, 1}: On input pp, coms mitment com, evaluation point α ∈ Fpf , claimed value v , and opening proof π , the verifier outputs 1 if the opening is accepted and 0 otherwise.
Definition 2 (PCS properties). A polynomial commitment scheme (Setup, Commit, Open, Verify) for the polynomial class PD satisfies the following properties. Completeness. For every polynomial f ∈ PD , every evaluation point α in f ’s domain, and every valid commitment randomness r, we have Pr [Verify(pp, com, α, v, π) = 1] = 1,
independent. The required number of variables and monomials in R therefore grows with the number of consumer proofs. For example, if the commitment is shared across 4 to 9 proofs, R can be defined as: R(z2 , z1 , w) =a0 + a1 z2 + a2 z22 + a3 z1 + a4 z12 + a5 w2 + a6 w + a7 z2 z1 + a8 z2 w + a9 z22 z12 w2 (9)
where a0 , . . . , a9 are randomly sampled from Fp .
where pp ← Setup(1λ , D),
com ← Commit(pp, f ; r),
and (v, π) ← Open(pp, f, α; r).
Binding. For every PPT adversary A, Verify(pp, com, α, v, π) = 1 ∧ Pr Verify(pp, com, α, v ′ , π ′ ) = 1 ∧ ≤ negl(λ), v ̸= v ′ where pp ← Setup(1λ , D), and (com, α, v, π, v ′ , π ′ ) ← A(pp). Hiding. For security parameter λ, public parameters pp ← Setup(1λ , D), polynomial f ∈ PD , PPT adversary A, and simulator S = (S1 , S2 ), consider the following two experiments. RealA,f (pp) : rf ← R; com ← Commit(pp, f ; rf ); st ← A(com); (α, y, π) ← ⟨Open(pp, f, · ; rf ), A⟩(st); b ← A(com, α, y, π); output b.
IdealSA,f (pp) : (com, td) ← S1 (pp); st ← A(com); α ← A(st); y = f (α); π ← S2 (td, α, y); b ← A(com, α, y, π); output b.
The PCS is hiding if, for every PPT adversary A and every f ∈ PD , there exists a PPT simulator S such that i h Pr [RealA,f (pp) = 1] − Pr IdealSA,f (pp) = 1 ≤ negl(λ).
Appendix B. Discussion B.1. Multiple Parts Consuming The Same Input In models with residual or skip connections (e.g., ResNet [65]), a layer’s output may be consumed by multiple non-contiguous downstream layers. If such a layer is chosen as a partition boundary, zkComposer can reuse a single commitment for the shared activations across multiple subproofs. However, the zero-knowledge construction requires care: when a committed polynomial is opened in more than two sub-proofs, the masking polynomial (R) used in its lowdegree extension must include sufficiently many monomials to ensure that all revealed evaluations remain statistically
B.2. Applying zkComposer To Other Computations The zkComposer construction only modifies the GKR protocol at the boundary layers, leaving the core protocol unchanged. Hence, zkComposer is not specific to machine learning workloads. zkComposer can be applied to any computation that can be represented as a layered arithmetic circuit verified by sumcheck-based protocols.
B.3. Applying zkComposer To PLONK-based Systems Although we present zkComposer for GKR-based zkML systems, the underlying idea of reusing committed intermediate values across independently verified sub-proofs also applies to table-based arithmetizations like PLONK [66]. In such settings, zkComposer can be realized by assigning shared boundary values to fixed advice columns and reusing them consistently across circuits, similar to techniques in Artemis [20]. The main requirement is that the commitment scheme enforces binding across all sub-proofs that reference the shared values.
B.4. zkComposer: Analysis Proof of Theorem 1. We prove completeness and knowledge soundness separately. Completeness. Let (i, x, w) ∈ Rzkml , where x = {q, r}. Consider an honest execution of zkComposer with witness w. By completeness of the PCS, every honestly generated opening of comb , comRb , and the other commitments used in Protocol 1 verifies. By completeness of the underlying GKR-based CP-SNARKs, the sub-proofs for RA and RB both accept. Since the zkComposer verifier accepts only if both sub-proofs accept and all PCS openings verify, the honestly generated proof π ← Prove(pp, i, x, w) is accepted. Therefore, zkComposer satisfies completeness for Rzkml . Knowledge Soundness. Let A be any PPT adversary that, on input public parameters pp, index i, and instance x = {q, r}, outputs an accepting zkComposer proof π = (comb , πA , πB , . . .)
with non-negligible probability. We construct a PPT extractor that outputs a valid witness for Rzkml .
Since the zkComposer verifier accepts, both underlying sub-verifiers accept. By knowledge soundness of the CPSNARK for RA , an extractor returns a witness wA = (θA , advA , wb )
such that (iA , xA = {r}, wA ) ∈ RA . Similarly, the CPSNARK for RB yields an extractor returning a witness wB = (θB , advB , actb )
such that (iB , xB = {q}, wB ) ∈ RB . It remains to show that these extracted boundary values are consistent. In Protocol 1, both sub-proofs use the same PCS commitment comb to the masked boundary polynomial V̇b . The RA sub-proof opens it when checking the boundary input polynomial for part A. The RB sub-proof opens it as the committed output polynomial for layer b. Since the zkComposer verifier accepts only if all such openings verify and the PCS is binding, all accepting openings of comb are consistent with a single degree-bounded polynomial, except with negligible probability. By construction (Eq. 3), V̇b and Ṽb agree on the Boolean hypercube. Therefore, except with negligible probability, the boundary values wb extracted from the RA proof equal the layer-b activations actb extracted from the RB proof. We define the combined witness w = (θA , θB , advA , advB ). The witness wA enforces correctness of layers {0, . . . , b−1} and wB of layers {b, . . . , d}. Since the extracted boundary values match, these two witnesses combine into a valid witness for the original end-to-end relation: (i, x, w) ∈ Rzkml , except with negligible probability. Therefore, zkComposer satisfies knowledge soundness for Rzkml . Since zkComposer satisfies both completeness and knowledge soundness, it is a knowledge argument for Rzkml . Proof of Theorem 2. We construct a simulator Smod for the two-partition protocol zkComposer. It combines Ssc for the underlying GKR-based CP-SNARK transcripts with Spc for the hiding PCS. All transcript components that do not involve the shared boundary polynomial V̇b are simulated as in the standard commit-and-prove GKR analysis. By the zero-knowledge of the underlying GKR-based CP-SNARKs and the hiding of the PCS, these components are indistinguishable from those in a real execution. It remains to consider the messages involving V̇b . The verifier learns two evaluations of V̇b : one at the input-layer query point g (inp,A) in sub-protocol A, and one at the layer-b query point g (b) in sub-protocol B . In addition, the zero-knowledge GKR oracle check for layer b reveals one evaluation of the boundary masking polyno(b) mial, Rb (g1 , c), for a verifier-chosen random c ∈ Fp . For simplicity, let u = g (b)
and
v = g (inp,A) .
Using the LDE form in Eq. 3, the revealed boundary values can be written as V̇b (u) = Veb (u) + Zb (u)Mu ,
V̇b (v) = Veb (v) + Zb (v)Mv ,
where Mu =
X
Rb (u1 , w),
Mv =
w∈{0,1}
X
Rb (v1 , w),
w∈{0,1}
and the third revealed value is ρ = Rb (u1 , c).
We analyze the distribution of the mask evaluations (Mu , Mv , ρ). By the definition of Rb in Eq. 4, these values are linear in the random coefficients a0 , . . . , a6 : a0 a1 2 2u1 1 u1 2u21 1 u21 a2 Mu 2 2 Mv = 2 2v1 1 v1 2v1 1 v1 a3 . 2 2 2 2 ρ 1 u1 c cu1 u1 c c u1 a4 a5 a6 Row reduction shows that the matrix has rank 3 whenever u1 ̸= v1 ,
2c − 1 ̸= 0,
2c2 − 1 ̸= 0
(mod p).
These conditions are required for zero-knowledge of the underlying SNARKs [12]. If any condition fails, the challenges are resampled [12]. Thus, the linear map from (a0 , . . . , a6 ) to (Mu , Mv , ρ) is surjective. Since a0 , . . . , a6 are sampled uniformly and independently, (Mu , Mv , ρ) is uniform over F3p . Therefore, the revealed boundary-related values are statistically independent of Veb . $ − Fp in place of The simulator Smod samples Yu , Yv , ρ′ ← V̇b (u), V̇b (v), Rb (u1 , c), respectively. It uses Spc to simulate the commitments and openings for comb and comRb , and Ssc to simulate the GKR/sumcheck transcripts consistently with Yu , Yv , ρ′ . We compare the real and simulated transcripts by a standard hybrid argument: first replace the GKR/CPSNARK sub-proofs with Ssc outputs, then the PCS commitments and openings with Spc outputs, and finally the boundary-related values with uniform field elements. The first two replacements are computationally indistinguishable by the underlying SNARK’s zero-knowledge and the PCS’s hiding properties. The last is statistically identical, as shown above. Thus, the real and simulated transcripts are indistinguishable. For every PPT distinguisher D, |Pr[D(π) = 1] − Pr[D(π ′ ) = 1]| ≤ negl(λ).
Therefore, zkComposer is zero-knowledge for Rzkml . Asymptotic Analysis. For a log-space uniform circuit C of depth d with input size n, the prover complexity is O(|C|), the verifier complexity is O(|x| + d · log |C|), and the proof size is O(d · log |C|) [12]. Under zkComposer, each sub-proof’s complexities—with input sizes n1 , n2 and circuits C1 , C2 of depths d1 , d2 —match the baseline GKR
protocol. The underlying zk-SNARK protocols for the subproofs remain unmodified. Thus, for k partitions, the i-th proof has prover complexity O(|Ci |), verifier complexity O(|xi | + di · log |Ci |), and proof size O(di · log |Ci |). Total complexities follow by summing across partitions. For equal partitions (|Ci | = |C|/k , |xi | = |x|/k ), the total prover complexity under zkComposer matches the monolithic proof. However, the additional polynomial commitments increase total proof size in practice.