> 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/nesa-docs/why-decentralized-ai-has-not-worked-yet.md). # Why Decentralized AI Has Not Worked (Yet) Decentralizing AI is not a new idea. Multiple projects and research efforts have attempted to marry AI with blockchain or peer-to-peer networks. However, existing decentralized AI (DeAI) approaches have consistently failed to meet the requirements of **trust**, **security**, and **scalability**. Many have merely replicated the shortcomings of centralized systems, or introduced new ones. Below, we examine the key limitations of past efforts, and how Nesa’s approach is fundamentally different. *** #### ❌ Limited Trust and Verification Mechanisms Most DeAI platforms still rely heavily on **off-chain computation** ([source](https://arxiv.org/abs/2505.07828)), with no robust way to verify results: * Inference is performed on nodes that users must **trust** to be honest. * Platforms like [SingularityNET](https://singularitynet.io/) or [Fetch.ai](https://fetch.ai/) may use blockchain for coordination, but the **actual computation happens off-chain**. * Users have no cryptographic assurance that the output is correct or that the model even ran as claimed.

Visualizing the interactions between offchain and onchain resources. Source: Chain Link, https://chain.link/education-hub/off-chain-data

Some networks attempt mitigation via **reputation systems**, **redundant execution**, or **escrow**, but these mechanisms introduce friction and **still do not guarantee correctness**. This is the core of the “verification dilemma”: > *It’s hard to confirm that an AI output is correct without re-running the entire computation—defeating the point of delegation.* Nesa explicitly addresses this through **zkDPS** (Zero-Knowledge Decentralized Proof System) and consensus-based verification. Either a proof of correct execution is provided, or multiple nodes must independently agree on the output. *** #### 🔐 Privacy Not Fully Preserved Many DeAI platforms claim to be privacy-preserving, but fall short in practice: * Some rely on **federated learning** or **secure multi-party computation (MPC)** to protect training data, but not inference inputs. * In many cases, users must send **raw input data** to remote nodes for inference—often operated by third parties. * Approaches based on **homomorphic encryption** remain largely impractical for large, real-time models due to extreme computational overhead. * Others explore **secure enclaves**, but these introduce hardware trust assumptions and carry performance or deployment constraints. Nesa avoids these pitfalls with a different strategy: * It builds on **Equivariant Encryption (EE)** and **HSS-EE**, which allow model inference to be performed on **encrypted embeddings** using **additive secret sharing**, without leaking raw inputs to any server. * The user locally embeds their input and splits it into shares that are **individually meaningless** to each compute node. * These shares are processed securely and efficiently, even for deep models, using **GPU-native primitives** and protocols optimized for transformer inference. > No node ever sees the full input, intermediate activations, or final output—ensuring strict confidentiality throughout the computation pipeline. This approach offers **end-to-end inference privacy** in a decentralized setting, without requiring trusted hardware or incurring FHE-level latency. *** #### 🧱 Performance and Scalability Bottlenecks Early decentralized AI systems have faced major issues scaling up: * **Blockchain-based computation** is too slow and expensive for real-world inference, so nearly all DeAI projects execute AI off-chain. * Performing inference redundantly across nodes to gain consensus **multiplies cost and latency**. * Networks like Bittensor attempt to crowdsource language model training across many participants—but performance still lags far behind centralized infrastructure. Other limitations include: * Hardware fragmentation: Many DeAI platforms require participants to run **specialized GPU nodes**, limiting network size. * Developer friction: Packaging and deploying models often demands **low-level infrastructure knowledge**. The result: **most DeAI platforms can only support toy workloads or narrow use cases.** Nesa approaches this differently: * It uses **sharded execution (BSNS)** to split models into sequential blocks, each small enough to run on modest machines. * A **uniform execution environment** ensures determinism and compatibility. * Additional optimizations (e.g., **caching**, **two-phase commit**, **VRF-based node selection**) reduce latency and coordination overhead. > Nesa is one of the first to make **large-scale, performant decentralized inference practical**, not just possible. *** #### 🧨 Summary: Why Most DeAI Platforms Fall Short In theory, decentralization solves many AI problems. In practice, most existing projects: * Fail to provide **cryptographic trust guarantees** * Compromise on **privacy** in real-world usage * Cannot handle large-scale, latency-sensitive workloads * Rely on **market dynamics** without formal checks and balances > A 2023 survey found that most “AI token” projects operate off-chain and simply add payments to conventional APIs, delivering **no real architectural innovation**. *** #### ✅ How Nesa Differs Nesa is a private, decentralized AI framework designed to address: * **Trust** — via zk-proofed or consensus-verified inference * **Privacy** — via SVE + split learning * **Scalability** — via model sharding and deterministic execution Nesa does not simply decentralize AI coordination. It **rebuilds AI execution** to be secure, verifiable, and scalable—without trusting any single node. This is why Nesa is often called: > *“AI sharding” or “the AI equivalent of a blockchain.”* By solving the open problems that plagued previous attempts, Nesa moves DeAI from prototype to infrastructure.