diff --git a/CHANGELOG.md b/CHANGELOG.md index f50f33c..b84ea4f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,13 @@ All notable changes to the IPTF Map are documented here. ## [Unreleased] ### Added + +- feat(pattern): [Network-Level Anonymity](patterns/pattern-network-anonymity.md) - Umbrella pattern for transport-layer sender anonymity (Tor, mixnets, private RPC, TEE-assisted, VPN) +- feat(pattern): [TEE-Assisted Network Anonymity](patterns/pattern-tee-network-anonymity.md) - TEE+secret-sharing approach for low-latency sender anonymity (Flashbots Flashnet) - feat(pattern): [Private Shared State](patterns/pattern-private-shared-state.md) - Umbrella pattern for multi-party private state (FHE, MPC+ZK, TEE comparison) +- feat(approach): Restructured [Private Trade Settlement](approaches/approach-private-trade-settlement.md) — separated single-chain and cross-chain approaches, added TEE+ZK, MPC, and intent-based settlement with trade-off matrices ([#77](https://github.com/ethereum/iptf-map/issues/77)) +- feat(pattern): Enhanced [Hybrid TEE + ZK Settlement](patterns/pattern-tee-zk-settlement.md) with trust framework, TEE API surface, stealth address design, anti-pattern table, and PoC learnings ([#79](https://github.com/ethereum/iptf-map/issues/79)) +- fix(pattern): Refreshed [TEE-Based Privacy](patterns/pattern-tee-based-privacy.md) — added CPU-encrypted vs hypervisor-isolated platform classification and threat model comparison - feat(approach): Enhanced [Private Bonds](approaches/approach-private-bonds.md) with PoC learnings, coprocessor model analysis (co-SNARKs vs FHE), comparison matrix, and implementation guidance - chore(vendors|approaches): add taceo merces and update private payments approach: [TACEO Merces](vendors/taceo-merces.md) - MPC + ZK approach for private stablecoin transfers - feat(approach): [Privacy Standards Survey](approaches/approach-privacy-standards-survey.md) - Standards catalog, gap analysis, and decision guidance ([#64](https://github.com/ethereum/iptf-map/pull/64)) diff --git a/approaches/approach-private-trade-settlement.md b/approaches/approach-private-trade-settlement.md index 16f68aa..713d71b 100644 --- a/approaches/approach-private-trade-settlement.md +++ b/approaches/approach-private-trade-settlement.md @@ -6,187 +6,188 @@ - [Private RWA Tokenization](../use-cases/private-rwa-tokenization.md) - [Private Derivatives](../use-cases/private-derivatives.md) -**High-level goal:** Enable confidential settlement of complex trades across multiple assets, networks, and jurisdictions while maintaining atomicity, regulatory compliance, and operational efficiency. +**High-level goal:** Enable confidential settlement of institutional trades while maintaining atomicity, regulatory compliance, and operational efficiency. Same-network settlement provides true atomicity (single transaction). Cross-network settlement requires trust assumptions — no trustless solution exists today. + +**Companion document:** [Atomic DvP Settlement](approach-dvp-atomic-settlement.md) covers atomicity primitives (HTLCs, escrow, oracle-based conditional transfers). This document focuses on how to add privacy to settlement. ## Overview ### Problem Interaction -Modern institutional trading requires coordinating multiple complex challenges: +Institutional trade settlement requires balancing: -1. **Cross-Border Coordination**: Assets and cash may need to settle on different networks optimized for different purposes (liquidity vs privacy) -2. **Multi-Asset Complexity**: Trades often involve multiple instruments (bonds + cash, derivatives + collateral, etc.) requiring coordinated settlement -3. **Privacy vs Transparency**: Trading strategies must remain confidential while maintaining regulatory oversight and settlement assurance -4. **Settlement Risk**: Ensuring atomic execution across multiple networks, asset types, and time zones +1. **Privacy vs Transparency**: Trading strategies, positions, and counterparty relationships must remain confidential while providing regulatory oversight and settlement assurance +2. **Atomicity**: Both legs of a trade must settle together or not at all — partial settlement creates counterparty risk +3. **Cross-Domain Coordination**: Assets and cash may reside on different networks optimized for different purposes (liquidity vs privacy) +4. **Compliance**: Cross-border regulatory requirements with varying privacy and disclosure rules -These problems interact because traditional settlement systems assume transparency and single-jurisdiction operations, while institutional privacy needs require coordination across fragmented privacy and liquidity domains. +On a single network, atomicity is trivial (one transaction settles both legs). Across networks, atomicity and privacy become competing constraints — revealing state to coordinate settlement undermines the privacy that motivated using separate networks. ### Key Constraints -- Must coordinate settlement across multiple networks (where cash has liquidity vs where assets can be private) -- Support for complex settlement patterns (DvP, PvP, multi-leg trades, collateral management) -- Cross-border regulatory compliance with varying privacy requirements -- Integration with existing institutional settlement infrastructure (custodians, CSDs, etc.) -- Real-time settlement coordination with acceptable failure recovery +- Atomic DvP: both legs complete or neither does (see [Atomic DvP Settlement](approach-dvp-atomic-settlement.md) for mechanisms) +- Support for institutional settlement patterns (DvP, PvP, multi-leg trades) +- Integration with existing custody infrastructure and compliance workflows +- Selective disclosure for regulators across jurisdictions ### TLDR for Different Personas -- **Business:** Execute trades privately across multiple networks while maintaining operational efficiency and regulatory compliance -- **Technical:** Coordinate atomic settlement across privacy domains using conditional settlement protocols and trusted coordination -- **Legal:** Provide regulatory oversight across jurisdictions while protecting proprietary trading information through selective disclosure +- **Business:** Settle trades privately on-chain. Same-network for guaranteed atomicity, cross-network when liquidity or regulation forces it — with explicit trust tradeoffs +- **Technical:** Same-chain: shielded pool DvP or privacy L2 native contracts. Cross-chain: TEE+ZK coordination, MPC threshold, or intent-based settlement — each with different trust models +- **Legal:** Selective disclosure mechanisms provide regulatory access. Trust model varies by approach — from cryptographic-only (same-chain ZK) to hardware trust (TEE) to economic guarantees (intents). Counterparty risk also varies: true atomicity on a single chain vs trusted bridges across two networks ## Architecture and Design Choices -### Recommended Architecture: Multi-Network Settlement Coordination - -**Primary Pattern:** [ERC-7573 DvP](../patterns/pattern-dvp-erc7573.md) with privacy-preserving coordination -**Supporting Patterns:** +### Single-Chain Private Settlement -- [Private Payments](../approaches/approach-private-payments.md) for cash leg execution -- [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md) -- [Private L2s](../patterns/pattern-privacy-l2s.md) for asset leg privacy -- [MPC Custody](../patterns/pattern-mpc-custody.md) for institutional coordination +On a single network, a smart contract can execute both legs in one transaction — atomicity is an inherent blockchain property, so the challenge is purely about privacy. -#### Core Components: +Privacy strength scales with anonymity set size: larger pools make individual transactions harder to distinguish. Institutions, however, need KYC'd and regulated counterparties, which restricts who can enter the pool and shrinks the set. An open permissionless pool maximizes privacy but mixes compliant and non-compliant actors; a permissioned-only pool satisfies compliance but may be too small for meaningful anonymity. [Privacy Pools](../vendors/privacypools.md) explore a middle path through association sets — participants transact in a shared pool but prove membership in a compliant subset without revealing their identity within it. The right balance remains jurisdiction, asset-class, and risk-appetite-dependent. -1. **Settlement Coordination Layer** +#### Approach A: UTXO Shielded Pool DvP - - Cross-network settlement orchestration using ERC-7573 with conditional atomicity - - Trusted or MPC-based relayers for privacy-preserving coordination - - Settlement state management across multiple domains - - Failure handling and rollback mechanisms +**Primary Pattern:** [Shielding](../patterns/pattern-shielding.md) with [ZK Shielded Balances](../patterns/pattern-zk-shielded-balances.md) -2. **Multi-Domain Execution** +Both counterparties hold assets in a shielded pool (Railgun, Privacy Pools). Settlement executes as coordinated JoinSplit operations within the pool — consuming input notes and producing output notes in a single atomic transaction. - - Cash Domain: Settlement on networks with deep stablecoin liquidity (Ethereum L1) - - Asset Domain: Private execution on networks optimized for confidentiality (Privacy L2s, shielded pools) - - Bridge Coordination: Secure communication between domains without information leakage +- **Primitives**: Shielded pool, JoinSplit circuits, Merkle tree, nullifier set, view keys +- **Trust model**: Cryptographic only — no hardware or operator trust. Privacy guaranteed by zero-knowledge proofs +- **Privacy**: Amounts, counterparties, and addresses hidden. Anonymity set is the entire shielded pool +- **Maturity**: Production (Railgun live since 2021, >$4B total volume) +- **Caveats**: Higher gas costs on L1. UTXO off-ramping to public ERC-20 requires unshielding, which creates linkability. Privacy set size on L1 affects anonymity guarantees. Relayer needed for full address privacy -3. **Institutional Integration** +**Vendors:** [Railgun](../vendors/railgun.md), [Paladin](../vendors/paladin.md) (white-label), [Privacy Pools](../vendors/privacypools.md) - - Custody Integration: Coordination with existing custodial infrastructure - - Settlement Timing: Support settlement cycles as required - - Risk Management: Real-time exposure monitoring and margin management - - Regulatory Reporting: Automated compliance reporting across jurisdictions +#### Approach B: Privacy L2 Native DvP -4. **Privacy-Preserving Coordination** +**Primary Pattern:** [Privacy L2s](../patterns/pattern-privacy-l2s.md) - - Trusted Relayers: Institutional-grade settlement coordination services - - MPC Coordination: Decentralized multi-party settlement coordination - - Hidden State: Settlement coordination without revealing trade details - - Selective Disclosure: Regulatory oversight through controlled access mechanisms +Deploy both asset and payment contracts on a privacy L2 where private state is a first-class primitive. DvP executes as a native private contract call — no shielding/unshielding overhead. -### Vendor Recommendations +- **Primitives**: L2 encrypted state, private smart contracts, validity proofs, native notes +- **Trust model**: L2 sequencer (liveness), validity proofs on L1 (correctness), Data Availability layer +- **Privacy**: Protocol-level encryption of all state. Nullifier keys are app-siloed for damage containment +- **Maturity**: Emerging — Aztec testnet (2026), Miden in development +- **Caveats**: Bridge risk for assets entering/exiting L2. Ecosystem maturity and tooling still early. Throughput characteristics unknown at scale -**Primary Infrastructure:** +**Vendors:** [Aztec Network](../vendors/aztec.md), [Miden](../vendors/miden.md) -- Settlement Coordination: Native ERC-7573 implementations with privacy-preserving relayers -- Cash Domain: [Private Payments](../approaches/approach-private-payments.md) infrastructure (Railgun, Aztec) -- Asset Domain: [Privacy L2s](../patterns/pattern-privacy-l2s.md), [Shielded Pools](../patterns/pattern-shielding.md), [Privacy Pools](../vendors/privacypools.md) -- Institutional Services: [MPC Custody](../patterns/pattern-mpc-custody.md) providers, institutional relayer networks +#### Single-Chain Trade-off Summary -**Supporting Infrastructure:** +| Dimension | UTXO Shielded Pool | Privacy L2 | +|-----------|-------------------|------------| +| **Privacy** | Amounts + addresses | Full state encryption | +| **Cost** | Medium-high (L1 gas) | Low (L2 execution) | +| **Maturity** | Production | Testnet (2026) | +| **Composability** | Shielded pool + DeFi via Adapt Modules | Within L2 ecosystem | +| **Off-ramping** | Unshield to ERC-20 (linkability) | Bridge to L1 (bridge risk) | -- Compliance: [ERC-3643 ONCHAINID](../patterns/pattern-erc3643-rwa.md), [Chainlink ACE](../vendors/chainlink-ace.md) for regulatory compliance automation +### Cross-Chain Private Settlement -### Implementation Strategy +**No trustless atomic cross-chain private settlement solution exists.** Networks are independent — a transaction can succeed on one chain while reverting on another. All cross-chain approaches introduce trust assumptions beyond cryptography. -**Phase 1: Single-Network Private Settlement** +For atomicity mechanisms (HTLCs, escrow, conditional transfers), see [Atomic DvP Settlement](approach-dvp-atomic-settlement.md). Below covers how to add privacy to cross-chain coordination. -- Deploy privacy-preserving DvP on chosen privacy infrastructure -- Implement basic settlement coordination with single asset/cash pairs -- Establish selective disclosure mechanisms for regulatory compliance +#### Approach A: TEE+ZK Coordination -**Phase 2: Cross-Network Coordination** +**Primary Pattern:** [Hybrid TEE + ZK Settlement](../patterns/pattern-tee-zk-settlement.md) -- Implement ERC-7573 conditional settlement across networks -- Deploy trusted or MPC relayer infrastructure -- Integrate with existing custodial and settlement systems +A TEE coordinator matches orders privately, generates zero-knowledge proofs of correct execution, and coordinates settlement across chains using stealth addresses with timeout-based refunds. -**Phase 3: Complex Multi-Asset Settlement** +- **Primitives**: Attested TEEs, zero-knowledge proofs, stealth addresses (EIP-5564), dual spending conditions (stealth key OR timeout refund) +- **Trust model**: Hardware vendor can observe plaintext during execution. Attestation infrastructure must be verified +- **Atomicity**: Timeout-based, not cryptographic — if TEE fails mid-settlement, funds are recoverable after timeout but not atomically settled +- **Best for**: Institutional contexts where hardware trust is already accepted (HSM infrastructure, custodial environments) +- **Maturity**: PoC stage -- Support for multi-leg trades and complex settlement patterns -- Advanced risk management and collateral optimization -- Full integration with traditional settlement infrastructure +#### Approach B: MPC/Threshold Settlement -## More Details +A distributed committee of MPC nodes coordinates settlement. Threshold signatures authorize transfers on each chain, with slashing for misbehavior. -### Trade-offs +- **Primitives**: MPC committee, threshold signatures (t-of-n), slashing contracts, encrypted state sharing +- **Trust model**: Honest majority — assumes fewer than t nodes collude. Economic security via staked collateral +- **Atomicity**: Economic — misbehavior results in slashing penalties, not cryptographic prevention +- **Best for**: Decentralized coordination without hardware trust. Scenarios requiring auditability of the coordination layer +- **Maturity**: Emerging (threshold networks exist, private settlement coordination is novel) -**Single vs Multi-Network Settlement:** +#### Approach C: Intent-Based Settlement (EIP-7683) -- Single Network: Simpler coordination, limited to network's liquidity/privacy characteristics -- Multi-Network: Optimized execution but increased coordination complexity -- **Recommendation:** Multi-network for institutional requirements, single-network for simpler use cases +Parties express settlement intents. Competitive solvers fill orders using their own capital across chains, then settle with the protocol. -**Trusted vs Trustless Coordination:** +- **Primitives**: [EIP-7683](https://eips.ethereum.org/EIPS/eip-7683) cross-chain intents, solver/filler network, reputation systems, collateral pools +- **Trust model**: Economic — solver incentives, collateral adequacy, and reputation. No hardware or cryptographic trust in the coordination layer +- **Atomicity**: Economic — solvers bear execution risk and are compensated for it +- **Privacy**: Variable — intents are visible to solvers (privacy-preserving solver discovery is an open problem). Settlement execution can integrate with private payment rails +- **Best for**: Asynchronous settlement where slight timing flexibility is acceptable. Competitive execution and price improvement +- **Maturity**: Early production (EIP-7683 standard published, solver networks emerging) -- Trusted Relayers: Faster settlement, institutional relationships, centralization risks -- MPC/Trustless: Decentralized coordination, higher complexity, emerging technology -- **Recommendation:** Trusted relayers for initial deployment with MPC migration path +#### Cross-Chain Trade-off Summary -### Open Questions +| Dimension | TEE+ZK | MPC/Threshold | Intent-Based | +|-----------|--------|---------------|-------------| +| **Trust** | Hardware vendor | Honest majority (t-of-n) | Economic incentives | +| **Privacy** | Strong (encrypted coordination) | Strong (MPC) | Weak (intents visible to solvers) | +| **Atomicity** | Timeout-based | Economic (slashing) | Economic (solver risk) | +| **Latency** | Low (enclave speed) | Medium (MPC rounds) | Variable (solver competition) | +| **Maturity** | PoC | Emerging | Early production | -1. **Cross-Network Finality:** How to handle different finality guarantees across networks in conditional settlement? +### Compliance -2. **Regulatory Harmonization:** Standardization of cross-border settlement reporting and compliance requirements? +All approaches support selective disclosure via [regulatory disclosure keys and proofs](../patterns/pattern-regulatory-disclosure-keys-proofs.md). Per-note viewing keys (UTXO), incoming viewing keys (Privacy L2), or TEE-mediated disclosure provide regulator access without breaking privacy for other parties. See [Private Bonds: Compliance](approach-private-bonds.md) for detailed comparison. -3. **Liquidity Fragmentation:** Impact of privacy requirements on market liquidity and price discovery? - -4. **Custodial Integration:** Standards for integrating privacy-preserving settlement with existing custodial infrastructure? +## More Details -5. **Failure Recovery:** Operational procedures for handling complex multi-network settlement failures? +### Implementation Recommendations -### Alternative Approaches Considered +**Decision framework:** Choose same-network settlement if both assets can coexist on one network. Resort to cross-network only when liquidity fragmentation or regulatory constraints force it. -**Traditional HTLC Settlement** +- **Phase 1**: Single-network private DvP on production infrastructure (shielded pool) +- **Phase 2**: Multi-asset settlement on same network (bonds + cash + collateral) +- **Phase 3**: Cross-network coordination with TEE or MPC if required by use case -- Use case: Simple atomic swaps without complex coordination -- Trade-off: Simpler implementation vs brittleness and limited institutional features -- Limitation: Lacks privacy preservation and institutional settlement patterns +### Research Directions -**Pure On-Chain Settlement** +These approaches are not production-ready but may reshape cross-chain private settlement: -- Use case: Maximum transparency and composability -- Trade-off: Full on-chain visibility vs privacy requirements -- Limitation: Exposes all trading information publicly +- **Realtime proving**: [Synchronous cross-rollup composability](https://ethresear.ch/t/synchronous-composability-between-rollups-via-realtime-proving/23998) via validity proofs generated within block time. Enables true atomic cross-rollup transactions but requires shared sequencing infrastructure +- **Based sequencing**: L1 proposers sequence L2 transactions, potentially enabling atomic L1↔L2 settlement without trusted intermediaries +- **Privacy-preserving solver networks**: Encrypted intent discovery and execution for EIP-7683 — would address the privacy gap in intent-based settlement -**Centralized Settlement with Proof** +### Open Questions -- Use case: High-performance settlement with cryptographic attestation -- Trade-off: Performance vs decentralization -- Pattern: Traditional settlement with ZK proofs of correct execution +1. **Privacy set economics**: What minimum shielded pool size provides adequate anonymity for institutional trade sizes? +2. **Cross-chain necessity**: Can tokenized deposit networks (EURC, USDC) deploy on privacy L2s to eliminate cross-chain needs for cash legs? +3. **Regulatory acceptance**: Which trust models (TEE, MPC, economic) satisfy regulatory requirements across jurisdictions? +4. **Solver privacy**: Can intent-based architectures preserve order privacy while enabling competitive execution? ## Example Scenarios -### Scenario 1: Cross-Border Bond Settlement +### Scenario 1: Same-Chain Bond DvP (Shielded Pool) -- European bank trades $100M US corporate bonds with Asian counterparty -- **Cash Settlement:** USDC on Ethereum L1 (where liquidity exists) -- **Bond Transfer:** Private execution on Aztec L2 (for confidentiality) -- **Coordination:** ERC-7573 with trusted relayer ensuring atomicity across networks -- **Compliance:** Selective disclosure to relevant regulators in both jurisdictions +- Asset manager sells EUR 25M corporate bonds to bank counterparty +- Both parties hold assets in Railgun shielded pool on Ethereum L1 +- Coordinated JoinSplit: bond notes consumed, EURC notes consumed, new notes created for each party +- Single atomic transaction — no coordination risk +- Regulator receives viewing key for audit access to both sides -### Scenario 2: Multi-Asset Derivatives Settlement +### Scenario 2: Cross-Chain Bond Settlement (TEE+ZK) -- Hedge fund settles complex derivatives package involving bonds, cash, and collateral -- **Collateral:** Privacy L2 for confidential margin management -- **Cash:** Public stablecoin network for efficient settlement -- **Bonds:** Shielded pools for private bond transfers -- **Coordination:** MPC relayers coordinating across all three domains +- European issuer's bonds on privacy L2, buyer's USDC on Ethereum L1 +- TEE coordinator matches and validates, locks notes to stealth addresses with 24h timeout +- Zero-knowledge proof submitted on-chain, TEE reveals stealth keys on success +- Failure path: TEE crash → both parties reclaim via timeout refund -### Scenario 3: Supply Chain Finance Settlement +### Scenario 3: Multi-Currency PvP (Intent-Based) -- Manufacturer settles trade finance involving multiple suppliers and currencies -- **Payment Rails:** Different stablecoins optimized for different regions -- **Asset Documentation:** Private transfer of trade documents and ownership -- **Settlement:** Coordinated settlement across multiple networks and asset types -- **Compliance:** Selective disclosure for trade finance regulations and ESG reporting +- Treasury desk swaps EUR stablecoin (Chain A) for USD stablecoin (Chain B) +- Publishes EIP-7683 intent with amount and acceptable rate +- Solver fills order from own inventory on both chains, settles atomically from solver's perspective +- Treasury receives fill on destination chain — solver assumes cross-chain execution risk ## Links and Notes -- **Standards:** [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573), [ERC-3643](https://eips.ethereum.org/EIPS/eip-3643), [ISO 20022](../patterns/pattern-private-iso20022.md) -- **Patterns:** [DvP ERC-7573](../patterns/pattern-dvp-erc7573.md), [MPC Custody](../patterns/pattern-mpc-custody.md) -- **Infrastructure:** [Aztec Network](https://docs.aztec.network/), [Railgun](https://railgun.org/), [Chainlink ACE](../vendors/chainlink-ace.md) +- **Standards:** [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573) (cross-network DvP, draft), [EIP-7683](https://eips.ethereum.org/EIPS/eip-7683) (cross-chain intents), [ERC-3643](https://eips.ethereum.org/EIPS/eip-3643) (permissioned tokens), [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564) (stealth addresses) +- **Patterns:** [Hybrid TEE + ZK Settlement](../patterns/pattern-tee-zk-settlement.md), [DvP ERC-7573](../patterns/pattern-dvp-erc7573.md), [Shielding](../patterns/pattern-shielding.md), [Privacy L2s](../patterns/pattern-privacy-l2s.md), [Cross-Chain Privacy Bridge](../patterns/pattern-cross-chain-privacy-bridge.md), [ZK-SPV Verification](../patterns/pattern-zk-spv.md) +- **Related Approaches:** [Atomic DvP Settlement](approach-dvp-atomic-settlement.md) (atomicity mechanisms), [Private Payments](approach-private-payments.md), [Private Bonds](approach-private-bonds.md) +- **Research:** [Synchronous composability via realtime proving](https://ethresear.ch/t/synchronous-composability-between-rollups-via-realtime-proving/23998) - **Regulatory:** [eWpG Compliance](../jurisdictions/de-eWpG.md), [MiCA Framework](../jurisdictions/eu-MiCA.md) -- **Related Approaches:** [Private Payments](../approaches/approach-private-payments.md), [Private Derivatives](../approaches/approach-private-derivatives.md), [Private Bonds](../approaches/approach-private-bonds.md) diff --git a/patterns/pattern-network-anonymity.md b/patterns/pattern-network-anonymity.md new file mode 100644 index 0000000..dbd657f --- /dev/null +++ b/patterns/pattern-network-anonymity.md @@ -0,0 +1,154 @@ +--- +title: "Pattern: Network-Level Anonymity" +status: draft +maturity: PoC +layer: offchain +privacy_goal: Hide sender identity (IP, timing, query patterns) at the transport layer +assumptions: Network observer is a threat; content-layer privacy is handled separately +last_reviewed: 2026-02-20 +works-best-when: + - Metadata leakage (IP, timing, query patterns) is a threat model concern + - Content privacy alone is insufficient — "who" matters as much as "what" + - Both read privacy (RPC queries) and write privacy (transaction submission) are needed +avoid-when: + - Threat model does not include network-level observers + - Institution runs its own full node (eliminates RPC provider trust) + - On-chain content privacy is the only requirement +dependencies: [] +--- + +## Intent + +Hide *who* is sending transactions or querying state at the network layer. Content-privacy patterns (ZK, FHE, MPC) hide *what* is in a transaction but not *who* submitted it — IP addresses, timing, and query patterns still leak sender identity. Network-level anonymity complements content privacy to close the metadata gap. + +This is an umbrella pattern. Multiple approaches exist, each with different trade-offs along the **anonymity trilemma**: anonymity set size, latency, and bandwidth overhead. No single approach dominates; the right choice depends on the institution's latency tolerance, threat model, and infrastructure constraints. + +## Ingredients + +- Cryptographic: onion encryption, mix-and-shuffle, secret sharing, cover traffic +- Hardware: client-side TEE (for TEE-assisted approach only) +- Infra: relay/mix network or anonymity server cluster, private RPC endpoint + +## Protocol (concise) + +1. Client prepares transaction or RPC query for submission. +2. Client routes message through chosen anonymity layer (relay network, mixnet, TEE cluster, or proxy). +3. Anonymity layer strips or obscures sender metadata (IP, timing, query pattern). +4. Message reaches destination (RPC node, mempool) without attribution to sender. +5. Response returns through the same or separate anonymous channel. + +## Anonymity Trilemma + +Any network anonymity system must trade off between three properties: + +- **Anonymity set size** — how many users your traffic blends with +- **Latency** — delay introduced by the anonymity mechanism +- **Bandwidth overhead** — cover traffic or padding required + +Pure-cryptographic approaches (Tor, mixnets, DC-Nets) must sacrifice at least one. Hardware-assisted approaches (TEE) relax the trilemma by offloading verification to hardware but introduce a hardware trust assumption. + +## Approaches + +### 1. Onion routing (Tor) + +Route traffic through multiple relay nodes; each relay peels one encryption layer. No single relay sees both sender and destination. + +| Property | Value | +|----------|-------| +| Anonymity set | Large (global Tor network) | +| Latency | High (3+ hops, ~200-500ms added) | +| Trust model | No single relay sees full path; vulnerable to global passive adversary | +| Maturity | Production (general-purpose); limited blockchain-specific deployment | + +**Trade-offs:** High latency makes it unsuitable for latency-sensitive DeFi. Exit nodes can observe unencrypted traffic. Well-resourced adversaries can perform traffic correlation attacks. + +### 2. Mixnets (Nym, Loopix) + +Messages are batched, delayed, reordered, and padded with cover traffic before forwarding. Provides stronger anonymity than onion routing against global adversaries. + +| Property | Value | +|----------|-------| +| Anonymity set | Medium-large (depends on cover traffic volume) | +| Latency | Very high (seconds to minutes, by design) | +| Trust model | Threshold trust across mix nodes; cover traffic defeats timing analysis | +| Maturity | Pilot (Nym network live but limited blockchain integration) | + +**Trade-offs:** Highest anonymity guarantees but latency is prohibitive for real-time use cases. Cover traffic adds bandwidth cost. + +### 3. Private RPC / trusted proxy + +Route queries through a trusted intermediary that strips identifying metadata before forwarding to the RPC provider. + +| Property | Value | +|----------|-------| +| Anonymity set | Small (trust boundary is the proxy operator) | +| Latency | Low (single hop) | +| Trust model | Full trust in proxy operator not to log or leak | +| Maturity | Production (multiple vendors offer private RPC endpoints) | + +**Trade-offs:** Simplest to deploy but weakest anonymity — shifts trust from RPC provider to proxy. Acceptable when the proxy is the institution itself or a contractually bound party. + +### 4. TEE-assisted anonymity (Flashnet) + +Client-side TEE secret-shares messages across a server network; homomorphic aggregation reveals messages but not which client sent which. See [TEE-Assisted Network Anonymity](pattern-tee-network-anonymity.md) for full protocol. + +| Property | Value | +|----------|-------| +| Anonymity set | Medium (all clients in the epoch) | +| Latency | Low (suitable for DeFi) | +| Trust model | Client TEE for liveness; semi-honest server majority; crypto preserves anonymity even if TEE is compromised | +| Maturity | PoC (Flashbots Flashnet, research stage) | + +**Trade-offs:** Relaxes the anonymity trilemma via hardware but introduces client-side TEE dependency. TEE compromise loses liveness, not anonymity. + +### 5. VPN / encrypted tunnel + +Route all blockchain traffic through a VPN. Hides IP from the RPC provider but the VPN operator sees everything. + +| Property | Value | +|----------|-------| +| Anonymity set | None (VPN operator sees all traffic) | +| Latency | Low | +| Trust model | Full trust in VPN provider | +| Maturity | Production | + +**Trade-offs:** Hides IP from destination but does not provide anonymity — merely shifts the observer from RPC provider to VPN provider. Insufficient as a standalone solution but may be part of defense in depth. + +## Comparison Matrix + +| Approach | Latency | Anonymity strength | Trust assumption | Read + Write | Maturity | +|----------|---------|-------------------|------------------|--------------|----------| +| Tor | High | Strong | No single relay | Both | Prod | +| Mixnet | Very high | Strongest | Threshold mix nodes | Both | Pilot | +| Private RPC | Low | Weak | Proxy operator | Reads mainly | Prod | +| TEE-assisted | Low | Medium | Client TEE + server majority | Both | PoC | +| VPN | Low | Minimal | VPN provider | Both | Prod | + +## Guarantees + +- Hides sender IP, timing correlation, and query-to-identity mapping (strength varies by approach). +- Complements content-privacy patterns — together they hide both *what* and *who*. +- Does not hide message content; pair with ZK, FHE, or MPC patterns for full-stack privacy. + +## Trade-offs + +- No approach simultaneously achieves strong anonymity, low latency, and low bandwidth (anonymity trilemma). +- Stronger anonymity generally means higher latency — institutional latency requirements constrain the choice. +- All approaches except mixnets are vulnerable to a sufficiently powerful global passive adversary. +- Operational complexity varies significantly: VPN is trivial; mixnet integration is non-trivial. + +## Example + +1. Fund manager needs to query 50 token balances to value a portfolio. +2. Without network anonymity, the RPC provider sees all queried addresses — revealing holdings and strategy. +3. **Tor**: queries routed through 3 relays; RPC provider cannot trace back to the fund. Added latency (~300ms/query) acceptable for end-of-day valuation. +4. **TEE-assisted**: queries secret-shared across anonymity servers; RPC provider sees aggregated queries from many clients. Low latency suitable for intraday checks. +5. **Private RPC**: queries proxied through institution's own relay; RPC provider sees relay IP only. Simplest but trusts the relay operator. + +## See also + +- [TEE-Assisted Network Anonymity](pattern-tee-network-anonymity.md) — TEE+secret-sharing approach (Flashnet) +- [Private Transaction Broadcasting](pattern-private-transaction-broadcasting.md) — content privacy for writes (complementary) +- [Threshold Encrypted Mempool](pattern-threshold-encrypted-mempool.md) — content privacy via threshold encryption +- [RFP: Private Reads](../rfps/rfp-private-reads.md) — read-side privacy gap +- [Modular Privacy Stack](pattern-modular-privacy-stack.md) — where network anonymity fits in the four-layer architecture diff --git a/patterns/pattern-tee-based-privacy.md b/patterns/pattern-tee-based-privacy.md index ed1564b..3466ed2 100644 --- a/patterns/pattern-tee-based-privacy.md +++ b/patterns/pattern-tee-based-privacy.md @@ -5,7 +5,7 @@ maturity: pilot layer: offchain privacy_goal: Protect computation and data confidentiality via hardware-isolated execution assumptions: Hardware vendor trust, attestation infrastructure, physical security of deployment environment -last_reviewed: 2026-01-14 +last_reviewed: 2026-02-13 works-best-when: - Confidential computation needed with lower latency than ZK proofs - Parties accept hardware trust assumptions over cryptographic-only solutions @@ -14,7 +14,8 @@ avoid-when: - Threat model includes nation-state physical access or supply-chain compromise - Full trustlessness required (prefer ZK or MPC alternatives) - Long-term secrets that outlive hardware security lifecycle -dependencies: [Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves, Azure Confidential Computing] +dependencies: + [Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves, Azure Confidential Computing] --- ## Intent @@ -25,11 +26,13 @@ This is a foundational pattern describing TEE trust models and failure modes. Sp ## Ingredients -- **Hardware Platforms**: - - **Intel SGX**: Process-level enclaves with memory encryption (SGX1, SGX2, SGX3) - - **AMD SEV-SNP**: VM-level isolation with memory encryption and integrity - - **AWS Nitro Enclaves**: Isolated VMs with no persistent storage, no network access - - **Azure Confidential Computing**: SGX and SEV-SNP offerings with attestation services +- **Hardware Platforms** (two categories with different trust models): + - _CPU-encrypted (hardware TEEs)_: Memory encrypted by the CPU itself; protects data even from the host OS and hypervisor + - **[Intel SGX](https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html)**: Process-level enclaves, 90–128 MB encrypted memory (EPC). Attestation rooted in Intel signing keys + - **[AMD SEV-SNP](https://www.amd.com/en/developer/sev.html)**: VM-level isolation with full memory encryption and integrity. Attestation rooted in AMD signing keys + - _Hypervisor-isolated (VM TEEs)_: Isolation enforced by a minimal hypervisor; no CPU-level memory encryption + - **[AWS Nitro Enclaves](https://aws.amazon.com/ec2/nitro/nitro-enclaves/)**: Isolated VMs with no persistent storage, no network access. Attestation signed by AWS root CA + - **[Azure Confidential Computing](https://azure.microsoft.com/en-us/solutions/confidential-compute/)**: Offers both SGX and SEV-SNP; also provides attestation-as-a-service - **ARM TrustZone**: Mobile/embedded TEE (less common in institutional settings) - **Attestation Infrastructure**: @@ -47,13 +50,28 @@ This is a foundational pattern describing TEE trust models and failure modes. Sp ### Who Must Be Trusted -| Entity | Trust Requirement | Mitigation | -|--------|-------------------|------------| -| **Hardware Vendor** | Correct implementation, no backdoors | Vendor reputation, third-party audits, multi-vendor strategy | -| **Firmware/Microcode** | No vulnerabilities, timely patches | TCB recovery, update policies, attestation checks | -| **Cloud Provider** | Physical security, correct hypervisor | Contractual obligations, attestation, multi-cloud | -| **Operator** | Correct deployment, no tampering | Remote attestation, sealed secrets, audit logs | -| **Code Author** | Correct enclave logic | Open source, audits, formal verification | +| Entity | Trust Requirement | Mitigation | +| ---------------------- | ------------------------------------- | ------------------------------------------------------------ | +| **Hardware Vendor** | Correct implementation, no backdoors | Vendor reputation, third-party audits, multi-vendor strategy | +| **Firmware/Microcode** | No vulnerabilities, timely patches | TCB recovery, update policies, attestation checks | +| **Cloud Provider** | Physical security, correct hypervisor | Contractual obligations, attestation, multi-cloud | +| **Operator** | Correct deployment, no tampering | Remote attestation, sealed secrets, audit logs | +| **Code Author** | Correct enclave logic | Open source, audits, formal verification | + +### Platform Threat Model Comparison + +| | CPU-encrypted (SGX, SEV) | Hypervisor-isolated (Nitro) | +| ------------------------- | --------------------------------------------------------- | ------------------------------------ | +| **Protects from** | Host OS, hypervisor, cloud provider | Parent instance, other tenants | +| **Does NOT protect from** | CPU manufacturer (holds master keys) | Cloud provider (controls hypervisor) | +| **Memory encryption** | CPU silicon | None (hypervisor boundary only) | +| **Attestation root** | CPU manufacturer signing keys | Cloud provider root CA | +| **Side-channel exposure** | High (CPU-level: Spectre, cache timing) | Lower (VM boundary) | +| **Institutional analogy** | "Programmable enclave" (weaker than HSM — see note below) | "Locked-down VM you can't SSH into" | + +For institutions already trusting a cloud provider with their infrastructure, hypervisor-isolated TEEs are operationally simpler. When protection _from_ the cloud provider is needed, CPU-encrypted TEEs are required. + +> **TEE ≠ HSM.** HSMs provide physical tamper resistance (EAL5–7), dedicated silicon, and minimal firmware surface. TEEs offer general-purpose computation with logical isolation but share the CPU die, lack physical tamper resistance (EAL2–4), and have a larger attack surface with documented side-channel history. Contractual controls (NDA, audit rights, SLAs) partially mitigate this gap but do not close it. Treat TEEs as complementary to HSMs, not replacements. ### What TEEs Protect @@ -64,7 +82,9 @@ This is a foundational pattern describing TEE trust models and failure modes. Sp ### What TEEs Do NOT Protect - **Availability**: Host can deny service, power off, or refuse to schedule enclave -- **Side Channels**: Timing, cache, power, and speculative execution leaks possible +- **I/O Channel Control**: Host operator controls all enclave communication (e.g., vsock) and can intercept, reorder, drop, replay, and inject messages — even without reading enclave memory +- **Communication Metadata**: Packet sizes, processing duration, and connection patterns remain visible even with encrypted payloads, leaking operation types +- **Side Channels**: Timing, cache, power, and speculative execution leaks remain possible without constant-time cryptography and platform-specific mitigations - **Physical Attacks**: Sophisticated attackers with hardware access may extract secrets - **Supply Chain**: Compromised hardware from manufacturing may have backdoors @@ -79,14 +99,16 @@ This is a foundational pattern describing TEE trust models and failure modes. Sp ## Failure Modes -| Failure Mode | Description | Impact | Mitigation | -|--------------|-------------|--------|------------| -| **Supply Chain Compromise** | Backdoored hardware from manufacturing | Complete confidentiality loss | Multi-vendor, hardware audits, attestation checks | -| **Firmware Vulnerability** | Exploitable bugs in microcode/firmware | Enclave escape, secret extraction | TCB recovery, rapid patching, version policies | -| **Side-Channel Attack** | Cache timing, Spectre/Meltdown variants | Partial secret leakage | Constant-time code, partitioning, updates | -| **Rollback Attack** | Replay of old sealed state | Policy bypass, double-spend | Monotonic counters, external anchoring | -| **Denial of Service** | Host refuses to run enclave | Availability loss | Redundancy, fallback procedures, SLAs | -| **Key Exfiltration** | Bug in enclave code leaks secrets | Complete compromise | Audits, formal verification, minimal TCB | +| Failure Mode | Description | Impact | Mitigation | +| --------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | +| **Supply Chain Compromise** | Backdoored hardware from manufacturing | Complete confidentiality loss | Multi-vendor, hardware audits, attestation checks | +| **Firmware Vulnerability** | Exploitable bugs in microcode/firmware | Enclave escape, secret extraction | TCB recovery, rapid patching, version policies | +| **Side-Channel Attack** | Cache timing, Spectre/Meltdown variants | Partial secret leakage | Constant-time code, partitioning, updates | +| **Rollback Attack** | Replay of old sealed state | Policy bypass, double-spend | Monotonic counters, external anchoring | +| **Denial of Service** | Host refuses to run enclave | Availability loss | Redundancy, fallback procedures, SLAs | +| **I/O Manipulation** | Operator intercepts, reorders, or injects messages on the channel | Data corruption, front-running, censorship | Authenticated channels with sequence numbers, ZK proofs of execution, multi-operator setups | +| **Incomplete Attestation Verification** | Client skips certificate chain or platform register validation | Code substitution while attestation appears valid | Validate full certificate chain to vendor root CA, check all platform registers, use nonce freshness | +| **Key Exfiltration** | Bug in enclave code leaks secrets | Complete compromise | Audits, formal verification, minimal TCB | ## Guarantees @@ -105,22 +127,26 @@ This is a foundational pattern describing TEE trust models and failure modes. Sp ## When TEEs Are Appropriate -| Use Case | TEE Fit | Notes | -|----------|---------|-------| -| Hot key management | Good | Faster than MPC; acceptable trust for operational keys | -| Private matching engine | Good | Real-time performance; ZK too slow for orderbooks | -| Bridge/oracle relayer | Acceptable | Defense in depth with other controls | -| Long-term custody | Poor | Prefer MPC or cold storage for years-long secrets | -| Regulatory-critical audit | Uncertain | Depends on regulator acceptance | +| Use Case | TEE Fit | Notes | +| ------------------------- | ---------- | ------------------------------------------------------ | +| Hot key management | Good | Faster than MPC; acceptable trust for operational keys | +| Private matching engine | Good | Real-time performance; ZK too slow for orderbooks | +| Bridge/oracle relayer | Acceptable | Defense in depth with other controls | +| Long-term custody | Poor | Prefer MPC or cold storage for years-long secrets | +| Regulatory-critical audit | Uncertain | Depends on regulator acceptance | + +## Defense Layers -## Upgrade Paths +A TEE alone is insufficient for high-value production workloads. Each layer reduces the trust surface: -TEEs should be viewed as a transitional technology when pure cryptographic solutions are impractical: +| Layer | Composition | What it adds | +| ------------------------ | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **TEE only** | Single enclave, single operator | Memory isolation. Vulnerable to operator I/O manipulation, side-channels, single point of compromise. Suitable for pilots and low-value operations only | +| **TEE + Threshold Keys** | Key material distributed across multiple TEE instances operated by independent parties | No single compromise yields full key. Minimum viable for production custody and coordination | +| **TEE + ZK** | TEE executes, produces ZK proof verified on-chain | Mitigates operator I/O manipulation: even if the operator tampers with inputs/outputs, the ZK proof will not verify unless execution was correct. Removes dependency on attestation infrastructure for verifiability (see [Hybrid TEE + ZK Settlement](pattern-tee-zk-settlement.md)) | +| **TEE + Threshold + ZK** | Full defense in depth | Threshold trust, cryptographic verifiability, hardware isolation as complementary layers | -1. **TEE → MPC**: Migrate key management to threshold schemes as MPC performance improves -2. **TEE → ZK**: Replace confidential computation with ZK proofs when circuits become practical -3. **TEE + ZK Hybrid**: Use TEE for execution, ZK for verifiable output (see pattern-tee-zk-settlement) -4. **Multi-TEE**: Distribute across vendors/platforms to reduce single-vendor risk +> **GPU TEEs**: For compute-intensive workloads offloaded to GPU (ZK proving, ML inference), GPU confidential computing (e.g., NVIDIA H100) extends the TEE boundary to accelerators. GPU attestation should be verified within the CPU TEE before offloading sensitive data. ## Example @@ -142,8 +168,7 @@ TEEs should be viewed as a transitional technology when pure cryptographic solut ## See also (external) -- Intel SGX: https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html -- AMD SEV: https://www.amd.com/en/developer/sev.html -- AWS Nitro Enclaves: https://aws.amazon.com/ec2/nitro/nitro-enclaves/ -- Azure Confidential Computing: https://azure.microsoft.com/en-us/solutions/confidential-compute/ +- Bluethroat Labs TEE Security Handbook: https://docs.bluethroatlabs.com/ +- Confidential Computing Consortium (Linux Foundation): https://confidentialcomputing.io/ +- awesome-tee-blockchain (curated resource list): https://github.com/dineshpinto/awesome-tee-blockchain - TEE security research: https://tee.dev/ diff --git a/patterns/pattern-tee-key-manager.md b/patterns/pattern-tee-key-manager.md index b3ea5c2..134df16 100644 --- a/patterns/pattern-tee-key-manager.md +++ b/patterns/pattern-tee-key-manager.md @@ -93,8 +93,9 @@ External systems bind the signer public key and policy hash to an approved attes ## Trade-offs - **Trust surface** - - Security depends on the TEE vendor (silicon, microcode, attestation roots/keys), the operator (physical security, provisioning, availability), and TEE code (correct, non-malicious policy logic), plus the attestation verifier and registry. + - Security depends on the TEE vendor (silicon, microcode, attestation roots/keys), the operator (physical security, provisioning, availability, and I/O channel control), and TEE code (correct, non-malicious policy logic), plus the attestation verifier and registry. - These are stronger trust assumptions than fully trust-minimised custody (for example, MPC without hardware trust anchors) and must be reflected in risk assessments. + - TEE key isolation provides weaker guarantees than HSM custody (no physical tamper resistance, larger attack surface, documented side-channel history). In institutional settings, contractual controls with TEE operators partially mitigate this gap. Treat TEE key managers as complementary to HSMs, not replacements. - **Attack and failure modes** - Supply-chain or firmware compromise can break TEE isolation or allow forged/meaningless attestation. @@ -106,9 +107,9 @@ External systems bind the signer public key and policy hash to an approved attes - Secure provisioning, protected-state handling, monitoring, re-attestation, key rotation, and incident response runbooks are required; loss or corruption of protected state without a recovery plan can render keys unusable. - TEE execution and policy checks add latency and cap throughput, making this pattern better suited to treasury, validator, and institutional flows than very high-frequency trading. -- **Lifecycle and upgrade path** - - TEEs offer a short- to medium-term way to improve key isolation where pure software custody is insufficient and MPC or threshold schemes are not yet practical at the required scale. - - Over time, long-lived custody keys can migrate to MPC or threshold schemes that reduce reliance on a single hardware trust anchor, with the TEE reduced to a control-plane component or phased out. +- **Single-TEE limitation** + - A single TEE instance is a single point of compromise. For production custody, threshold key distribution across multiple TEE instances operated by independent parties is recommended. Single-TEE deployments are acceptable for pilot use or warm/operational keys with limited exposure. + - See [TEE-Based Privacy — Defense Layers](pattern-tee-based-privacy.md#defense-layers) for the layered security model. ## Example diff --git a/patterns/pattern-tee-network-anonymity.md b/patterns/pattern-tee-network-anonymity.md new file mode 100644 index 0000000..81c1bd8 --- /dev/null +++ b/patterns/pattern-tee-network-anonymity.md @@ -0,0 +1,72 @@ +--- +title: "Pattern: TEE-Assisted Network Anonymity" +status: draft +maturity: PoC +layer: offchain +privacy_goal: Hide sender identity (IP, timing) for both reads and writes at the transport layer +assumptions: TEE availability on client side, semi-honest server majority +last_reviewed: 2026-02-18 +works-best-when: + - Metadata leakage (IP, timing, query patterns) is a threat + - Low latency is required (rules out Tor/mixnets) + - Both read and write privacy are needed from the same infrastructure +avoid-when: + - Threat model does not include network observers + - Running own node eliminates RPC provider trust + - High-latency anonymity networks (Tor, Nym) are acceptable +dependencies: [TEE (client-side), Secret sharing, Additive homomorphic commitments] +--- + +## Intent + +Hide *who* is sending transactions or querying state at the network layer. Existing privacy patterns hide *what* (transaction content, balances) but not *who* — IP addresses, timing, and query patterns still leak sender identity. This pattern provides sender anonymity for both writes (transaction submission) and reads (RPC queries) with latency suitable for DeFi. + +## Ingredients + +- Cryptographic: secret sharing, additive homomorphic commitments +- Hardware: client-side TEE (ensures correct secret sharing without revealing message) +- Infra: server network (semi-honest majority), leader node for output reconstruction + +## Protocol (concise) + +1. Client positions message (transaction or query) in a random slot of a fixed-size array. +2. Client TEE secret-shares the array across servers, verifying correct construction. +3. Servers receive encrypted shares; no single server sees the original message. +4. Servers compute homomorphic sums over all client shares. +5. Leader reconstructs aggregated output from server contributions. +6. Output reveals messages but not which client sent which message. + +## Guarantees + +- Hides sender IP, timing correlation, and query-to-identity mapping. +- TEE compromise loses liveness (system stalls), never anonymity (crypto layer preserves it). +- Same infrastructure anonymizes both transaction submission and state queries. +- Does not hide message content — pair with content-privacy patterns for full stack. + +## Trade-offs + +- Anonymity trilemma: anonymity set size, latency, and bandwidth (cover traffic) are in tension. Pure-crypto approaches (Tor, Nym, DC-Nets) must sacrifice at least one. TEE-assisted designs like Flashnet relax the trilemma by offloading verification to hardware, but introduce a hardware trust assumption for liveness. +- Client TEEs required for liveness; hardware trust for availability only, not privacy. +- Requires semi-honest majority among servers; colluding majority can break liveness. +- Research-stage (Flashbots Flashnet); no production deployment yet. + +## Example + +1. Fund manager queries 50 token balances across DeFi protocols to value portfolio. +2. Without network anonymity, RPC provider sees all queried addresses — revealing holdings and strategy. +3. Queries are secret-shared via client TEE across anonymity server network. +4. Servers process shares; RPC provider sees aggregated queries from many clients, cannot attribute any query to the fund manager. +5. Result: Portfolio valued without leaking positions or identity to any infrastructure provider. + +## See also + +- [Network-Level Anonymity](pattern-network-anonymity.md) — general problem and alternative approaches (Tor, mixnets, VPNs) +- [Private Transaction Broadcasting](pattern-private-transaction-broadcasting.md) — content privacy for writes (complementary) +- [Threshold Encrypted Mempool](pattern-threshold-encrypted-mempool.md) — content privacy via threshold encryption +- [TEE-Based Privacy](pattern-tee-based-privacy.md) — broader TEE trust model analysis +- [RFP: Private Reads](../rfps/rfp-private-reads.md) — read-side privacy gap this pattern addresses +- [Vendor: Flashbots](../vendors/flashbots.md) — Flashnet development + +## See also (external) + +- Flashbots Flashnet: https://writings.flashbots.net/network-anonymized-mempools diff --git a/patterns/pattern-tee-zk-settlement.md b/patterns/pattern-tee-zk-settlement.md index d667261..7db33ff 100644 --- a/patterns/pattern-tee-zk-settlement.md +++ b/patterns/pattern-tee-zk-settlement.md @@ -1,60 +1,138 @@ --- title: "Pattern: Hybrid TEE + ZK Settlement" status: draft -maturity: pilot +maturity: PoC layer: hybrid -privacy_goal: Private cross-chain settlement in TEEs with ZK proofs attesting correct execution -assumptions: Attested TEE infrastructure, ZK prover backend, attestation registry -last_reviewed: 2026-01-14 +privacy_goal: Private settlement coordination inside TEEs with zero-knowledge proofs for on-chain verifiability +assumptions: Attested TEE infrastructure, ZK prover backend, attestation registry, participants accept hardware trust +last_reviewed: 2026-02-13 works-best-when: - - Participants accept some trust in TEEs but want zk-based attestations for audit. - - Privacy requirements exceed what public smart contracts can do alone. + - Counterparty risk is the primary concern and atomicity of settlement is the goal + - Privacy breach (operator/manufacturer sees trade details) is an acceptable residual risk manageable through contractual controls + - Settlement coordination requires low latency that client-side ZK cannot meet avoid-when: - - TEE availability or attestation infra is weak/untrusted. - - Regulators reject opaque enclaves. + - Trustless guarantees are required (client-side ZK is preferable) + - Regulators reject opaque enclaves without additional compliance layers + - Simple same-chain transfers where shielded pools suffice without coordination overhead dependencies: - - Attested TEEs (Intel SGX/AMD SEV) - - ZK proof system for attestation validity + - Attested TEEs (Intel SGX, AMD SEV, AWS Nitro) + - zero-knowledge proof system (Groth16/PLONK) + - Stealth address support (EIP-5564) --- ## Intent -Coordinate private cross-chain settlement inside TEEs, with zk-proofs attesting to correct execution — hiding counterparties/amounts but proving atomicity. +Coordinate private settlement inside TEEs, with zero-knowledge proofs attesting correct execution to smart contracts on-chain. The TEE acts as a neutral synchronization layer between parties who do not trust each other — matching orders, managing escrow state, and producing verifiable proofs — while hiding counterparties, amounts, and matching logic from all external observers. + +The key property of this construction is the separation of financial risk from privacy risk. The ZK proof guarantees correct, atomic settlement on-chain regardless of TEE integrity: counterparty risk is eliminated by the protocol, not by trusting the hardware. If the TEE is compromised (operator or manufacturer observes plaintext), the worst case is a privacy breach — trade details are exposed — but no funds are lost and settlement correctness is unaffected. In institutional settings, this residual privacy risk is manageable through contractual controls (NDA, audit rights, penalties) with TEE operators, making it a legal/commercial matter rather than a protocol failure. ## Ingredients -- **Standards**: EAS (attestations), ERC-20/3643 assets -- **Infra**: TEEs on relayers, zk-prover backend -- **Off-chain**: Attestation registry, KMS +- **Standards**: EIP-5564 (stealth addresses), ERC-20/3643 assets, EAS (attestations) +- **TEE platforms**: Intel SGX (90–128 MB EPC), AMD SEV (full VM memory), AWS Nitro Enclaves +- **On-chain**: State commitment contract, zero-knowledge proof verifier, attestation registry, announcement contract (for stealth key revelation) +- **Off-chain**: Encrypted state blobs (replicated), KMS for sealed storage, multiple TEE nodes for availability + +## TEE API Surface + +| Function | Input | Output | Purpose | +|----------|-------|--------|---------| +| `key_gen()` | Entropy source | `(pubkey, attestation_report)` | Generate enclave keypair; report contains code hash + pubkey + hardware signature | +| `attest(measurement)` | Code measurement | `signed_report` | Prove specific code runs unmodified in genuine TEE | +| `process(encrypted_orders[], state)` | User-encrypted orders, current state | `{new_state, encrypted_results[], log}` | Decrypt orders, validate nonces, match counterparties, update state | +| `prove(execution_log)` | Internal execution trace | `zk_proof` | Generate succinct proof of correct matching and state transition | +| `settle(commitment, proof, blobs)` | State root, proof, encrypted outputs | `tx_hash` | Submit proof on-chain, reveal stealth keys via announcement contract | + +Attestation verification: check hardware signature is from known manufacturer, code hash matches expected binary, TEE model is not revoked. + +## Protocol + +1. **Setup**: TEE generates keypair inside enclave, publishes attestation report and public key. Verifiers check report against manufacturer root of trust. +2. **Order submission**: Each party encrypts their order (asset, amount, conditions, nonce) to the TEE public key and submits on-chain or via direct channel. +3. **Matching**: TEE decrypts orders, validates nonces against state (rollback protection), matches counterparties according to settlement rules. +4. **Escrow via stealth addresses**: Notes are locked to stealth addresses derived per-settlement. Each note has dual spending conditions in the zero-knowledge circuit: spendable by the stealth-derived key OR by the original owner after a timeout period. +5. **Proof generation**: TEE generates a zero-knowledge proof attesting: orders were valid, matching followed protocol rules, state transition is monotonic (no rollback), output commitments are correct. +6. **On-chain settlement**: Proof is verified on-chain. On success, the TEE atomically publishes both ephemeral keys to the announcement contract, allowing recipients to derive their spending keys. +7. **Completion or timeout**: Recipients scan the announcement contract, derive spending keys, and claim their notes. If the TEE fails before revealing keys, original owners reclaim notes after the timeout period. + +## Trust Framework + +> For the general TEE threat model, failure modes, and defense layers, see [TEE-Based Privacy](pattern-tee-based-privacy.md). This section covers only what is specific to the settlement protocol. -## Protocol (concise) +**Who sees what:** -1. Parties submit encrypted orders to TEE. -2. TEE executes settlement privately. -3. TEE outputs zk-proof: “Settlement followed protocol, balances match.” -4. Proof verified on-chain; state updates applied. -5. Optional: Audit attestation logged in registry. +| Actor | Sees | Does not see | +|-------|------|-------------| +| Users | Own order details, own settlement outcome | Other parties' orders, matching logic | +| TEE operator | Communication metadata (packet sizes, timing, connection patterns), I/O channel control (can reorder, delay, drop messages) | Enclave memory contents (isolated by hardware) | +| Hardware vendor | Everything during execution (master keys) | Nothing after enclave destroyed | +| Network observers | Commitments, proofs, stealth address outputs | Amounts, counterparties, order flow | +| Auditors | Selectively disclosed data via viewing keys | Full state unless explicitly granted | + +**Threat model:** + +| Threat | Impact | Mitigation | +|--------|--------|------------| +| Hardware vendor compromise | Full plaintext access during execution | Multi-vendor TEE diversity, zero-knowledge proofs limit damage to current session | +| Side-channel attacks (Spectre, cache timing) | Partial data leakage | ORAM inside enclave, constant-time algorithms, firmware patching | +| Rollback / replay attacks | Double-spend, stale state processing | Nonce monotonicity enforced in zero-knowledge proof, on-chain state root anchoring | +| Single TEE failure | Service unavailability, locked funds | Multiple TEE nodes, timeout refund escape hatch in stealth note circuits | +| Fake TEE (no attestation verification) | Operator steals all data | Mandatory attestation verification before encrypting orders | +| Operator metadata leakage | Communication metadata (packet sizes, timing) can reveal trade magnitudes and enable front-running, even though the ZK proof guarantees correct execution | Constant-size message padding, constant-time processing, multi-operator coordination | +| Operator selective delay | Operator stalls settlement to lock counterparty capital while market conditions change (timeout griefing) | Appropriate timeout calibration, operator reputation/staking, multi-operator threshold | +| Supply chain tampering | Compromised hardware from manufacturing | Attestation checks, multi-vendor sourcing | ## Guarantees -- Strong privacy of state & flow. -- On-chain proof of correct execution. -- Atomicity across networks. +- **Privacy**: Counterparties, amounts, and matching logic hidden from all observers including TEE operator +- **Verifiability**: zero-knowledge proof provides on-chain verification of correct execution without TEE attestation infrastructure dependency +- **Rollback safety**: Nonce monotonicity in proofs prevents replay of old state +- **Availability**: Timeout refund ensures funds are never permanently locked, even if TEE goes offline +- **Auditability**: Selective disclosure via viewing keys for regulatory compliance ## Trade-offs -- Trust anchor in TEEs (supply chain risk). -- Performance limited by enclave capacity. -- Attestation verification infra needed. +**Failure modes and correct approach:** + +| Anti-pattern | Consequence | Correct approach | +|-------------|-------------|-----------------| +| Plaintext inputs/outputs | Network sees all data | Encrypt all I/O to TEE pubkey, per-user encryption keys | +| No rollback protection | Double-spend via old state | Nonce in state, zero-knowledge proof verifies monotonicity | +| Single TEE instance | Total unavailability on failure | Multiple TEE nodes with replicated encrypted state | +| TEE without zero-knowledge proofs | No public verifiability, must trust attestation | zero-knowledge proof of execution verified on-chain | +| Shared encryption key | One compromise leaks all data | Per-user encryption, key isolation | +| In-memory state only | Crash loses all funds | Persist encrypted state blobs + on-chain commitments | + +**Core limitations:** + +- **Privacy depends on TEE integrity, financial correctness does not**: The ZK proof guarantees settlement correctness on-chain regardless of TEE compromise. However, the TEE hardware vendor can observe plaintext during execution — a privacy breach, not a financial one. This separation is the core design tradeoff versus client-side ZK (which provides both). +- **Cross-chain atomicity is timeout-based, not cryptographic**: When coordinating across independent networks, one leg can succeed while the other fails. The timeout refund mechanism provides safety but not true atomicity. Same-network settlement remains the most practical path to atomic DvP. +- **Performance**: 10–50% overhead versus native execution. Enclave memory limits constrain batch sizes on SGX. + +**When to use this pattern vs alternatives:** + +| Scenario | TEE+ZK | Client-side ZK | Pure TEE | +|----------|--------|---------------|----------| +| Simple private transfers | Overkill | Preferred | Insufficient | +| Cross-chain coordination | Good fit | Cannot coordinate | No verifiability | +| High-frequency matching | Good fit | Too slow | No auditability | +| Institutional coordination (contractual trust) | Good fit | May suffice | Acceptable with audit layers | ## Example -- Euro stablecoin on Chain A, security token on Chain B. -- TEE matches & settles off-chain, emits zk-proof. -- Both ledgers accept update when proof verifies. +**Cross-border bond DvP with stealth address settlement:** + +1. Bank A (Frankfurt) wants to sell EUR-denominated corporate bonds to Bank B (Singapore) for USDC. Both assets exist on shielded pools on the same L1. +2. Both banks verify the TEE's attestation report and encrypt their orders (Bank A: sell 500 bond notes at par; Bank B: buy with 500K USDC) to the TEE public key. +3. TEE decrypts, validates nonces, confirms KYC attestations, matches the orders. Notes are locked to stealth addresses with 24-hour timeout refund. +4. TEE generates zero-knowledge proof of correct matching and submits on-chain. Proof verifies, TEE publishes both ephemeral keys to announcement contract. +5. Bank B derives the spending key for the bond notes, Bank A derives the key for the USDC notes. Settlement complete. +6. **Failure path**: If the TEE crashes after step 3 but before step 4, both banks reclaim their original notes via the timeout circuit after 24 hours. ## See also -- pattern-regulatory-disclosure-keys-proofs.md -- pattern-dvp-erc7573.md -- pattern-aztec-privacy-l2-erc7573.md +- [TEE-Based Privacy](pattern-tee-based-privacy.md) — general TEE trust model, failure modes, upgrade paths +- [TEE Key Manager](pattern-tee-key-manager.md) — key generation, entropy, lifecycle in TEEs +- [DvP ERC-7573](pattern-dvp-erc7573.md) — cross-network DvP coordination standard +- [ZK-SPV Cross-Chain Verification](pattern-zk-spv.md) — trustless cross-chain proof verification +- [Cross-Chain Privacy Bridge](pattern-cross-chain-privacy-bridge.md) — bridging assets between chains with privacy