Future Architecture — Trustless Data Yield

The current system uses a trusted oracle. The target architecture eliminates all trust — patients prove compliance with zero-knowledge proofs, sponsors verify without any intermediary, and even the oracle can't cheat.

Phase Roadmap

Phase 1 (Current)    Phase 2 (Next)       Phase 3              Phase 4
─────────────────    ──────────────       ──────────────       ──────────────
HMAC Oracle          Groth16 ZK           Homomorphic          Federated TEE
                     Circuit              Encryption           
                                                               
Trusted oracle       Trustless proof      Compute on           Oracle in SGX/
signs results        via circuit          encrypted data       TrustZone
                                                               
AES-256-GCM          NaCl.box +           TFHE/SEAL +          Attestation +
encryption           Poseidon             encrypted compute    remote proof
                                                               
Backend cron         Client-side          Server-side          Edge compute
evaluation           proof gen            HE evaluation        on patient device

Phase 2: Groth16 ZK Compliance Circuit

Circuit Design

Template: blind-compliance-v1.circom

Inputs:
  // Private (prover knows, verifier doesn't)
  signal private input patientSalt0;
  signal private input patientSalt1;
  signal private input sponsorSalt0;
  signal private input sponsorSalt1;
  signal private input dataTypeHash;
  signal private input scaledValue;
  signal private input threshold;
  signal private input comparator;

  // Public (both prover and verifier know)
  signal input dataCommitment;
  signal input reqCommitment;
  signal output result;  // 0 or 1

Constraints:
  1. dataCommitment === Poseidon(patientSalt0, patientSalt1, dataTypeHash, scaledValue)
  2. reqCommitment === Poseidon(sponsorSalt0, sponsorSalt1, dataTypeHash, threshold, comparator)
  3. IF comparator == 0: result === (scaledValue >= threshold) ? 1 : 0
     IF comparator == 1: result === (scaledValue <= threshold) ? 1 : 0
     IF comparator == 2: result === (scaledValue == threshold) ? 1 : 0
     IF comparator == 3: result === (scaledValue >= threshold && scaledValue <= thresholdHigh) ? 1 : 0

Estimated Constraints

Operation	Constraints	Notes
Poseidon hash (patient)	~250	4 field elements
Poseidon hash (sponsor)	~300	5 field elements
Comparison (GTE)	~50	Bit decomposition
Multiplexer (comparator)	~100	4-way select
Total	~700	Proof time: ~0.5s

Trusted Setup

The circuit requires a Groth16 trusted setup ceremony:

Powers of Tau: Use existing powersOfTau28_hez_final_12.ptau (sufficient for 4K constraints)
Circuit-specific ceremony: Generate blind-compliance-v1_final.zkey
Verification key: Extract verification_key.json for on-chain/off-chain verification

Who Generates the Proof?

Option A: Oracle generates (simpler, oracle knows all private inputs)

Oracle decrypts patient value + knows sponsor threshold
Generates proof server-side
Patient and sponsor verify proof independently

Option B: MPC between patient and oracle (more private, more complex)

Patient provides their private inputs
Oracle provides sponsor's private inputs
Neither learns the other's full inputs
Proof generated collaboratively

Recommended: Option A for Phase 2, transition to Option B when MPC tooling matures.

Phase 3: Homomorphic Encryption

Vision

Compute compliance without decrypting anything:

Patient encrypts:   HE.encrypt(7500, programPubKey) → ciphertext_value
Sponsor encrypts:   HE.encrypt(5000, programPubKey) → ciphertext_threshold

Oracle computes:    HE.compare(ciphertext_value, ciphertext_threshold)
                  → ciphertext_result (encrypted 0 or 1)

Oracle decrypts:    HE.decrypt(ciphertext_result, oraclePrivKey)
                  → 1 (patient value ≥ threshold)

The oracle learns the result (pass/fail) but never sees the raw value OR the threshold.

Technology Options

Library	Type	Performance	Maturity	Best For
TFHE-rs	Fully HE	Fast booleans, slow arithmetic	Production	Comparison operations
OpenFHE	BFV/CKKS/TFHE	Good arithmetic	Production	Sum, mean, range
SEAL	BFV/CKKS	Best arithmetic	Production	Rolling averages
Concrete	TFHE	Fastest booleans	Beta	Binary compliance

Supported Operations

Operation	HE Scheme	Use Case	Estimated Time
`HE_COMPARE`	TFHE	Value ≥/≤ threshold	~50ms
`HE_RANGE`	TFHE	Value in [min, max]	~80ms
`HE_SUM`	BFV/CKKS	Sum values across periods	~20ms per add
`HE_MEAN`	CKKS	Rolling average compliance	~100ms

Architecture Change

Current:     Patient → encrypt(AES) → Oracle decrypts → compares → proof
Phase 3:     Patient → encrypt(HE) → Oracle computes on ciphertext → decrypts result only

The key difference: in Phase 3, the oracle never sees the patient's raw value. It computes the comparison on encrypted data and only learns the boolean result.

Phase 4: Federated TEE Oracle

Vision

The oracle runs inside a Trusted Execution Environment (Intel SGX, ARM TrustZone, AWS Nitro Enclaves). Even the server operator can't access the oracle's memory.

┌─────────────────────────────────────────┐
│  AWS Nitro Enclave / Intel SGX          │
│  ┌───────────────────────────────────┐  │
│  │  Compliance Oracle                │  │
│  │                                   │  │
│  │  ✓ Decrypts patient values        │  │
│  │  ✓ Loads sponsor thresholds       │  │
│  │  ✓ Evaluates compliance           │  │
│  │  ✓ Generates proofs               │  │
│  │                                   │  │
│  │  ✗ Memory NOT readable by host    │  │
│  │  ✗ Storage NOT accessible         │  │
│  │  ✗ Network traffic encrypted      │  │
│  └───────────────────────────────────┘  │
│                                         │
│  Remote Attestation:                    │
│  "This code is running unmodified       │
│   inside a secure enclave"              │
└─────────────────────────────────────────┘

Attestation Chain

Code hash: SHA-256 of the oracle binary (publicly auditable)
Enclave measurement: Platform-signed attestation that the code is running inside TEE
Patient verifies: Before submitting data, patient checks attestation against known-good hash
No trust required: Even if the server is compromised, the enclave's memory is inaccessible

Design Improvements for Current System

1. Commitment Upgradeability

When Phase 2 ZK circuits are ready, existing SHA-256 commitments (from web/mobile) won't be compatible. Solution:

BlindSubmission {
  commitmentVersion: 1,          // 1 = SHA-256, 2 = Poseidon
  dataCommitment: "0x...",
  legacyCommitment: "0x...",     // Keep old hash for audit trail
}

The oracle accepts both versions during the transition period.

2. Proof Aggregation

Instead of one proof per submission, batch proofs:

Week 15 has 500 submissions across all programs.
Instead of 500 individual proofs:
  1. Evaluate all 500
  2. Generate one Merkle root of all 500 proofs
  3. Anchor single root on-chain
  4. Each patient gets a Merkle path to verify their specific result

This reduces on-chain costs from 500 transactions to 1.

3. Cross-Program Compliance Correlation

When a patient is enrolled in multiple programs with overlapping data types:

Patient enrolled in:
  - Heart Failure (needs daily vitals)
  - Digital Biomarker AI (needs daily vitals)

One submission → auto-fulfills both programs.

The oracle checks: "does this data type match any other active enrollment?" and creates compliance records for all matching programs.

4. Dispute Resolution Protocol

If a patient believes the oracle evaluated incorrectly:

Patient requests re-evaluation
Oracle re-runs comparison with logged inputs
If result differs: oracle was buggy → credit patient + flag for audit
If result matches: patient commitment doesn't match claimed value → no change
Dispute hash anchored in Merkle tree for transparency

5. Oracle Rotation

No single oracle should run forever. Planned key rotation:

Oracle Key Epochs:
  Epoch 1 (months 1-6):   oracleKey_v1
  Epoch 2 (months 7-12):  oracleKey_v2
  ...

During rotation:
  - New submissions encrypted with new key
  - Pending submissions still evaluated with old key
  - Old key destroyed after all pending evaluated

6. Patient-Side Verification

After oracle evaluation, the patient can verify:

// Patient has: their value (7500), the proof, the proofHash
// Patient does NOT have: the threshold (still hidden)

// They CAN verify:
1. proofHash === SHA256(proof)  ✓ (proof wasn't tampered)
2. The Merkle tree includes proofHash  ✓ (proof was anchored)
3. Their dataCommitment matches their value  ✓ (they submitted what they think)

// They CANNOT reverse-engineer:
- What the threshold was
- Why they passed or failed specifically
- Other patients' results

This is the key anti-spoofing property: even after seeing "pass", the patient doesn't learn the threshold. They might have passed at 7,500 steps, but they don't know if the threshold was 3,000 or 7,000. Next time, they still have no incentive to fabricate.

Future Architecture — Trustless Data Yield

Phase Roadmap​

Phase 2: Groth16 ZK Compliance Circuit​

Circuit Design​

Estimated Constraints​

Trusted Setup​

Who Generates the Proof?​

Phase 3: Homomorphic Encryption​

Vision​

Technology Options​

Supported Operations​

Architecture Change​

Phase 4: Federated TEE Oracle​

Vision​

Attestation Chain​

Design Improvements for Current System​

1. Commitment Upgradeability​

2. Proof Aggregation​

3. Cross-Program Compliance Correlation​

4. Dispute Resolution Protocol​

5. Oracle Rotation​

6. Patient-Side Verification​

Phase Roadmap

Phase 2: Groth16 ZK Compliance Circuit

Circuit Design

Estimated Constraints

Trusted Setup

Who Generates the Proof?

Phase 3: Homomorphic Encryption

Vision

Technology Options

Supported Operations

Architecture Change

Phase 4: Federated TEE Oracle

Vision

Attestation Chain

Design Improvements for Current System

1. Commitment Upgradeability

2. Proof Aggregation

3. Cross-Program Compliance Correlation

4. Dispute Resolution Protocol

5. Oracle Rotation

6. Patient-Side Verification