Private Shared State (TEE)

Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others. This variant stores state encrypted to an enclave public key; a Trusted Execution Environment decrypts inputs, runs the state transition at native speed, and posts updated encrypted state plus a remote-attestation report proving which code ran.

Works best when

  • Multiple institutions share a ledger, pool, or order book and must hide individual positions from each other.
  • Low latency is required and participants accept hardware trust assumptions.
  • Contractual and audit controls can bound hardware-vendor and host-operator risk.

Avoid when

  • Single-party privacy is sufficient (use shielding instead).
  • The threat model includes nation-state physical access or supply-chain compromise.
  • Full trustlessness is required; prefer the co-SNARK or Fully Homomorphic Encryption variants.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions, hardware trust is bounded by contractual controls (NDAs, audit rights, attestation logging) and by running enclaves across diverse operators. The consortium can standardise enclave code, measurement values, and rotation policy.

Institution to end user

I2U

For user-facing deployments a single-operator enclave gives the user no independent verification of integrity. A coalition of host plus hardware vendor can observe plaintext. Threshold keys across multiple independent enclave operators, combined with zero-knowledge proofs of correct execution, are required to make the guarantee meaningful.

Post-quantum exposure

Risk · medium
Vector
Remote attestation typically uses elliptic-curve signatures (ECDSA, EdDSA) broken by CRQC. Recorded attestation reports and sealed blobs face HNDL risk if encrypted to vendor-operated key hierarchies.
Mitigation
Migrate attestation signing and sealing keys to post-quantum signatures (ML-DSA, SLH-DSA) as vendors ship them. See Post-Quantum Threats.

Components

  • Trusted execution environment: Intel SGX (process-level), AMD SEV-SNP (VM-level), or AWS Nitro Enclaves (hypervisor-isolated). Each imposes a different threat model and attestation chain.
  • Enclave guest code implements the state-transition logic and holds the decrypted state only for the duration of a transition.
  • Remote attestation service binds the enclave's measurement (code hash plus configuration) to a signed attestation report that participants and the on-chain verifier can check.
  • Commitment scheme (Pedersen, Poseidon) represents state on-chain; an optional zero-knowledge proof hybrid proves correct execution beyond attestation.
  • On-chain state store and verifier contract anchor attested state updates; a fallback hybrid path verifies a zero-knowledge proof of execution.
  • Regulatory disclosure path uses enclave-mediated decryption scoped to specific positions or time windows.

Protocol

  1. operator Deploy the attested enclave cluster; publish enclave measurements and attestation public keys.
  2. user Each party verifies attestation, then deposits assets; balances are encrypted to the enclave public key.
  3. user A party submits an encrypted state-transition request to the enclave.
  4. operator The enclave decrypts inputs, executes the transition at native speed, and emits the updated encrypted state plus an attestation report.
  5. contract The on-chain verifier checks the attestation (and, in the hybrid variant, a zero-knowledge proof of correct execution) and updates the state root.
  6. auditor Regulator requests scoped disclosure; the enclave decrypts only the approved scope and emits a signed disclosure record.

Guarantees & threat model

Guarantees:

  • Inputs and intermediate state remain confidential from other parties and from the host operator, subject to the enclave assumptions.
  • Remote attestation binds every state transition to a specific code measurement and configuration.
  • Settlement finality anchored to Ethereum L1 or an L2.
  • Enclave-mediated scoped disclosure for regulators.

Threat model:

  • Enclave integrity, including resistance to cache-timing and transient-execution side-channels. Constant-time code and timely firmware patching are required mitigations.
  • Hardware-vendor trust: vendor master keys and attestation-chain integrity are unavoidable roots of trust.
  • Host-operator availability: the host can schedule or refuse to schedule the enclave; privacy is unaffected, liveness is not.
  • Physical access and supply-chain compromise are out of scope for the bare TEE variant; combine with a zero-knowledge execution proof for stronger guarantees.
  • Sender and receiver addresses are not hidden by default; address unlinkability requires composition with stealth addresses.

Trade-offs

  • Lowest latency of the private-shared-state variants; execution runs at near-native speed inside the enclave.
  • Hardware trust is a hard dependency. Contractual controls and enclave-operator diversity mitigate but do not remove it.
  • Attestation-verification gas cost on-chain is non-trivial and varies by platform.
  • Side-channel exposure is a moving target; assume ongoing firmware maintenance and code hardening.
  • Hybrid designs that add a zero-knowledge proof of correct execution reduce hardware dependence at the cost of proving overhead.

Example

  • Three banks share a tokenised-bond collateral pool on an Ethereum settlement L2. Each bank's deposit is encrypted to the enclave cluster's public key. A margin call triggers enclave computation: the enclave decrypts inputs, evaluates aggregate collateral coverage at native speed, and emits the updated encrypted state with an attestation report. The regulator uses enclave-mediated disclosure to audit one bank's position without learning the others.

See also

Open-source implementations