# Verifier Network

## **Overview**

The **Verifier** is a service responsible for validating the **Sequencer’s execution** by performing **Zero-Knowledge (ZK) proof verification** and **attesting the result** to other **Verifier nodes** participating in the network.

The **Verifier** continuously monitors the **Bitcoin blockchain** to track **Sequencer and the other verifiers executions**. It listens for two primary events:

1. **Proof Inscription:** Contains the **proof data** generated for the corresponding batch.
2. **Verifier Attestation:** The attestations created by other verifiers.

The **Verifier Network** is also responsible for **processing withdrawals**. However, only **whitelisted Verifiers** are authorized to perform this operation.

### **Batch Verification**

The verification process begins when a new **proof inscription** is indexed by the verifier from the Bitcoin chain.

<figure><img src="https://706953515-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZHn2dZ9ChqzLzpQ8FPwd%2Fuploads%2F0RiLJ6NxkAD79h3WevX9%2FVerifier%20network.jpg?alt=media&#x26;token=b99f66ef-de4b-43c9-a4e0-50194f36179a" alt=""><figcaption><p>Verification process</p></figcaption></figure>

The verifier proceeds as follows:

1. **Fetch Data:**

   Retrieve the **pubdata** from the **Data Availability (DA)** layer along with the corresponding **proof**.
2. **Validate Priority Transactions:**

   Confirm that all **priority transactions** (e.g., L1 Bitcoin deposits) were executed correctly and are included in the pubdata.
3. **Verify Proof:**

   Check that the provided **ZK proof** was computed correctly and matches the execution.
4. **Attestation:**

   Once verification succeeds, the verifier **attests to the result** by creating an **attestation transaction on the Bitcoin chain**, notifying other verifiers of the outcome.

#### **Batch Finalization**

After sufficient verifiers attest to the validity of a batch, and once the required number of votes is reached, the batch status is updated to **`Finalized`**.

#### **Withdrawals**

<figure><img src="https://706953515-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZHn2dZ9ChqzLzpQ8FPwd%2Fuploads%2FwFnPEDKt1RIzREGP2R8V%2FVerifier%20network-withdrawal.jpg?alt=media&#x26;token=34135fae-f06c-4ff9-bc26-e35ff5c08f9f" alt=""><figcaption></figcaption></figure>

Once a batch is finalized, the verifier network can start processing the withdrawals. To make sure that no withdrawal processed twice, every **withdrawal ID** is written to the Bitcoin chain and consists of **10 bytes** stored in an `OP_RETURN` field:

```
withdrawal_id = 8 bytes of L2 transaction hash + 2 bytes of log_index
```

This mechanism enables the **Verifier Network** to **track processed withdrawals** and ensures that when a **new Verifier** joins the network, it can **synchronize and reconstruct the state directly from on-chain data**, without relying on other Verifiers.

The withdrawal process is executed within a coordinated session involving all whitelisted verifiers. Their public keys are combined using the MuSig2 scheme to generate the bridge address. Since [MuSig2](https://eprint.iacr.org/2020/1261) requires **`N-of-N`** signatures, the participation of every verifier is mandatory. The absence of even a single signature can prevent the successful execution of the withdrawal. On the other hand, only one honest **Verifier** is enough to make sure the funds can not be stolen (`1-of-n` trust assumption to guarantee **safety**).&#x20;

The coordination is managed by a designated verifier known as the **coordinator**. Its role is to collect the signatures generated by all verifiers. Once gathered, these signatures are made accessible to anyone, allowing the construction of the final transaction, which is then broadcast by all verifiers.

Only t**rusted, whitelisted Verifiers** are authorized to **process withdrawals**. This restriction is expected to be lifted once the Via Network implements its **slashing mechanism**.

### Assign new Verifier Set

If the network is unable to process withdrawals, the Via Network **DAO** can assign a new verifier network to handle them. Currently, this process is managed via the **DAO multisig**, but once the **slashing mechanism** and **verifier network upgrade consensus** are implemented, this procedure will be executed automatically, ensuring a fully decentralized and resilient recovery process.

### **Absence of Slashing Mechanisms**

At this stage, there is no slashing mechanism in place to penalize malicious behavior by either the Verifier or the Sequencer. This decision was made to simplify the design, but we recognize the importance of robust incentive models and intend to introduce appropriate measures in future iterations.