Verity’s Data Flow Proofs (DFPs) are composed of recursive sub-proofs, each layer corresponding to a specific stage of the data pipeline.
The base protocol abstracts proof generation and management mechanics, allowing developers to focus on defining data-specific protocols.
1. Data Sourcing
Data sourcing involves obtaining third-party data from TLS-enabled endpoints, to combine with first-party data. Third-party data sources include:- Government APIs
- Financial APIs
- Weather APIs
- Social media APIs
- Private user data
- Systems data
- Custom data
TLS Proof Generation
Verity generates TLS proofs for data sourced from these endpoints, allowing developers to aggregate proofs across multiple requests into a single, cryptographically verifiable proof. Verity leverages a fork of TLSNotary, an MPC-TLS implementation supported by Ethereum’s Privacy and Scaling Explorations (PSE). See examples of TLS proofs.2. Data Processing
At this stage, data is processed and/or transformed into a format compatible with the destination system. This transformation must be verifiable to ensure the integrity of the applied logic.- Aggregation examples include computing median or mean values, as seen in Decentralised Oracle Networks.
- Computational logic must be provably adhered to using a Verifiable Data Processing Environment (VDPE).
TLS Proof Aggregation
The Prover orchestrates the aggregation of TLS proofs within a VDPE, ensuring verifiability of transformations. A VDPE can be:- zkVM: For privacy-preserving computation.
- Replicated Compute Platform (e.g., Internet Computer): For faster processing with simpler proofs (e.g., tECDSA).
- RiscZero zkVM (default ZK VDPE).
- Internet Computer (replicated compute VDPE).
zkTLS Flow & Optimisation
In Verity, “zkTLS” refers to a data flow where a zkVM-based VDPE is used to aggregate and process MPC-TLS proofs. Essentially, zkTLS represents TLS data flow through ZK compute. Therefore, Verity uses zkTLS proofs and Data Flow Proofs (DFPs) interchangeably. To enhance zkTLS, Verity offloads pre-computation to replicated compute platforms, significantly reducing zkVM proving times from hours to minutes.3. Output
The output is a succinct, verifiable value ready for delivery to the destination system, typically a Smart Contract.zkSNARK or tECDSA Proof
- zkSNARK: Ensures privacy, recommended for private TLS data.
- tECDSA: Efficient, suitable for public TLS data.
4. Proof & Data Delivery
Verity equips developers with tools for orchestrating proof generation, aggregation, and delivery. The delivery mechanism, often referred to as the Orchestrator, manages:- Proof generation timing (e.g., accounting for blockchain re-orgs).
- Data authentication.
- Follow-on actions upon proof delivery.
Example: A zkVM-based Verity pipeline might wait for a predetermined period post-blockchain event detection before generating and delivering the ZK-DFP to mitigate risks in blockchain re-orgs.