Proof of work
Proof of work is a form of cryptographic proof in which one party proves to others that a certain amount of a specific computational effort has been expended. Verifiers can subsequently confirm this expenditure with minimal effort on their part. The concept was first proposed by Moni Naor and Cynthia Dwork in 1993 as a way to deter denial-of-service attacks and other service abuses such as spam on a network by requiring some work from a service requester, usually meaning processing time by a computer. Extending the work of Cynthia Dwork and Moni Naor, Adam Back formally described a proof of work system called Hashcash as a protection against email spam in 1997. The term "proof of work" was first coined and formalized in a 1999 paper by Markus Jakobsson and Ari Juels. The concept was adapted to digital tokens by Hal Finney in 2004 through the idea of "reusable proof of work" using the 160-bit secure hash algorithm 1.
Proof of work was later popularized by Bitcoin as a foundation for consensus in a permissionless decentralized network, in which miners compete to append blocks and mine new currency, each miner experiencing a success probability proportional to the computational effort expended. PoW and PoS remain the two best known Sybil deterrence mechanisms. In the context of cryptocurrencies they are the most common mechanisms.
A key feature of proof-of-work schemes is their asymmetry: the work – the computation – must be moderately hard on the prover or requester side but easy to check for the verifier or service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle, or CPU pricing function. Another common feature is built-in incentive-structures that reward allocating computational capacity to the network with value in the form of cryptocurrency.
The purpose of proof-of-work algorithms is not proving that certain work was carried out or that a computational puzzle was "solved", but deterring manipulation of data by establishing large energy and hardware-control requirements to be able to do so. Proof-of-work systems have been criticized by environmentalists for their energy consumption.
Background
The concept of Proof of Work has its roots in early research on combating spam and preventing denial-of-service attacks. One of the earliest implementations of PoW was Hashcash, created by British cryptographer Adam Back in 1997. It was designed as an anti-spam mechanism that required email senders to perform a small computational task, effectively proving that they expended resources before sending an email. This task was trivial for legitimate users but would impose a significant cost on spammers attempting to send bulk messages.Hashcash's system was based on the concept of finding a hash value that met certain criteria, a task that required computational effort and thus served as a "proof of work." The idea was that by making it computationally expensive to send large volumes of email, spamming would be reduced.
One popular system, used in Hashcash, uses partial hash inversions to prove that computation was done, as a goodwill token to send an e-mail. For instance, the following header represents about 252 hash computations to send a message to
calvin@comics.net on January 19, 2038:X-Hashcash: 1:52:380119:calvin@comics.net:::9B760005E92F0DAE
It is verified with a single computation by checking that the SHA-1 hash of the stamp begins with 52 binary zeros, that is 13 hexadecimal zeros:
0000000000000756af69e2ffbdb930261873cd71
Whether PoW systems can actually solve a particular denial-of-service issue such as the spam problem is subject to debate; the system must make sending spam emails obtrusively unproductive for the spammer, but should also not prevent legitimate users from sending their messages. In other words, a genuine user should not encounter any difficulties when sending an email, but an email spammer would have to expend a considerable amount of computing power to send out many emails at once. Proof-of-work systems are being used by other, more complex cryptographic systems such as Bitcoin, which uses a system similar to Hashcash.
Evolution of proof-of-work algorithms
Proof of work traces its theoretical origins to early efforts to combat digital abuse, evolving significantly over time to address security, accessibility, and broader applications beyond its initial anti-spam purpose. The idea first emerged in 1993 as a deterrent for junk mail, but it was Satoshi Nakamoto’s 2008 whitepaper, "Bitcoin: A Peer-to-Peer Electronic Cash System," that solidified proof of work's potential as a cornerstone of blockchain networks. This development reflects the rising demands for secure, trustless systems.The earliest appearance of proof of work was in 1993, when Cynthia Dwork and Moni Naor proposed a system to curb junk email by requiring senders to perform computationally demanding tasks. In their paper, "Pricing via Processing or Combatting Junk Mail," they outlined methods such as computing modular square roots, designed to be challenging to solve yet straightforward to verify, establishing a foundational principle of proof of work's asymmetry. This asymmetry is the crucial to the effectiveness of proof of work, ensuring that tasks like sending spam are costly for attackers, while verification remains efficient for legitimate users.
This conceptual groundwork found practical use in 1997 with Adam Back’s Hashcash, a system that required senders to compute a partial hash inversion of the SHA-1 algorithm, producing a hash with a set number of leading zeros. Described in Back’s paper "Hashcash: A Denial of Service Counter-Measure," Hashcash imposed a computational cost to deter spam while allowing recipients to confirm the work effortlessly, laying a critical foundation for subsequent proof of work implementations in cryptography and blockchain technology.
Bitcoin, launched in 2009 by Satoshi Nakamoto, marked a pivotal shift by adapting Hashcash's proof of work for cryptocurrency. Nakamoto's Bitcoin whitepaper outlined a system using the SHA-256 algorithm, where miners compete to solve cryptographic puzzles to append blocks to the blockchain, earning rewards in the process. Unlike Hashcash's static proofs, Bitcoin's proof of work algorithm dynamically adjusts its difficulty based on the time taken to mine the previous block, ensuring a consistent block time of approximately 10 minutes, creating a tamper-proof chain. This innovation transformed proof of work from a standalone deterrent into a consensus mechanism for a decentralized network, emphasizing financial incentives over computational effort.
However, Bitcoin was not perfect. Miners began exploiting Bitcoin's proof of work with specialized hardware like ASICs. Initially mined with standard CPUs, Bitcoin saw a rapid transition to GPUs and then to ASIC, which vastly outperformed general hardware in solving SHA-256 puzzles. This gave ASICs miners an overwhelming advantage, rendering casual participants insignificant, which undermines Bitcoin's initial vision of a decentralized network accessible to all.
To address Bitcoin's increasing reliance on specialized hardware, proof of work evolved further with the introduction of Litecoin in 2011, which adopted the Scrypt algorithm. Developed by Colin Percival and detailed in the technical specification "The scrypt Password-Based Key Derivation Function," Scrypt was designed as a memory-intensive algorithm, requiring significant RAM to perform its computations. Unlike Bitcoin's SHA-256, which favored powerful ASICs, Scrypt aimed to level the playing field by making mining more accessible to users with general-purpose hardware through heightened memory demands. However, over time, advancements in hardware led to the creation of Scrypt-specific ASICs, shifting the advantage back toward specialized hardware and reducing the algorithm's goal for decentralization.
Variants
There are two classes of proof-of-work protocols.- Challenge–response protocols assume a direct interactive link between the requester and the provider. The provider chooses a challenge, say an item in a set with a property, the requester finds the relevant response in the set, which is sent back and checked by the provider. As the challenge is chosen on the spot by the provider, its difficulty can be adapted to its current load. The work on the requester side may be bounded if the challenge-response protocol has a known solution, or is known to exist within a bounded search space.
- Solution–verification protocols do not assume such a link: as a result, the problem must be self-imposed before a solution is sought by the requester, and the provider must check both the problem choice and the found solution. Most such schemes are unbounded probabilistic iterative procedures such as Hashcash.
Known-solution protocols tend to have slightly lower variance than unbounded probabilistic protocols because the variance of a rectangular distribution is lower than the variance of a Poisson distribution. A generic technique for reducing variance is to use multiple independent sub-challenges, as the average of multiple samples will have a lower variance.
There are also fixed-cost functions such as the time-lock puzzle.
Moreover, the underlying functions used by these schemes may be:
- CPU-bound where the computation runs at the speed of the processor, which greatly varies in time, as well as from high-end server to low-end portable devices.
- Memory-bound where the computation speed is bound by main memory accesses, the performance of which is expected to be less sensitive to hardware evolution.
- Network-bound if the client must perform few computations, but must collect some tokens from remote servers before querying the final service provider. In this sense, the work is not actually performed by the requester, but it incurs delays anyway because of the latency to get the required tokens.