​
Modules Overview

The VDP Framework is organised into the following modules:
  • evm: Smart Contract templates for integrating various chains in an app-specific multi-chain protocol powered by the IC and Verity. It works in tandem with ic/canisters/asset_manager.
  • examples: Demonstrations of how to use Verity, including:
    • zktls: An example of zkTLS proof generation using the ZK VDPE.
  • ic: Contains libraries for the Internet Computer (IC).
    • canisters: Pre-built canisters for the Internet Computer that facilitate primitives such as cross-chain asset management.
      • asset_manager (WIP): A set of canisters that can be deployed to facilitate data-driven cross-chain asset management across integrated blockchains.
    • libraries: A collection of general-purpose and Verity-specific libraries that abstract logic and primitives for the IC.
    • managed: A directory containing canisters and primitives managed by Usher Labs.
      • verifier: The Verity Verifier: A canister that:
        1. Verifies TLS proofs either via inter-canister calls (XNET) or via updates from external system calls.
        2. Performs pre-computations specifically for the ZK VDPE.
        3. Produces proofs of computation for verification in external systems, such as a zkVM.
        4. Orchestrates a participation protocol to enforce the security and integrity of Verity Notary network nodes.
  • rs: Contains Rust libraries that abstract logic for engaging with Verity and ensuring verifiability in ZK data processing.
    • verity-client: A Rust SDK for interfacing with a Verity Prover.
    • verify-remote: Used for sending TLS proofs/attestations to the IC for partial or full verification. Only required if using ZK VDPE, or preparing TLS proofs for verification and data processing directly on the destination chain.
      • Partial verification is necessary when leveraging the zkVM, maintaining high performance by partially verifying proofs in a replicated compute platform to minimise ZK proving times.
      • Full verification is only necessary when the data processed is public, which is rare as the zkVM is designed to maintain data privacy and roll up various TLS attestations into a single succinct proof.
    • verify-local: Performs TLS proof verification by combining remote proof of computation verification of public facets with private facets of the TLS proof. Designed primarily for the zkVM guest environment.
    • verity-tls: A library to abstract the verification of TLS proofs produced by the Verity Network.
  • zk: Utilities and tests supporting zkVM usage.

​
SDK Reference

For detailed documentation on the Verity Data Processor Framework SDK, please refer to the SDK Reference. To refer to the Verity DP Github Repo and review examples, please visit: https://github.com/usherlabs/verity-dp

​
Verity Client

The Verity Client abstracts logic associated with interfacing with a Verity Prover. The Verity Prover operates as a proxy, receiving HTTP request parameters and executing these requests with assistance from the rest of the Verity protocol to generate a TLS attestation. The proof generation mechanism within the Prover is asynchronous, and the client is responsible for subscribing to proofs generated by the Prover until the proof is generated. The Verity Client is used in both Verifiable Data Processing Environments (VDPEs). Currently, the Verity Client language support is as follows:
  • Rust
  • Typescript (Coming Soon…)
We are actively working on expanding language support. Stay tuned for updates via X (Twitter) or Discord.

​
TLS Proof Redactions

A ZK function embedded in MPC-TLS primitive is the ability for the Prover to redact data from the TLS transcript (i.e., request/response) when presenting the TLS proof.
The Verity Prover simplifies this operation by exposing the T-REDACT header.
The Verity Client simplifies this further by exposing a .redact() helper function, as demonstrated in the following code example: 
let response = VerityClient::new(config)
    .get("https://jsonplaceholder.typicode.com/posts/98")
    .redact(String::from("res:body:dolor"))
    .send()
    .await?;
The TLS proof will be generated, and if a property exists within the JSON response named dolor, then its value will be redacted and shown as XXXXXXXX.... To see this in action, please review the demos of Verity.