NETDEX FOUNDATION
  • Introduction
  • Blockchain Challenges
    • Scale, Finalization, and Consensus
    • Decentralization vs. Functional Confirmation Times
    • Fees
    • Accessibility
    • Tokenomics
    • Reputation
  • NetDex Solutions
    • A Robust Blockchain Protocol
      • Scalability
      • Compatibility
      • Permissionless Decentralization
      • Leaderless Proof of Stake
      • Cryptography
    • Battle-Tested Security
      • Proof of Stake Security
      • Protection Against Sybil Attack
      • Protection from a Parasite Chain Attack
      • Protection Against Denial of Service Attack
      • Quantum Secure
    • Engaged Communities
      • Building Reputation
      • Engaged Tech-Literate Community
      • Engaged Wider Community
    • Resilient Economics
      • Bootstrapping
      • Deflation
      • Digital Asset Growth
  • Technical Overview
    • Netdex Chain and the Directed Acyclic Graph
    • The Lachesis Consensus Algorithm
    • Validator Node Minimum Requirements
  • Products
    • DEX
    • NFT Marketplace
    • LaunchPad
    • NetDex Metaverse
    • Cross-Chain Bridges
    • Yield Optimizers
    • Lending-Borrowing Portal
  • TOKENOMICS
    • Tokenomics
  • NETDEX
    • 🧰Privacy Policy
    • ✅Terms of Service
    • 📸Social Media
    • 📨Bug Bounty
  • More
    • 🔍Market Status
      • DeFi Market Overview
      • NFT Market Overview
Powered by GitBook
On this page
  1. NetDex Solutions
  2. Battle-Tested Security

Protection from a Parasite Chain Attack

In one variant of a Double Spending attack, the Parasite Chain attack, a malicious actor places a transaction of a specified value in the main DAG chain, while attempting to replicate this on a thread in an attempt to double-spend the tokens.

Netdex's blockchain protocol does not start with a main chain. It generates the main chain from threads of chains using a graph protocol related to network analysis in biological systems. This means that, theoretically, any thread can ultimately come to belong to the main chain. So, what prevents a malicious parasite chain from making a successful attack? 



A thread chain must have a parent chain for whom the verification of each Event Block can be successfully performed. This means that a parasite chain with a false history – the parasite thread will not be accepted unless the history it attests to reflects that of the main chain. Also, there must be a connection between the existing main chain and any thread to be added to it – preventing a parasite thread from creating a false history of Event Blocks and successfully merging. To successfully add a false history, more than 1/3rd of the nodes would have to be malicious.

PreviousProtection Against Sybil AttackNextProtection Against Denial of Service Attack

Last updated 12 months ago