Usher Labs' Managed Verity Services
This topic covers operating the Verity Network Nodes via the CLI, and additional tools for verifying TLS proofs.
Verity Notary
Usher Labs manages Verity Notaries as a fundamental requirement for operating the Verity Network. Provers must connect to a verified Notary to generate TLS proofs. Notaries, can however, be operated third-party Node Operators in a fully decentralised manner. This feature is not yet available. Usher Labs has conducted thorough research and benchmarks to evaluate that ensuring Prover and Notary nodes are in close proximity is a requirement for reliable proof generation.
Verity Prover
Self-hosting the Verity Prover is advised to ensure full security over your data, and data acquired from your data sources. Self-hosting does require additional overhead in operating and scaling the Prover, especially in a production environment that demands massive concurrency.
To address this, Usher Labs offers a fully managed Verity Prover infrastructure. This includes autoscaling, monitoring, and alerting to ensure uptime and performance of the Prover for your zkTLS use case.
For specific circumstances, we may deploy a Prover at a different domain specific to your enterprise. Please contact Usher Labs for more information.
Getting Started
This guide outlines how to interact with the managed Verity Prover from a terminal. For convenience, the Verity Client has been developed to streamline and abstract many of these steps.
Verity Client Source Code
https://github.com/usherlabs/verity-dp/tree/main/rs/verity-client
Verity Client Integration Example
-
Instantiate the Client — https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/helpers/verity.rs#L7
-
Execute a Request Using the Client — ****https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/handlers/price/sources/pyth.rs#L58
Step 1: Generate a UUID
A UUID serves as a unique identifier for the verifiable request. It enables correlation between asynchronously generated proofs and the originating request.
To generate a request_id
, use the following command:
Output:
Step 2: Subscribe to Async Proofs
To receive proofs delivered via Server-Sent Events (SSE), use the curl
tool. Open a terminal and listen for SSE at the /proof/[request_id]
endpoint:
Step 3: Execute Request via Verity Prover
The Verity Prover functions as a proxy.
It facilitates the desired HTTP request while generating a TLS attestation to cryptographically prove the correctness and authenticity of the data source.
Under the hood, the process is assisted by the network and follows a protocol to guarantee integrity.
In a second terminal window, execute the request to the Verity Prover, including the request_id
as the value for the T-REQUEST-ID
header.
Verity is designed to support high-concurrency proof generation for TLS attestations, accommodating a range of APIs, from social data to crypto asset data.
Sample HTTP Request Body to X API:
Step 4: Rollup
Verity operates as a zkRollup for TLS attestations, consolidating numerous attestations into a single verifiable proof.
The Verity Data Processor (VDP) Framework simplifies this process by providing libraries and tools to process multiple TLS attestations into a verifiable output via a zkVM. This ensures scalability and efficiency.
Verifiability is underpinned by decentralised compute, leveraging both public and private compute environments to partially verify proofs before consolidation.
For more information, visit: