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