Sightless is the open protocol for verifiable private compute — backend-agnostic across FHE, TEE, MPC and ZK, with portable cryptographic Receipts any third party can validate.
Every cloud AI service in production today reads user data in cleartext. Communication is encrypted in transit, storage is encrypted at rest — but the operator running the model holds the keys and processes the plaintext. This is the trust singleton.
Sightless changes that. A Data Owner encrypts data locally, transmits the ciphertext to a remote Operator that evaluates a requested function homomorphically without decrypting it, and receives the encrypted result alongside a signed Sightless Receipt that any third party can validate offline.
The Receipt cryptographically binds the Operator's claim about which function ran on which inputs under which policy — providing accountability that survives long after the session and is portable across machines, time, and counterparties.
Sightless is to private compute what HTTPS is to web encryption. HTTPS did not invent ciphers, public-key cryptography, or certificate hierarchies — those existed long before TLS. What HTTPS standardized was the orchestration layer above them. Sightless plays the same role for FHE, TEE, MPC, ZK, and FE.
The protocol is defined entirely at the top layer. The wire format, the cryptographic envelope, and the validation rules are meaningful regardless of which backend evaluates the function.
v0.1 specifies a single concrete backend — TFHE via tfhe-rs — but the artifacts that travel on the wire are defined in terms of
opaque ciphertext bytes and structural attestations. A TEE-based
Operator, an MPC consortium, or a ZK-augmented FHE Operator can
implement the same envelope with localized changes.
L3 Sightless protocol — wire format, envelope,
validation
L2 Backends — FHE (v0.1), TEE, MPC, ZK, FE (future)
L1 Cryptographic primitives & hardware
The Receipt cryptographically binds the Operator to a tuple: which function ran, on which input, under which policy, producing which output. Given only the Receipt and the Operator's public key — acquired out-of-band — any Verifier can validate it offline, at any time, without contacting the Operator that signed it.
Every field above is bound by the signature. JCS (RFC 8785)
guarantees deterministic byte-for-byte reproducibility. H_label (SHA-256 with domain separation) prevents cross-purpose hash confusion.
A worked example against the v0.1 reference implementation. The Client
encrypts four credit features under TFHE, the Operator evaluates
weighted_sum_u8/v1 against the credit_risk_v3
model without ever decrypting, and signs a Receipt the Verifier validates
offline against pk_op. Every §7.6 validation rule — 12 on
the Operator side, 14 on the Client side, 3 on the Verifier — is
exercised on the wire.
tfhe-rsJCS(unsigned)weighted_sum_u8/v1credit_risk_v3OwnerOnly (§3.1)cargo run -p sightless --example credit_scoring_demosk_fhe. Encrypts the input, runs the 14 client
rules on the response, decrypts the result.
sk_op.
pk_op out-of-band. Validates the Receipt offline,
anywhere, any time — never contacts the Operator.
v0.1 makes a deliberate split: cryptographic prevention for plaintext confidentiality, cryptographic accountability for computation integrity. Honest specs distinguish what they prove from what they make attributable.
Input x and output y are not revealed to any network adversary or to an honest-but-curious Operator. Holds against passive and active wire attackers under TFHE security.
A valid Receipt cryptographically attributes the claimed (function, input_hash, output_hash, policy) tuple to the Operator's pk_op. Cryptographic prevention (ZK proofs) is targeted in Phase 4.
No party — including the Operator — can credibly deny having produced the signature, absent compromise of sk_op. Verifiers acquire pk_op through a trusted out-of-band channel.
A Receipt cannot be reused for a different ComputeRequest; a request cannot be replayed within the Operator's acceptance window. Enforced by 16-byte CSPRNG nonces and timestamp mirroring.
Given only (Receipt, pk_op), any Verifier can validate without contacting the Operator, at any time after issuance. A regulator in 2030 verifies a Receipt issued in 2026.
Signing and validation logic do not change when the backend changes. Future TEE, MPC, and ZK backends inherit P1–P5 by construction via localized extensions to the wire format.
v0.1 is an open invitation to adversarial review. Each phase below is a commitment of intent, not of timeline. The protocol's value stands on what is delivered, not what is projected.