In Proof of Data Flow, we outline the stages of Verity’s verifiable data pipelines. These pipelines are orchestrated by a developer-operated Prover, which generates Data Flow Proofs (DFPs) through a structured sequence of interactions with the Verity Network, referred to as the Verity Protocol.

Understanding the Verity Protocol and its architecture requires familiarity with the roles played by various nodes within the Verity Network.

​
Roles

Verity’s protocol is facilitated by a network of nodes, each fulfilling specific roles within the system.

​
Prover

The Prover orchestrates the verifiable data pipeline, managing data sourcing and processing for delivery to the destination platform.

  • Data Sourcing: Generates TLS proofs for data.
  • Data Processing: Executes logic in a Verifiable Data Processing Environment (VDPE),such as a zkVM or a decentralised replicated compute platform like the Internet Computer (IC).

​
Notary

The Notary supports the Prover by enabling privacy-preserving MPC-TLS proof generation for API requests.

  • 3-Party MPC (3PC): The Prover and Notary establish an MPC session with the source HTTP server to emulate a TLS client-server interaction.
  • Privacy-preserving Integrity Assurance: Signs off on the TLS handshake and request/response data without accessing the raw data, ensuring authenticity to the source.

​
Collusion Prevention

  • Non-collusion Enforcement: Provers and Notaries operate independently to preserve security properties and prevent proof fabrication.
  • TEE Environments: Notaries run in Intel TDX-enabled environments, ensuring operations are secure and isolated.
  • Bitcoin Staking: Notaries bond BTC as fraud insurance, enforced by protocol-level rules.
  • On-chain TEE Verification: Verifiers validate that Notaries operate with authorised OS images, on approved cloud providers, and generate TLS certificates confidentially within TEE parameters.

Even if the same entity operates both the Prover and the Notary, cryptographic enforcement ensures that the Notary remains a secure, isolated black box. The goal of this collusion prevention mechanism is to prevent the Prover from accessing the Notary’s cryptographic keys and to prevent the Notary from accessing the Prover’s cryptographic keys.

The approach ensures that the Notary generates its TLS certificates within a TEE-enabled environment, preventing interception or fabrication of TLS certificate keys.

​
Verifier

The Verifier is a Smart Contract (or “Canister”) deployed on the Internet Computer (IC), chosen for its unique capabilities that combine blockchain security with AVS-like functionality. The Verifier’s responsibilities include:

  • Notary Validation: Enforces TEE operation, authorised OS usage, and confidential TLS certificate generation.
  • Bitcoin Staking Management: Manages BTC bonds as fraud protection, leveraging BTC’s high cryptoeconomic security.
  • Proof Precomputation: Extracts and processes public elements from TLS proofs to optimise ZK computations and minimise proving times.
  • Proof Verification & Conversion: Verifies TLS proofs and facilitates conversions to cryptographic formats like tECDSA for reduced ZK computational load and wider compatibility with destination systems.

​
Source

The source is a TLS-enabled HTTP endpoint, either third-party or first-party data owned by the Prover.

Examples of third-party sources:

  • Government APIs
  • Financial APIs
  • Weather APIs
  • Social media APIs

​
Destination

The destination is typically a blockchain for trustless final verification. It may also include centralised systems for:

  • Data analysis
  • Cryptographically supported trust management
  • Cybersecurity applications

​
High-level Architecture

The diagram below illustrates the roles and interactions within the Verity Network’s architecture:

On 7) TLS Proof Generation:

  1. The Notary generates secret entropy for the MPC session state machine.
  2. The Prover and Notary validate the TLS handshake.
  3. The Prover commits byte sequences as Merkle tree leaves representing TLS data.
  4. The Notary validates and signs the Merkle root hash.
  5. Entropy is revealed to the Prover, enabling TLS proof construction.

On 8) TLS Proof Preparation (In case of ZK VDPE):

  1. Parse the TLS proof into public and private facets.
  2. Submit public facets to the Verifier for conversion or ZK pre-computation.

On 9) ZK Proof Aggregation (In case of ZK VDPE):

  1. Verify remote tECDSA signature over the Merkle root hash of proof verifications and pre-computes.
  2. Verify private facets of the TLS proof.
  3. Generate a zkSNARK or zkSTARK.

On 10) Proof Delivery:

  1. Destination blockchains must support at least ECDSA signature verification.
  2. For ZK VDPE, the destination blockchain should support Groth16 SNARK verification.
  3. If SNARK verification is unsupported, an IC VDPE can perform SNARK-to-ECDSA conversion. Alternatively, a zkProof verification intermediary network may be necessary.
  4. If the destination blockchain is the Internet Computer, the Prover Orchestrator does not need to collect a response from the Verifier. Instead, the IC VDPE Canister can serve as the destination for the TLS proofs and interface directly with the Verifier, all within the Internet Computer’s environment.

​
Process

  1. Prover Proxy Initiation: Verity Prover technology operates as a proxy, routing API requests through the Prover Proxy to begin TLS proof generation.

  2. Session Initiation: The Prover validates that the selected Notary is an authenticated and verified actor from the Verifier’s state.

  3. Notary Engagement: The Notary assists the Prover in generating TLS proofs.

    Notaries operate at the edge, minimising latency in network communication compared to other MPC-TLS networks.

  4. MPC Session Facilitation: A cryptographic MPC session is conducted between the Prover and Notary to validate and prove data requests to various sources.

  5. Repeat for Each Data Source: Steps 1–4 are repeated for each data source in the pipeline, with the Prover orchestrating the process.

  6. Proof Collation and Processing: After collating data source proofs locally, the Prover proceeds with one of two paths:

    • IC VDPE: Forward proofs and data to a replicated compute VDPE (e.g., IC) for verification and processing into a tECDSA signature.
    • ZK VDPE: Use remote replicated compute Verifier to cryptographically convert public facets of TLS proofs, perform ZK-relevant pre-computations, for processing of private data through a ZK VDPE.

  7. Proof Generation: The Prover receives the succinct output and cryptographic proof of computation from the VDPE.

  8. Proof Delivery: The Prover forwards the output and proof to the destination system for trustless verification and utilisation.

Proof of Data FlowProtocol