Loading...
private.meDocs
Explore ACIs
PRIVATE.ME PLATFORM

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.

Platform / Verification ALL 4 TIERS + KKW BUILT xCompute Powered
Section 01

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

xCompute MPC on shares Correct result Auditor "Trust us" No proof ? Unverifiable
The Gap
Insurance fraud detection across 3 insurers via xCompute produces a match list. The regulator asks: "Prove this match list was computed correctly from the actual claims data." Without xProve, the only answer is "trust us." With xProve, the answer is a cryptographic proof.
Section 02

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

xCompute MPC on shares Correct result + PROOF XPROVE VERIFY Proof Verifier O(log n) verification No data access needed Auditor Verified correct CRYPTOGRAPHIC GUARANTEE
Section 03

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.

PROOF 1 Circuit Well-formed DAG PROOF 5 T2A Convert Linearity preserved PROOF 2 Gate Eval Per-party honest PROOF 6 A2T Re-share Output correct PROOF 3 Beaver Triple Validity c = a AND b PROOF 4 Beaver Opening XOR reduction correct PROOF BUNDLE End-to-End Verification: 6 proofs chained by session ID VERIFIER CHECKS BUNDLE IN O(log n) TIME — NO DATA ACCESS REQUIRED
Key Property
The proof bundle is publicly verifiable. Anyone with the bundle can verify the computation was correct — they do not need to be a participant, hold any shares, or have access to the underlying data. The verifier learns nothing except that the result is correct.
Section 04

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.

Tier 1
HMAC Audit Trail
Easy · ~1.3x overhead · Ship now

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 resolution
Tier 2
Commit-and-Reveal
Easy · Negligible overhead · Ship now

Commitment 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-equivocation
Tier 3
Information-Theoretic MACs
Medium · ~2x overhead · On demand

Per-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 security
Tier 4a
ZKBoo MPCitH (3-Party)
Advanced · 81 reps · Built

3-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 verifiability
Tier 4b
KKW N-Party MPCitH
Advanced · 32 reps (N=16) · Built

N-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
PropertyTier 1Tier 2Tier 3Tier 4a (ZKBoo)Tier 4b (KKW)
Overhead~1.3xNegligible~2x81 reps × circuit32 reps × circuit
Proof size32 B / party32 B / AND / partyInline~880 KB~50 KB
Repetitions (128-bit)8132
Soundness / rep1/31/16
Publicly verifiableNoNoNoYesYes
Detects semi-honestYesYesYesYesYes
Detects maliciousNoEquivocation onlyYesYesYes
Zero-knowledgeNoNoNoYesYes
The GF(2) Advantage
Binary tower fields are the natural proof system for XorIDA computations. In a prime-field STARK, encoding a single bit requires a ~254-bit field element — a 254x blowup. Binary-field STARKs operate natively at the bit level. Addition is XOR. Multiplication is AND. The cost structure matches xCompute exactly.
4
Verification tiers
FREE
XOR proof cost
O(log n)
Tier 4 verify
GF(2)
Native field
Section 05

Use Cases

The third party who needs proof is who pays for xProve.

Insurance
Fraud Ring Detection

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 + xProve
Healthcare
Clinical Trial Verification

Drug 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 + xProve
Government
Auditable Surveillance

Intelligence 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 + xProve
Finance
Credit Score Integrity

Banks 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 + xProve
Elections
Verifiable Ballot Tallying

Votes 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 + xProve
Software Licensing (Anti-Piracy)
Proof-of-Execution Licensing

Software 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 Verification
Section 06

Integration

Add .prove() to any xCompute circuit. Get a verifiable receipt.

Tier 4: ZKBoo Zero-Knowledge Proof
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
Verify a ZKBoo Proof
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');
}
Tier 1: HMAC Audit Trail
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');
Tier 4b: KKW N-Party Proof (Recommended)
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)

proveKKW(circuit, witness, config?): Promise<Result<KKWProof, XproveErrorCode>>
Generate an N-party KKW zero-knowledge proof. Default N=16, 32 reps for 128-bit security. ~17x smaller proofs than ZKBoo. Drop-in upgrade. Same SHA-256 hash-based post-quantum security.
verifyKKW(circuit, proof, publicOutput, config?): Promise<Result<boolean, XproveErrorCode>>
Verify a KKW proof. Re-derives Fiat-Shamir challenge, checks N commitments per rep, re-simulates N-1 opened parties, cross-checks combined Beaver opens across all opened views.

Tier 4a — ZKBoo API (Legacy)

prove(circuit, witness, securityBits?): Promise<Result<ZKBooProof, XproveErrorCode>>
Generate a ZKBoo zero-knowledge proof. Simulates a 3-party MPC in-the-head, commits to all views via SHA-256, derives Fiat-Shamir challenge, reveals 2 of 3 parties per repetition. 81 reps for 128-bit security. Post-quantum (hash-based).
verify(circuit, proof, publicOutput, securityBits?): Promise<Result<boolean, XproveErrorCode>>
Verify a ZKBoo proof against a circuit and expected output. Re-derives Fiat-Shamir challenge, checks commitments, re-simulates opened parties, cross-checks Beaver opens. Returns ok(true) if valid. Zero access to witness or wire values.

Tier 1 — Audit API

createAuditTrail(circuit, wireValues, key): Promise<Result<AuditTrail, XproveErrorCode>>
Generate per-party HMAC-SHA256 audit chain over gate evaluations. 32-byte final hash commits to the entire computation sequence.

Tier 2 — Commit-Reveal API

commitBeaverOpens(opens, nonces): Promise<Result<BeaverCommitment[], XproveErrorCode>>
SHA-256 commit to Beaver triple open values before broadcast. Prevents equivocation attacks.

Tier 3 — IT-MAC API

evaluateAuthenticatedCircuit(circuit, inputs, ...): Result<Map, XproveErrorCode>
Evaluate circuit with per-wire MAC tracking. XOR gates: free. AND gates: authenticated Beaver triples. Detects any single-party malicious deviation.
Section 07

Security Properties

PropertyMechanismGuarantee
Computation CorrectnessPer-gate proof chainCryptographic
Input PrivacyXorIDA threshold sharesInformation-theoretic
Proof Privacy (Tier 4)ZKBoo/KKW MPCitH ZK proofsNothing leaked
Anti-ReplaySession ID bindingPer-session unique
Anti-EquivocationCommit-and-reveal (Tier 2)Cannot change after seeing
Malicious DetectionIT-MACs (Tier 3)Overwhelming probability
Public VerifiabilityZKBoo/KKW MPCitH (Tier 4)Anyone can verify
Quantum ResistanceGF(2) operations, no keysUnconditional
6
Proof checkpoints
256-bit
HMAC integrity
0
Data revealed
GF(2)
Native proof field
The Competitive Moat
xProve combines XorIDA threshold sharing with binary-field succinct proofs. No existing system combines these properties. The proof system operates natively over GF(2). The result: verifiable computation on information-theoretically shared data — a first-of-its-kind capability.
Section 08

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

XORIDA Threshold sharing + HMAC-SHA256 + PKCS#7 XCOMPUTE MPC on shares — XOR-homomorphic computation + Beaver triples XPROVE VERIFICATION T1 HMAC • T2 Commit-Reveal • T3 IT-MAC • T4 KKW Zero-Knowledge XcheckInsuranceT4 KKW XscoreFinanceT4 KKW xVoteGovernmentT4 KKW xBlindHealthcareT3 IT-MAC xClearedGovernmentT3 IT-MAC XtraceEnterpriseT2 Commit XframlFinanceT4 KKW XreachHealthcareT2 Commit

Cross-ACI Verification Matrix

ACICategoryxProve TierVerification
XcheckInsuranceT4 (KKW)Public proof of fraud match
XscoreFinanceT4 (KKW)Borrower-verifiable score
xVoteGovernmentT4 (KKW)Public ballot tally proof
xBlindHealthcareT3 (IT-MAC)FDA trial verification
xClearedGovernmentT3 (IT-MAC)Oversight court proof
XtraceEnterpriseT2 (Commit)Supply chain audit
XframlFinanceT4 (KKW)Regulator AML proof
XreachHealthcareT2 (Commit)Contact trace audit
All othersVariousT1 (HMAC)HMAC audit trail
CROSS-ACI VERIFICATION
Every XorIDA operation produces HMAC-verified shares. xProve T1 turns those HMACs into an audit chain. For xCompute ACIs, T2–T4 add progressively stronger guarantees up to public zero-knowledge proofs. Each ACI white paper is a sales funnel for xProve — and each xProve proof is a sales funnel for the ACI that produced it.
125
ACIs verified
8
xCompute ACIs
4
Verification tiers
~50 KB
KKW proof size
Section 09

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

Basic (Default)
Static Prover DIDs
One DID per prover, persistent across all proof generations. Simple, but linkable — same identity can be tracked across different computations, proofs, and time.
Current xProve behavior
xProve+ (With Xid)
Ephemeral Per-Proof Prover DIDs
Each proof generation gets a unique prover DID derived from an XorIDA-split master seed. DIDs are unlinkable across proofs and rotate per epoch. Verifiable within proof context, but cross-proof correlation is impossible. ~50µs overhead per proof.
Unlinkable proof generation
xProve Enterprise
K-of-N High-Assurance Proof Generation
Require 3-of-5 signals (biometric + device TPM + location + time + YubiKey) to generate prover DIDs. IAL2/3 assurance levels for financial reporting, regulatory compliance, or classified computations. Continuous refresh ensures only authorized provers can generate proofs.
IAL2/3 compliance

How Ephemeral Proof Generation Works

Proof Workflow (xProve+ with Xid)
// 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
Integration Pattern
xProve+ is not a new ACI — it's an integration of two existing ACIs (xProve + Xid). This demonstrates ACI composability — building blocks combine to create enhanced capabilities without requiring new primitives.

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
Section 10

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.

116
Test Cases
4 tiers
Verification Levels
<1ms
Tier 1 (HMAC)
~50 KB
T4b Proof Size
OperationTimeNotes
T1: HMAC chain generation<0.5msShared-secret verification, fastest tier
T1: HMAC chain verification<0.3msSingle HMAC comparison
T2: Commit-reveal (Beaver)~5msTwo-round protocol with commitment
T3: IT-MAC (SPDZ-style)~10msInformation-theoretic MAC verification
T4a: ZKBoo (3-party MPCitH)~200ms81 repetitions for 128-bit security
T4b: KKW (N-party MPCitH)~30ms32 repetitions for 128-bit security
HMAC tag generation<0.1msPer-share integrity, all tiers

Tier Comparison

TierProver TimeVerifier TimeProof SizeTrust Model
T1 — HMAC Chain<0.5ms<0.3ms32 bytesShared secret
T2 — Commit-Reveal~5ms~3ms~200 bytes2-party honest
T3 — IT-MAC (SPDZ)~10ms~5ms~500 bytesDishonest minority
T4a — ZKBoo~200ms~150ms~880 KBZero-knowledge (public)
T4b — KKW~30ms~20ms~50 KBZero-knowledge (public)
KKW vs ZKBoo
KKW (Katz-Kolesnikov-Wang) is the recommended zero-knowledge tier. At 32 repetitions vs ZKBoo’s 81, it produces ~17x smaller proofs (~50 KB vs ~880 KB) and runs ~6.5x faster. Both achieve 128-bit security. ZKBoo remains available as a legacy option.
Section 11

Honest Limitations

Five known limitations documented transparently. xProve provides practical verifiable computation with explicit constraints.

LimitationImpactMitigation
Not constant-time proof generationProof 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 secretsTiers 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 compositionProofs 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 ceilingPure 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 fixedSecurity 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.