What Security Threats Does Blockchain Face? Detailed Explanation of 51% Attacks, Double Spending, and Smart Contract Vulnerabilities

Blockchain Security Overview

Although blockchain has cryptographic protection, it still faces various security threats. Understanding these threats is crucial for developing and operating secure blockchain applications.

Main Security Threat Categories

shell
Blockchain Security Threats
├── Network Layer Attacks
│   ├── 51% Attack
│   ├── Double Spending
│   └── Eclipse Attack
├── Smart Contract Vulnerabilities
│   ├── Reentrancy
│   ├── Integer Overflow
│   ├── Access Control Vulnerabilities
│   └── Front-running
└── Application Layer Attacks
    ├── Phishing
    ├── Private Key Leakage
    └── Exchange Hacks

1. 51% Attack (Majority Attack)

Attack Principle

When an attacker controls more than 50% of network hashrate (PoW) or staked tokens (PoS), they can:

• Prevent transaction confirmation
• Reverse confirmed transactions
• Prevent other miners from mining

shell
Normal Network:              51% Attack:
┌─────┐ ┌─────┐ ┌─────┐      ┌─────┐ ┌─────┐ ┌─────┐
│ 20% │ │ 30% │ │ 50% │      │ 20% │ │ 30% │ │ 50% │ ← Attacker controls
│MinerA│ │MinerB│ │MinerC│      │MinerA│ │MinerB│ │Attacker│
└─────┘ └─────┘ └─────┘      └─────┘ └─────┘ └─────┘
                                    ↓
                              Can decide which block is confirmed

Real Cases

Time	Project	Loss
2018-05	Bitcoin Gold	$18 million
2019-01	Ethereum Classic	$1.1 million
2020-08	Ethereum Classic	Attacked again

Protection Measures

• ✅ Increase network total hashrate/stake
• ✅ Require higher confirmation counts
• ✅ Implement checkpoint mechanisms
• ✅ Adopt hybrid consensus mechanisms

2. Double Spending

Attack Principle

Spending the same funds twice by exploiting blockchain confirmation delays.

shell
Double Spending Process:

Attacker ──┬──→ Merchant A: Pay 10 BTC for goods (Tx A)
           │
           └──→ Merchant B: Pay the same 10 BTC (Tx B)
           
Steps:
1. Broadcast Tx A to network
2. Merchant A ships goods after seeing transaction
3. Attacker quickly broadcasts Tx B
4. Attacker controls miners to prioritize Tx B
5. Tx A becomes orphaned
6. Attacker gets goods without actual payment

Attack Types

Type	Description	Difficulty
Race Attack	Broadcast two conflicting transactions simultaneously	Low
Finney Attack	Miner mines block first then broadcasts	Medium
Vector76	Combines Race and Finney	Medium
51% Attack	Control majority hashrate to reorg chain	High

Protection Measures

• ✅ Wait for multiple confirmations (Bitcoin recommends 6)
• ✅ Use payment processors to detect anomalies
• ✅ Require more confirmations for high-value transactions

3. Eclipse Attack

Attack Principle

Attacker controls all network connections of victim node, making it only see the blockchain view controlled by attacker.

shell
Normal Network Connection:    After Eclipse Attack:
┌─────┐                     ┌─────┐
│Node │──┬── Honest Node 1   │Node │── Attacker Node 1
│     │  ├── Honest Node 2 → │     │── Attacker Node 2
│     │  └── Honest Node 3   │     │── Attacker Node 3
└─────┘                     └─────┘
     (Sees real network)        (Only sees attacker's chain)

Attack Consequences

• Miners waste hashrate on isolated chain
• Merchants accept invalid transactions
• Double spending attacks become easier

Protection Measures

• ✅ Limit connections from single IP
• ✅ Randomly select peer nodes
• ✅ Use hardcoded seed nodes

4. Smart Contract Security Vulnerabilities

Reentrancy

The DAO Incident (2016): Loss of 3.6 million ETH

solidity
// Vulnerable code
function withdraw() public {
    uint256 amount = balances[msg.sender];
    require(amount > 0);
    (bool success, ) = msg.sender.call{value: amount}(""); // External call
    require(success);
    balances[msg.sender] = 0; // State update after
}

// Attacker contract
contract Attacker {
    function attack() external {
        victim.withdraw(); // Trigger reentrancy
    }
    
    receive() external payable {
        if (address(victim).balance >= amount) {
            victim.withdraw(); // Recursive call
        }
    }
}

Protection Measures:

• Checks-Effects-Interactions pattern
• Use ReentrancyGuard
• Update state before transferring

Integer Overflow/Underflow

solidity
// Vulnerable code (Solidity < 0.8)
function transfer(address to, uint256 amount) public {
    balances[msg.sender] -= amount; // Underflow!
    balances[to] += amount;
}

// Attack: when amount > balances[msg.sender]
// balances[msg.sender] becomes extremely large

Protection Measures:

• Use Solidity 0.8+ (built-in checks)
• Use SafeMath library

5. Front-running

Attack Principle

Attacker monitors mempool, discovers profitable transactions, then pays higher Gas Price to execute first.

shell
Attack Process:

1. User broadcasts transaction: Buy token A on DEX
   Gas Price: 20 Gwei
   
2. Attacker monitors transaction
   
3. Attacker broadcasts same transaction
   Gas Price: 30 Gwei ← Higher, prioritized
   
4. Attacker's transaction executes first, token price rises
   
5. User's transaction executes later, buys at higher price
   
6. Attacker sells for profit

Protection Measures

• ✅ Use Commit-Reveal pattern
• ✅ Set slippage protection
• ✅ Use private mempools like Flashbots

Security Best Practices

Development Level

1. Code Audits: Professional audit before deployment
2. Formal Verification: Use tools to verify critical logic
3. Test Coverage: Unit tests + Integration tests + Fuzzing
4. Use Standard Libraries: OpenZeppelin Contracts
5. Bug Bounties: Establish vulnerability reward programs

Operations Level

1. Multi-sig Wallets: Critical operations require multiple approvals
2. Timelocks: Important operations have delayed execution
3. Monitoring Alerts: Real-time monitoring of anomalous transactions
4. Emergency Response: Emergency pause and fund recovery plans

Interview Key Points

• Understand principles and consequences of 51% attacks
• Master types and protections of double spending attacks
• Familiar with common smart contract vulnerabilities and protections
• Understand mechanisms of front-running attacks
• Know blockchain security best practices
• Able to analyze real security incidents (e.g., The DAO)