# ZKP Verification Process

The following diagram illustrates the comprehensive workflow of the Fiamma chain, highlighting the processes involved in handling and verifying Zero-Knowledge Proofs (ZKP) and the interactions between

## Components

**Public Chains:**These are the major blockchain networks like Bitcoin and Ethereum, where final transactions and state updates are recorded.**ZK Apps:**Applications that generate and aggregate Zero-Knowledge Proofs, ensuring privacy and integrity of transactions.**Objective Nodes:**Nodes participating in the Proof-of-Stake consensus mechanism to validate proofs.**Intersubjective Nodes :**User-operated nodes run on mobile devices involved in validating, submitting, and verifying proofs.**Fiamma Chain:**The core network handling the verification of Zero-Knowledge Proofs built with Cosmos SDK**DA :**Data Availability layer that stores proof-related data securely.**Staking:**Mechanism within the Fiamma ecosystem responsible for staking operations and state updates.**Finalize:**Finalization layer where transactions and state updates are recorded on the Bitcoin blockchain.

## Workflow Steps

**Step 1: Proof Submission and Aggregation**

**ZK Apps:**Submit individual proofs to the Fiamma network.

**Aggregate Proofs(Optional):**Aggregate proofs before submission to save costs. Note that this can increase the processing time from seconds to hours depending on the situation.

**Step 2:Objective Finality and Consensus**

**Objective Nodes (PoS):****Begin Objective Finality:**The process to reach consensus on the submitted proofs begins.**Consensus:**Nodes collaborate to validate the proof, ensuring its accuracy.**Send Hash, Proof Results, and Multi-Signatures:**The validated proof, along with hash and signatures, is sent to the DA module.

**Fiamma Chain:****Return Commitment:**The chain returns the commitment to the data.**Pre-Sign Asset Transaction:**Prepares to sign the asset transaction for further processing.

**Step 3:Data Request and Proof Validation**

**ZK Apps:****Request Merkle Proof:**Applications request the Merkle proof to construct transactions sent to the L1 chain.**Access Proofs:**The requested proofs are accessed for validation.

**Objective Nodes (PoS):****Provide Merkle Proof Request:**Nodes process the request for Merkle proofs.**Access Proof Data:**Data required for proof validation is accessed and prepared.

**Fiamma Chain:****Begin Intersubjective Finality:**The process for final validation involving intersubjective nodes**begins.**

**Step 4: Intersubjective verification and hard Finality**

**Intersubjective Nodes (User):****Verify ZKP:**Nodes verify the Zero-Knowledge Proof.**If Valid (Happy Path):**If the proof is valid, the result is marked as TRUE.**Collect Intersubjective Results:**The results from various nodes are collected to confirm the proof’s validity. if the number exceeds the threshold, the proof state will be updated to hard finality.

**Step 5: Happy Path**

**Intersubjective Nodes (User):****Send Results if TRUE:**If the proof is valid, the results are sent as TRUE.**Achieve Objective and Intersubjective Finality:**Both objective and intersubjective finality are achieved, confirming the proof’s validity.

**Public Chains:****Process Transactions (Soft Finality):**Transactions are processed if the network trusts the soft finality of the proof.

**Fiamma Chain:****State Updates:**The chain updates its state, confirming the successful verification of proofs.

**Step 6: Unhappy Path (Orange)**

**Intersubjective Nodes (User):****If Invalid (Unhappy Path):**If the proof is invalid, the unhappy path is triggered.**Read Commitments:**Nodes read the commitments to identify discrepancies.**Send Disputed Sub-Script:**A disputed sub-script is sent for further verification.

**Fiamma Chain:****Handle Dispute:**The chain processes the dispute, verifying the invalid proof.**Initiate Slashing:**Penalizes the involved parties for submitting invalid proofs.

**Babylon Chain:****Manage Penalties and Slashing:**Manages the penalties and slashing operations for invalid proofs.

**Bitcoin Chain:****Record Commitments and Checkpoints:**Records the necessary commitments and checkpoints for validation.

**Public Chains:****Process Transactions (Hard Finality):**Transactions are processed if the network trusts the hard finality of the proof.

**Step 7: Finalization and Penalties**

**Fiamma Chain:****Ensure Finalization:**Ensures that all processes are finalized, managing stakes and penalties appropriately.

**Bitcoin Chain:****Record Timestamps and Checkpoints:**Records final timestamps and checkpoints to validate the process.

***Additional Details:**

**Unhappy Path Handling****:**When an invalid proof is detected (Proof_0), it follows the "Unhappy Path," triggering the Slash mechanism and involving steps like reading commitments, issuing challenge transactions, and validating through consensus.**Happy Path Processing****:**Valid proofs follow the "Happy Path," ensuring smooth and efficient processing without triggering penalties.

**Here's a table comparing the Happy Path and Unhappy Path in Fiamma's ZKP handling:**

Last updated