# UPA protocol specification

## Overview

*Application developers* register Groth16 *verification keys* (VKs) for their circuits with the `UpaVerifier` contract (through the `IUpaProofReceiver` interface). Upon registration, each VK is assigned a $$\mathsf{circuitId}$$ (the keccak hash of the VK).

*Application Clients* submit proofs and public inputs (PIs) to the `UpaVerifier` contract as tuples$$(\pi, \mathsf{PI}, \mathsf{circuitId})$$, where $$\pi$$ is expected to be a (compressed) proof of knowledge that $$\mathsf{PI}$$ is an instance of the circuit with *circuit id* $$\mathsf{circuitId}$$.

A single call to the contract submits an *ordered list* $$(\pi\_i, \mathsf{PI}\_i, \mathsf{circuitId}*i)*{i=0}^{n-1}$$ (of any size $$n$$ up to some implementation-defined maximum $$N$$) of these tuples. This ordered list of tuples is referred to as a *Submission*. Submissions of more than 1 proof allow the client to amortize the cost of submitting proofs. Note that there is no requirement for the $$\mathsf{circuitId}\_i$$s to match. A single *Submission* may contain proofs for multiple application circuits.

Each tuple in a submission is assigned:

* $$\mathsf{proofId}$$ - a unique *proof id* (equal to the Keccak hash of the circuit ID and PIs)

Each submission is assigned:

* a *Submission Id* $$\mathsf{submissionId}$$, computed as the Merkle root of the list of $$\mathsf{proofId}\_i$$s, padded to the nearest power of 2 with `bytes32(0)`.
* a *submission index* $$\mathsf{submissionIndex}$$, a simple incrementing counter of submissions, used later for censorship resistance.

Note that:

* for submissions that consist of a single proof, $$\mathsf{submissionId} = \mathsf{keccak}(\mathsf{proofId\_0})$$, whereas
* for submissions of multiple proofs, each proof is referred to by $$\mathsf{submissionId}$$ along with an index (or *location*) of the proof within the submission. Where required, a Merkle proof can be used to show that a proof with $$\mathsf{proofId}\_i$$ is indeed at the given index within the submission $$\mathsf{submissionId}$$.

\
The proof and public inputs are not stored on-chain. The aggregator monitors for transactions submitting proofs to the contract and pulls this information from the transaction calldata. The contract stores information about the submission (including $$\mathsf{submissionIndex}$$, $$n$$ and some further metadata), indexed by the $$\mathsf{submissionId}$$.

There is a single *Aggregator* that puts together *batches* of proofs with *increasing* submission index values. The proofs in a batch must be ordered exactly as they appear within submissions. Aggregated batches do not need to align with submissions- a batch may contain multiple submissions, and a submission may span multiple batches. If a submission contains any invalid proofs, the entire submission is considered *invalid*. The aggregator may skip *only* invalid submissions. If the Aggregator skips a valid submission, it will be punished [(see Censorship Resistance)](#censorship-resistance).

Once a submission is verified by the UPA contract, its submission id is marked as verified. Applications can confirm that an individual proof id is verified by providing a `ProofReference`, which is a Merkle proof that the proof id was included in a verified submission. Note that for proofs in a multi-proof submission with $$\mathsf{submissionId}$$, the contract does not mark the proof as verified until the entire submission has been verified.

Once the UPA contract marks a proof (or the submission containing a proof) as verified, an application client can submit a transaction to the application contract (optionally with some `ProofReference` metadata), and the application contract can verify the existence of an associated ZKP as follows:

* The application computes the public inputs for the proof, exactly as it would in the absence of UPA.
* The application contract calls `isProofVerified` on the `UpaVerifier` contract, passing in the public inputs $$\mathsf{PI}$$, the circuit Id $$\mathsf{circuitId}$$, and a `ProofReference` (when required).
* The `UpaVerifier` contract computes $$\mathsf{proofId} = \mathsf{keccak}(\mathsf{circuitId}, \mathsf{PI})$$ from the public inputs and then checks that `ProofReference` contains a valid Merkle proof that $$\mathsf{proofId}$$ belongs to a verified submission.
* The `UpaVerifier` returns `true` if it has a record of a valid proof for $$(\mathsf{circuitId}, \mathsf{proofId})$$, and `false` otherwise.

Application contracts can also verify the existence of multiple ZKPs belonging to the same submission. In this case:

* Application contract computes an array of public inputs $$\[\mathsf{PI}\_i]$$ where the $$i$$-th entry corresponds to the $$i$$-th proof of a submission with $$\mathsf{submissionId}$$.
* Application contract submits an array of tuples $$\[(\mathsf{circuitId}\_i, \mathsf{PI}\_i)]$$ to the UPA contract.
* The UPA contract computes the (unique) $$\mathsf{submissionId}$$ corresponding to the submitted array of circuit ids and public inputs.
* The UPA contract returns 1 if it has verified the submission $$\mathsf{submissionId}$$ (i.e. it has verified all of the proofs within $$\mathsf{submissionId}$$), and 0 otherwise.

Note that in this case, there is no need to submit a `ProofReference`.

## Protocol

### Circuit registration

Before submitting proofs on-chain, the application developer submits a transaction calling the `registerVK` method to the UPA contract (through the `IUpaProofReceiver` interface), passing their verification key $$\mathsf{VK}$$.

The circuit's $$\mathsf{circuitId}$$ is computed as

$$
\mathsf{circuitId} = \mathsf{keccak}(\mathsf{DT}\_\mathsf{circuitId} || \mathsf{VK})
$$

where $$\mathsf{DT}\_\mathsf{circuitId}$$ denotes a domain tag derived from a string describing the context, such as `UPA Groth16 circuit id` (See the Universal Batch Verifier specification for details.)

$$\mathsf{VK}$$ is stored on the contract (for censorship resistance) in a mapping indexed by $$\mathsf{circuitId}$$, and the aggregator is notified via an event. This $$\mathsf{circuitId}$$ will be used to reference the circuit for future operations.

### Application proof submission

The a*pplication client* creates the parameters for its smart contract as normal, including one or more proofs $$\pi\_i$$ and public inputs $$\mathsf{PI}\_i$$. It then passes these, along with the relevant (pre-registered) circuit Ids $$\mathsf{circuitId}\_i$$, to the `submit` method on the `IUpaProofReceiver` interface, paying the aggregation fee in ether:

```solidity
interface IUpaProofReceiver
{
    ...
    function submit(
        uint256[] calldata circuitIds,
        Proof[] calldata proofs,
        uint256[][] calldata publicInputs
    ) external payable override returns (bytes32 submissionId)
    ...
}
```

The `UpaProofReceiver.submit` method:

* computes $$\mathsf{proofId}\_i = \mathsf{keccak}(\mathsf{circuitId}\_i, \mathsf{PI}\_i)$$ for $$i = 0, \ldots, n-1$$.
* computes a `proofDigest` $$\mathsf{proofDigest}$$ for each proof, as $$\mathsf{keccak}(\pi\_i)$$
* computes the submission Id $$\mathsf{submissionId}$$ as the Merkle root of the list $$(\mathsf{\mathsf{keccak}(proofId}*i))*{i=0}^{n-1}$$ (padded as required to the nearest power of 2)
* computes the `digestRoot` as the Merkle root of the list $$(\mathsf{proofDigest}*i)*{i=0}^{n-1}$$ (again padded as required to the nearest power of 2)
* rejects the tx if an entry for $$\mathsf{submissionId}$$ already exists
* assigns a $$\mathsf{submissionIndex}$$ to the submission (using a single incrementing counter)
* assigns a $$\mathsf{proofIndex}\_i$$ to each $$(\pi\_i, \mathsf{PI}\_i)$$ (using a single incrementing counter)
* emits an event for each proof, including $$(\mathsf{circuitId}\_i, \pi\_i, \mathsf{PI}\_i, \mathsf{proofIndex}\_i)$$
* updates the contract state to record the fact that a submission with id $$\mathsf{submissionId}$$ has been made, mapping it to `digestRoot`, $$\mathsf{submissionIndex}$$, $$n$$ and the block number at submission time.

> **NOTE:** Proof data itself does not appear in the input data used to compute $$\mathsf{proofId}$$. This is because when the proof is verified by the application, the application does not have access to (and does not require) any proof data. The application is only verifying the *existence* of a valid proof for the given circuit and public inputs.

> **NOTE:** Application authors must ensure that the public inputs to their ZKPs contain some element that is hard to compute without the corresponding private witness (and in general this will already be the case for sound protocols, in order to prevent replay attacks). If the set of public inputs can be predicted by a malicious party, that malicious party can submit an invalid proof for the public inputs, preventing submission of further (valid) proofs for that same set of public inputs.

### Aggregated proof submission

There is a single (permissioned) *Aggregator* that submits aggregated proofs to the `Upa.verifyAggregatedProof` method. Each aggregated proof attests to the validity of a batch of application proofs. In return, the aggregator can claim submission fees (for on-chain submissions). An aggregated batch may contain proofs from both on-chain and off-chain submissions, as well as *dummy proofs* which are used to fill partial batches.

```solidity
function verifyAggregatedProof(
        bytes calldata proof,
        bytes32[] calldata proofIds,
        uint16 numOnchainProofs,
        SubmissionProof[] calldata submissionProofs,
        uint256 offChainSubmissionMarkers
) external onlyWorker
```

> `proof` - An aggregated proof for the validity of this batch.
>
> `proofIds` - The list of proofIds that are verified by the aggregated proof `proof`. These are assumed to be arranged in the order: \[On-chain, Dummy, Off-chain]. Furthermore, it is assumed that if there are dummy proofIds in this batch, these appear after the last proof in a submission. I.e. where dummy proof ids are used, the on-chain proof ids do not end with a partial submission.
>
> `numOnChainProofs` - The number of proofIds that were from on-chain submissions. This count includes dummy proofs.
>
> `submissionProofs` - An array of 0 or more Merkle proofs, each showing that some of the entries in `proofIds` belong to a specific multi-proof on-chain submission. These are required as we do not have a map from `proofId` to `submissionId` or `submissionIdx`. See the algorithm below for details.
>
> `offChainSubmissionMarkers` - Represents a `bool[]` marking each off-chain member of `proofIds` with a 0 or 1. A proofId is marked with a 1 precisely when the proofId is the last one in an off-chain submission. This `bool[]` is packed into a `uint256` to compress calldata.

The `UpaVerifier` contract:

* checks that `proof` is valid for `proofIds`
* for each $$\mathsf{proofId}$$ in `proofIds`:
  * skips $$\mathsf{proofId}$$ if it corresponds to a dummy proof,
  * checks that $$\mathsf{proofId}$$ has been submitted to the contract, and that proofs appear in the aggregated batch in the order of submission (see below)
  * marks $$\mathsf{proofId}$$ as valid (see below)
  * if $$\mathsf{proofId}$$ is the last proof in a submission $$\mathsf{submissionId}$$, emit an event indicating that the submission $$\mathsf{submissionId}$$ has been verified

Specifically, the algorithm for verifying (in the correct order) submissions of `proofIds`  and marking them as verified, is as follows.

**State:** the contract holds

* a dynamic array `uint16[] numVerifiedInSubmission` of counters, where the $$i$$-th entry corresponds to the number of proofs that have been verified (in order) of the submission with $$\mathsf{submissionId} == i$$
* the submission index `lastVerifiedSubmissionIdx` of the last submission from which a proof was verified.

Given a list of `proofIds` and `submissionProofs`, the contract verifies that `proofIds` appear in previous submissions as follows:

* For each $$\mathsf{proofId}$$ in `proofIds`:
  * If $$\mathsf{proofId}$$ corresponds to a dummy proof, then the rest of the proofs in the batch are assumed to be dummy proofs. No more proofs from this batch will be marked as valid.
  * Attempt to lookup the submission data (see [Proof Submission](#proof-submission)) for a submission with Id $$\mathsf{keccak}(\mathsf{proofId})$$. If such a submission exists:
    * The proof was submitted as a single-proof submission. The contract extracts the $$\mathsf{submissionIndex}$$ from the submission data and then checks that $$\mathsf{submissionIndex}$$ is greater than or equal to`nextSubmissionIdxToVerify`. If not reject the transaction.
    * The entry `numVerifiedInSubmission[` $$\mathsf{submissionIndex}$$ `]` should logically be 0 (this can be sanity checked by the contract). Set this entry to 1
    * Update `nextSubmissionIdxToVerify` in contract state
  * Otherwise (if no submission data was found for $$\mathsf{submissionId} = \mathsf{keccak}(\mathsf{proofId})$$)
    * the proof is expected to be part of a multi-proof submission with $$\mathsf{submissionIndex} \geq$$ `nextSubmissionIdxToVerify`.
      * Note that if a previous aggregated proof verified some subset, but not all, of the entries in the submission, `nextSubmissionIdxToVerify` would still refer to the partially verified submission at this stage. In this case, `numVerifiedInSubmission[` $$\mathsf{submissionIndex}$$ `]` should contain the number of entries already verified.
    * Take the next entry in `submissionProofs`. This includes the following information:
      * the $$\mathsf{submissionId}$$ for the submission to be verified
      * a Merkle "interval" proof for a contiguous set of entries from that submission.
* Determine the number `m` of entries in `proofIds`, including the current $$\mathsf{proofId}$$, that belong to this submission, as follows:
  * Let `numProofIdsRemaining` be the number of entries (including $$\mathsf{proofId}$$) still unchecked in `proofIds`.
  * Look up the submission data for $$\mathsf{submissionId}$$, in particular $$\mathsf{submissionIndex}$$ and $$n$$.
  * Let `numUnverifiedFromSubmission =` $$n$$ `- numVerifiedInSubmission[` $$\mathsf{submissionIndex}$$ `]`.
  * The number `m` of entries from `proofIds` to consider as part of $$\mathsf{submissionId}$$ is given by `Min(numUnverifiedFromSubmission, numProofIdsRemaining)`.
* Use the submission Id $$\mathsf{submissionId}$$ and the Merkle "interval" proof from the submission proof, to check that the hashes of the `m` next entries from `proofIds` (including $$\mathsf{keccak}(\mathsf{proofId})$$) indeed belong to the submission $$\mathsf{submissionId}$$. Reject the transaction if this check fails.
* Increment the entry `numVerifiedInSubmission[` $$\mathsf{submissionIndex}$$ `]` by `m`, indicating that `m` additional proofs from the submission have been verified.
* update `nextSubmissionIdxToVerify` in the contract state

> **NOTE:** The arguments `offChainSubmissionMarkers` and `numOnchainProofs` are there for future off-chain submission support. For now, aggregators call this function with `numOnchainProofs = BATCH_SIZE`, which will skip the off-chain logic of this function. 

### Proof verification by the application

The application client now creates the transaction calling the application's smart contract to perform the business logic. Since the proof has already been submitted to UPA, the proof is not required in this transaction.  If the proof was submitted as part of a multi-entry submission, the client must compute and send a `ProofReference` structure indicating which submission the proof belongs to, and its "location" (or index) within it.

The application contract computes the public inputs, exactly as it otherwise would under normal operation, and queries the `isProofVerified` on the `UpaVerifier` contract (using the `ProofReference` if given) to confirm the existence of a corresponding verified proof.

For proofs from single-entry submissions, the UPA provides the entry points:

```solidity
function isProofVerified(
        uint256 circuitId,
        uint256[] calldata publicInputs)
    external
    view
    returns (bool);

function isProofVerified(bytes32 proofId) external view returns (bool);
```

For proofs from multi-entry submissions, the UPA provides entry points:

```solidity
function isProofVerified(
        uint256 circuitId,
        uint256[] calldata publicInputs,
        ProofReference calldata proofRef)
    external
    view
    returns (bool);

function isProofVerified(
        bytes32 proofId,
        ProofReference calldata proofReference
    ) external view returns (bool);
```

The UPA contract:

* receives $$\mathsf{proofId}$$ or computes $$\mathsf{proofId}$$ from the public inputs
* (using the `ProofReference` if necessary) confirms that $$\mathsf{proofId}$$ belongs to a submission $$\mathsf{submissionId}$$. 
* Checks if there was an on-chain submission for $$\mathsf{submissionId}$$, and if so reads the stored submission index $$\mathsf{submissionIdx}$$ and the total number of proofs `numProofs` contained in the submission $$\mathsf{submissionId}$$. If it finds that `numVerifiedInSubmission[`$$\mathsf{submissionIdx}$$`] == numProofs` then the submission $$\mathsf{submissionId}$$ was verified, and therefore so was the proof $$\mathsf{proofId}$$.

The application contract can also look up the verification status of entire submissions by computing the corresponding (nested) array of public inputs. The contract can then either use a submissionId computed from this array, or the array itself, to query the submission's status in the UPA contract.

The UPA provides the entry points:

```solidity
// If all proofs have the same circuitId.
function isSubmissionVerified(
    uint256 circuitId,
    uint256[][] memory publicInputsArray
) external view returns (bool);

function isSubmissionVerified(
    uint256[] calldata circuitIds,
    uint256[][] memory publicInputsArray
) external view returns (bool);

function isSubmissionVerified(
    bytes32 submissionId
) external view returns (bool);
```

The UPA contract:

* receives $$\mathsf{submissionId}$$ or computes $$\mathsf{submissionId}$$ from the public inputs
* Looks up the number of proofs `numProofsInSubmission` in $$\mathsf{submissionId}$$ and then checks if `numVerifiedInSubmission[`$$\mathsf{submissionIdx}$$`] = numProofsInSubmission`.

### Censorship resistance

A censorship event is considered to have occurred for a submission with Id $$\mathsf{submissionId}$$ (with submission index $$\mathsf{submissionIndex}$$, consisting of $$n$$ entries) if all of the following are satisfied:

* a submission with Id $$\mathsf{submissionId}$$ has been made, and **all** proofs in the submission are valid for the corresponding public inputs and circuit Ids
* some of the entries in $$\mathsf{submissionId}$$ remain unverified, namely
  * `numVerifiedInSubmission[`$$\mathsf{submissionIndex}$$`] <` $$n$$
* one or more proofs from a submission with index greater than $$\mathsf{submissionIndex}$$ (the submission index of the submission with id $$\mathsf{submissionId}$$) have been included in an aggregated batch
  * namely, there exists $$j > \mathsf{submissionIndex}$$ s.t. `numVerifiedInSubmission[`$$j$$`] > 0`

Note that, if one or more entries in a submission are invalid, aggregators are not obliged to verify any proofs from that submission.

Censorship by the *Aggregator* can be proven by a *claimant*, by calling the method:

```solidity
function challenge(
        bytes32 circuitId,
        Groth16Proof calldata proof,
        uint256[] calldata publicInputs,
        bytes32 submissionId,
        bytes32[] calldata proofIdMerkleProof,
        bytes32[] calldata proofDataMerkleProof
) external returns (bool challengeSuccessful);
```

providing:

* the **valid** tuple $$(\mathsf{circuitId}, \pi, \mathsf{PI})$$, or `circuitId`, `proof` and `publicInputs`, the claimed next unverified entry in the submission
* $$\mathsf{submissionId}$$ or `submissionId`
* $$j$$ or `laterSubmissionIdx`
* A Merkle proof that $$\mathsf{proofId}\_i$$ (computed from $$\mathsf{circuitId}\_i$$ and $$\mathsf{PI}$$ belongs to the submission (at the "next index" - see below)
* A Merkle proof that $$\pi\_i$$ belongs to the submission's `proofDigest` entry (at the "next index" - see below)

On receipt of a transaction calling this method, the contract:

* checks that the conditions above hold and that the provided proof has indeed been skipped
* looks up the verification key $$\mathsf{VK}$$ using $$\mathsf{circuitId}$$ and performs the full proof verification for $$(\mathsf{VK}, \pi, \mathsf{PI})$$. The transaction is rejected if the proof is not valid or if the verification key hasn't been registered.
* increments the stored count `numVerifiedInSubmission[`$$\mathsf{submissionIndex}$$`]`

The aggregator is punished only when all proofs in the submission have been shown to be valid. As such, after the above, the contract:

* checks the condition `numVerifiedInSubmission[`$$\mathsf{submissionIndex}$$`] == n` (where `n` is the number of proofs in the original submission $$\mathsf{submissionId}$$).
* if this final condition holds then validity of all proofs in the submission has been shown and the aggregator is punished.

Note: `proofDigest` is used here to prevent malicious clients from submitting invalid proofs, forcing aggregators to skip their proofs, and then later providing valid proofs for the same public inputs. This would otherwise be an attack vector since $$\mathsf{proofId}$$ is not dependent on the proof data.

### Collecting Aggregation Fees

The application contract pays an aggregation fee at submission time. These fees are held in the UPA contract. In order for the aggregator to claim the fees for a given submission, the UPA contract must have verified that submission.

The aggregator collects fees in two steps. First it calls

```solidity
function allocateAggregatorFee(uint64 lastSubmittedSubmissionIdx)
```

which stores the current value of `lastSubmittedSubmissionIdx` and allocates all fees collected up to now to be claimable by the aggregator once it has verified the submission at `lastSubmittedSubmissionIdx` (which implies that all previous submissions have also been verified). Once the aggregator has done this, it can call

```solidity
function claimAggregatorFee(
    address aggregator,
    uint64 lastVerifiedSubmissionIdx
)
```

to withdraw the previously allocated fees.

### Circuit Statements

Batches of $$n$$ application proofs are verified in a *batch verify circuit.*

A *keccak circuit* computes all $$\mathsf{circuitId}$$s and $$\mathsf{proofId}$$s of application proofs appearing in the *batch verify proof*, along with a *final digest* (the keccak hash of these $$\mathsf{proofId}$$s, used to reduce the public input size of the outer circuit below).

A collection of $$N$$ *batch verify proofs* along with the *keccak proof* for their $$\mathsf{circuitId}$$s, $$\mathsf{proofId}$$s and *final digest* is verified in an *outer circuit*.

On-chain verification of an outer circuit proof thereby attests to the validity of $$n \times N$$ application proofs with given $$\mathsf{proofId}$$s.

$$n$$ - inner batch size. Application proofs per batch verify circuit.

$$N$$ - outer batch size. Number of batch-verify circuits per outer proof.&#x20;

$$L$$ - the maximum number of public inputs for an application circuit.

#### Batch Verify Circuit: Groth16 batch verifier

The batch verify circuit corresponds to the following relation:

* *Public inputs*:
  * $$(\ell\_i, \overline{\mathsf{VK}}\_i, \overline{\mathsf{PI}}*i)*{i=1}^n$$ where
    * $$\mathsf{PI}*i = (x*{i,j})\_{j=1}^{\ell\_i}$$ is the public inputs to the $$i$$-th proof
    * $$\overline{\mathsf{PI}}\_i = \mathsf{PI}*i | {0}*{j=\ell\_i + 1}^{L}$$ is $$\mathsf{PI}\_i$$ after zero-padded to extend it to length $$L$$
    * $$\overline{\mathsf{VK}}\_i$$ - application verification keys, each padded to length $$L$$
* *Witness values*:
  * $$(\pi\_i)\_{i=1}^n$$ - application proofs
* *Statement*:
  * $$\mathsf{PI}\_i = \mathsf{truncate}(\ell\_i, \overline{\mathsf{PI}}*i) | {0}*{j=\ell\_i + 1}^{L}$$
  * $$\mathsf{Groth16.Verify}(\overline{\mathsf{VK}}\_i, \pi\_i, \overline{\mathsf{PI}}\_i) = 1$$ for $$i=1,\ldots,n$$
  * where
    * $$\mathsf{truncate}(\ell, \overline{\mathsf{VK}})$$ is the truncation of the size $$L$$ verification key $$\overline{\mathsf{VK}}$$ to a verification key of size $$\ell$$, and
    * $$\mathsf{truncate}(\ell, \overline{\mathsf{PI}})$$ is the truncation of the public inputs to an array of size $$\ell$$

#### Keccak Circuit: ProofIds and Final Digest

Computes the $$\mathsf{proofId}$$ for each entry in each application proof in one or more verify circuit proofs.

* *Public inputs*:
  * $$c^\*, (\ell\_i, \overline{\mathsf{VK}}\_i, \mathsf{circuitId}\_i, \overline{\mathsf{PI}}*i)*{i=1}^{n \times N}$$ where
    * $$\mathsf{PI}*i = (x*{i,j})\_{j=1}^{\ell\_i}$$ is the public inputs to the $$i$$-th proof
    * $$\overline{\mathsf{PI}}\_i = \mathsf{PI}*i | {0}*{j=\ell\_i + 1}^{L}$$ is $$\mathsf{PI}\_i$$ after zero-padded to extend it to length $$L$$
    * $$\overline{\mathsf{VK}}\_i$$ - application verification keys, each padded to length $$L$$
    * $$c^\* = (c^*\_1, c^*\_2)$$ (digest, which consists of 32 bytes and is represented by two field elements)
* *Witness values*: (none)
* *Statement*:
  * $$c\_i = \mathsf{keccak}(\mathsf{circuitId}\_i || \mathsf{truncate}(\ell\_i, \overline{\mathsf{PI}}\_i))$$
  * $$c^\* = \mathsf{keccak}(c\_1 || c\_2 || \ldots || c\_{n \times N})$$
  * $$\mathsf{circuitId}\_i = \mathsf{keccak}(\mathsf{truncate}(\ell\_i, \overline{\mathsf{VK}}\_i))$$

#### Outer Circuit: Recursive verification of Batch Verifier and Keccak circuits

This step aggregates $$N$$ batch verify proofs $${\pi\_{\text{bv}}}^{(j)}, j = 1, \ldots N$$ as well as a single corresponding Keccak proof $$\pi\_{keccak}$$.

* Public Inputs:
  * $$c^\*$$ - final 32-byte public input digest, encoded as $$(c\_1, c\_2) \in \mathbb{F}\_r^2$$
  * $$(L, R) \in \mathbb{G}\_1^2$$ - overall KZG accumulator, encoded as $$12 = 4 \* \texttt{num\_limbs}$$ points of $$\mathbb{F}\_r$$
* Witness values:
  * $$(\ell\_{i,j}, \overline{\mathsf{VK}}*{i, j}, \overline{\mathsf{PI}}*{i,j}) \text{ for } i=1,\ldots, n, j=1, \ldots, N$$: the number of public inputs, the padded verifying key, and padded public inputs for the $$i$$-th application proof in the $$j$$-th BV proof.
  * &#x20;for $$j=1, \ldots, N$$ BV proofs
  * $$\pi\_{\mathsf{keccak}}$$ the Keccak proof for the public inputs
    * $$c^\*$$, and
    * $${ (\ell\_{i, j}, \overline{\mathsf{VK}}*{i, j}, \overline{\mathsf{PI}}*{i, j} }*{\substack{i=1,\ldots, n \ j=1,\ldots,  N}}$$$$(\ell*{1,N}, \mathsf{circuitId}*{1,N}, \overline{\mathsf{PI}}*{1,N}), (\ell\_{2,N}, \mathsf{circuitId}*{2,N}, \overline{\mathsf{PI}}*{2,N}), \ldots , (\ell\_{n,N}, \mathsf{circuitId}*{n,N}, \overline{\mathsf{PI}}*{n,N}),$$
* "Equivalent Statement": (actual statement is shown as multiple sub-statements, given below)
  * All BV proofs are valid, and therefore there exist valid application proofs for each $$\mathsf{PI}*{i,j}$$: $$\textsf{SNARK}*{\text{BV}}.\textsf{Verify} \left( \pi\_{\text{bv}}^{(j)}, (\ell\_{i,j}, \overline{\mathsf{VK}}*{i,j}, \overline{\mathsf{PI}}*{i,j})*{i=1}^n, \mathsf{VK}*{\text{BV}} \right)$$ for $$j=1,\ldots, N$$
  * Keccak proof is valid, and therefore $$c^*$$ is the final digest for all application PIs and vk hashes: $$\textsf{SNARK}*{\mathsf{keccak}}.\textsf{Verify} \left(\pi*\mathsf{keccak}, c^*,(\ell\_{i,j}, \overline{\mathsf{VK}}*{i,j}, \overline{\mathsf{PI}}*{i,j})*{\substack{i=1,\ldots, n \ j=1,\ldots,  N}}, \mathsf{VK}*\mathsf{keccak} \right)=1$$
* Actual Statement:

  * "Succinct" Plonk verification ($$\textsf{SuccinctVerify}$$) namely "GWC Steps 1-11" using Shplonk, without final pairing, for random challenge scalar $$r$$:

  &#x20;$$\begin{gathered} (L\_j, R\_j) = \textsf{SuccinctVerify} \left( \pi\_{\text{bv}}^{(j)}, (\ell\_{i,j}, \overline{\mathsf{VK}}*{i,j}, \overline{\mathsf{PI}}*{i,j})*{i=1}^n, \mathsf{VK}*{\text{BV}} \right) \~\text{ for } j=1,\ldots N \ (L\_{N+1}, R\_{N+1}) = \textsf{SuccinctVerify} \left( \pi\_\mathsf{keccak}, c^\*,(\ell\_{i,j}, \overline{\mathsf{VK}}*{i,j}, \overline{\mathsf{PI}}*{i,j})*{\substack{i=1,\ldots, n \ j=1,\ldots, N}}, \mathsf{VK}*\mathsf{keccak} \right) \ (L, R) = \sum\_{j=1}^{N+1} r^j (L\_j, R\_j) \end{gathered}$$&#x20;
* Verification: The EVM verifier does the following, given $$(\pi\_{\text{outer}}, L, R, c^\*)$$.
  * $$(L\_\text{outer}, R\_\text{outer}) := \textsf{SuccinctVerify}(\mathsf{PI}*\text{outer}, L, R, c^\*, \mathsf{VK}*\text{outer})$$
  * $$e(L + r' L\_\text{outer}, \[\tau]*2) \stackrel{?}{=} e(R + r' R*\text{outer}, \[1]\_2)$$ for random challenge scalar $$r'$$

Note that:

* The same witness values $$\overline{\mathsf{PI}}*{i,j}$$ are used to verify $$\pi*{\text{bv}}^{(j)}$$ and $$\pi\_{\mathsf{keccak}}$$, implying that $$c^\*$$ is indeed the commitment to all application public inputs and circuit IDs.
* The outer circuit does not include the pairing checks, therefore its statement is not that the BV/Keccak proofs are *valid*, but rather that they have been correctly accumulated into a single KZG accumulator $$(L,R)$$. Checking that $$e(L + r' L\_\text{outer}, \[\tau]*2) \stackrel{?}{=} e(R + r' R*\text{outer}, \[1]\_2)$$, for random scalar $$r'$$, therefore implies their validity.
* In the case there is a Pedersen commitment point for proofs coming from e.g. gnark, the statements of the batch verifier and keccak circuits are a bit different. For each application proof:
  * \[Batch verifier circuit] The Pedersen proof is verified: $$e(\mathsf{comm}, h\_1) e( \mathsf{pok}, h\_2) = 1$$, where
    * $$h\_1, h\_2 \in \mathbb{G}\_2$$ is the Pedersen verification key (which is part of the corresponding app $$\mathsf{VK}$$).
    * $$\mathsf{comm}$$ is the Pedersen commitment point and $$\mathsf{pok}$$ the corresponding Pedersen proof of knowledge.
  * \[Keccak circuit] The last public input is computed as the keccak hash of the commitment point: $$\overline{PI}\_{\ell + 1} = \mathsf{keccak}(\mathsf{comm})$$. Note that this last public input is not used in the computation of the proof Id.$$f(x) = x \* e^{2 pi i \xi x}$$