Back to Store

Blockchain Attack Laboratory

Simulate and understand 4 fundamental blockchain attacks

51% Attack
Sybil Attack
Eclipse Attack
Reentrancy

51% Attack Simulation

Control majority hashpower to reorganize the chain and double-spend.

  1. Attacker begins mining secret chain fork
  2. Attacker sends TX to merchant on public chain
  3. Merchant confirms (6 blocks)
  4. Attacker reveals longer secret chain
  5. Network reorganizes — TX reversed (double-spend!)

Chain Visualization

Public Chain: 0 blocks Secret Chain: 0 blocks

Defenses

  • Wait for more confirmations (increase cost of attack)
  • Use Proof-of-Stake (no hashpower market)
  • Checkpointing by trusted parties
  • Penalize equivocation (slashing conditions)

Sybil Attack Simulation

Flood the network with fake identities to gain disproportionate influence.

  1. Network starts with 12 honest nodes
  2. Attacker creates 24 fake identities (Sybils)
  3. Sybils connect to honest nodes
  4. Sybils gain majority vote in consensus
  5. Attacker controls network decisions
Honest: 12 Sybil: 0 Control: 0%

Network View

Attacker network influence

Defenses

  • Proof-of-Work: each identity costs real resources
  • Proof-of-Stake: each identity needs capital at risk
  • Identity verification / reputation systems
  • Resource testing (computational puzzles per node)
  • Social trust graphs (vouch-based admission)

Eclipse Attack Simulation

Isolate a victim node by monopolizing all its peer connections.

  1. Identify target node and its peer slots (8 slots)
  2. Flood target with connection requests
  3. Wait for target to restart / rotate peers
  4. All slots filled with attacker nodes
  5. Target only sees attacker's view of the chain
  6. Feed target a fake chain / withhold blocks

Connection Map

Victim peers: 8/8 honest Isolated: No

Defenses

  • Diverse peer selection (random from many buckets)
  • Limit inbound connections per IP/subnet
  • Anchor connections to trusted peers
  • Monitor for sudden peer churn
  • Use multiple network transports (Tor, I2P)

Reentrancy Attack

Exploit a vulnerable withdrawal function to drain contract funds (like the DAO hack).

  1. Vulnerable contract holds 10 ETH
  2. Attacker deposits 1 ETH
  3. Attacker calls withdraw()
  4. Contract sends ETH — triggers attacker's fallback
  5. Fallback re-calls withdraw() before balance update
  6. Loop repeats — drains entire contract

Contract State

contract.balance = 10.0 ETH
balances[victim1] = 4.0 ETH
balances[victim2] = 3.0 ETH
balances[victim3] = 2.0 ETH
balances[attacker] = 1.0 ETH

Call Stack

Defenses

  • Checks-Effects-Interactions pattern
  • ReentrancyGuard mutex (OpenZeppelin)
  • Use transfer() instead of call() (2300 gas limit)
  • Pull-over-push payment pattern