TEE-Assisted Network Anonymity
Hide who is sending transactions or querying state at the network layer with latency low enough for interactive workloads. Content-privacy patterns hide what is in a transaction but not who submitted it; IP addresses, timing, and query patterns still leak sender identity. A client-side Trusted Execution Environment secret-shares the outbound payload across a set of servers so that no single server sees the cleartext, and the anonymity guarantee survives a compromise of the TEE at the cost of liveness.
Hide who is sending transactions or querying state at the network layer with latency low enough for interactive workloads. Content-privacy patterns hide what is in a transaction but not who submitted it; IP addresses, timing, and query patterns still leak sender identity. A client-side Trusted Execution Environment secret-shares the outbound payload across a set of servers so that no single server sees the cleartext, and the anonymity guarantee survives a compromise of the TEE at the cost of liveness.
- Client-side Trusted Execution Environment: generates and verifies the secret-sharing of the outbound message, and attests to correct construction.
- Secret-sharing layer: splits each message into shares that can only be reconstructed by the aggregate of server contributions.
- Additive homomorphic commitments: allow servers to compute aggregate outputs over encrypted shares without decrypting any individual share.
- Anonymity server set: a semi-honest majority that processes shares, computes homomorphic sums, and forwards aggregated traffic.
- Leader node: reconstructs aggregated output from server contributions and delivers it to the destination (RPC endpoint or mempool).
Guarantees:
- Sender IP, timing correlation, and query-to-identity mapping are hidden from any single server and from downstream RPC or mempool infrastructure.
- The same infrastructure anonymizes transaction submission and state queries, so read-side and write-side metadata protection share a single deployment.
- A client Trusted Execution Environment compromise costs liveness, not anonymity: the cryptographic layer still prevents reconstruction of individual messages.
Threat model:
- Semi-honest majority among anonymity servers; a colluding majority can halt the round but still cannot reconstruct individual messages unless the TEE has also been compromised.
- Client Trusted Execution Environment integrity for liveness and for correct share construction. A compromised TEE can submit malformed shares that stall the round.
- Network-layer cover: the anonymity set is all clients active in the same round. In a low-adoption deployment, the effective guarantee degrades.
- Message content is out of scope; pair with a content-privacy pattern such as shielding or threshold encryption for a full stack.
- The anonymity trilemma of anonymity-set size, latency, and bandwidth still applies. Hardware assistance relaxes it compared to pure-cryptographic designs but does not eliminate it.
- Client Trusted Execution Environments are required on the submission path, which constrains device support and adds attestation infrastructure.
- Live deployments are research-stage; there is no production service targeting Ethereum as of 2026-04, and server-operator governance is still being defined.
- Defence in depth can pair this layer with onion routing or a mixnet when the hardware trust assumption is considered weaker than the cryptographic layer.
A fund manager needs to query balances for fifty tokens across decentralized-finance protocols to value a portfolio. Without network anonymity, the RPC provider sees all queried addresses and can infer holdings and strategy. Each query is placed into a random slot of a fixed-size array, secret-shared by the manager's client Trusted Execution Environment across the server set, and aggregated homomorphically. The RPC provider sees a batch of queries from many clients in the round and cannot attribute any single query to the manager. Latency is under a second per round, so the workflow remains interactive.