Skip to content

Proof by Query

The Proof by Query method involves using; credentials that implement Baby Jubjub key pairs & signatures, a zero knowledge proof based verifier smart contract, and a zk-query language to surface eligibility criteria and verify claims made by users based on their verifiable credentials without revealing the information on chain.

By using this method, you will be able to prove that a user meets defined logical conditions without knowing the information. For example, a user can prove to you that they are above 18 years of age, because their date of birth—stored in their passport credential—can be queried against a relative date, rather than being revealed. Therefore, the proof of age can be made without disclosing their exact birth date, nor any other information contained within the passport.

Proof by Query is maximally privacy preserving for users since only the eligibility criteria are public. The information that proves the user meets that criteria however, remains private. The method increases data security because any Personally Identifiable Information (PII), which is normally passed between all entities, is never seen or stored by the Verifier.

Key Components

Identity Wallet

The Identity Wallet serves as the cornerstone of user identity management.

Key Management Store (KMS)

Allows users to sign data securely using keys, coordinating communication between various key storage systems.

Data Storage interface

Serves as a gateway to essential storage components, including Credential storage, Identity storage, Merkle tree storage, and State interfaces. This interface plays a pivotal role in creating and managing user identities within the system.

Credential Wallet

Dedicated to preserving credentials issued by Issuers, the Credential Wallet operates through a specialised Credential Interface. This interface facilitates interactions between the credential storage, ensuring efficient management and retrieval of issued credentials.

Proof Service

The Proof Service class is a multifaceted component that plays a central role in the protocol. Its functionalities include:

  • Verification of zero-knowledge proofs for specified circuit IDs.
  • Generation of proofs in response to protocol proof requests.
  • Authentication inputs generation.
  • State verification and transition, with subsequent publication to the blockchain.

Reverse Hash Service (RHS)

As a specialised service, the Reverse Hash Service (RHS) is purpose-built to streamline the construction of proofs of existence or non-existence within sparse Merkle trees. Its focused functionality enhances the overall robustness of the protocol.

Circuits Storage

Central to the protocol's operations, Circuits Storage houses critical circuit components, each playing a dedicated role:

High Level Diagram

sequenceDiagram
    autonumber

    participant Issuer
    participant Holder
    participant Verifier
    participant BSC
    participant Redbelly Network
    participant RHS

    Issuer->> Issuer: Download all the circuits info
    Issuer->> Issuer: Create Data Storage
    Issuer->> Issuer: Initialise CredentialWallet and IdentityWallet
    Issuer->> Issuer: Create a unique identity (IssuerDID)

    Holder->> Holder: Download all the circuits info
    Holder->> Holder: Create Data Storage
    Holder->> Holder: Initialise CredentialWallet and IdentityWallet
    Holder->> Holder: Create a unique identity (HolderDID)


    Verifier->> BSC: Create or Update the Business Smart Contract (BSC) as per the use case
    Verifier->> BSC: Can override the fns like afterProofSubmit, beforeProofSubmit from ZKPVerfier in BSC as per use case
    Verifier->> Redbelly Network: Deploy the Business Smart Contract (BSC) on Redbelly Network


    Holder->> Issuer: Sends the HolderDID to issuer
    Issuer->> Issuer: Issue verifiable credential (VC) for the HolderDID and saves the VC in its own data store
    Issuer->> RHS: Submit new state information to the Reverse Hash Service (RHS)
    Issuer->> Redbelly Network: Submit new state according to RHS in the State Contract
    Issuer->> Holder: Passes the VC to the Holder

    Verifier->> BSC: Generate the credential request (CR) and updates the same in the ZKPVerifier using setZKPRequest
    Verifier->> Holder: Sends the CR as QR code

    Holder->> Holder: Scan QR code / copy the CR and check the CR and Circuit ID in it
    Holder->> RHS: Check the Revocation Status of the VC
    Holder->> Holder: Generate the proof for the CR and specific Circuit ID using VC and stored Circuit
    Holder->> BSC: Call function submitZKPResponse and send the proof with public signals for verification

    Verifier-->> BSC: Check for the Response
    alt
    BSC-->> Verifier: If public signals are valid, show a success screen
    else
    BSC-->> Verifier: If public signals are not valid, show an error screen
    end