# Core Functionalities

The key functionalities that define the core of the Via Network Protocol are as follows

### Block Generation Process

Block generation is a critical component of the Via Network **Network architecture**, encompassing the creation and publication of blocks across both the **Bitcoin (L1)** and Via Network**(L2)** networks. The process involves the following key stages:

1. **Transaction Aggregation**\
   The **Sequencer** collects transactions from the **L2 network** and aggregates them into multiple new **L2 blocks**. During this process, the Sequencer executes the transactions within the [**EraVM**](https://matter-labs.github.io/eravm-spec/spec.html), ensuring state transitions are correctly applied.
2. **Batch Construction**\
   Once several L2 blocks are formed, the Sequencer constructs a corresponding **L1 batch**. This batch includes a summary of **L2 transaction state changes** and the necessary **metadata** to support later **verification and validation** steps.
3. **Data Availability**\
   The **L1 batch pubdata** is then published to the **Data Availability (DA) layer**. This ensures that transaction data remains **accessible for a defined period** and can be **verified by any participant** in the network. The DA layer is fundamental for maintaining **transparency**, **auditability**, and **system integrity**.
4. **Bitcoin Inscription**\
   An **optimized block header**, summarizing the **L1 batch**, is **inscribed on the Bitcoin blockchain**. This step establishes a **secure, decentralized reference point**, serving both as a **commitment** to the new L1 batch and a **trigger** for subsequent processes such as **proof generation**.

### Proof Generation

**ZK proof generation** ensures the validity of all transactions contained within an **L1 batch**.\
The process consists of the following key steps:

1. **Prover Notification**\
   Once the **L1 batch** is committed to **Bitcoin** and its transaction is confirmed, the **Proof Data Handler** initiate the proof generation process.
2. **Data Retrieval**\
   The data required for proof generation is passed from the **Sequencer’s database** to the **Prover** through the **Prover Gateway API**. This data includes **state changes**, **batch metadata**, and other relevant details necessary for **witness generation**.
3. **Witness & Proof Generation**\
   Using the retrieved data, the **Prover** constructs a **Zero-Knowledge SNARK proof** that attests to the **correctness of the transactions and state transitions** within the L1 batch.
4. **Proof Inscription**\
   The resulting proof is **inscribed on the Bitcoin blockchain** in an **optimized and compressed format**.\
   This inscription provides a **tamper-proof**, **decentralized record** of the proof, leveraging **Bitcoin’s security and transparency**.

### Proof Verification

**Proof verification** ensures the **integrity and validity** of the proofs inscribed on the **Bitcoin blockchain**, confirming that they accurately represent the corresponding **L1 batch**. For more details on how the verification process works, check out the [verifier Network](https://docs.onvia.org/~/revisions/bScstit45vLsDYaSeSI5/technical-specs/verifier-network)