Verify offchain program

Example program

// The 'verify_offchain' program.
program verify_offchain.aleo {
    struct Credentials {
        issuer: address,
        subject: address,
        dob: u32,
        nationality: field,
        expiry: u32
    }

    // msg and r are used to construct a public commitment for ownership verification
    // Any message works as long the prover is able to open the commitment
    transition verify(
        msg: field,
        r: scalar,
        sig: signature,
        public issuer: address,
        dob: u32,
        nationality: field,
        expiry: u32
    ) -> public field {
        let creds: Credentials = Credentials {
            issuer: issuer,
            subject: self.signer,
            dob: dob,
            nationality: nationality,
            expiry: expiry
        };
        let res: bool = signature::verify(sig, creds.issuer, Poseidon2::hash_to_field(creds));
        assert_eq(res, true);

        // Return the commitment publicly
        return BHP256::commit_to_field(msg, r);
    }
}

The program above demonstrates an example implementation of an offchain verification mechanism using zPass. The Credentials can be adjusted to contain any value type supported on Aleo, providing flexibility for various use cases.

In the verify transition function, the program takes a msg, random, signature and all values within the Credentials. The signature is generated by the trusted issuer responsible for attesting to the user's credentials. While Zero-Knowledge Proofs (ZKPs) excel at verifying the correctness of computations or private data without revealing the underlying data, they lack the ability to authenticate the data itself. To overcome this limitation, digital signatures from trusted parties are used to ensure the authenticity of the data. These signatures provide a cryptographic guarantee that the data originates from a legitimate and trusted source, thereby complementing the privacy-preserving and verification strengths of ZKPs.

Within the verify transition function, the program reconstructs the hash of the credentials using self.caller as the subject, ensuring that the caller is indeed the user. It then asserts that the user’s credentials have been signed by the trusted issuer. To enable transparent verification, the issuer's identity is made publicly visible, allowing the verifier to confirm that the signature originates from a trusted party.

Because the ZKP does not reveal any information including the signer, the verifier has no way to know that valid proof is indeed originated from the claimed subject. To overcome this, a message (msg) and a random value (r) are used to create a public commitment, which is included with the transaction. The user must later open this commitment to prove that they are the one who generated the ZKP. Any message can be used, as long as the user is able to open the commitment.

If the program executes successfully, the user can generate a ZKP, which can be passed to the verifier. This approach allows the verifier to confirm the validity of the proof without requiring access to the user’s private credentials, maintaining privacy while ensuring security and authenticity.