zkURL Protocol

The zkURL protocol is Cubiq Network's innovative solution for decentralized, verifiable, and efficient distribution of zero-knowledge proofs.

Proofs as First-Class Citizens

zkURL treats zero-knowledge proofs as addressable resources, enabling seamless fetching and verification across the network.

Overview

In a zero-knowledge blockchain like Cubiq, proofs are fundamental. They attest to the correctness of computations performed off-chain, allowing lightweight nodes (Qubes) to verify the entire network state without re-executing every transaction. However, efficiently distributing and retrieving these proofs across a decentralized network, especially to mobile devices, presents a unique challenge.

The zkURL protocol addresses this by providing a standardized, secure, and resilient mechanism for proof publication and retrieval, making proofs as accessible as web pages.

The Need for zkURL

Traditional content distribution methods are often centralized or not optimized for the specific requirements of cryptographic proofs. The need for zkURL arises from:

Decentralized Access: Proofs must be retrievable from multiple, decentralized sources to avoid single points of failure and censorship.
Verifiability: The protocol must ensure the authenticity and integrity of the retrieved proofs.
Efficiency for Mobile: Proofs need to be fetched quickly and with minimal overhead for resource-constrained mobile devices.
Standardization: A common format and retrieval mechanism simplifies integration for dApps and network participants.

Protocol Design

The zkURL protocol defines a URI scheme for addressing zero-knowledge proofs. Its structure is designed to be intuitive yet comprehensive:

3.1. zkURL Format

zk://[proverID]@[domain_or_hash]/[proof_id]#[metadata]

Each component serves a specific purpose:

`zk://` (Scheme): Identifies the protocol as a zkURL.
`[proverID]` (Optional Prover Identifier): A unique identifier for the prover that generated or published the proof. This can be a public key hash or a registered alias.
`[domain_or_hash]` (Host/Content Address):
- Domain: A traditional domain name (e.g., `prover.cubiq.org`) pointing to a prover endpoint.
- Content Hash: A cryptographic hash (e.g., IPFS CID, Arweave ID) pointing to the proof's location in decentralized storage.
`/[proof_id]` (Proof Identifier): A unique identifier for the specific proof, typically a block number, transaction hash, or a unique proof hash.
`#[metadata]` (Optional Metadata): Additional parameters like proof version (`v1`), compression format (`gzip`), or specific proof types.

3.2. Example zkURLs

zk://prover01@prover.cubiq.org/block/8472934#v1zk://QmHash...CID@ipfs/tx/0xabc...def#gzip

Standardized Addressing

A uniform way to locate and reference any zero-knowledge proof on the network.

Decentralized Retrieval

Supports fetching proofs from both centralized endpoints and decentralized storage.

Proof Lifecycle with zkURL

The zkURL protocol integrates seamlessly into the Cubiq Network's proof lifecycle:

Transaction Submission: Users submit transactions to the network.
Block Proposal: A Qube validator proposes a new block containing batched transactions.
Proof Generation: Cloud Provers generate a zero-knowledge proof for the proposed block.
zkURL Publication: The generated proof is published to a zkURL endpoint (e.g., a prover server or IPFS). The zkURL for this proof is then included in the block header.
Qube Verification: Mobile Qubes receive the block header, extract the zkURL, fetch the proof, and verify it locally.
Consensus & Finality: Upon successful verification, Qubes vote to finalize the block.

Security and Reliability

zkURL is designed with robust security and reliability features:

4.1. Cryptographic Verification

Proof Signatures: Proofs are signed by the generating prover, allowing verifiers to authenticate the source.
Content Addressing: When using content hashes in the zkURL, the integrity of the proof is guaranteed by the hash itself.

4.2. Redundancy and Fallbacks

Multiple Sources: Qubes can attempt to fetch proofs from multiple zkURL endpoints or decentralized storage networks (e.g., IPFS, Arweave) if a primary source is unavailable.
Caching: CDNs and local caches can be used to speed up proof retrieval.

Tamper-Proof

Ensures that retrieved proofs have not been altered since publication.

High Availability

Proofs remain accessible even if some distribution points go offline.

Implementation Guide

The Cubiq SDK provides convenient functions for interacting with the zkURL protocol:

5.1. Parsing zkURLs

import { zkURL } from "@cubiq/sdk";

const url = "zk://prover01@prover.cubiq.org/block/8472934#v1";
const parsed = zkURL.parse(url);

console.log(parsed.proverID);   // "prover01"
console.log(parsed.domainOrHash); // "prover.cubiq.org"
console.log(parsed.proofId);    // "block/8472934"
console.log(parsed.metadata);   // { v: "1" }

5.2. Fetching Proofs

import { zkURL } from "@cubiq/sdk";

async function fetchAndVerifyProof(zkUrl: string) {
  try {
    const proof = await zkURL.fetch(zkUrl, {
      fallbacks: ["ipfs", "arweave"], // Optional fallback sources
      timeout: 5000 // Optional timeout
    });
    
    const isValid = await zkURL.verify(proof, {
      checkSignature: true,
      checkTimestamp: true,
      maxAge: 3600 // Proof valid for 1 hour
    });

    if (isValid) {
      console.log("Proof verified successfully!");
      return proof;
    } else {
      throw new Error("Proof verification failed.");
    }
  } catch (error) {
    console.error("Failed to fetch or verify proof:", error);
    throw error;
  }
}