# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nesa.ai/nesa/major-innovations/private-inference-for-ai/why-privacy-matters-in-decentralized-ai.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.