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.
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.
Unlike single-party shielding, private shared state requires computation across multiple parties' secrets.
- 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.
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.
- 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.
- 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.