Proof of Work (PoW)
Proof of Work to mechanizm konsensusu, który wymaga od uczestników sieci (górników) rozwiązywania obliczeniowo intensywnych zagadek w celu walidacji transakcji i dodawania nowych bloków do blockchaina.
Proof of Work (PoW) został po raz pierwszy wprowadzony w whitepaperze Bitcoina z 2008 roku przez Satoshi Nakamoto, choć koncept pochodzi z Hashcash (1997). Rozwiązuje problem podwójnego wydawania bez konieczności posiadania zaufanej trzeciej strony.
Jak działa PoW:
1. Górnicy zbierają oczekujące transakcje do bloku
2. Wielokrotnie haszują nagłówek bloku z różnymi wartościami nonce
3. Cel: znaleźć hash poniżej docelowej trudności (zaczyna się od wystarczającej liczby zer)
4. Pierwszy górnik, który znajdzie poprawny hash, rozgłasza blok
5. Inne węzły weryfikują i akceptują blok
6. Zwycięski górnik otrzymuje nowo utworzone monety + opłaty transakcyjne
Model bezpieczeństwa:
- Aby zaatakować sieć, potrzebujesz >50% całkowitej mocy wydobywczej (atak 51%)
- Im więcej górników uczestniczy, tym bardziej bezpieczna jest sieć
- Ekonomiczne zachęty skłaniają górników do uczciwego działania
Dostosowanie trudności:
Bitcoin dostosowuje trudność co 2016 bloków (~2 tygodnie), aby utrzymać ~10-minutowe czasy bloków niezależnie od całkowitej mocy wydobywczej.
Krytyka:
- Wysokie zużycie energii (~150 TWh/rok dla Bitcoina)
- Centralizacja mocy wydobywczej w regionach z tanią energią elektryczną
- Wyścig zbrojeń sprzętowych (dominacja ASIC)
Pomimo krytyki, PoW pozostaje najbardziej sprawdzonym i bezpiecznym mechanizmem konsensusu.
graph LR
Center["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;
🧠 Sprawdzenie wiedzy
🧒 Wyjaśnij jak 5-latkowi
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](/pl/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.