Was ist Proof of Work (PoW)
Proof of Work ist ein Konsensmechanismus, der von den Netzwerkteilnehmern (Minern) verlangt, rechenintensive Rätsel zu lösen, um Transaktionen zu validieren und neue Blöcke zur Blockchain hinzuzufügen.
Proof of Work (PoW) wurde erstmals 2008 im Bitcoin Whitepaper von Satoshi Nakamoto vorgestellt, obwohl das Konzept von Hashcash (1997) stammt. Es löst das Problem des Double-Spending, ohne dass eine vertrauenswürdige dritte Partei erforderlich ist.
Wie PoW funktioniert:
1. Miner sammeln ausstehende Transaktionen in einem Block
2. Sie hashen wiederholt den Block-Header mit verschiedenen Nonce-Werten
3. Das Ziel: Einen Hash unterhalb der Zielschwierigkeit finden (beginnt mit genügend Nullen)
4. Der erste Miner, der einen gültigen Hash findet, sendet den Block
5. Andere Nodes verifizieren und akzeptieren den Block
6. Der gewinnende Miner erhält neu erstellte Coins + Transaktionsgebühren
Sicherheitsmodell:
- Um das Netzwerk anzugreifen, benötigen Sie >50% der gesamten Mining-Leistung (51% Angriff)
- Je mehr Miner teilnehmen, desto sicherer ist das Netzwerk
- Wirtschaftliche Anreize richten die Miner auf ehrliches Verhalten aus
Schwierigkeitsanpassung:
Bitcoin passt die Schwierigkeit alle 2016 Blöcke (~2 Wochen) an, um Blockzeiten von ~10 Minuten unabhängig von der gesamten Mining-Leistung beizubehalten.
Kritik:
- Hoher Energieverbrauch (~150 TWh/Jahr für Bitcoin)
- Zentralisierung der Mining-Leistung in Regionen mit billigem Strom
- Hardware-Wettrüsten (ASIC-Dominanz)
Trotz der Kritik bleibt PoW der am besten getestete und sicherste Konsensmechanismus.
graph LR
Center["Was ist Proof of Work (PoW)"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_consensus_mechanism["consensus-mechanism"]:::related -.-> Center
click Rel_consensus_mechanism "/terms/consensus-mechanism"
Rel_proof_verification["proof-verification"]:::related -.-> Center
click Rel_proof_verification "/terms/proof-verification"
Rel_proof_of_stake["proof-of-stake"]:::related -.-> Center
click Rel_proof_of_stake "/terms/proof-of-stake"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Wissenstest
🧒 Erkläre es wie einem 5-Jährigen
It's like a giant, difficult Sudoku puzzle that miners race to solve. The first one to solve it gets to add the next page of transactions to the shared digital ledger and gets a reward, but everyone else can easily check their answer.
🤓 Expert Deep Dive
The security of Proof-of-Work is rooted in the computational difficulty and the probabilistic nature of block discovery. The [hash function](/de/terms/hash-function) used (typically SHA-256 for Bitcoin) provides pre-image resistance, second pre-image resistance, and collision resistance, ensuring that finding a valid nonce is computationally infeasible without performing the hashing work. The difficulty target is dynamically adjusted (e.g., every 2016 blocks in Bitcoin) to maintain a consistent block generation time, regardless of fluctuations in the network's total hash rate.
From a game-theoretic perspective, the Nash equilibrium incentivizes miners to act honestly. The cost of acquiring and operating the necessary hashing hardware to mount a 51% attack is substantial. The expected reward for honest mining (block reward + fees) is generally greater than the expected cost of mining, assuming a rational actor. However, the concentration of mining power in large pools presents a centralization vector.
Potential vulnerabilities include selfish mining strategies, where miners strategically withhold discovered blocks to gain an advantage, and the aforementioned 51% attack. The energy consumption is a significant environmental and economic externality. Alternative PoW variants exist, such as Proof-of-Capacity or Proof-of-Burn, which aim to reduce energy usage while maintaining security properties, though they often introduce different trade-offs regarding hardware requirements or attack vectors.