> For the complete documentation index, see [llms.txt](https://litepaper.fiammalabs.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://litepaper.fiammalabs.io/solution-overview/handling-and-verification-of-zero-knowledge-proofs-and-cross-chain-interactions.md).
# Handling and Verification of Zero-Knowledge Proofs and Cross-Chain Interactions
Fig4. Sequence diagram for the Fiamma network
## 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:**
| **Aspect** | **Unhappy Path** | **Happy Path** |
| ---------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------- |
| **Definition** | Error-handling workflow triggered by invalid proofs | Standard, error-free workflow with valid proofs |
| **Proof Submission** | Users submit zero-knowledge proofs to the Fiamma chain | Users submit zero-knowledge proofs to the Fiamma chain |
| **Proof Reception** | Proofs are received and processed | Proofs are received and processed |
| **Objective Finality** | Invalid proof triggers error handling | Consensus is reached, and proof results are sent to the Fiamma chain |
| **Proof Validation** | Invalid proof detected, challenge process is initiated | Proofs are validated, multi-signatures are generated |
| **Data Request** | Commitments are read to identify discrepancies | Merkle proof is requested and accessed |
| **Intersubjective Finality** | Disputed sub-script is sent for verification | Users verify proofs and confirm validity (results marked TRUE) |
| **Consensus Process** | Nodes handle disputes and initiate slashing | Nodes achieve both objective and intersubjective finality |
| **State Updates** | State update is paused for further verification | State is updated with validated proofs |
| **Commitments Handling** | Invalid commitments handled through dispute resolution | Valid commitments sent to Bitcoin chain |
| **Penalty Mechanism** | Slashing mechanism is triggered for invalid proofs | Not applicable |
| **Transaction Processing** | Transactions processed if hard finality is trusted | Transactions processed if soft finality is trusted |
| **User Notification** | Users are informed of invalid proof and penalties | Users are informed of successful validation |
| **Finalization** | Ensures disputes are resolved, and penalties managed | Ensures all processes are finalized and recorded |
| **Efficiency** | More complex with additional steps for error handling | Smooth, efficient, and straightforward |
| **Outcome** | Invalid proofs lead to penalties and potential delays | Valid proofs lead to state updates and rewards |
| **User Experience** | More complex due to error handling and validation processes | Positive, with timely processing |