1 Introduction

Arguments of Knowledge. Decentralised systems make extensive use of protocols that enable a prover to post a statement together with a short proof, such that any verifier can publicly check that the statement (e.g., correctness of a computation, claims of storage etc.) is true while expending fewer resources, e.g. less time than would be required to re-execute the computation.

SNARKs are such proofs that allow one party to demonstrate knowledge of a satisfying witness to some NP statement and have verification time and proof size independent of the size of this witness. If these proofs also conceal anything else about the witness we refer to them as zk-SNARKs. In the last decade, there has been a series of works on constructing SNARKs [BCI+13, GGPR13, PHGR13, BCTV14, Gro16] with constant-size proofs that rely on trusted setups.

SNARKs are becoming very popular in real-world applications such as delegated computation or blockchain systems: as examples of early practical use case, Zerocash [BCG+14] showed how to use zk-SNARKs in distributed ledgers to achieve payment systems with strong privacy guarantees. The Zerocash protocol, with some modifications, is now commercially deployed in several cryptocurrencies, e.g. Zcash.

More recent zk-SNARK use cases are Aztec and zkSync, two projects boosting the scalability and privacy of Ethereum smart contractsFootnote 1. Another example of SNARK application is the Filecoin SystemFootnote 2 that implements a decentralized storage solution for the internet.

The rapid and massive adoption of SNARK schemes has created new scalability challenges for blockchain systems: the generation of trusted setups requires complicated ceremonies, proving large statements has significant overhead, and verifying multiple proofs is expensive even with batching.

Trusted Setup Ceremony. All the constant-size zk-SNARK schemes have a common major disadvantage in practice: they rely on some public parameters, the structured reference string (SRS), that are generated by a trusted setup. In theory, this setup is run by a trusted third party, while in practice, such a string can be generated by a so called “ceremony”, a multi-party computation between participants who are believed not to collude as shown in [ABL+19, BGM17, BCG+15]. Generating such a trusted setup is a cumbersome task. These ceremonies are expensive in terms of resources, they must follow specific rules, and they are generally hard to organise: hundreds of participants with powerful machines need to join efforts to perform a multi-party computation over multiple months.

Groth16. The construction by Groth [Gro16] is the state-of-the-art for pairing-based zk-SNARKs. Groth16 requires the computation to be expressed as an arithmetic circuit and relies on some trusted setup to prove the circuit satisfiability. Due to its short proof size (3 group elements) and verifier’s efficiency, Groth16 has become a de facto standard in blockchain projects. This results in a great number of available implementations, code auditing, and multiple trusted setup ceremonies run by independent institutions.

Motivation. Importantly, the trusted setup in SNARK schemes sets an upper bound on the size of computations that can be proven (number of constraints in the circuit description). Because modern applications have an increased demand for the size of circuits, Groth16 is starting to face scalability problems. A simple solution would be to split the computation in different pieces and prove them independently in smaller circuits, but this increases the number of proofs to be added to a single statement and the verification time.

We address this problem by demonstrating a method to reduce the overhead in communication and verification time for multiple proofs without the need of further larger trusted setup ceremonies.

Filecoin System. One example is Filecoin [Lab18] proof-of-space blockchain. To onboard storage in the network, Filecoin miners post a Groth16 proof that they correctly computed a Proof-of-Space [Fis19]. Each proof guarantees that the miner correctly “reserves” 32 GB of storage to the network and consists of 10 different SNARKs. The chain currently processes a large number of proofs each day: approximately 500,000 Groth16 proofs, representing 15 PiB of storage.

Contribution. We explore reducing proof size and verifier time for SNARKs even further by examining techniques to aggregate proofs without the requirement for additional trusted setups.

We design SnarkPack, an argument that allows to aggregate n Groth16 zkSNARKs with a \(O(\log n)\) proof size and verifier time. Our scheme is based on a trusted setup that can be constructed from two different existing ceremonies (e.g. the “powers of tau” for Zcash [Zca18] and Filecoin [Fil20]).

Being able to rely on the security of well-known trusted setups for which the ceremonies have been largely publicly advertised is a great practical advantage and makes SnarkPack immediately useful in real-world applications.

Our techniques are generic and can also apply to other pairing-based SNARKs. The roadmap is similar, since all such SNARK constructions require the generation of “powers of tau” for the setup ceremony and then have a few pairing check equations in the verification algorithm. However, we choose to focus on Groth16 proofs and tailor optimisations for this case, since it is the most popular scheme among practitioners. Therefore, SnarkPack is the first practical system that can be used in blockchain applications to reduce the on-chain work by employing verifiable outsourcing to process a large number of proofs off-chain. This applies broadly to any system that needs to delegate batches of state updates to an untrusted server.

Related Work. Prior works have built similar schemes for recursion or aggregation of proofs, but they all have critical shortcomings when it comes to implementing them in real-world systems.

Bünz et al. [BMM+19] presented a scheme for aggregating Groth16 proofs that requires a specific trusted setup to construct the structured reference string (SRS) necessary to verify such aggregated proofs. Our result is conceptually similar to that of Bünz et al. while benefiting from many optimizations. We focus specifically on aggregating proofs generated using the same Groth16 SRS which is the common use case, as opposed to the generic result in [BMM+19] that allows aggregation of proofs from different SRSes. Our result can be extended to support this latter case as well.

While our techniques built on top of inner pairing arguments with logarithmic verifier previously introduced by [DRZ20], we build new such schemes that avoid the need of a different trusted setup ceremony (other than the existing SNARK setup). Our approach for aggregation is preferable to [BMM+19] in practical use cases.

Other approaches to aggregation rely on recursive composition. In more detail, [BCG+20] propose a new SNARK for the circuit that contains n copies of the Groth16 verifier’s circuit. However, constructing arithmetic circuits for pairings is expensive (e.g., computing a pairing on the BLS12-377 curve requires \(\approx 15 000\) constraints as shown in [BCG+20]). The advantage of using such expensive schemes for aggregation is their transparent setup.

However, the costs are significant compared with our scheme: they compute FFTs, which require time \(O(n \log n)\), the verifier performs O(n) cryptographic operations as opposed to O(n) field operations in our scheme and they require special cycles of curves.

SnarkPack has the best of both worlds: it benefits from the power of structured public parameters to avoid expensive computations, while it does not require additional trust assumptions, as it relies on already available trusted setup transcripts for the underlying Groth16 scheme.

Technical Overview. To explain how SnarkPack works, we need to consider 3 multiplicative cyclic groups \(\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T\) of order p equipped with the bilinear map, also called “pairing” \(e: \mathbb {G}_1 \times \mathbb {G}_2 \rightarrow \mathbb {G}_T\) such that \(\forall a, b \in \mathbb {Z}_p : e(g^a, h^b) = e(g, h)^{ab}\).

Groth16 proofs \(\pi =(A, B, C)\) for statements \(u=\textbf{a}\) consist of 3 group elements \(A,C \in \mathbb {G}_1\) and \(B \in \mathbb {G}_2\). The high-level idea of Groth16 aggregation is quite simple: Since Groth16 verification consists in checking a pairing equation between the proof elements \(\pi =(A, B, C)\), instead of checking that n different pairing equations are simultaneously satisfied, it is sufficient to prove that only one inner pairing product of a random linear combination of these initial equations defined by a verifier’s random challenge \(r\in \mathbb {Z}_p\) holds. In a bit more detail, Groth16 verification asks to check an equation of the type \(e(A_i,B_i)= Y_{i} \cdot e(C_i, D) \) for \(Y_{i}\in \mathbb {G}_T, D \in \mathbb {G}_2\) where \(Y_i\) is a value computed from each statement \(u_i=\textbf{a}_i\), \(D\in \mathbb {G}_2\) is a fixed verification key and \(\pi _i =( A_i,B_i, C_i)_{i=0}^{n-1}\) are proof triples.

The aggregation will instead check a single randomized equation:

$$\begin{aligned} \prod _{i=0}^{n-1} e(A_i,B_i)^{r^i}= \prod _{i=0}^{n-1} Y_{i}^{r^i} \cdot e\big (\prod _{i=0}^{n-1} C_i^{r^i} , D\big ). \end{aligned}$$

We denote by \(Y_{prod}'{:}{=}\prod _{i=0}^{n-1} Y_{i}^{r^i}\) so this can be rewritten as:

$$\begin{aligned} Z_{AB} = Y_{prod}' \cdot e(Z_C, D), ~\text { where } Z_{AB} {:}{=}\prod _{i=0}^{n-1} e(A_i,B_i)^{r^i} \text { and }~ Z_C {:}{=}\prod _{i=0}^{n-1} C_i^{r^i}. \end{aligned}$$

What is left after checking that this unified equation holds is to verify that the elements \( Z_{AB}, Z_C\) are consistent with the initial proof triples in the sense that they compute the required inner product. This is done by applying an argument that proves two different inner pairing product relations:

  • TIPP: the target inner pairing product takes some initial committed vectors \(\textbf{A}\in \mathbb {G}_1, \textbf{B}\in \mathbb {G}_2\) and shows that \(Z_{AB}=\prod _{i=0}^{n-1} e(A_i,B_i)\);

  • MIPP: the multi-exponentiation inner product takes a committed vector \(\textbf{C}\in \mathbb {G}_1\) and a vector \(\textbf{r}\in \mathbb {Z}_p\) and shows that \(Z_{C}=\prod _{i=0}^{n-1} C_i^{r^i}\).

New Commitment Schemes. The key ingredient for SnarkPack is the efficient realisation of the two specialised inner pairing product arguments following the ideas initially proposed by [DRZ20] and generalised to other inner products by [BMM+19]. These require a special commitment scheme that allows a party to commit to vectors of group elements in both source groups \(\mathbb {G}_1\) and \(\mathbb {G}_2\) with further homomorphic and collapsing properties.

We therefore introduce two new Pair Group Commitment schemes described in Sect. 3 that enable to commit to vectors \(\textbf{A}, \textbf{C}\in \mathbb {G}_1, \textbf{B}\in \mathbb {G}_2\). Our commitments are doubly-homomorphic with respect to the message space and key space and they have a collapsing property. Both schemes have constant-size commitments and are proved to be binding based on assumptions that hold in the generic group model. Our second scheme has the advantage that it allows a party to commit to two vectors from two different groups with no size overhead. We think these schemes can be of independent interest in protocols that need to commit to source-group elements.

Reusing Groth16 Trusted Setup. The advantage of our commitment schemes is that they can reuse existing public setups for Groth16 to generate their structured commitment keys.

The public parameters required for the generation of the commitment keys can be extracted from two compatible copies of Groth16 SRS.

For a given bilinear group \((p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T )\), Groth16 SRS consist (among other elements) of consecutive powers of some random evaluation point \(\tau \) in both groups \(\mathbb {G}_1\) and \(\mathbb {G}_2: \{g^{\tau ^i}\}_i \in \mathbb {G}_1^d, \{h^{\tau ^i}\}_i \in \mathbb {G}_2^d.\) We will call these “powers of tau”.

The generation of SnarkPack public parameters (the commitment keys) comes naturally from two ceremonies for Groth16 setup (also known as “powers of tau”) for the same generators g and h and different powers \(a= \tau _1\) and \(b=\tau _2\): \(g,h, g^{\tau _1},\dots ,g^{\tau _1^n},h^{\tau _1},\dots ,h^{\tau _1^n}\), one up to n and the other \(g^{\tau _2} \dots ,g^{\tau _2^m},h^{\tau _2},\dots ,h^{\tau _2^m}\) up to \(m \ge n\).

Our assumptions rely on the fact that cross powers (e.g. \(g^{\tau _1 \tau _2}\)) are not known to the prover. Since the two SRSes we use are the result of two independent ceremonies, it is unlikely that such terms can be learned since \(\tau _1\) and \(\tau _2\) were destroyed after the SRS generation.

In practice, we fortunately have at least two ceremonies that satisfy the requirements for same group generators and different powers: Such values can be obtained from the powers of tau transcript of Zcash [Zca18] and Filecoin [Lab18]. The SRS created goes up to \(n=2^{19}\) for \(\tau _1\) and \(m =2^{127}\) for \(\tau _2\).

Implementation. In ?? we provide benchmarks and optimisation details for our implementation in Rust, and evaluate its efficiency against batching. SnarkPack is exponentially more efficient than aggregation via batching: it takes 163 ms to verify an aggregated proof for 8192 proofs (including unserialization) versus 621 ms when doing batch verification. The former is of 40 kB in size. The aggregator can aggregate 8192 proofs in 8.7 s.

2 Preliminaries

Bilinear Groups. A bilinear group is given by a description \(~\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T )\) such that

  • p is prime, so \(\mathbb {Z}_p=\mathbb {F}\) is a field.

  • \(\mathbb {G}_1 =\langle g\rangle , \mathbb {G}_2 =\langle h \rangle \) are cyclic groups of prime order p.

  • \(e: \mathbb {G}_1 \times \mathbb {G}_2 \rightarrow \mathbb {G}_T\) is a bilinear asymmetric map (pairing), which means that \(\forall a, b \in \mathbb {Z}_p : e(g^a, h^b) = e(g, h)^{ab}\).

Vectors. For n-dimensional vectors \(\textbf{a}\in \mathbb {Z}_p^n, \textbf{A}\in \mathbb {G}_1^n, \textbf{B}\in \mathbb {G}_2^n\), we denote the i-th entry by \(a_i \in \mathbb {Z}_p, A_i \in \mathbb {G}_1, B_i\in \mathbb {G}_2\) respectively. Let \(\textbf{A}\Vert \textbf{A}' = (A_0, \dots , A_{n-1},A_0', \dots , A_{n-1}')\) be the concatenation of vectors \(\textbf{A}, \textbf{A}' \in \mathbb {G}_1^n \). We write \(\textbf{A}_{[:\ell ]} = (A_0, \dots , A_{\ell -1}) \in \mathbb {G}_1^{\ell }\) and \(\textbf{A}_{[\ell :]} = (A_{\ell }, \dots , A_{n-1}) \in \mathbb {G}_1^{n-\ell }\) to denote slices of vectors \(\textbf{A}\in \mathbb {G}_1^n\) for \(0 \le \ell < n-1\).

We write group operations as multiplications. We define:

  • \(\textbf{A}^{x} = (A_0^x, \dots , A_{n-1}^x) \in \mathbb {G}_1^n\) for \(x \in \mathbb {Z}_p\) and a vector \(\textbf{A}\in \mathbb {G}_1^n\).

  • \(\textbf{A}^{\textbf{x}} = (A_0^{x_0}, \dots , A_{n-1}^{x_{n-1}}) \in \mathbb {G}_1^n\) for vectors \(\textbf{x}\in \mathbb {Z}_p^n, \textbf{A}\in \mathbb {G}_1^n\).

  • \(\textbf{A}* \textbf{x}= \prod _{i=0}^{n-1} A_i^{x_i}\) for vectors \(\textbf{x}\in \mathbb {Z}_p^n, \textbf{A}\in \mathbb {G}_1^n\).

  • \(\textbf{A}* \textbf{B}{:}{=}\prod _{i=0}^{n-1} e(A_i, B_i)\) for group vectors \(\textbf{A}\in \mathbb {G}_1^n, \textbf{B}\in \mathbb {G}_2^n\).

  • \(\textbf{A}\circ \textbf{A}' {:}{=}(A_0A_0', \dots , A_{n-1}A_{n-1}')\) for vectors \(\textbf{A}, \textbf{A}' \in \mathbb {G}_1^n \).

Relations. We use the notation \(\mathcal {R}\) to denote an efficiently decidable binary relation. For pairs \((u,w) \in \mathcal {R}\) we call u the statement and w the witness. We write \(\mathcal {R}= \{(u; w) : p(u, w)\}\) to describe an NP relation.

Common and Structured Reference String. The common reference string (CRS) model, introduced by Damgård [Dam00], captures the assumption that a trusted setup exists. Schemes proven secure in the CRS model are secure given that the setup was performed correctly. We will use the terminology “Structured Reference String” (SRS) since all our \(\textsf{crs}\) strings are structured.

Background on Groth16. We recall here some necessary elements from [Gro16] construction. The definition of zk-SNARKs is given in Appendix A.1. A detailed description of the Groth16 protocol can be found in Appendix C. The main highlights follow:

Setup. For a given bilinear group \(\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T )\), the SRS contains, among other elements, consecutive powers of some random evaluation point s in both groups \(\mathbb {G}_1, \mathbb {G}_2: \{g^{s^i}\}_{i=0}^{d-1} ~\in \mathbb {G}_1^d,\) and \( \{h^{s^i}\}_{i=0}^{d-1} ~\in \mathbb {G}_2^d.\)

Prove. A Groth16 proof \(\pi \) for a statement \(u {:}{=}\textbf{a}= \{a_j\}_{j=0}^{t}\) (with \(a_0=1\)) and a witness \(w {:}{=}\{a_j\}_{j=t+1}^{m}\) consists in 3 group elements \(\pi =(A, B, C)\), where \(A,C \in \mathbb {G}_1\) and \(B \in \mathbb {G}_2\).

Verify. For the verification algorithm, Groth16 uses only a part of its structured reference string which we will call verification key \(\textsf{vk}\):

$$\begin{aligned} \textsf{vk}{:}{=}\Big (P = g^\alpha , Q= h^\beta , ~ \Big \{S_j =g^{\textstyle \frac{ \beta v_j(s) + \alpha w_j(s) + y_j(s)}{\gamma }} \Big \}_{j =0}^{t}, H = h^\gamma , D = h^\delta \Big ). \end{aligned}$$

Groth16 verification consists in checking a pairing equation between the proof elements \(\pi =(A, B, C)\) using the verification key:

$$\begin{aligned} e(A,B)= e(g^\alpha ,h^\beta ) \cdot e(\prod _{j=0}^{t} S_j^{a_j},h^\gamma ) \cdot e(C, h^{\delta }). \end{aligned}$$

Assumptions. We introduce two new assumptions necessary to prove our schemes are secure. Formal proofs that these assumptions hold in the Generic Group Model can be found in Appendix B.1.

Assumption 1

(ASSGP). The (qm)-Auxiliary Structured Single Group Pairing assumption holds for the bilinear group generator \(\mathcal {G}\) if for all \(~\textsf{PPT}\) adversaries \(\mathcal {A}\) we have, on the probability space \(~\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T ) \leftarrow \mathcal {G}(1^\lambda )\), and the following probability is negligible in \(\lambda \):

figure c

Assumption 2

(ASDGP). The (qm)-ASDGP assumption holds for the bilinear group generator \(~\mathcal {G}\) if for all \(~\textsf{PPT}\) adversaries \(\mathcal {A}\) we have, on the probability space \(~\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T ) \leftarrow \mathcal {G}(1^\lambda )\), and the following probability is negligible in \(\lambda \):

figure f

We can similarly define the dual assumptions, by swapping \(\mathbb {G}_1\) and \(\mathbb {G}_2\) in the definition above.

3 Pair Group Commitment Schemes

In this section we introduce a new commitment scheme to group elements in a bilinear group. In order to use them in our aggregation protocol, we require the following properties from the commitment schemes:

  • Computationally Binding Commitment: as per Definition 4

  • Constant Size Commitment: the commitment value is independent of the length of the committed vector

  • Doubly-Homomorphic: homomorphic both in the message space and in the key space

    $$\begin{aligned}{} & {} \textsf{CM}(\textsf{ck}_1 + \textsf{ck}_2; M_1+M_2) = \textsf{CM}(\textsf{ck}_1; M_1) + \textsf{CM}(\textsf{ck}_1; M_2)+ \\{} & {} \qquad \qquad \qquad \qquad \qquad \qquad \qquad \qquad \qquad \textsf{CM}(\textsf{ck}_2; M_1)+ \textsf{CM}(\textsf{ck}_2; M_2). \end{aligned}$$
  • Collapsing Property: double-homomorphism implies a distributive property between keys and messages that allows multiple messages to be collapsed via a deterministic function \(\textsf{Collapse}\) defined as follows:

    figure g

There are a few candidates for such schemes, but none of them are adapted for fulfilling our goals. The commitment schemes proposed by [DRZ20, BMM+19] work under some new assumption that asks for the commitment keys to be structured in a specific way. In order to use this commitment, we need to run a new trusted setup to generate a commitment key. It would be impossible to consider existing Groth16 setups, since those give away elements that break the binding of the commitment scheme.

Our main goal is to find a commitment scheme that uses a structured reference string similar to the one from many popular SNARK implementations, e.g. Groth16.

The commitment scheme proposed by Lai et al. [LMR19] is likely to satisfy these properties, but it is shown to be binding only for unstructured random public parameters; however, in order to obtain a log-time verification Inner Pairing Product Argument scheme, we would need some structure for the commitment keys. We adapt the commitments from [LMR19] to work with structured keys and prove the binding property for an adversary that has access to these structured public parameters under our new assumptions ASSGP and ASDGP.

To optimise the commitment sizes, we define two different variants of the commitment scheme: one that takes a vector of elements of a single group \(\mathbb {G}_1\), and one that takes two vectors of points in \(\mathbb {G}_1\) and \(\mathbb {G}_2\), respectively.

Single Group Version \(\boldsymbol{\textsf{CM}_s}\). This version is useful for the MIPP relation. It takes one vector \(\textbf{A}\in \mathbb {G}_1^n \) and outputs two target group elements \((T_{A}, U_{A})~\in \mathbb {G}_T^2\) as a commitment.

  • \(\textsf{KG}_s(1^\lambda ) \rightarrow \textsf{ck}_s=(\textbf{v}_1, \textbf{v}_2) \) Sample and set \(\textbf{v}_1 = (h,h^a,\dots ,h^{a^{n-1}}), \quad ~\textbf{v}_2 = (h,h^b,\dots ,h^{b^{n-1}}).\)

  • \(\textsf{CM}_s(\textsf{ck}_s=(\textbf{v}_1, \textbf{v}_2), \textbf{A}= (A_0, \dots , A_{n-1})) \rightarrow (T_A, U_A){:}\)

    1. 1.

      \(T_A = \textbf{A}* \textbf{v}_1 = e(A_0,h) \cdot e(A_1,h^a) \dots e(A_{n-1},h^{a^{n-1}}) \)

    2. 2.

      \(U_A = \textbf{A}* \textbf{v}_2 = e(A_0,h) \cdot e(A_1,h^b)\dots e(A_{n-1},h^{b^{n-1}}) \)

Lemma 1

Under the hardness of (nm)-ASSGP assumption for \(m>2n\), this commitment scheme is computationally binding as per Definition 4.

Proof

Suppose there exists a \(\textsf{PPT}\) adversary \(\mathcal {A}\) that breaks the binding property of the commitment scheme. Then, given the output \(((T_A, U_A);\textbf{A}, \textbf{A}^* ) \) of the adversary \(\mathcal {A}\), we have that \( (T_A, U_A) = (T_{A^*}, U_{A^*})\):

$$\begin{aligned} e(A_0,h) e(A_1,h^a) \dots e(A_{n-1},h^{a^{n-1}})&= e(A_0^*,h) e(A_1^*,h^a) \dots e(A_{n-1}^*,h^{a^{n-1}})\\ e(A_0,h) e(A_1,h^b) \dots e(A_{n-1},h^{b^{n-1}})&= e(A_0^*,h) e(A_1^*,h^b) \dots e(A_{n-1}^*,h^{b^{n-1}}) \end{aligned}$$

By applying the homomorphic properties of the commitment scheme to these equations we get:

$$\begin{aligned} e(A_0/A_0^*,h) e(A_1/A_1^*,h^a) \dots e(A_{n-1}/A_{n-1}^*,h^{a^{n-1}})&= 1\\ e(A_0/A_0^*,h) e(A_1/A_1^*,h^b) \dots e(A_{n-1}/A_{n-1}^*,h^{b^{n-1}})&= 1 \end{aligned}$$

where the vector \((A_0/A_0^*, A_1/A_1^*, \dots A_{n-1}/A_{n-1}^*) \ne \textbf{1}_{\mathbb {G}_1} \). This breaks the (nm)-ASSGP assumption.

Double Group Version \(\boldsymbol{\textsf{CM}_d}\). This version is useful for the TIPP relation. It takes two vectors \(\textbf{A}\in \mathbb {G}_1^n, \textbf{B}\in \mathbb {G}_2^n\) and outputs two target group elements \((T_{AB}, U_{AB})~\in \mathbb {G}_T^2\) as a commitment.

  • \(\textsf{KG}_d(1^\lambda ) \rightarrow \textsf{ck}_d=(\textbf{v}_1, \textbf{v}_2, \textbf{w}_1, \textbf{w}_2): \) Sample and set \(\textbf{v}_1 = (h,h^a,\dots ,h^{a^{n-1}}), \quad \textbf{w}_1 = (g^{a^n}, \dots , g^{a^{2n-1}})\), \(\textbf{v}_2 = (h,h^b,\dots ,h^{b^{n-1}}), \quad ~\textbf{w}_2 = (g^{b^n},\dots ,g^{b^{2n-1}}).\)

  • \(\textsf{CM}_d(\textsf{ck}_d, \textbf{A}, \textbf{B}) \rightarrow (T_{AB}, U_{AB})\):

    1. 1.

      \(T_{AB} = (\textbf{A} * \mathbf {v_1})(\mathbf {w_1} * \textbf{B}) \)

    2. 2.

      \(U_{AB} = (\textbf{A} * \mathbf {v_2})(\mathbf {w_2} * \textbf{B}) \)

Lemma 2

Under the hardness of (nm)-ASDGP assumption for \(m>2n\), this commitment scheme is computationally binding.

Proof

The proof is analogous to the one of Lemma 1. Since the commitment is homomorphic, breaking the binding is equivalent to finding a non-trivial opening to 1. Thus it breaks the assumption.

Inner Pairing Product Commitments. It is straightforward to check that the two versions of pairing commitment schemes \(\textsf{CM}_s\) and \(\textsf{CM}_d\) are compatible with inner product arguments, in the sense that they satisfy all the necessary properties: constant size, doubly-homomorphic, and the identity is a collapse function defined \(\textsf{Collapse}_{id}(C) = C\).

Reusing Groth16 SRS. The two commitment schemes have the advantage that they can reuse two compatible (independent) SNARK setup ceremonies for their structured keys generation and therefore can be easily deployed without requiring a new trusted setup.

The SRSes required for the generation of the public commitment keys should satisfy some properties: We ask for the two ceremonies to use the same basis/generators in the same bilinear group \(g \in \mathbb {G}_1, h \in \mathbb {G}_2\), but two different randomnesses \( a, b, \in \mathbb {Z}_p, a \ne b\) for the exponents. The setups consists of consecutive powers \(\{g^{a^i}, h^{a^i}\}_{i=0}^m\) and \(\{g^{b^i}, h^{b^i}\}_{i=0}^n\).

Importantly, even if the two setups have different dimensions \(m\ne n\), this does not affect the binding of the commitments. The extra elements available to the adversaries are taken into account in the auxiliary input \(\textsf{aux}\) in the two assumptions, by setting the parameters accordingly.

4 \(\mathsf {MT\text {-}IPP}\) Scheme

This new protocol will be used to prove two inner pairing product relations that are essential to SNARK aggregation: the multiexponentiation inner product (MIPP) between vectors \(\textbf{C}\) and \(\textbf{r}\) and the target inner pairing product (TIPP) between vectors \(\textbf{A}, \textbf{B}\), for vectors \(\textbf{A}, \textbf{C}\in \mathbb {G}_1\) and \(\textbf{B}\in \mathbb {G}_2\).

In order to optimize the aggregation construction, we design a new protocol \(\mathsf {MT\text {-}IPP}\) that “fuses” together proofs for MIPP and TIPP relations. The formal relations \(\mathcal {R}_\textsf{mipp}\) and \(\mathcal {R}_\textsf{tipp}\) are stated in Appendix D.1.

We recall the two inner product maps for bilinear group \(\textsf{gk}= (p, \mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_T, e)\) and the combined relation for \(\mathsf {MT\text {-}IPP}\):

  1. 1.

    Multiexponentiation inner product map \(\mathbb {G}_1^n \times \mathbb {F}^n \rightarrow \mathbb {G}_1\): \( \textbf{C}*{\textbf{r}} = \prod C_i^{r_i}\)

  2. 2.

    Target inner pairing product map \(\mathbb {G}_1^n \times \mathbb {G}_2^n \rightarrow \mathbb {G}_T\): \(\textbf{A}* \textbf{B}{:}{=}\prod e(A_i, B_i) \)

  3. 3.

    Relation for both MIPP and TIPP:

$$ \mathcal {R}_{\textsf{mt}} {:}{=}\left\{ \begin{array}{c} \big ( (T_{AB}, U_{AB}), (T_{C}, U_{C}), \\ ~ \qquad ~ \ ~ Z_{AB}, Z_C, r; \textbf{A}, \textbf{B}, \textbf{C}\big ) \end{array} \, : \, \begin{array}{c} (\textsf{CM}_s(\textbf{C}), Z_C, r; \textbf{C}) \in \mathcal {R}_{\textsf{mipp}} \\ \wedge \\ (\textsf{CM}_d(\textbf{A}, \textbf{B}), Z_{AB}, r; \textbf{A}, \textbf{B}) \in \mathcal {R}_{\textsf{tipp}} \end{array} \right\} $$

Construction. Our \(\mathsf {MT\text {-}IPP}\) makes black-box use of the two Pair Group Commitments schemes \(\textsf{CM}_s=({\textsf{KG}}_s,\textsf{CM}_s)\) and \(\textsf{CM}_d=({\textsf{KG}}_d,\textsf{CM}_d)\) from Sect. 3 and KZG Polynomial Commitment \(\textsf{KZG}.\textsf{PC}= (\textsf{KZG}.{\textsf{KG}},\textsf{KZG}.\textsf{CM},\textsf{KZG}.\textsf{Open},\textsf{KZG}.\textsf{Check})\) from Appendix A.4.

The scheme consists of 3 algorithms: \(\mathsf {MT\text {-}IPP}= (\textsf{MT}.\textsf{Setup}, \textsf{MT}.\textsf{Prove}, \textsf{MT}.\textsf{Verify})\):

  • \(\textsf{MT}.\textsf{Setup}(1^\lambda , \mathcal {R}_\textsf{mt})\rightarrow \textsf{crs}_\textsf{mt}\):

    1. 1.

      Run: \(\textsf{ck}_s{:}{=}(\textbf{v}_1, \textbf{v}_2) \leftarrow \textsf{CM}_s(1^\lambda ), ~\textsf{ck}_d{:}{=}(\textbf{v}_1, \textbf{v}_2, \textbf{w}_1, \textbf{w}_2) \leftarrow \textsf{CM}_d(1^\lambda )\).

    2. 2.

      Set commitment keys for \(\textsf{KZG}.\textsf{PC}\) scheme:

      $$\begin{aligned} \textsf{ck}_{1v}&{:}{=}\{h^{a^i}\}_{i=0}^{n-1}, ~\textsf{vk}_{1v} {:}{=}g^{a} \quad \quad \textsf{ck}_{1w} {:}{=}\{g^{a^i}\}_{i=0}^{2n-1}, ~\textsf{vk}_{1w} {:}{=}h^{a}\\ \textsf{ck}_{2v}&{:}{=}\{h^{b^i}\}_{i=0}^{n-1}, ~\textsf{vk}_{2v} {:}{=}g^{b} \quad \quad ~\textsf{ck}_{2w} {:}{=}\{g^{b^i}\}_{i=0}^{2n-1}, ~\textsf{vk}_{2w} {:}{=}h^{b} \end{aligned}$$
    3. 3.

      Define \(\textsf{ck}_{\textsf{kzg}} {:}{=}(\textsf{ck}_{j\sigma }), ~\textsf{vk}_{\textsf{kzg}}{:}{=}(\textsf{vk}_{j\sigma })\) for \(j=1,2; ~ \sigma =v, w\).

    4. 4.

      Fix \(\textsf{Hash}_{com}\): \(\mathbb {G}_T^{4} \rightarrow \mathbb {Z}_p\) and its description \(\textsf{hk}_{com}\).

    5. 5.

      Fix \(\textsf{Hash}_{x_0}\): \( \mathbb {Z}_p^2 \times \mathbb {G}_T \times \mathbb {G}_1 \rightarrow \mathbb {Z}_p\) and its description \(\textsf{hk}_{x_0}\).

    6. 6.

      Fix \(\textsf{Hash}: \mathbb {Z}_p \times \mathbb {G}_T^{12} \rightarrow \mathbb {Z}_p\) and its description \(\textsf{hk}\).

    7. 7.

      Fix \(\textsf{Hash}_z: \mathbb {Z}_p \times \mathbb {G}_2^2 \times \mathbb {G}_1^2 \rightarrow \mathbb {Z}_p\) and its description \(\textsf{hk}_z\).

    8. 8.

      Set \(\textsf{crs}_\textsf{mt}{:}{=}(\textsf{hk}_{com}, \textsf{hk}_{x_0}, \textsf{hk}, \textsf{hk}_z,\textsf{ck}_s, \textsf{ck}_d, \textsf{ck}_\textsf{kzg}, \textsf{vk}_\textsf{kzg})\).

  • \(\textsf{MT}.\textsf{Prove}(\textsf{crs}_\textsf{mt}, (T_{AB}, U_{AB}),(T_{C}, U_{C}), Z_{AB}, Z_C, r; \textbf{A}, \textbf{B}, \textbf{C})\rightarrow \pi _\textsf{mt}\):

    • Loop “split & collapse” for step i

      1. 1.

        \(n'=n_{i-1}/2\) where \(n_0=n=2^\ell \)

      2. 2.

        If \(n' < 1\): break

      3. 3.

        Set \(\textbf{B}' {:}{=}\textbf{B}^{\textbf{r}}, \textbf{w}'_1 {:}{=}\textbf{w}_1^{\textbf{r}^{-1}}, \textbf{w}'_2 {:}{=}\textbf{w}_2^{\textbf{r}^{-1}}\).

      4. 4.

        Compute L/R inner products:

        $$(Z_L)_{AB} = \textbf{A}_{[n':]} * \textbf{B}'_{[:n']} ~\text { and } ~(Z_R)_{AB} = \textbf{A}_{[:n']} * \textbf{B}'_{[n':]}$$
        $$ (Z_L)_C = \textbf{C}_{[n':]}^{\textbf{r}_{[:n']}}~\text { and } ~ (Z_R)_C = \textbf{C}_{[:n']}^{\textbf{r}_{[n':]}} $$
      5. 5.

        Compute left cross commitments:

        $$\begin{aligned} (T_{L},U_{L})_{AB}&= \textsf{CM}_d((\textbf{v}_1,\textbf{w}_1';\textbf{v}_2,\textbf{w}_2'); \textbf{A}_{[n':]} || \textbf{0},\textbf{0}||\textbf{B}'_{[:n']})) \\ (T_{L},U_{L})_C&= \textsf{CM}_s((\textbf{v}_1,\textbf{v}_2), \textbf{C}_{[n':]} || \textbf{0}) \\ \end{aligned}$$
      6. 6.

        Compute right cross commitments:

        $$\begin{aligned} (T_{R}, U_{R})_{AB}&= \textsf{CM}_d((\textbf{v}_1,\textbf{w}_1';\textbf{v}_2, \textbf{w}_2');\textbf{0}||\textbf{A}_{[:n']},\textbf{B}'_{[n':]}||\textbf{0}) \\ (T_{R}, U_{R})_C&= \textsf{CM}_s((\mathbf {v_1},\mathbf {v_2}),\textbf{0}||\textbf{C}_{[:n']}) \\ \end{aligned}$$
      7. 7.

        Compute hash to the vector commitments

        $$h_{com} = \textsf{Hash}_{com}((T_{AB}, U_{AB}),(T_C, U_C)).$$
      8. 8.

        Compute challenge \(x_i\): \(x_0 = \textsf{Hash}_{x_0}(r, h_{com}, Z_{AB},Z_C).\)

        $$\begin{aligned} x_i = \textsf{Hash}\left( x_{i-1};(Z_{L}, Z_{R})_{AB}, (Z_{L}, Z_{R})_{C}, (T_L,U_L; T_R, U_R)_{AB},\right. \\ \left. (T_L,U_L; T_R, U_R)_{C}\right) \end{aligned}$$
      9. 9.

        Compute Hadamard products on vectors

        $$\textbf{A} {:}{=}\textbf{A}_{[:n']} \circ \textbf{A}_{[n':]}^{x_i}, ~ \textbf{B}' {:}{=}{\textbf{B}'}_{[:n']} \circ {\textbf{B}'}_{[n':]}^{x_i^{-1}}, ~ \textbf{C}{:}{=}\textbf{C}_{[:n']} \circ \textbf{C}_{[n':]}^{x_i} $$
      10. 10.

        Compute Hadamard products on keys \(\textbf{v}_1, \textbf{v}_2\) and \(\textbf{w}'_1, \textbf{w}'_2\):

        $$\begin{aligned} (\mathbf {v_1},\mathbf {v_2})&{:}{=}(\mathbf {v_1}_{[:n']} \circ \mathbf {v_1}_{[n':]}^{x^{-1}}, \mathbf {v_2}_{[:n']} \circ \mathbf {v_2}_{[n':]}^{x^{-1}}) \nonumber \\ (\textbf{w}_1',\textbf{w}_2')&{:}{=}(\textbf{w}'_{{1}_{[:n']}} \circ \textbf{w}_{{1}_{[n':]}}^{_{'}x},\textbf{w}'_{{2}_{[:n']}} \circ \textbf{w}_{{2}_{[n':]}}^{_{'}x}) \nonumber \end{aligned}$$
      11. 11.

        Set \(n_i = n'\)

    • Compute proofs \((\pi _{v_j},\pi _{w_j})_{j=1,2}\) of correctness of final commitment keys \((v_1,v_2) \in \mathbb {G}_2^2; ~(w_1',w_2')\in \mathbb {G}_1^2\) (This step is detailed in Appendix E):

      1. 1.

        Define \(f_{v}(X) = \prod _{j=0}^{\ell -1} (1 + x_{\ell -j}^{-1} X^{2^{j}})\) and \(f_w(X) = X^n \prod _{j=0}^{\ell -1} \big (1 + x_{\ell -j} r^{-2^j}X^{2^j}\big )\)

      2. 2.

        Draw challenge \(z = \textsf{Hash}_z(x_\ell ,v_1,v_2,w_1,w_2)\)

      3. 3.

        Prove that \(v_1 = g^{f_{v}(a)}, ~v_2 = h^{f_{v}(a)}\), \(w_1 = g^{f_w(a)}, ~w_2 = h^{f_{w}(b)}\) are \(\textsf{KZG}\) commitments of \(f_v(X)\) by opening evaluations in z

        $$\begin{aligned} \pi _{v_j}&\leftarrow \textsf{KZG}.\textsf{Open}(\textsf{ck}_{jv}; v_j, z,f_v(z); f_v(X)) \text { for j=1,2} \\ \pi _{w_j}&\leftarrow \textsf{KZG}.\textsf{Open}(\textsf{ck}_{jw}; w_j, z, f_w(z); f_w(X)) \text { for j=1,2} \end{aligned}$$
    • Given the final elements \(A, B', C\) and \((v_1,v_2),(w_1',w_2')\) at the end of the loop after split & collapsing \(\textbf{A}, \textbf{B}'=\textbf{B}^{\textbf{r}}, \textbf{C}\) and \(\textbf{v}_1, \textbf{v}_2, \textbf{w}_1', \textbf{w}_2'\), set

      $$\begin{aligned} \pi _\textsf{mt}= \big (A,B',C, (\mathbf {Z_L},\mathbf {Z_R})_{AB}, (\mathbf {Z_L},\mathbf {Z_R})_{C}, (\mathbf {T_L},\mathbf {U_L})_{AB},(\mathbf {T_R},\mathbf {U_R})_{AB}, \\ (\mathbf {T_L},\mathbf {U_L})_{C},(\mathbf {T_R},\mathbf {U_R})_{C}, (v_1,v_2),(w_1',w_2'),(\pi _{v_j},\pi _{w_j})_{j=1,2}\big ) \end{aligned}$$
  • \(\textsf{MT}.\textsf{Verify}(\textsf{crs}_\textsf{mt}, \textsf{statement}; \pi _\textsf{mt})\rightarrow b\):

    1. 1.

      Parse \(\textsf{statement}= ((T_{AB}, U_{AB}),(T_{C}, U_{C}), Z_{AB}, Z_C, r)\)

    2. 2.

      Compute hash to the commitments

      $$h_{com} = \textsf{Hash}_{com}((T_{AB}, U_{AB}),(T_C, U_C))$$
    3. 3.

      Reconstruct challenges \(\{x_i\}_{i=1}^\ell \): \(\quad x_0 = \textsf{Hash}_{x_0}(r, h_{com}, Z_{AB},Z_C)\)

      $$\begin{aligned}{} & {} x_i =\textsf{Hash}\big (x_{i-1},(\mathbf {Z_L}[i],\mathbf {Z_R}[i])_{AB}, (\mathbf {Z_L}[i],\mathbf {Z_R}[i])_{C}, \\{} & {} \qquad \quad (\mathbf {T_L}[i],\mathbf {T_R}[i], \mathbf {U_L}[i],\mathbf {U_R}[i])_{AB}, (\mathbf {T_L}[i],\mathbf {T_R}[i], \mathbf {U_L}[i],\mathbf {U_R}[i])_{C}\big ) \end{aligned}$$
    4. 4.

      Construct products and commitments recursively, \(i=1 \rightarrow \ell \):

      • \((Z_i)_{AB} = \mathbf {Z_L}[i]_{AB}^{x_i}\cdot (Z_{i-1})_{AB}\cdot \mathbf {Z_R}[i]_{AB}^{x_i^{-1}}\)

      • \((T_i)_{AB} = \mathbf {T_L}[i]_{AB}^{x_i}\cdot (T_{i-1})_{AB}\cdot \mathbf {T_R}[i]_{AB}^{x_i^{-1}}\)

      • \((U_i)_{AB} = \mathbf {U_L}[i]_{AB}^{x_i}\cdot (U_{i-1})_{AB}\cdot \mathbf {U_R}[i]_{AB}^{x_i^{-1}}\)

      where \((Z_0)_{AB}= Z_{AB}, (T_0)_{AB}= T_{AB}, (U_0)_{AB}= U_{AB}\)

      • \((Z_i)_{C} =\mathbf {Z_L}[i]_C^{x_i} \cdot (Z_{i-1})_C \cdot \mathbf {Z_R}[i]_C^{x_i^{-1}}\)

      • \((T_{i})_C = \mathbf {T_L}[i]_C^{x_i} \cdot (T_{i-1})_C \cdot \mathbf {T_R}[i]_C^{x_i^{-1}},\)

      • \((U_i)_C = \mathbf {U_L}[i]_C^{x_i} \cdot (U_{i-1})_C \cdot \mathbf {U_R}[i]_C^{x_i^{-1}}\)

      where \((Z_0)_{C}= Z_{C}, (T_0)_{C}= T_{C}, (U_0)_{C}= U_{C}\)

    5. 5.

      Compute final vector value from r: \( r' = \prod _{i=0}^{\ell -1}(1+ x_{\ell -i}^{-1}r^{2^i}) \)

    6. 6.

      Verify final values \((T_{\ell }, U_{\ell }, Z_{\ell })_{AB}, (T_{\ell }, U_{\ell }, Z_{\ell })_C\):

      1. (a)

        \((Z_{\ell })_{AB} {\mathop {=}\limits ^{?}} e(A,B')\)

      2. (b)

        \((Z_{\ell })_C {\mathop {=}\limits ^{?}} C^{r'}\)

      3. (c)

        Check if \( (T_{\ell })_{AB} {\mathop {=}\limits ^{?}} e(A, v_1)e(w_1',B') \) and \((U_{\ell })_{AB} {\mathop {=}\limits ^{?}}e(A, v_2)e(w_2',B') \)

      4. (d)

        Check if \((T_{\ell })_C {\mathop {=}\limits ^{?}} e(C,v_1) \text { and } (U_{\ell })_C {\mathop {=}\limits ^{?}} e(C,v_2)\)

    7. 7.

      Verify final commitment keys \(v_1, v_2, w_1', w_2'\) as detailed in Appendix E

      1. (a)

        Reconstruct KZG challenge point: \(z = \textsf{Hash}_z(A, B', C,x_\ell ,v_1,v_2,w_1',w_2')\)

      2. (b)

        Reconstruct commitment polynomials: \( f_{v}(X) = \prod _{j=0}^{\ell -1} \left( 1 +\right. \) \(\left. x^{-1}_{\ell -j}X^{2^{j}}\right) , f_w(X) = X^n\prod _{j=0}^{\ell -1} \left( 1 + x_{\ell -j} r^{-2^j}X^{2^j}\right) \)

      3. (c)

        Run verification for openings of evaluations in z for \(j=1,2\):

      $$\begin{aligned} b_{1j}&\leftarrow \textsf{KZG}.\textsf{Check}(\textsf{vk}_{jv}; v_j, z,f_v(z); \pi _{v_j} ), \\ b_{2j}&\leftarrow \textsf{KZG}.\textsf{Check}(\textsf{vk}_{jw}; w_j, z, f_w(z); \pi _{w_j} ) \end{aligned}$$

Theorem 3

If \(\textsf{CM}_s, \textsf{CM}_d\) are computationally binding commitments as per Definition 4, the hash functions are modelled as random oracles, and \(\textsf{KZG}.\textsf{PC}\) has computational knowledge binding as per Definition 6, then the protocol \(\mathsf {MT\text {-}IPP}\) has completeness and computational knowledge soundness (Definition 1) against algebraic adversaries in the random oracle model.

Proof

An adversary breaking soundness of the \(\mathsf {MT\text {-}IPP}\) scheme, either convinces the verifier of incorrect final keys \(v_1, v_2, w'_1, w'_2\) or breaks computational binding of one of \(\textsf{CM}_s, \textsf{CM}_d\).

Since both \(\textsf{CM}_s, \textsf{CM}_d\) are computationally binding, what is left to show is the completeness and soundness of the proof of correctness of the final commitment keys. The validity of the final commitment keys is shown using the \(\textsf{KZG}.\textsf{PC}\) scheme. The complete analysis for this step follows in Appendix E.

5 \(\textsf{SnarkPack}\): Aggregation Scheme

In this section we describe \(\textsf{SnarkPack}\), our new efficient protocol for Groth16 aggregation. The relation proven by \(\textsf{SnarkPack}\) can be stated as follows:

Relation for Aggregation. More formally, we introduce the relation for aggregating n Groth16 proof vectors \(\textbf{A},\textbf{C} \in \mathbb {G}_1^n,\textbf{B} \in \mathbb {G}_2^n\) with respect to a fixed verification key \(\textsf{vk}\):

$$ \mathcal {R}_{\textsf{AGG}} {:}{=}\left\{ (\textbf{u}=\{\textbf{a}_i\}_{i=0}^{n-1}; \mathbf {\pi }= \{(\textbf{A}, \textbf{B}, \textbf{C})\} ) : \textsf{Verify}(\textsf{vk}, u_i, \pi _i)=1, ~\forall i \right\} $$

where \(u_i= \textbf{a}_i= \{a_{i,j}\}_{j=0}^{t}, \pi _i = (A_i, B_i, C_i) \in \mathbb {G}_1 \times \mathbb {G}_2 \times \mathbb {G}_1\) for \(i=0, \dots n-1\).

The resulting argument for aggregation consists in 3 algorithms \(\textsf{SnarkPack}= (\textsf{SP}.\textsf{Setup},\textsf{SP}.\textsf{Prove},\textsf{SP}.\textsf{Verify})\) that work as follows:

  • \(\textsf{SP}.\textsf{Setup}(1^\lambda , \mathcal {R}_\textsf{AGG})\rightarrow (\textsf{crs}_{\textsf{agg}}, \textsf{vk}_{\textsf{agg}})\)

    1. 1.

      Generate commitment key for \(\textsf{CM}_d\):

      $$\textsf{ck}_{d} = (\textbf{v}_1, \textbf{v}_2, \textbf{w}_1, \textbf{w}_2) \leftarrow \textsf{CM}_d.\textsf{KG}(1^\lambda )$$
    2. 2.

      Set commitment key for \(\textsf{CM}_s: \textsf{ck}_{s} = (\textbf{v}_1, \textbf{v}_2) \)

    3. 3.

      Call \(\textsf{crs}_\textsf{mt}\leftarrow \textsf{MT}.\textsf{Setup}(1^\lambda , \mathcal {R}_\textsf{mt})\)

    4. 4.

      Fix hash function \(\textsf{Hash}_r: \mathbb {Z}_p^{t \cdot n} \times \mathbb {G}_T^4 \rightarrow \mathbb {Z}_p\) given by its description \(\textsf{hk}_r\)

    5. 5.

      Set aggregation public parameters: \( ~\textsf{crs}_{\textsf{agg}}= (\textsf{vk}, \textsf{crs}_\textsf{mt}, \textsf{hk}_r) \)

  • \(\textsf{SP}.\textsf{Prove}(\textsf{crs}_{\textsf{agg}}, \textbf{u}, \mathbf {\pi }= (\textbf{A}, \textbf{B}, \textbf{C})) \rightarrow \pi _{\textsf{agg}}\)

    1. 1.

      Parse proving key \(\textsf{crs}_{\textsf{agg}}{:}{=}(\textsf{vk}, \textsf{crs}_\textsf{mt}, \textsf{ck}_{s}, \textsf{ck}_{d}, \textsf{hk})\)

    2. 2.

      Parse \(\textsf{ck}_{s} = (\textbf{v}_1, \textbf{v}_2), ~\textsf{ck}_{d} = (\textbf{v}_1, \textbf{v}_2, \textbf{w}_1, \textbf{w}_2)\)

    3. 3.

      Commit to \(\textbf{A}\) and \(\textbf{B}\):

      $$\textsf{CM}_d((\mathbf {v_1},\mathbf {v_2},\mathbf {w_1},\mathbf {w_2});\textbf{A},\textbf{B}) = (T_{AB},U_{AB})$$
    4. 4.

      Commit to \(\textbf{C}:~\textsf{CM}_s((\mathbf {v_1},\mathbf {v_2});\textbf{C}) = (T_{C},U_{C})\)

    5. 5.

      Hash these commitments \(h_{com} = \textsf{Hash}_{com}((T_{AB}, U_{AB}),(T_C, U_C))\)

    6. 6.

      Derive random challenge \(r = \textsf{Hash}_r(\textbf{u},h_{com})\) and set \(\textbf{r} = \{r^i\}_{i=0}^{n-1}\)

    7. 7.

      Compute \(Z_{AB} = \mathbf {A^r} * \textbf{B}\)

    8. 8.

      Compute \(Z_{C} = \textbf{C}^\textbf{r}= \prod _{i=0}^{n-1} C_i^{r_i}\).

    9. 9.

      Run \(\textsf{MT}\) proof for inner products \(Z_{AB}, Z_C,r\):

      $$\begin{aligned} \pi _{\textsf{mt}} = \textsf{MT}.\textsf{Prove}(\textsf{crs}_\textsf{mt}, (T_{AB},U_{AB}), (T_C,U_C), Z_{AB}, Z_C,r; \textbf{A},\textbf{B},\textbf{C},\textbf{r}) \end{aligned}$$
    10. 10.

      Set \(\pi _{\textsf{agg}}= ((T_{AB}, U_{AB}), (T_C, U_C), Z_{AB},Z_C, \pi _{\textsf{mt}})\)

  • \(\textsf{SP}.\textsf{Verify}(\textsf{vk}_{\textsf{agg}}, \textbf{u}, \pi _{\textsf{agg}}) \rightarrow b\)

    1. 1.

      Parse SNARK instances \(\textbf{u}= \{a_{i,j}\}_{i=0,\dots n-1; j=0,\dots t}\)

    2. 2.

      Parse verification key \(\textsf{vk}_{\textsf{agg}}{:}{=}(\textsf{vk}, \textsf{crs}_\textsf{mt}, \textsf{hk})\)

    3. 3.

      Hash the commitments \(h_{com} = \textsf{Hash}_{com}((T_{AB}, U_{AB}),(T_C, U_C))\)

    4. 4.

      Parse \(\textsf{vk}{:}{=}\big (P = g^\alpha , Q= h^\beta , ~\{S_j \}_{j =0}^{t}, H = h^\gamma , D = h^\delta \big )\)

    5. 5.

      Derive random challenge \(r = \textsf{Hash}_r(\textbf{u}, h_{com})\)

    6. 6.

      Set \(\textsf{statement}= (\textbf{u},(T_{AB}, U_{AB}),(T_{C}, U_{C}), Z_{AB}, Z_C, r)\)

    7. 7.

      Check \(\textsf{MT}\) proof \(~b_1 \leftarrow \textsf{MT}.\textsf{Verify}(\textsf{crs}_\textsf{mt}, \textsf{statement},\pi _{\textsf{mt}})\)

    8. 8.

      Compute \(Z_{S_j}= S_j^{\sum _{i=0}^{n-1} a_{ij}r^i}\) for all \(j=0 \dots t\)

    9. 9.

      Check Groth16 final equation to the decision bit \(b_2\):

      $$ Z_{AB} {\mathop {=}\limits ^{?}} e(P^{\sum _{i=0}^{n-1} r^i},Q)e(\prod _{j=0}^{t} Z_{S_j},H)e(Z_C,D) $$
    10. 10.

      Set decision bit \(b=b_1 \wedge b_2 \)

Assumptions. We introduce two new assumptions necessary to prove our schemes are secure. Formal proofs that these assumptions hold in the Generic Group Model can be found in Appendix B.1.

Assumption 4

(ASSGP). The (qm)-Auxiliary Structured Single Group Pairing assumption holds for the bilinear group generator \(\mathcal {G}\) if for all \(~\textsf{PPT}\) adversaries \(\mathcal {A}\) we have, on the probability space \(~\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T ) \leftarrow \mathcal {G}(1^\lambda )\), and the following probability is negligible in \(\lambda \):

figure l

Assumption 5

(ASDGP). The (qm)-ASDGP assumption holds for the bilinear group generator \(~\mathcal {G}\) if for all \(~\textsf{PPT}\) adversaries \(\mathcal {A}\) we have, on the probability space \(~\textsf{gk}=(p,\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T ) \leftarrow \mathcal {G}(1^\lambda )\), and the following probability is negligible in \(\lambda \):

figure o

We can similarly define the dual assumptions, by swapping \(\mathbb {G}_1\) and \(\mathbb {G}_2\) in the definition above.