At Parasol, we’re building the trading engine for high-performance perpetuals on Solana. Execution happens inside the engine, and gets verified on-chain through ZK proofs, which puts hard constraints on what those proofs can look like: Solana's transaction-size and compute limits make verifying large STARK proofs directly on-chain impractical.

ZK proof systems often trade off proving efficiency against verification cost. STARK-style systems based on FRI are transparent and prover-friendly, but their proofs are relatively large. Groth16 sits at the opposite end:  tiny proofs, fast verification, but a circuit-specific trusted setup.

One way to get the best of both: use Groth16 as a recursive wrapper. Verify the STARK proof inside a Groth16 circuit, and the output is a compact Groth16 proof attesting to the STARK's validity. On-chain verification becomes cheap — at the cost of inheriting Groth16's trusted-setup requirement.

This blog walks through how the Groth16 algorithm works under the hood, drawing on RareSkills' Groth16 explainer, with a view to whether this approach makes sense for execution at scale on Solana.

‍

‍

The trusted setup

Throughout this article, for any $[x]_1 \in \mathbb{G}_1$ and $[x]_2 \in \mathbb{G}_2$ pairing between $[x]_1$ and $[x]_2$ is denoted as $[x]_1 \bullet [x]_2 \in \mathbb{G}_{12}$.

Before any Groth16 proof can be made, the system needs a one-time setup phase. This is where the "trusted" part of "trusted setup" comes from.

‍

SRS generation ceremony

A Structured Reference String (SRS) generation ceremony — often called a "powers of tau" ceremony — is a multi-party computation protocol that produces the public parameters Groth16 needs before any proofs can be generated.

Multiple independent participants each contribute a secret random value, which is then discarded, resulting in an SRS that encodes powers of a hidden point τ on the elliptic curve. The setup is secure as long as at least one participant honestly destroys their contribution, making large public ceremonies a practical way to establish trust. Note that the ceremony is circuit-specific, meaning a new SRS must be generated whenever the circuit changes.

Let the structured reference strings be computed as follows:

$$\begin{align*} [\Omega_{n-1}, \Omega_{n-2},\dots,\Omega_2,\Omega_1,G_1] &= [\tau^nG_1,\tau^{n-1}G_1,\dots,\tau G_1,G_1] && \text{srs for } G_1 \\ [\Theta_{n-1}, \Theta_{n-2},\dots,\Theta_2,\Theta_1,G_2] &= [\tau^nG_2,\tau^{n-1}G_2,\dots,\tau G_2,G_2] && \text{srs for } G_2\\ [\Upsilon_{n-2},\Upsilon_{n-3},\dots,\Upsilon_1,\Upsilon_0]&=[\tau^{n-2}t(\tau)G_1,\tau^{n-3}t(\tau)G_1,\dots,\tau t(\tau)G_1,t(\tau)G_1] && \text{srs for }h(\tau)t(\tau)\\ \end{align*}$$

Having the SRS $[\tau^d G_1, \ldots, \tau^2 G_1, \tau G_1, G_1]$, anyone can compute the value of any polynomial f at a random secret point τ: f(τ):

$$f(\tau) = \sum_{i=1}^d f_i\Omega_i=\langle[f_d, f_{d-1},...,f_1,f_0],[\Omega_d,\Omega_{d-1},...,G_1]\rangle$$

or for $\mathbb{G}_2$ srs:

$$f(\tau) = \sum_{i=1}^d f_i\Theta_i=\langle[f_d, f_{d-1},...,f_1,f_0],[\Theta_d,\Theta_{d-1},...,G_2]\rangle$$

f(τ) is shorthand for the above expression, and produces an elliptic curve point. Even though the Prover can compute the value of any polynomial at the point τ, the value of τ stays secret.

‍

Converting an R1CS circuit to a QAP

Groth16 doesn't work directly on circuits — it works on a polynomial form of them. This section walks through that translation.

An R1CS circuit is represented by 3 matrices, L, R and O, such that for a witness vector ‘a’:

$$\mathbf{L}\mathbf{a}\circ \mathbf{R}\mathbf{a} = \mathbf{O}\mathbf{a}$$

Usually, ZK circuits are written in a form that can be represented as R1CS, while Groth16 works over a Quadratic Arithmetic Program (QAP). We can convert the R1CS to Quadratic Arithmetic Program (QAP) by interpolating the columns of the matrices as $y$ values over the $x$ values $[1,2,…,n]$.

Since $\mathbf{L}$, $\mathbf{R}$, and $\mathbf{O}$ have $m$ columns, we will end up with three sets of $m$ polynomials:

$$\begin{array}{} u_1(x),...,u_m(x) & m \text{ polynomials interpolated on the }m \text{ columns of } \mathbf{L}\\ v_1(x),...,v_m(x)& m \text{ polynomials interpolated on the }m \text{ columns of } \mathbf{R}\\ w_1(x),...,w_m(x)& m \text{ polynomials interpolated on the }m \text{ columns of } \mathbf{O}\\ \end{array}$$

From this, we can construct a Quadratic Arithmetic Program (QAP):

$$\sum_{i=1}^m a_iu_i(x)\sum_{i=1}^m a_iv_i(x) = \sum_{i=1}^m a_iw_i(x) + h(x)t(x)$$

where $t(x) = (x-1)(x-2)\dots(x-n)$ and

$$h(x) = \frac{\sum_{i=1}^m a_iu_i(x)\sum_{i=1}^m a_iv_i(x) - \sum_{i=1}^m a_iw_i(x)}{t(x)}$$

The prover can evaluate sum terms (the $\sum a_if_i(x)$ terms) in the QAP at a hidden point $\tau$ using the SRS.

The prover can evaluate their QAP on the trusted setup by computing:

$$\begin{align*}
[A]_1 &= \sum_{i=1}^m a_iu_i(\tau)\\
[B]_2 &= \sum_{i=1}^m a_iv_i(\tau)\\
[C]_1 &= \sum_{i=1}^m a_iw_i(\tau) + h(\tau)t(\tau)
\end{align*}$$

If the QAP is balanced, then the following equation holds:

$$[A]_1\bullet[B]_2 \stackrel{?}= [C]_1\bullet G_2$$

‍

The forgery problem

Simply submitting the triple ($[A]_1, [B]_2, [C]_1$) to a verifier does not actually prove that the prover knows a valid witness ‘a’ satisfying the QAP. A dishonest prover could freely pick arbitrary scalars a, b, c with the property that $a \cdot b = c$, then construct the corresponding elliptic curve points $[A]_1 = aG_1$, $[B]_2 = bG_2$, and $[C]_1 = cG_1$, and hand these over to the verifier.

The core challenge, therefore, is to design a protocol that compels the prover to act honestly — i.e., to use actual witness values derived from the circuit — while keeping the verification procedure as lightweight and efficient as possible.

The verification equation as written so far isn't safe. A dishonest prover can fake it. The next two sections show how the scheme defends against that: first with α and β, then with γ and δ.

‍

Preventing forgery with α and β

‍

An “unsolvable” verification formula

The trusted setup generates two random scalars α and β and publishes the elliptic curve points ($[\alpha]_1$,$[\beta]_2$) computed as:

$$\begin{align*} [\alpha]_1 &= \alpha G_1 \\ [\beta]_2 &= \beta G_2 \end{align*}$$

Let’s denote $[D]_{12} = [\alpha]_1 \bullet [\beta]_2$.

Suppose we update our verification formula to the following:

$$[A]_1 \bullet [B]_2 \stackrel{?}{=} [D]_{12} + [C]_1 \bullet G_2$$

Since $[D]_{12}$ has an unknown discrete logarithm, the verifier cannot provide a solution ($[A]_1, [B]_2,[C]_1$) to this equation.

‍

Re-deriving the proving and verification formulas

To make the verification formula

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1\bullet[\beta]_2 + [C]_1\bullet G_2$$

"solvable", we need to alter our QAP formula to incorporate α and β.

$$\sum_{i=1}^m a_iu_i(x)\sum_{i=1}^m a_iv_i(x) = \sum_{i=1}^m a_iw_i(x) + h(x)t(x)$$

Let’s introduce terms θ and η to the left hand side of the equation:

$$\left(\boxed{\theta}+\sum_{i=1}^m a_iu_i(x)\right)\left(\boxed{\eta} +\sum_{i=1}^m a_iv_i(x)\right) =$$

$$=\boxed{\theta\eta} + \boxed{\theta}\sum_{i=1}^m a_iv_i(x) + \boxed{\eta}\sum_{i=1}^m a_iu_i(x) + \sum_{i=1}^m a_iu_i(x)\sum_{i=1}^m a_iv_i(x)$$

$$=\theta\eta + \theta\sum_{i=1}^m a_iv_i(x) + \eta\sum_{i=1}^m a_iu_i(x) + \boxed{\sum_{i=1}^m a_iu_i(x)\sum_{i=1}^m a_iv_i(x)}$$

$$=\theta\eta + \theta\sum_{i=1}^m a_iv_i(x) + \eta\sum_{i=1}^m a_iu_i(x) + \boxed{\sum_{i=1}^m a_iw_i(x) + h(x)t(x)}$$

Now we can introduce an “expanded” QAP with the following definition:

$$\left(\theta+\sum_{i=1}^m a_iu_i(x)\right)\left(\eta +\sum_{i=1}^m a_iv_i(x)\right) =\theta\eta + \theta\sum_{i=1}^m a_iv_i(x) + \eta\sum_{i=1}^m a_iu_i(x) + \sum_{i=1}^m a_iw_i(x) + h(x)t(x)$$

If we replace θ with $[\alpha]_1$ and η with $[\beta]_2$, we get the required verification formula:

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1 \bullet [\beta]_2 + [C]_1\bullet G_2$$

where

$$\underbrace{\left([\alpha]_1+\sum_{i=1}^m a_iu_i(\tau)\right)}_{[A]_1}\underbrace{\left([\beta]_2+\sum_{i=1}^m a_iv_i(\tau)\right)}_{[B]_2} \\ = [\alpha]_1\bullet[\beta]_2 + \underbrace{\left(\alpha\sum_{i=1}^m a_iv_i(\tau) + \beta\sum_{i=1}^m a_iu_i(\tau) + \sum_{i=1}^m a_iw_i(\tau) + h(\tau)t(\tau)\right)}_{[C]_1} \bullet G_2$$

The prover can compute $[A]_1$ and $[B]_2$ without knowing τ, α, or β. Given the SRS and ($[\alpha]_1$,$[\beta]_2$), the prover computes $[A]_1$ and $[B]_2$ as

$$\begin{align*}
[A]_1 &= [\alpha]_1 + \sum_{i=1}^m a_iu_i(\tau)\\
[B]_2 &= [\beta]_2 + \sum_{i=1}^m a_iv_i(\tau)\\
\end{align*}$$

Here, the values of $aᵢuᵢ(τ)$ are computed using the SRS $[τⁿ⁻¹G₁,τⁿ⁻²G₁,…,τG₁,G₁]$ and the $\mathbb{G}_2$ srs for $[B]_2$.

However, it isn’t currently possible to compute $[C]_1$ without knowing α and β. The prover cannot pair $[\alpha]_1$ with $\sum_i a_i u_i(\tau)$ and $[\beta]_2$ with $\sum_i a_i v_i(\tau)$ because that would create a $\mathbb{G}_{12}$ point, whereas the prover needs a $\mathbb{G}_1$ point for $[C]_1$.

Instead, the trusted setup needs to precompute m polynomials for the problematic C term of the expanded QAP.The trusted setup can create m polynomials evaluated at τ from the boxed term above, and the prover can use that to compute the sum. The exact details are shown in the next section.

$$\alpha\sum_{i=1}^m a_iv_i(\tau) + \beta\sum_{i=1}^m a_iu_i(\tau) + \sum_{i=1}^m a_iw_i(\tau) \\=\sum_{i=1}^m (\alpha a_iv_i(\tau)+\beta a_iu_i(\tau) + a_iw_i(\tau)) \\ =\sum_{i=1}^m a_i\boxed{(\alpha v_i(\tau)+\beta u_i(\tau) + w_i(\tau))}$$

‍

Summary of the algorithm so far

‍

Trusted setup steps

$$\begin{align*} \alpha,\beta,\tau &\leftarrow \text{random scalars}\\ [\tau^{n-1}G_1,\tau^{n-2}G_1,\dots,\tau G_1,G_1] &\leftarrow \text{srs for } \mathbb{G}_1\\ [\tau^{n-1}G_2,\tau^{n-2}G_2,\dots,\tau G_2,G_2] &\leftarrow \text{srs for } \mathbb{G}_2\\ [\tau^{n-2}t(\tau)G_1,\tau^{n-3}t(\tau)G_1,\dots,\tau t(\tau)G_1,t(\tau)G_1] &\leftarrow \text{srs for }h(\tau)t(\tau)\\ [\Psi_1]_1 &= (\alpha v_1(\tau) + \beta u_1(\tau) + w_1(\tau))G_1\\ [\Psi_2]_1 &= (\alpha v_2(\tau) + \beta u_2(\tau) + w_2(\tau))G_1\\ &\vdots\\ [\Psi_m]_1 &= (\alpha v_m(\tau) + \beta u_m(\tau) + w_m(\tau))G_1\\ \end{align*}$$

The trusted setup publishes $([\alpha]_1,\, [\beta]_2,\, \text{srs}_{\mathbb{G}_1},\, \text{srs}_{\mathbb{G}_2},\, \text{srs for } h(\tau)t(\tau),\, [\Psi_1]_1,\, [\Psi_2]_1,\, \dots,\, [\Psi_m]_1)$.

‍

Prover steps

The prover computes

$$\begin{align*}
[A]_1 &= [\alpha]_1 + \sum_{i=1}^m a_iu_i(\tau)\\
[B]_2 &= [\beta]_2 + \sum_{i=1}^m a_iv_i(\tau)\\
[C]_1 &= \sum_{i=1}^m a_i[\Psi_i]_1 + h(\tau)t(\tau)\\
\end{align*}$$

Note that we replaced the “problematic” polynomial

$$\sum_{i=1}^m a_i\boxed{(\alpha v_i(\tau)+\beta u_i(\tau) + w_i(\tau))}$$

(the one that contained α and β) with $\sum_i a_i[\Psi_i]_1$

‍

Verifier steps

The verifier computes:

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1 \bullet [\beta]_2 + [C]_1\bullet G_2$$

For Parasol, this is the part of the design space we're looking at most carefully: can the verification cost savings justify the trusted-setup overhead at the throughput perp markets demand?

‍

Supporting public inputs

The verification equation presented above has no mechanism for handling public inputs — that is, for exposing part of the witness to the verifier. By convention, the public portion of the witness consists of the first ℓ elements of the vector a. The prover makes these elements public simply by disclosing them directly:

$$[a_1, a_2, \dots, a_\ell]$$

In order for the verifier to confirm that those disclosed values were actually used in the proof, it must take over part of the computation that was previously handled entirely by the prover.Concretely, the prover computes:

$$\begin{align*}
[A]_1 &= [\alpha]_1 + \sum_{i=1}^m a_iu_i(\tau)\\
[B]_2 &= [\beta]_2 + \sum_{i=1}^m a_iv_i(\tau)\\
[C]_1 &= \sum_{i=\ell+1}^m a_i[\Psi_i]_1 + h(\tau)t(\tau)\\
\end{align*}$$

Note that only the computation of $[C]_1$ changed – the prover only uses the private portion of aᵢ and $\Psi_i$.

The verifier computes the first ℓ terms of the sum:

$$[X]_1 = \sum_{i=1}^\ell a_i\Psi_i$$

And the verification equation is:

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1 \bullet [\beta]_2 + [X]_1\bullet G_2 + [C]_1\bullet G_2$$

‍

Preventing forgery with γ or δ

The equation above implicitly assumes that the prover restricts itself to $\Psi_{\ell+1}$ to $\Psi_{m}$ when computing $[C]1$. However, there is nothing preventing a malicious prover from using $\Psi{1}$ to $\Psi_{l}$Ψℓ in that computation, which would allow it to construct a fraudulent proof.

To illustrate, consider the current verification equation:

$$[A]_1\bullet[B]_2 \stackrel{?}{=} [\alpha]_1 \bullet [\beta]_2 + \sum_{i=1}^\ell a_i\Psi_i + [C]_1\bullet G_2$$

If we expand the C term under the hood, we get the following:

$$[A]_1\bullet[B]_2 \stackrel{?}{=} [\alpha]_1 \bullet [\beta]_2 + \sum_{i=1}^\ell a_i\Psi_i + \underbrace{\left(\sum_{i=\ell+1}^m a_i[\Psi_i]_1 + h(\tau)t(\tau)\right)}_C \bullet G_2$$

Suppose for example and without loss of generality that a=[1,2,3,4,5] and ℓ=3. In that case, the public part of the witness is [1,2,3] and the private part is [4,5].

The final equation would be as follows:

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1 \bullet [\beta]_2 + (1\Psi_1+2\Psi_2+3\Psi_3)\bullet G2 + \underbrace{(4\Psi_4 + 5\Psi_5 + h(\tau)t(\tau))}_C \bullet G_2$$

However, the prover could still construct a valid public witness segment such as [1,2,0], while shifting the omitted public value into the private portion of the computation, as shown below:

$$[A]_1\bullet[B]_2 \stackrel{?}= [\alpha]_1 \bullet [\beta]_2 + (1\Psi_1+2\Psi_2+\boxed{0\Psi_3})\bullet G2 + \underbrace{(\boxed{3\Psi_3}+4\Psi_4 + 5\Psi_5 + h(\tau)t(\tau))}_C \bullet G_2$$

The equation above is valid, but the witness does not necessarily satisfy the original constraints. Therefore, we need to prevent the prover from using $\Psi_1$ to $\Psi_\ell$ as part of the computation of $[C]_1$.

‍

Introducing γ and/or δ

To address the vulnerability described earlier, the trusted setup adds new scalar values — γ or δ  — that ensure the terms $\Psi_{\ell+1}$ to $\Psi_{m}$ remain cryptographically distinct from $\Psi_1$ to $\Psi_\ell$. This is achieved by dividing (i.e., multiplying by the modular inverse) the private terms that make up $[C]_1$ by δ, and/or the public terms that make up $[X]_1$ — the sum computed by the verifier — by γ.

Because the h(τ)t(τ) component is part of $[C]_1$, it must also be divided by δ. As long as neither δ nor γ has a known discrete logarithm, the previously described forgery attack — along with other potential exploits — is effectively prevented.

$$\begin{align*}
\alpha,\beta,\tau,\gamma,\delta &\leftarrow \text{random scalars}\\
[\tau^{n-1}G_1,\tau^{n-2}G_1,\dots,\tau G_1,G_1] &\leftarrow \text{srs for } \mathbb{G}_1\\
[\tau^{n-1}G_2,\tau^{n-2}G_2,\dots,\tau G_2,G_2] &\leftarrow \text{srs for } \mathbb{G}_2\\
\left[\frac{\tau^{n-2}t(\tau)}{\delta}G_1,\frac{\tau^{n-3}t(\tau)}{\delta}G_1,\dots,\frac{\tau t(\tau)}{\delta}G_1,\frac{t(\tau)}{\delta}G_1\right] &\leftarrow \text{srs for }h(\tau)t(\tau)\\
\\
&\text{public portion of the witness}\\
[\Psi_1]_1 &= \frac{\alpha v_1(\tau) + \beta u_1(\tau) + w_1(\tau)}{\gamma}G_1\\
[\Psi_2]_1 &= \frac{\alpha v_2(\tau) + \beta u_2(\tau) + w_2(\tau)}{\gamma}G_1\\
&\vdots\\
[\Psi_\ell]_1 &= \frac{\alpha v_\ell(\tau) + \beta u_\ell(\tau) + w_\ell(\tau)}{\gamma}G_1\\
\\
&\text{private portion of the witness}\\
[\Psi_{\ell+1}]_1 &= \frac{\alpha v_{\ell+1}(\tau) + \beta u_{\ell+1}(\tau) + w_{\ell+1}(\tau)}{\delta}G_1\\
[\Psi_{\ell+2}]_1 &= \frac{\alpha v_{\ell+2}(\tau) + \beta u_{\ell+2}(\tau) + w_{\ell+2}(\tau)}{\delta}G_1\\
&\vdots\\
[\Psi_{m}]_1 &= \frac{\alpha v_{m}(\tau) + \beta u_{m}(\tau) + w_{m}(\tau)}{\delta}G_1\\
\end{align*}$$

The trusted setup publishes

$$[A]_1\bullet[B]_2 \stackrel{?}{=} [\alpha]_1 \bullet [\beta]_2 + \sum_{i=1}^\ell a_i\Psi_i + [C]_1\bullet G_2$$

The prover steps are the same as before:

$$[A]_1\bullet[B]_2 \stackrel{?}{=} [\alpha]_1 \bullet [\beta]_2 + \sum_{i=1}^\ell a_i\Psi_i + \underbrace{\left(\sum_{i=\ell+1}^m a_i[\Psi_i]_1 + h(\tau)t(\tau)\right)}_C \bullet G_2$$

And the verifier steps now include pairing by $[\gamma]_2$ and/or $[\delta]_2$ to cancel out the denominators:

$$\begin{align*}
\alpha,\beta,\tau,\gamma,\delta &\leftarrow \text{random scalars}\\
[\tau^{n-1}G_1,\tau^{n-2}G_1,\dots,\tau G_1,G_1] &\leftarrow \text{srs for } \mathbb{G}_1\\
[\tau^{n-1}G_2,\tau^{n-2}G_2,\dots,\tau G_2,G_2] &\leftarrow \text{srs for } \mathbb{G}_2\\
\left[\frac{\tau^{n-2}t(\tau)}{\delta}G_1,\frac{\tau^{n-3}t(\tau)}{\delta}G_1,\dots,\frac{\tau t(\tau)}{\delta}G_1,\frac{t(\tau)}{\delta}G_1\right] &\leftarrow \text{srs for }h(\tau)t(\tau)\\
\\
&\text{public portion of the witness}\\
[\Psi_1]_1 &= \frac{\alpha v_1(\tau) + \beta u_1(\tau) + w_1(\tau)}{\gamma}G_1\\
[\Psi_2]_1 &= \frac{\alpha v_2(\tau) + \beta u_2(\tau) + w_2(\tau)}{\gamma}G_1\\
&\vdots\\
[\Psi_\ell]_1 &= \frac{\alpha v_\ell(\tau) + \beta u_\ell(\tau) + w_\ell(\tau)}{\gamma}G_1\\
\\
&\text{private portion of the witness}\\
[\Psi_{\ell+1}]_1 &= \frac{\alpha v_{\ell+1}(\tau) + \beta u_{\ell+1}(\tau) + w_{\ell+1}(\tau)}{\delta}G_1\\
[\Psi_{\ell+2}]_1 &= \frac{\alpha v_{\ell+2}(\tau) + \beta u_{\ell+2}(\tau) + w_{\ell+2}(\tau)}{\delta}G_1\\
&\vdots\\
[\Psi_{m}]_1 &= \frac{\alpha v_{m}(\tau) + \beta u_{m}(\tau) + w_{m}(\tau)}{\delta}G_1\\
\end{align*}$$

‍

A note on zero knowledge

The current scheme does not achieve full zero knowledge. An attacker who can narrow down the possible witness vectors — for instance, in scenarios with a limited input space like secret voting from a fixed set of addresses — could confirm a guess by checking whether their reconstructed proof matches the original.

While Groth16 does support fully  ZK proofs, at this stage that property is not a requirement for our purposes. Our goal is succinctness.

‍

Final thoughts

Groth16's key strengths are its remarkably compact proof size (just three elliptic curve points) and fast, constant-time verification via a small number of pairings, making it attractive whenever on-chain verification cost is a bottleneck. Its main drawback is the requirement for a circuit-specific trusted setup: any change to the circuit necessitates a new SRS generation ceremony.

For Parasol, the appeal is concrete. Solana's transaction-size and compute limits make verifying large STARK proofs directly on-chain impractical. Wrapping the STARK in Groth16 collapses that problem: verification cost drops dramatically, and the proof fits comfortably in a Solana transaction.