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
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) |
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. |