by Usher Labs
For comprehensive documentation on the architecture of Verity, please refer to the Verity Documentation.
The Verity Data Processor (VDP) is an evolution of Usher Labs' Cross-chain Asset Manager Protocol (CCAMP), initially developed for the Internet Computer (IC). To learn more about CCAMP, please refer to the original README.
This evolution involves extracting the logic within CCAMP that enables the IC as a cross-chain orchestrator and co-processor, and modularising it into libraries and components that form the framework. To enhance data sourcing and indexing throughput for the IC, the VDP leverages a highly concurrent zkTLS protocol.
Verity is distinguished by its:
- Server-side only design, tailored for business-centric processes and applications.
- High-frequency and concurrent proof generation capabilities.
- Ability to produce zkProofs that can be verified within any on-chain environment.
- Maintenance of data privacy and security while enabling verifiable data processing.
In essence, Verity functions as a zkRollup for TLS attestations.
This repository contains the framework for the data processing component of the Verity Protocol.
The framework is divided into the following modules:
ic: Contains libraries and pre-built cross-chain asset manager canisters for the Internet Computer.rs: Houses Rust libraries that abstract logic for engaging Verity, and ensuring verifiability in ZK data processing.verity-client: A Rust SDK for interfacing with a Verity Prover. Usher Labs manages a Verity Prover to streamline zkTLS proof generation, otherwise you can run your own. For more information, please contact us via Discord.remote-verify: Used for sending TLS proofs/attestations to the IC for partial or full verification.- 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.
local-verify: Completes the partial verification performed by the IC within the zkVM guest environment.
evm: Smart Contracts templates for integrating various chains in an app-specific multi-chain protocol powered by the IC and Verity.zk: Utilities and tests supporting zkVM usage.
For detailed documentation on the Verity Data Processor Framework SDK, please refer to the SDK Reference.
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.
You can find the Verity Client integrated into our early zkTLS programs. A notable example is the IC-ADC, an asset data oracle for the Internet Computer. In this program, you can review how to:
Additionally, you can review our X (Twitter) NFTs prediction market mini-game to learn how Verity can guarantee the accuracy of data from the X API for use in on-chain dynamics.
Finally, you can review direct examples of the Verity Client in the Verity Client Examples.
Currently, the Verity Client language support is as follows:
- Rust
- Typescript (Coming Soon...)
Note: We are actively working on expanding language support. Stay tuned for updates via X (Twitter) or Discord.
zkTLS acts as a cryptographic primitive that transforms a comprehensive data pipeline into a succinct proof. The Verity DP framework empowers you to develop your own verifiable data pipelines, allowing data to be sourced from any location, processed, and utilised on a blockchain in a trust-minimised manner. This significantly enhances the integrity of data-driven on-chain financial markets and liquidity management.
These verifiable data pipelines result in zkTLS proofs (using either SNARK or STARK) that can be verified across major blockchains.
For a full implementation of zkTLS, please visit the zkTLS demo directory.
The Internet Computer (IC) is a blockchain-first, decentralised compute environment that supports verifiable data portability. It can process data and produce a proof that an honest majority of actors attest to the same outcome. This data processing can be a WASM or WASI binary, offering significant flexibility.
The downside, as with many blockchains, is that processed data is assumed to be public. Within Verity, the IC powers our decentralised Verifier component.
For those interested in working with the IC, we recommend reviewing their documentation here.
You can use the Verity DP alongside the IC to source arbitrary data cost-effectively without compromising high concurrency and frequency. Verity aims to reduce the cost of data sourcing for IC applications by approximately 60-80% compared to their default Oracle mechanism.
Generally applications should opt to use the zkVM for data processing, as it maintains data privacy and provides a rollup of TLS proofs/attestations into a single succinct proof. The Verity DP includes libraries that abstract complexities in managing cryptographic operations between the host and guest to ensure full data verifiability.
In essence, Verity acts as an Oracle for the zkVM.
RiscZero is the most production-grade zkVM, designed for CPUs with smaller workloads. It is the zkVM of choice for Verity, ensuring stateless Rust development to a limit, providing data processing capabilities, and a portable succinct proof format for verification across various environments, whether on- or off-chain.
If you're interested in contributing, please follow the guidelines outlined in our CONTRIBUTORS.md file. Your contributions are greatly appreciated and help improve the project for everyone.
This repository is licensed under the terms specified in the LICENSE file located in the base directory.
If a subdirectory contains its own LICENSE file, the license specified in that subdirectory's LICENSE file will override the base directory license for the contents of that subdirectory. This hierarchical licensing ensures that specific components or modules within the repository can have different licensing terms as needed.
For any questions regarding the licensing terms, please refer to the respective LICENSE files or contact Usher Labs directly.
If you have any questions or need further assistance, feel free to reach out via Discord.