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