> For the complete documentation index, see [llms.txt](https://docs.nesa.ai/nesa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nesa.ai/nesa/major-innovations/private-inference-for-ai/why-privacy-matters-in-decentralized-ai.md). # Why Privacy Matters in Decentralized AI In centralized AI systems, users implicitly trust the provider to keep their data and model execution private. But in a decentralized setting, **no such trust can be assumed**. That makes privacy preservation far more difficult—and far more important. The emergent importance of **private decentralized AI** has caught significant attention and investment, such as Intel's [Private AI Collaborative Research Institute](https://www.intel.com/content/www/us/en/research/blogs/private-ai-collaborative-research-institute-launch.html), which funded research in this direction.

Source: Intel Labs, https://www.intel.com/content/www/us/en/research/blogs/private-ai-collaborative-research-institute-launch.html

*** ### Why Privacy in Decentralized AI Is Hard Decentralized AI networks often operate on untrusted, globally distributed hardware. In this setting: * Anyone can spin up a node and receive user inputs or model fragments * Data may pass through an **unknown or adversarial infrastructure** * Model owners often want to keep their weights secret * Users need strong guarantees that **no intermediate computation leaks sensitive data** Even if communication is encrypted, once data reaches the node for computation, **exposure risk begins**. Most traditional privacy techniques focus on training—not inference—and assume trusted environments or offline processing. In decentralized inference, privacy must be enforced: * **Across untrusted compute** * **During live inference** * **Without sacrificing performance or usability** This requires an entirely different design paradigm—one where **nodes never need to see raw inputs, intermediate states, or full model logic**. *** ### Why Homomorphic Encryption (HE), Trusted Execution Environments (TEEs), Differential Privacy (DP), and Zero-Knowledge Proofs (ZKPs) Alone Don’t Work Several communities have tackled privacy using specialized tools. But none of them, on their own, solve the challenges of decentralized inference. *** #### ❌ Homomorphic Encryption (HE)

Source: Chainlink, https://chain.link/education-hub/homomorphic-encryption

**Fully Homomorphic Encryption (FHE)** allows arbitrary computation on encrypted data. In theory, this could enable privacy-preserving inference without exposing inputs or model internals. But in practice: * Even state-of-the-art FHE schemes introduce **4–6 orders of magnitude overhead** over plaintext execution * Deep models (e.g., Transformers or ResNets) involve **nonlinear operations** and large matrix multiplications that are **prohibitively slow or unsupported in FHE** * Most FHE frameworks only support basic arithmetic operations, requiring **approximation of activation functions**, which degrades model fidelity * Batch sizes are constrained by ciphertext packing limitations, further reducing throughput > FHE remains **theoretically elegant** but **computationally impractical** for real-time inference on large models. *** #### ❌ Trusted Execution Environments (TEEs)

Source: Samsung, https://developer.samsung.com/blockchain/keystore/understanding-keystore/keystore-architecture.html

TEEs execute code in hardware-isolated memory regions, shielding it from the rest of the system. Intel SGX and AMD SEV are common examples. However, TEEs are **not well-suited to large-model inference** for several reasons: * **Limited memory and compute capacity**: most enclaves cannot handle LLMs or vision models due to size constraints (e.g., 128–512MB secure memory) * **Hardware trust assumptions**: users must trust the CPU vendor, firmware supply chain, and enclave verification process * **Vulnerability to side-channel and rollback attacks**, especially under concurrent workloads * **Incompatibility with decentralized networks**, where not all nodes have TEE hardware > TEEs shift the trust surface from the node operator to the hardware vendor—**not a full solution for adversarial settings**. *** #### ❌ Differential Privacy (DP) Differential Privacy introduces controlled randomness to outputs to ensure individual data points are not statistically identifiable. It is widely used in **training-time privacy** (e.g., DP-SGD). But in decentralized inference: * DP does **not apply to individual inputs**, which are processed directly * It **cannot prevent raw input or intermediate leakage** if a node is compromised * Adding DP noise during inference **can degrade output quality**, especially for deterministic tasks (e.g., document classification, image captioning) > DP is a training-level guarantee—**not a usable protection for query-time privacy or model confidentiality**. *** #### ❌ Zero-Knowledge Proofs (ZKPs) ZKPs can prove that a computation was performed correctly without revealing inputs or model parameters. This is essential for **verifiability**—but not sufficient for privacy: * ZKPs typically assume **inputs are known** to the prover; they do not hide inputs by default * Generating ZK proofs for large neural networks (e.g., 100M+ parameters) is **computationally expensive and memory intensive** * For modern transformers, proving even a few layers takes **seconds to minutes**, making real-time serving infeasible * ZKPs cannot protect **data in use**—only the final output's correctness > ZKPs are powerful for validation, but must be **paired with encryption or secure execution** to achieve full privacy. *** ### Summary | Technique | Protects Input? | Verifies Correctness? | Scales to LLMs? | Drawbacks | | ----------------------- | --------------- | --------------------- | ----------------- | ------------------------------------------ | | Homomorphic Encryption | ✅ | ❌ | ❌ | 10⁴–10⁶× slowdown; limited ops | | Trusted Execution (TEE) | ✅ (assumed) | ❌ | ❌ | Vendor trust, memory limits, side-channels | | Differential Privacy | ❌ | ❌ | ✅ (training only) | Doesn't apply to inference-time privacy | | Zero-Knowledge Proofs | ❌ | ✅ | ❌ | Costly; needs external encryption | > **No single method solves privacy and verification for large-model decentralized inference.**\ > Only a hybrid stack—combining lightweight encrypted computation with secure sharing and verifiable proofs—can satisfy all constraints. *** ### Summary Each of these approaches offers partial value, but none alone solve the core challenge of decentralized inference: > *How can we compute on user data across untrusted nodes—without ever exposing the input, model, or output—and still verify that the result is correct?* The rest of this section introduces **Nesa’s cryptographic stack**, designed to solve exactly that.