xProve: Verifiable Computation on Threshold Shares
Prove the answer is right without seeing the question. Generate cryptographic proofs that xCompute evaluations were performed correctly — so regulators, auditors, and counterparties can verify results without re-running the computation or accessing the underlying data.
The Problem
xCompute produces answers. But answers without proof require trust. In regulated industries, trust is not enough.
Multi-party computation lets organizations compute on private data without revealing it. But the output arrives with a fundamental question: how do you know the computation was done correctly?
Today, the participants must either trust each other, trust the compute infrastructure, or re-run the computation themselves (which defeats the purpose of delegation). In regulated industries — insurance, healthcare, finance, government — a third party (regulator, auditor, court) needs assurance that the result is correct, without accessing the underlying data.
This is the verifiable computation gap: the space between "we computed this privately" and "here is cryptographic proof the computation was honest."
Without xProve
The PRIVATE.ME Solution
xProve generates cryptographic proofs that xCompute evaluations were performed correctly. The verifier learns that the result is correct — nothing else. No access to the underlying data, shares, or intermediate values.
The key insight: XorIDA operates over GF(2), and GF(2) is the native field for binary-tower STARK proofs. This is not a coincidence to be ignored. XOR is free in xCompute (zero communication) and free in the proof system (linear constraint). AND gates are the only non-trivial constraint in both systems. The cost structures align perfectly.
This structural alignment means xProve proofs for xCompute circuits are 10–50x more efficient than encoding the same circuits into prime-field proof systems (which waste 30–255x space per bit).
With xProve
How It Works
xProve generates proofs at six checkpoints across the xCompute pipeline. Each proof attests that one stage of the computation was performed correctly. Together, they form an end-to-end proof chain.
Four Verification Tiers
Not every use case needs the full proof system. xProve offers four tiers of verification, from lightweight audit trails to publicly verifiable succinct proofs. Ship what you need today, upgrade when the market demands it.
HMAC-SHA256 chain over every gate evaluation. Each party produces a 32-byte audit hash. Participating parties can verify that no one deviated from the protocol. Extends existing xCompute HMAC infrastructure.
Dispute resolutionCommitment phase on Beaver triple open values. Each party commits H(d, e, nonce) before revealing d and e. Prevents equivocation — a party cannot change their opened values after seeing others. One hash per AND gate.
Anti-equivocationPer-wire MAC tracking through the entire circuit. MACs are linear through XOR gates (free) and verified at output. Detects any single-party deviation with overwhelming probability. Provides malicious-security verification between parties.
Malicious security3-party MPC-in-the-Head (ZKBoo) with Fiat-Shamir transform. 81 repetitions for 128-bit security. SHA-256 commitments. Post-quantum (hash-based). Publicly verifiable.
Public verifiabilityN-party generalization (KKW). N=16 needs only 32 reps for 128-bit security. Soundness 1/N per rep vs 1/3. ~17x smaller proofs than ZKBoo. Same post-quantum hash-based security. Drop-in upgrade from ZKBoo.
Compact proofs| Property | Tier 1 | Tier 2 | Tier 3 | Tier 4a (ZKBoo) | Tier 4b (KKW) |
|---|---|---|---|---|---|
| Overhead | ~1.3x | Negligible | ~2x | 81 reps × circuit | 32 reps × circuit |
| Proof size | 32 B / party | 32 B / AND / party | Inline | ~880 KB | ~50 KB |
| Repetitions (128-bit) | — | — | — | 81 | 32 |
| Soundness / rep | — | — | — | 1/3 | 1/16 |
| Publicly verifiable | No | No | No | Yes | Yes |
| Detects semi-honest | Yes | Yes | Yes | Yes | Yes |
| Detects malicious | No | Equivocation only | Yes | Yes | Yes |
| Zero-knowledge | No | No | No | Yes | Yes |
Use Cases
The third party who needs proof is who pays for xProve.
Three insurers share claims via xCompute. The regulator receives a proof that the fraud matching was computed correctly on the actual claims data — without seeing any claims.
Xcheck + xProveDrug company, hospital, and regulator each hold trial data shares. The FDA receives a proof that the statistical analysis was performed correctly. No one can manipulate results.
xBlind + xProveIntelligence agencies hold classified fragments. xCompute finds connections. The oversight court receives a proof that the search was conducted correctly and only on authorized targets.
xCleared + xProveBanks share partial credit signals via xCompute. The borrower receives a proof that their score was computed from the actual data — not manipulated. "Prove my score wasn't rigged."
Xscore + xProveVotes are split across election servers. xCompute tallies. The public receives a proof that the tally is correct without revealing any individual ballot. Verifiable elections.
xVote + xProveSoftware vendors require customers to generate proofs that licensed computations were executed correctly. Prevents verification bypass and unauthorized usage. The vendor receives cryptographic proof of execution without seeing customer data. Revenue assurance for computation-as-a-service.
Licensed VerificationIntegration
Add .prove() to any xCompute circuit. Get a verifiable receipt.
import { CircuitBuilder, buildEqualityCircuit } from '@private.me/xcompute'; import { prove, verify } from '@private.me/xprove'; // Build circuit: 8-bit equality check const circuit = buildEqualityCircuit(8); // Witness: A = B = 10110011 (private input, never revealed) const witness = new Uint8Array([1,0,1,1,0,0,1,1, 1,0,1,1,0,0,1,1]); // Generate ZKBoo proof (128-bit security = 81 repetitions) const proofResult = await prove(circuit, witness, 128); // Proof reveals NOTHING about the witness — only that output = 1 console.log(proofResult.ok); // true
import { verify } from '@private.me/xprove'; // Verifier has: proof + public output + circuit definition // Verifier does NOT have: witness, shares, or wire values const publicOutput = new Uint8Array([1]); // Expected: equal const valid = await verify(circuit, proof, publicOutput, 128); if (valid.ok && valid.value) { console.log('Computation verified correct'); } else { console.log('Verification failed'); }
import { createAuditTrail, generateAuditKey, compareAuditTrails } from '@private.me/xprove'; // Each party generates an audit trail during computation const key = generateAuditKey(); const trail = await createAuditTrail(circuit, wireValues, key); // Parties exchange trails — any deviation detected const match = compareAuditTrails([trail1, trail2, trail3]); if (match.ok && match.value) console.log('All parties agree');
import { proveKKW, verifyKKW } from '@private.me/xprove'; // Same circuit, same witness — just use proveKKW instead of prove const proof = await proveKKW(circuit, witness, { numParties: 16, // N=16 parties (default) securityBits: 128, // 32 repetitions (vs 81 for ZKBoo) }); // Verify — same pattern, ~17x smaller proof const valid = await verifyKKW(circuit, proof.value, publicOutput); if (valid.ok && valid.value) console.log('Verified');
Tier 4b — KKW API (Recommended)
Tier 4a — ZKBoo API (Legacy)
Tier 1 — Audit API
Tier 2 — Commit-Reveal API
Tier 3 — IT-MAC API
Developer Experience
Progress callbacks, fine-grained error codes, and developer-friendly observability built in. Track proof generation status and handle failures with precision.
Progress Callbacks
All proof generation and verification functions accept optional progress callbacks. Track long-running operations in real-time.
import { proveKKW } from '@private.me/xprove'; // Track proof generation progress for responsive UIs const result = await proveKKW(circuit, witness, { securityBits: 128, onProgress: (p) => { console.log(`${p.stage}: ${p.percent}% (rep ${p.current}/${p.total})`); updateProgressBar(p.percent); } }); // Example progress output: // "Simulating parties: 25% (rep 8/32)" // "Generating commitments: 50% (rep 16/32)" // "Computing challenges: 75% (rep 24/32)" // "Finalizing proof: 100% (rep 32/32)"
import { verifyKKW } from '@private.me/xprove'; const valid = await verifyKKW(circuit, proof, publicOutput, { onProgress: (p) => { console.log(`Verification: ${p.percent}% complete`); } }); if (valid.ok && valid.value) { console.log('Proof verified successfully'); }
Error Handling
xProve provides 20 fine-grained error codes across 5 categories. Every error includes actionable guidance for developers.
// Configuration Errors (E001-E004) INVALID_SECURITY_BITS // Must be 80, 96, 112, 128, or 256 INVALID_NUM_PARTIES // Must be N ≥ 3 for KKW proofs INVALID_CIRCUIT // Circuit definition malformed INVALID_WITNESS // Witness length mismatch or type error // Tier 1 Errors (E101-E103) HMAC_GENERATION_FAILED // SHA-256 HMAC failed — check input data HMAC_CHAIN_INVALID // Trail integrity check failed AUDIT_KEY_INVALID // Key must be 32 bytes // Tier 2 Errors (E201-E203) COMMITMENT_FAILED // SHA-256 commitment generation failed REVEAL_MISMATCH // Opened value doesn't match commitment BEAVER_OPEN_INVALID // Triple verification failed // Tier 3 Errors (E301-E304) TIER3_MAC_INVALID // SPDZ MAC verification failed — possible tampering TIER3_MAC_GENERATION_FAILED // IT-MAC generation error TIER3_SHARE_INVALID // Share integrity check failed TIER3_KEY_INVALID // MAC key must be in GF(2^128) // Tier 4 Errors (E401-E408) PROOF_TOO_LARGE // Reduce circuit complexity or security bits SIMULATION_FAILED // Party simulation error — check circuit gates CHALLENGE_DERIVATION_FAILED // Fiat-Shamir hash failed COMMITMENT_CHECK_FAILED // Proof commitment verification failed OPENED_VIEW_INVALID // Revealed party view inconsistent CROSS_CHECK_FAILED // Beaver triple cross-check failed VERIFICATION_TIMEOUT // Increase timeout or reduce proof size UNSUPPORTED_TIER // Tier not implemented or deprecated
import { prove, XproveErrorCode } from '@private.me/xprove'; const result = await prove(circuit, witness, 128); if (!result.ok) { switch (result.error.code) { case XproveErrorCode.PROOF_TOO_LARGE: console.error('Proof too large:', result.error.message); console.log('Suggestion: Reduce circuit size or security bits'); break; case XproveErrorCode.TIER3_MAC_INVALID: console.error('MAC verification failed:', result.error.message); console.log('Possible tampering detected — reject computation'); break; case XproveErrorCode.VERIFICATION_TIMEOUT: console.error('Verification timed out:', result.error.message); console.log('Suggestion: Increase timeout or reduce proof complexity'); break; default: console.error('Proof generation failed:', result.error); } return; } // Success path const proof = result.value;
createDetailedError for custom error contexts and standardized progress callbacks across all proof tiers. Progress events fire every 5% for fine-grained UI updates. Error objects include context fields with circuit metadata and operation timestamps for debugging.
Security Properties
| Property | Mechanism | Guarantee |
|---|---|---|
| Computation Correctness | Per-gate proof chain | Cryptographic |
| Input Privacy | XorIDA threshold shares | Information-theoretic |
| Proof Privacy (Tier 4) | ZKBoo/KKW MPCitH ZK proofs | Nothing leaked |
| Anti-Replay | Session ID binding | Per-session unique |
| Anti-Equivocation | Commit-and-reveal (Tier 2) | Cannot change after seeing |
| Malicious Detection | IT-MACs (Tier 3) | Overwhelming probability |
| Public Verifiability | ZKBoo/KKW MPCitH (Tier 4) | Anyone can verify |
| Quantum Resistance | GF(2) operations, no keys | Unconditional |
Cross-ACI Verification
Every ACI in the PRIVATE.ME platform produces operations that xProve can verify. The verification tier depends on the ACI's computation model.
Building Blocks Stack
Cross-ACI Verification Matrix
| ACI | Category | xProve Tier | Verification |
|---|---|---|---|
| Xcheck | Insurance | T4 (KKW) | Public proof of fraud match |
| Xscore | Finance | T4 (KKW) | Borrower-verifiable score |
| xVote | Government | T4 (KKW) | Public ballot tally proof |
| xBlind | Healthcare | T3 (IT-MAC) | FDA trial verification |
| xCleared | Government | T3 (IT-MAC) | Oversight court proof |
| Xtrace | Enterprise | T2 (Commit) | Supply chain audit |
| Xframl | Finance | T4 (KKW) | Regulator AML proof |
| Xreach | Healthcare | T2 (Commit) | Contact trace audit |
| All others | Various | T1 (HMAC) | HMAC audit trail |
Enhanced Identity with Xid
xProve can optionally integrate with Xid to enable unlinkable proof generation — proofs are verifiable for the specific context, but the prover's identity is uncorrelatable across different proofs, verifiers, or time.
Three Identity Modes
How Ephemeral Proof Generation Works
// Initialize xProve with Xid integration import { XProveEngine } from '@private.me/xprove-cli'; import { XidClient } from '@private.me/xid'; const xid = new XidClient({ mode: 'ephemeral' }); const prover = new XProveEngine({ identityProvider: xid, tier: 'T4b' }); // Each proof derives unlinkable prover DID automatically const proof = await prover.prove({ computation: addTwoNumbers, inputs: [a_share, b_share] }); → [xProve] Deriving ephemeral DID from master seed... → [xProve] DID: did:key:z6MkE... (unique to this proof + circuit + epoch) → [xProve] Prover authenticated (~50µs) → [xProve] KKW proof generated (~30ms) → [xProve] Key purged (<1ms exposure) // Proof is signed with unlinkable prover DID // Verification works for this proof, but cross-proof correlation fails
See the Xid white paper for details on ephemeral identity primitives and K-of-N convergence.
Market Positioning
| Industry | Use Case | Compliance Driver |
|---|---|---|
| Finance | Regulatory proofs with unlinkable prover identity | GLBA, SOX, Basel III, SEC 17a-4 |
| Healthcare | Patient data analytics proofs with HIPAA unlinkability | HIPAA, 42 CFR Part 2, HITECH |
| Government | Classified computation proofs with IAL3 prover identity | FISMA, CJIS, FedRAMP, Zero Trust |
| EU Compliance | GDPR-compliant verifiable computation, unlinkable prover logs | eIDAS 2.0 ARF, DORA, GDPR Art. 5 |
Key Benefits
- Cross-proof unlinkability — Can't track provers across different proofs
- Per-circuit derivation — Same prover has different DIDs for different circuit types
- Epoch rotation — DIDs automatically rotate daily/weekly/monthly
- Split-protected derivation — Master seed is XorIDA-split, never reconstructed
- eIDAS 2.0 ARF compliance — Meets EU unlinkability requirements for proofs
- GDPR data minimization — Proof logs contain minimal linkable identifiers
Benchmarks
Performance characteristics measured on Node.js 22, Apple M2. Four verification tiers with distinct performance profiles — from sub-millisecond HMAC chains to ~30ms zero-knowledge proofs.
| Operation | Time | Notes |
|---|---|---|
| T1: HMAC chain generation | <0.5ms | Shared-secret verification, fastest tier |
| T1: HMAC chain verification | <0.3ms | Single HMAC comparison |
| T2: Commit-reveal (Beaver) | ~5ms | Two-round protocol with commitment |
| T3: IT-MAC (SPDZ-style) | ~10ms | Information-theoretic MAC verification |
| T4a: ZKBoo (3-party MPCitH) | ~200ms | 81 repetitions for 128-bit security |
| T4b: KKW (N-party MPCitH) | ~30ms | 32 repetitions for 128-bit security |
| HMAC tag generation | <0.1ms | Per-share integrity, all tiers |
Tier Comparison
| Tier | Prover Time | Verifier Time | Proof Size | Trust Model |
|---|---|---|---|---|
| T1 — HMAC Chain | <0.5ms | <0.3ms | 32 bytes | Shared secret |
| T2 — Commit-Reveal | ~5ms | ~3ms | ~200 bytes | 2-party honest |
| T3 — IT-MAC (SPDZ) | ~10ms | ~5ms | ~500 bytes | Dishonest minority |
| T4a — ZKBoo | ~200ms | ~150ms | ~880 KB | Zero-knowledge (public) |
| T4b — KKW | ~30ms | ~20ms | ~50 KB | Zero-knowledge (public) |
Ship Proofs, Not Source
xProve generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.
- Tier 1 HMAC (~0.7KB)
- Tier 2 Commit-Reveal (~0.5KB)
- Tier 3 IT-MAC (~0.3KB)
- Tier 4 KKW ZK (~0.4KB)
Use Cases
Honest Limitations
Five known limitations documented transparently. xProve provides practical verifiable computation with explicit constraints.
| Limitation | Impact | Mitigation |
|---|---|---|
| Not constant-time proof generation | Proof generation time varies with input size and circuit complexity. Side-channel timing attacks could leak information about the computation. | Proof generation runs on the prover’s own machine. Timing information is not exposed to verifiers. For sensitive contexts, add random delays to mask timing patterns. |
| T1–T3 require shared secrets | Tiers 1–3 require the prover and verifier to share a secret or participate in a multi-party protocol. They are not publicly verifiable. | Use T4b (KKW) for public verifiability. T1–T3 are designed for bilateral verification (auditor-auditee) where shared context exists naturally. |
| No recursive composition | Proofs cannot be composed recursively (proof of a proof). Complex workflows require generating independent proofs for each step. | Chain proofs via HMAC linking — each proof references the previous proof’s hash. This provides sequential composition without recursive ZK overhead. |
| TypeScript performance ceiling | Pure TypeScript implementation is ~10–100x slower than Rust/C equivalents for compute-intensive ZK operations (T4a/T4b). | KKW at ~30ms is fast enough for production use cases. Future VOLE-in-the-Head implementation via Rust+WASM (FAEST-rs) would close the performance gap. |
| 128-bit security fixed | Security parameter is fixed at 128 bits. Cannot be upgraded to 256-bit without changing the number of MPC-in-the-Head repetitions. | 128-bit security is the NIST standard for most applications. Upgrade path to 256-bit requires doubling repetitions (64 for KKW) — roughly doubling proof time and size. |